Requirements capture Using UML Use Cases David Millard

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

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

The Big Software Engineering Picture

Software Engineering: Big Picture Requirement s Gathering • Surveys • User studies • Focus groups Specification • UML • Use Cases • Scenarios • Storyboards Design • UML • Class Diagrams • Activity Diagrams • Sequence Diagrams • Etc… Implementati on • 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

Software Engineering: Big Picture Requirement s Gathering • Surveys • User studies • Focus groups Specification • UML • Use Cases • Scenarios • Storyboards From a problem statement to starting to find a solution – Requirements Capture Design • UML • Class Diagrams • Activity Diagrams • Sequence Diagrams • Etc… Implementati on • 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

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

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

Use Case Descriptions

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

Anatomy of a Use Case Description Use Case Name Scope (system boundary) Process sale What is the system? POS system Stakeholders The stakeholder in a role that initiates an interaction Cashier with the system to achieve a goal Cashier Who are the other stakeholders: other people or Customer organisations who have an interest in this? Company Preconditions hashas to authenticated happen beforethe thiscashier use can occur? The. What system Main success scenario (system happiness) 1. 2. 3. 4. Primary Actor Customer arrives at POS checkout with items to buy Cashier starts new sale Cashier scans new item (enters ID) System records item, displays price and calculates What happens running total in the usual sequence that we would expect to see? 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 Extensions What are the alternative things that can happen (for Other success failure scenarios ? example, if or something goes wrong)?

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

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

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

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

Use Case Diagrams

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

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

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

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

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

Use Case Diagram Anatomy Anyone or anything with behaviour that gets value from interacting with the system Actor Use Case 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 includes Shows that one use case always includes a second use case extends Shows that one use case is a sometimes done as a variation of a second use case

Break

The Process of Use Case Modeling

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.

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

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

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

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 Submit Coursework Obtain Receipt Student View Assignment Create Assignment Lecturer Duplicate Assignment

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 Submit Coursework Obtain Receipt Student View Assignment Create Assignment Lecturer Duplicate Assignment

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 Submit Coursework Obtain Receipt Student View Assignment Create Assignment Lecturer Duplicate Assignment

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

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

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