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?

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. 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. 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. 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. 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. 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.

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. 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. 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. UML • We will use UML (Unified Modelling Language) in some of the examples of the course. The slides will introduce some of the necessary notation. • UML is a language, which has been obtained by merging different languages and features, some made for equal purposes, and therefore one should not aim for using all of UML in a software project. Much rather, pick what you need.

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. The Salary Raise Example Salary system Raise asalary User

14. Several use cases Vehicle rental system Booking Using Returning <<include>> Official Customer Service

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. 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. 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. 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. 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. 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. 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!