Use Cases Descriptions and Use Case Models

1. Use Cases Descriptions and Use Case Models

2. Objectives • To explain what use case descriptions are • To specify the contents of use case descriptions • To present a use case description writing process • To present heuristics for use case descriptions • To explain the relationship between use cases and requirements • To explain what use case models are • To explain how to design with use case models • To outline how to use use cases in iterative development

3. Topics • Use case descriptions, their formats, and their contents • Writing use case descriptions • Use case description heuristics • Use case descriptions and requirements • Use case models • Designing with use case models • Use-case-driven iterative development

4. Use Case Descriptions • What each party does • The order in which each party acts • All possible courses of interaction: complex activity flows A use case description is a specification of the interaction between a product and the actors in a use case.

5. Use Case Description Contents 1 • Use case name and number • Actors • Stakeholders and their needs • Preconditions—A precondition is an assertion that must be true when an activity or operation begins. • Not checked by the use case • Postconditions—A postcondition is an assertion of what must be true when an activity or operation ends. • Must satisfy stakeholder needs

6. Use Case Description Contents 2 • Trigger—A trigger is an event that causes a use case to begin. • May be the first step in the use case • Basic flow • An action flow: a list of steps • Documents a standard, successful interaction • Begins at the trigger, continues until the use case ends • Extensions • Alternative action flows • May begin and end anywhere • Extensions may have extensions

7. Car Wash Example – Part 1 Use Case 2: Activate/Deactivate Actors: Soap sensor Stakeholders and needs: Customers—Need their cars washed with soap, and want a complete wash Operations—Want the carwash to operate without constant attention Preconditions: None Postconditions: The carwash is active if and only if the soap sensor indicates that there is soap. No wash currently in progress is interrupted.

8. Car Wash Example – Part 2 • Trigger: One minute has passed since the last time the soap sensor was checked. • Basic Flow: • The carwash queries the soap sensor. • The soap sensor indicates that there is soap. • If the carwash is active, it continues its operation and the use case ends. • Extensions: • 1a: The carwash is unable to query the soap sensor: • 1a1. The controller logs the problem and the use case ends.

9. Car Wash Example – Part 3 Extensions (continued): 2a: The soap sensor indicates that there is no more soap: 2a1. If the carwash is inactive, the use case ends. 2a2. If the carwash is active, the controller displays an out-of- order message and becomes inactive; the use case ends. 2b: The soap sensor does not respond: 2b1. The controller logs the problem. 2b2. If the carwash is inactive, the use case ends. 2b3. If the carwash is active, the controller displays an out-of- order message and becomes inactive; the use case ends. 2a2, 2b3: A wash is in progress: 2a21. The carwash completes the current wash, then displays an out-of-order message; the use case ends. 3a: The carwash is inactive: 3a1. The carwash becomes active and displays a ready message.

10. Use Case Description Formats • Many alternatives • “Fully-dressed” format • Underlined text refers to another use case. • Extensions use a special numbering scheme: • Numbers are for action step sequencing; • Letters are for extension triggers; • Extension identifiers have interleaved numbers and letters; • An asterisk refers to all action steps; • A dash is used for ranges of action steps; • A comma separates action steps in a list.

11. Use Case Description Template

12. Description Writing Process

13. Filling in the Initial Fields • Stakeholders are human use case actors or anyone with an interest to protect. • Only state things that really matter as use case preconditions. • Postconditions must be true when the use case ends whether it is successful or not. • The trigger is often the first step in the use case (but not always).

14. Writing the Basic Flow 1 • Choose a common, simple activity flow. • Trace it from the trigger through use case completion. • Scenarios are often good resources.

15. Writing the Basic Flow 2 • Steps may assume the preconditions and should achieve the postconditions. • Each step should state an action of a single agent (the product or an actor). • Supplemental directions about conditions, iteration, or currency are allowed.

16. Brainstorming Branch Points • A branch point is a place where the action flow may diverge. • Brainstorm a list of branch points and failure conditions. • Look at scenarios for failed or alternative interactions. • Consider errors, faults, and alternatives at every step. • Don’t forget an actor’s failure to act.

17. Rationalizing Branch Points • Remove from further considerations any conditions that the product • Cannot detect • Cannot do anything about • Rewrite poorly stated conditions

18. Writing Extensions • Treat an extension as if it were a separate use case: • The condition is the trigger; • Extension steps are the basic flow; • Completing the use case or returning to the branch point are the goals. • Scenarios are a good resource. • Repeat the extension writing process for the extension (extensions may have extensions).

19. Use Case Description Heuristics 1 • Fill in the use case template from top to bottom. • Obtain use case and actor names from the use case diagram. • Make human actors stakeholders whose needs include completion of the task done by the use case. • Write simple declarative sentences in the active voice.

20. Use Case Description Heuristics 2 • Make actors or the the product the subject of each step description. • Write a basic flow with three to nine steps. • Avoid sequences of steps by actors or the product. • Don’t specify physical details. • Impose minimal order on activities. • Proofread the description.

21. Use Case Models • The diagram is a static model cataloging product interactions. • The descriptions are dynamic models detailing the interactions. A use case model is a use case diagram together with use case descriptions for each use case in the diagram.

22. Designing with Use Case Diagrams • Models a design alternative for the interactions that a product will support • Generate several design alternatives • Alternative can be evaluated in terms of • Unmet needs • Extraneous features or capabilities • Development costs • Time and risk • Conformance to constraints • Feasibility, simplicity, beauty

23. Designing with Use Case Descriptions • Use case descriptions refine the user-level specification in a use case diagram into operational-level specifications. • Design alternatives are specified in different descriptions. • Alternatives can be evaluated as already described.

24. Requirements and Use Case Models • Use case models do not provide atomized requirements statements. • They are not traceable; • Some product functions may not appear; • Data and non-functional requirements are not explicit. • Use case models sometime serve as surrogates for requirements.

25. Extracting Requirements • Extracting requirements from use case models • Helps designers understand their designs better; • Helps find errors and improve designs; • Produces a useful artifact for engineering design. • Additional requirements are also needed. • Data and non-functional requirements • Physical-level requirements

26. Use-Case-Driven Iterative Development In an iterative development project • Choose several use cases for implementation in an iteration; • Furnish product design details; • Do engineering design, code, test, and (perhaps) deploy; • Evaluate the result for the next iteration; • Repeat these steps.

27. Process Guidelines • Start with a complete use case diagram. • Choose use cases for each iteration according the the following criteria: • Important to stakeholders • Requires a core system function • Requires the essentials of the system architecture • The implementation is technically challenging

28. Summary • A use cases description is structured text that specifies the details of a use case. • Templates, processes, and heuristics guide use case description writers. • Use case descriptions, though not requirements, can be a source for them. • Use case diagrams and descriptions together form use case models. • These models are a powerful product design tool. • Use cases can drive iterative development.