SOFTWARE ENGINEERING LECTURE 4

1. SOFTWARE ENGINEERING LECTURE 4 • In this lecture:- Use cases

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. A USE CASE 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) • 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) • Use Case Name - idenifies 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 • Preconditions - when can the use case take place- can be another use case - to be continued …

6. ELEMENTS OF A USE CASE (2) • DESCRIPTION - the story • Exceptions • Illustrations • Postconditions - conditions which must hold after the use case

7. EXAMPLE REVISITED (1) 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. EXAMPLE REVISITED (2) 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] 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: ...

9. USE CASES - FOR WHAT? • To give concrete examples of the things we are supposed to be implementing. • To give a little more flesh to the requirements specification. • A source for object analysis • The first version of the user’s guide • The basis of system testing

10. USE CASES - RULE 1 • USE CASES MUST SPECIFY THE MOST IMPORTANT FUNCTIONAL REQUIREMENTS • For each functionality specified in the requirements there should be one or more use cases.

11. USE CASES - RULE 2 • USE CASES ARE USED TO SPECIFY THE SYSTEM IN MORE DETAIL, BUT THEY CAN ALSO GIVE RISE TO NEW REQUIREMENTS. • 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.

12. USE CASES - RULE 3 • A USE CASE DESCRIBES SOMETHING THAT THE DESIGNER CAN BE PROUD OF AND THE CUSTOMER IS WILLING TO PAY FOR. • 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. • Each use case must be beneficial to the end user as such.

13. USE CASES - RULE 9 (sorry about the order :) • 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 ”Exception” section.

14. USE CASES - RULE 4 • A USE CASE IS A PLAY. • And you should be able to be one of the actors if you read the use case. • Too much freedom to the actors results in chaos. • In system testing the tester reads the use case through the manuscript.

15. USE CASES - RULE 5 • A USE CASE HAS A BEGINNING, A MAIN BODY, AND AN ENDING. • So, it 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.

16. USE CASES - RULE 6 • A USE CASE IS LIKE AN ESSAY WRITTEN BY AN ELEMENTARY SCHOOL PUPIL • Simple and straightforward • 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.” • A software designer may easily try to cover every possibility in the story. • If you do not know something, you can refine it later, but do not leave the initial use case too vague.

17. USE CASES - RULE 7 • A 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.

18. RULE 8: A USE CASE IS LOUD & CLEAR • A use case must make a clear statemnt. • It must be explicit to the readers. • 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.

19. RULE 10: USE USE CASES FOR DEVELOPMENT & TESTING • Use cases should be specified so that they can be used in object and behaviour analysis. And they should be used there, too. • Also, the use cases should be so explicit that they can be used as the basis of system test cases. And they should be used there, too.

20. 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 will 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 modified later, but it will produce extra work. • Make enough use cases!