1. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 1 USE CASES In this lecture: Use cases - What are use cases? - Why to use use cases? - How to write use cases? - What use cases are good for?

2. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 2 Use Cases - Why? The users are usually not able to produce sufficient formal descriptions of the functionalities. A simple list of the required functionalities is not good enough. The informal general description by the users hardly does the job, either. The users may be able to describe by examples how they would want to use the system or how they perform certain tasks.

3. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 3 An Example: Raising A Salary ”The user finds the salary data of the employee whose salary is to be raised. The user chooses the ”raise salary” functionality. The system raises a dialogue into which the user types the percentage and commits the raise.” It may be possible to specify preconditions and postconditions and exceptions to the processing of a use case. The example above had none of them.

4. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 4 A Definition ”When a user uses the system, she or he will perform a behaviourally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.” … ”A use case is a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system.” (I. Jacobsen) –The word ”transaction” does not mean exactly the same as the technical term ”transaction” in database terminology. A use case is a story about the usage of the system told from an end user’s perspective.

5. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 5 Elements Of A Use Case (1/2) Use Case Name - identifies the use case Version Summary - What is it all about? Frequencey - How often the use case is performed? Usability Requirements - The most important aspects ensuring that the use case can be performed safely and efficiently Actors - The role of the people and other systems interacting with the system - to be continued …

6. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 6 Elements Of A Use Case (2/2) Preconditions - When can the use case take place? - can be another use case Description – The story! Exceptions Illustrations Postconditions - Conditions which must hold after the use case

7. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 7 Example Revisited (1/3) Name: SalaryRaise Version: 0.9 Summary: User raises an employees salary Frequencey: 5 times per day Usability Requirements: Actors: The user, the employee database Preconditions: The user has the rights to search and modify the employees salary data.

8. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 8 Example Revisited (2/3) Description: The user finds the salary data of the employee whose salary is to be raised by employee number. [Exception: Employee not found] The user chooses the ”raise salary” functionality.[Exception: No rights to raise salary] The system raises a dialogue into which the user types the percentage and commits the raise [Exception: Maximum salary exceeded]

9. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 9 Example Revisited (3/3) Exceptions: - Employee not found: Raised if no employee data can be found with the given number. Error information is shown. - No rights to raise the salary. Raised if the user has no rights to update salary data for this employee. Error information is shown. - Maximum salary exceeded: …

10. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 10 What Can Use Cases Be Used For? To give concrete examples of the things we are supposed to be implementing. To give more flesh to the requirements specifications. As a source for analysis phase As input for the user’s guide As the basis for system testing

11. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 11 UML We will use UML (Unified Modelling Language) in object-oriented modelling in this course. I will introduce some of the diagrams when they are first needed. There will also be a lecture to cover the rest. UML is a collection of modelling languages. They are not all meant to be used together. Instead, a suitable set of languages should be chosen.

12. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 12 UML Use Case Diagram A use case diagram represents use cases and the participating actors external to the system. A use case may also include (use) another use case – this is represented as an arrow. If a use case diagram gets too large, it may be divided into logical collections of use cases.

13. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 13 Raise a salary User Salary system The Salary Raise Example

14. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 14 Booking Returning Service Customer Official > Vehicle rental system Using A Larger Example

15. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 15 Use Cases As A Part Of The Requirements Specification Use cases should specify the most important functional requirements For each functionality specified in the requirements there should be one or more use cases. In principle, the use cases are used to clarify the functional specifications and to show how different functional specifications relate to each other. However, by reading through the use cases it may be possible to identify system components (hardware and software) which have been neglected in the requirements specification.

16. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 16 What Should Be Chosen As A Use Case? Meaningful for implementation Valuable for the user (or customer) as such Too broad use cases are either too complex to understand or too vague to be useful. Too narrow use cases are either too detailed or describe fairly trivial events.

17. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 17 A Use Case Is Just An Example A use case depicts a typical way of using the system - but nothing more. The use cases are not meant to describe all ways to peform one task. Other ways can be described in other use cases or in the ”Exceptions” section. A software designer may easily try to cover every possibility in the story. This is not meant to be done here.

18. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 18 Stylistic Issues For Use Cases Try to read the use case through – if you get stuck, the use case is probably too vague. A use case should be a complete story, which starts from somewhere and ends up somewhere. It must make clear how and when it starts and how and when it finishes. A use case should have an explicit flow of actions: ”I took the pizza from the fridge and put it in the microwave. I set the time to 2 minutes and put it on. When it was ready I took it out and ate it.”

19. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 19 More Stylistic Issues A use case must be simple and straightforward It must be so explicit that it can be argued about. If nobody disagrees with the first version of a use case, it is probably too vague.

20. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 20 How Long Should A Use Case Be? A rule of thumb: It is usually good if the use case fits in one page. Long use cases are hard to understand. They may be too detailed or they try to cover too much functionality. In the latter case you may be able to break up the use case into several use cases.

21. 15.1.2003Software Engineering 2003 Jyrki Nummenmaa 21 How To Find The Use Cases? You (as the analyst) are not supposed to invent them, as they express the way the users intent to do things. So, you must identify the functionalities and talk with the users. Use cases are simple, the users should be able to provide you with the stories. You can discuss these stories and try to find out if things could/should be done differently. The use cases can be refined and modified later, but it will produce extra work. Make enough use cases!