USE CASES

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? Software Engineering 2004 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. Software Engineering 2004 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. Software Engineering 2004 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. Software Engineering 2004 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 … Software Engineering 2004 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 Software Engineering 2004 Jyrki Nummenmaa

7. Example Revisited (1/3) Name: SalaryRaise Version: 0.9 Summary: User raises an employees salary Frequency: 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. Software Engineering 2004 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] Software Engineering 2004 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: … Software Engineering 2004 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 Software Engineering 2004 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. Software Engineering 2004 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. Software Engineering 2004 Jyrki Nummenmaa

13. The Salary Raise Example Salary system Raise asalary User Software Engineering 2004 Jyrki Nummenmaa

14. A Larger Example Vehicle rental system Booking Using Returning <<include>> Official Customer Service Software Engineering 2004 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. Software Engineering 2004 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. Software Engineering 2004 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. Software Engineering 2004 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.” Software Engineering 2004 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. Software Engineering 2004 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. Software Engineering 2004 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! Software Engineering 2004 Jyrki Nummenmaa