1. Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem, ymh}@ecs.soton.ac.uk

2. Overview The Big Software Engineering Picture Use Cases Descriptions ▫The Anatomy of a Use Case ▫An Example Use Case Diagrams ▫The Anatomy of a Use Case Diagram ▫The includes and extends relationship Use Case Modeling ▫An example

3. The Big Software Engineering Picture

4. Software Engineering: Big Picture Requirements Gathering Surveys User studies Focus groups Specification UML Use Cases Scenarios Storyboard s Design UML Class Diagrams Activity Diagrams Sequence Diagrams Etc… Implementation Software code APIs Document formats Testing Unit Tests Black Box Tests Etc… Deployment Configuration Bug Tracking User Support This is rarely a straightforward progression – in reality there are lots of iterations and points of feedback

5. Software Engineering: Big Picture Requirements Gathering Surveys User studies Focus groups Specification UML Use Cases Scenarios Storyboard s Design UML Class Diagrams Activity Diagrams Sequence Diagrams Etc… Implementation Software code APIs Document formats Testing Unit Tests Black Box Tests Etc… Deployment Configuration Bug Tracking User Support This is rarely a straightforward progression – in reality there are lots of iterations and points of feedback From a problem statement to starting to find a solution – Requirements Capture

6. Requirements Capture: What is the Challenge? Requirements Gathering Surveys User studies Focus groups Specification UML Use Cases Scenarios Storyboards

7. Requirements Gathering Surveys User studies Focus groups Specification UML Use Cases Scenarios Storyboards Users don’t always know what they want They often need help to innovate They may have conflicting requirements They may not have a complete picture They use the language of their mini-world (domain) ▫Not necessarily the same language as technologists ▫It may be imprecise and contextual

8. Use Case Descriptions

9. Use Cases A structured textual description Captures a more formal view of a user’s interaction with a system From the User’s point of view Use cases model ▫A collection of use cases ▫Define what the system should do ▫And shows who uses (benefits from) the system They are useful because they ▫Capture fuzzy user requirements in a more precise way ▫Provide a basis for testing

10. Anatomy of a Use Case Description Use Case NameProcess sale Scope (system boundary)POS system Primary ActorCashier StakeholdersCashier Customer Company PreconditionsThe system has authenticated the cashier Main success scenario (system happiness)1.Customer arrives at POS checkout with items to buy 2.Cashier starts new sale 3.Cashier scans new item (enters ID) 4.System records item, displays price and calculates running total Cashier repeats 3 and 4 until all items scanned 5. System displays total 6.Customer inserts card in reader, enters PIN 7.Cashier completes sale 8.System logs sale and updates stock inventory ExtensionsOther success or failure scenarios ? What is the system? What happens in the usual sequence that we would expect to see? The stakeholder in a role that initiates an interaction with the system to achieve a goal Who are the other stakeholders: other people or organisations who have an interest in this? What has to happen before this use case can occur? What are the alternative things that can happen (for example, if something goes wrong)?

11. Anatomy of a Use Case Description Use Case NameProcess sale Scope (system boundary)POS system Primary ActorCashier StakeholdersCashier Customer Company PreconditionsThe system has authenticated the cashier Main success scenario (system happiness)1.Customer arrives at POS checkout with items to buy 2.Cashier starts new sale 3.Cashier scans new item (enters ID) 4.System records item, displays price and calculates running total Cashier repeats 3 and 4 until all items scanned 5. System displays total 6.Customer inserts card in reader, enters PIN 7.Cashier completes sale 8.System logs sale and updates stock inventory ExtensionsOther success or failure scenarios ? Use Case Scenario A customer arrives at a checkout with a basket of items to buy. The cashier uses a Point-of-Sale system to scan each item. The POS system records a running total and line-item details. The customer pays for the total bill using a debit card, entering their PIN to authorise the payment. The system updates the stock levels. The Customer leaves

12. Anatomy of a Use Case Description Use Case NameProcess sale Scope (system boundary)POS system Primary ActorCashier StakeholdersCashier Customer Company PreconditionsThe system has authenticated the cashier Main success scenario (system happiness)1.Customer arrives at POS checkout with items to buy 2.Cashier starts new sale 3.Cashier scans new item (enters ID) 4.System records item, displays price and calculates running total Cashier repeats 3 and 4 until all items scanned 5. System displays total 6.Customer inserts card in reader, enters PIN 7.Cashier completes sale 8.System logs sale and updates stock inventory ExtensionsOther success or failure scenarios ?

13. Use Case NameProcess sale Scope (system boundary)POS system Primary ActorCashier StakeholdersCashier Customer Company PreconditionsThe system has authenticated the cashier Main success scenario (system happiness)1.Customer arrives at POS checkout with items to buy 2.Cashier starts new sale 3.Cashier scans new item (enters ID) 4.System records item, displays price and calculates running total Cashier repeats 3 and 4 until all items scanned 5. System displays total 6.Customer inserts card in reader, enters PIN 7.Cashier completes sale 8.System logs sale and updates stock inventory ExtensionsOther success or failure scenarios Anatomy of a Use Case Description 1.Scan failure: item ID not in system - Enter item id manually 2.Customer PIN not valid - Call manager 3.Customer pays by cash - Cashier accepts cash 1.Scan failure: item ID not in system - Enter item id manually 2.Customer PIN not valid - Call manager 3.Customer pays by cash - Cashier accepts cash

14. In Summary Cockburn says: ▫A Use Case captures a contract with the stakeholders of a system about its behaviour ▫The Use Case describes how the system reacts to a request from a primary actor in order to achieve a goal ▫Use cases are essentially textual  There will be a whole collection of use cases for a given system ▫A collection of use cases can be shown together in a Use Case Diagram

15. Use Case Diagrams

16. A Use Case Diagram At it’s simplest a use case diagram shows an Actor interacting with a Use Case Student Submit Coursework

17. A Use Case Diagram Several actors can interact with different use cases in the same System Student Lecturer Submit Coursework Create Assignment Handin System

18. A Use Case Diagram Actors can share the same use case Student View Assignment Lecturer Submit Coursework Create Assignment Handin System

19. A Use Case Diagram One use case can include another use case to show that this is always included in its function Student View Assignment Lecturer Submit Coursework Create Assignment Handin System Obtain Receipt Obtain Receipt includes

20. A Use Case Diagram One use case can extend another use case to show that there is sometimes a variation Student View Assignment Lecturer Submit Coursework Create Assignment Handin System Duplicate Assignment Obtain Receipt Obtain Receipt extends includes

21. Use Case Diagram Anatomy Actor Use Case includes extends System Anyone or anything with behaviour that gets value from interacting with the system A description of a user’s goal – normally starts with a verb Shows the system boundary (and gives the system a name) Connects an Actor with a Use Case Shows that one use case always includes a second use case Shows that one use case is a sometimes done as a variation of a second use case

22. Break

23. The Process of Use Case Modeling

24. Use Case Modeling 1 Start from a scenario ▫Find Stakeholders and Actors ▫Find use cases  Noun analysis  Verb analysis Very similar to identifying modules ▫Use Cases are effectively a modular users view A handin system allows Lecturers to set assignments (or duplicate assignments from previous years). Students can look at assignments and using the system can hand in their coursework. They get a receipt for each coursework they hand in.

25. Use Case Modeling 1 Start from a scenario ▫Find Stakeholders and Actors ▫Find use cases  Noun analysis  Verb analysis Very similar to identifying modules ▫Use Cases are effectively a modular users view A handin system allows Lecturers to set assignments (or duplicate assignments from previous years). Students can look at assignments and using the system can hand in their coursework. They get a receipt for each coursework they hand in. Stakeholders

26. Use Case Modeling 1 Start from a scenario ▫Find Stakeholders and Actors ▫Find use cases  Noun analysis  Verb analysis Very similar to identifying modules ▫Use Cases are effectively a modular users view A handin system allows Lecturers to set assignments (or duplicate assignments from previous years). Students can look at assignments and using the system can hand in their coursework. They get a receipt for each coursework they hand in. Stakeholders Nouns

27. Use Case Modeling 1 Start from a scenario ▫Find Stakeholders and Actors ▫Find use cases  Noun analysis  Verb analysis Very similar to identifying modules ▫Use Cases are effectively a modular users view A handin system allows Lecturers to set assignments (or duplicate assignments from previous years). Students can look at assignments and using the system can hand in their coursework. They get a receipt for each coursework they hand in. Stakeholders Nouns Verbs

28. Use Case Modeling 2 Having sorted out the actors and use cases - Structure the use case model using analysis ▫Find common or independent functionality in use cases and make them a separate use case ▫Find variations of use cases that can be grouped Student View Assignment Lecturer Submit Coursework Create Assignment Duplicate Assignment Obtain Receipt Obtain Receipt

29. Use Case Modeling 2 Having sorted out the actors and use cases - Structure the use case model using analysis ▫Find common or independent functionality in use cases and make them a separate use case ▫Find variations of use cases that can be grouped Student View Assignment Lecturer Submit Coursework Create Assignment Duplicate Assignment Obtain Receipt Obtain Receipt

30. Use Case Modeling 2 Having sorted out the actors and use cases - Structure the use case model using analysis ▫Find common or independent functionality in use cases and make them a separate use case ▫Find variations of use cases that can be grouped Student View Assignment Lecturer Submit Coursework Create Assignment Duplicate Assignment Obtain Receipt Obtain Receipt

31. Use Case Modeling 3 Bring this together in a use case diagram ▫Include the system boundary ▫Use includes and extends as appropriate Student View Assignment Lecturer Submit Coursework Create Assignment Duplicate Assignment Obtain Receipt Obtain Receipt Handin System extends includes

32. Now your turn! In groups of 3-4 look at this scenario Perform a noun verb analysis ▫Identify Actors ▫Identify Use Cases Perform a use case analysis ▫Look for common functions (includes) ▫Look for variations (extends) ▫Draw a Use Case Diagram “A brasserie wants a new system to improve the process of reserving and allocating tables. They want a phone receptionist to be able to check current bookings, make new reservations and cancel old ones. A waiter uses the same system to record the arrival of pre-booked customers, and they can also use the system to transfer them to alternative tables if the customer is unhappy. Sometimes a customer walks in from the street, in which case the waiter can use the system to check availability and allocate them a table.”

33. Summary A Use Case describes a users interaction with a system ▫Captures system requirements from the user point of view A Use Case Description ▫Is a structured textual description of that interaction ▫Identifies actors, stakeholders and preconditions ▫Includes main (success) scenario and alternatives A Use Case Diagram ▫Shows (many) actors interacting with (many) use cases in a system ▫Use cases can be related using:  Includes (always includes this other use case)  Extends (sometimes this other use case happens instead) Use Cases are useful at capturing requirements because: ▫Helps to share mental models ▫Bridge the technical and domain divide