Chapter 6

1. Chapter 6 Use Cases The first step in getting what you want is to decide what you want. CS6359 Fall 2012 John Cole

2. What they are • Use cases are text stories (not diagrams!) used to discover and record requirements • If a diagram clarifies the text, use it CS6359 Fall 2012 John Cole

3. Definitions • Actor – something with a behavior, such as a person, an input device, etc. • Scenario – Specific sequence of actions and interactions between actors. (also called a use-case instance) • Use Case is a collection of related success and failure scenarios that describe an actor using a system to support a goal CS6359 Fall 2012 John Cole

4. Dissecting a Use Case Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and leaves with the items. CS6359 Fall 2012 John Cole

5. Three Formats • Brief – Terse, one-paragraph summary, usually the main success scenario. Create during early requirements phase. • Casual – Informal paragraph format. Can cover various scenarios in multiple paragraphs. • Fully-dressed – All steps and variations written in detail. Has supporting sections, success guarantees, main scenario, alternate scenarios, etc. CS6359 Fall 2012 John Cole

6. Use Case Exercise CS6359 Fall 2012 John Cole

7. Scope • Defines how broad the use case is. This can be for the whole system, as in the POS example, or narrow, as in a use case for creating a journal entry in an accounting system. CS6359 Fall 2012 John Cole

8. Level • User-goal: Scenarios that let a user get something done. Corresponds to an elementary business process. • Subfunction: smaller steps required to support a user goal. CS6359 Fall 2012 John Cole

9. Primary Actor • The person (or sometimes object) that calls upon system services to fulfill a goal. (When might an actor not be a person?) CS6359 Fall 2012 John Cole

10. Stakeholders and Interests • The stakeholders are people who have a reason to want this system. The Interests are their reasons for wanting it and what they expect from it. • You could view the system as a contract between various stakeholders. CS6359 Fall 2012 John Cole

11. Preconditions and Success Guarantee • These should be non-obvious. • Preconditions state what must ALWAYS be true before you can start the scenario. This often defines the success of another use case. • Success guarantees state what must be true on successful completion of the use case. CS6359 Fall 2012 John Cole

12. Main Success Scenario • This satisfies the interests of the stakeholders. You get your groceries, the store gets your money, inventory is reduced, etc. • Steps: • An interaction between actors • Validation (by the system) • State change to the system CS6359 Fall 2012 John Cole

13. Extensions or Alternate Flows • These are usually the majority of the text. Remember Murphy’s Law  • These include all other possible outcomes, both success and failure. CS6359 Fall 2012 John Cole

14. Performing Another Use Case • Use cases can branch to other use cases. For example, if a POS system rejects a bar code, the cashier can request alternate lookup. • Denote this by underlining: Cashier performs Find Product Help to get item ID and price CS6359 Fall 2012 John Cole

15. Technology and Data Variations • Technical variations on how something must be done: • Scan bar code • Key item ID • RFID • Avoid early design decisions; keep things general. CS6359 Fall 2012 John Cole

16. Write in a UI-Free Style • Most programs are dependent upon a particular user interface. However, avoid constraining your program too early: • “The user keys an ID and password into a dialog box and presses the OK button.” • “The user identifies himself to the system.” • The latter allows for biometric ID, keyin, etc. CS6359 Fall 2012 John Cole

17. Essential Style • Focus on the essence, or basic idea, not the details of implementation • Contrast with concrete style CS6359 Fall 2012 John Cole

18. Write Terse Use Cases • Enough said CS6359 Fall 2012 John Cole

19. Write Black-Box Use Cases • Don’t describe internal workings • Describe responsibilities • “The system records the sale” vs. “The System writes the sale record to a database” CS6359 Fall 2012 John Cole

20. Actor-Goal Perspective • “A set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.” • Focus on the users, asking about their goals • Understand what the actors consider a valuable result CS6359 Fall 2012 John Cole

21. Finding Use Cases • Choose the system boundary • Identify the primary actors • Identify the goals for each primary actor • Define use cases that satisfy these goals CS6359 Fall 2012 John Cole

22. Questions to Find Actors and Goals • Who starts and stops the system? • Who does user and security management? • Who does system administration? • Is “time” an actor because the system does something in response to a time event? • How are software updates handled? • Who gets notified of problems? CS6359 Fall 2012 John Cole

23. Actor-Goal List CS6359 Fall 2012 John Cole

24. Who is the Primary Actor? • Cashier? Why? • Customer? Why • Depends upon the system boundary CS6359 Fall 2012 John Cole

25. Event Analysis • Look at external events. E. g. “Enter sale line items” or “enter payment.” CS6359 Fall 2012 John Cole

26. Which is a Valid Use Case? • Negotiate a supplier contract • Handle returns • Log in • Move pieces on a game board CS6359 Fall 2012 John Cole

27. Tests • The Boss test: “What have you been doing all day?” Is this strongly related to achieving results? • The Elementary Business Process test: Task performed by one person at one place at one time in response to a business event that adds value and leaves data in a consistent state. • The size test: Fully dressed is 3-10 pages. • Reasonable violations: Separate subfunction, or fails boss test but is complex and useful. CS6359 Fall 2012 John Cole

28. Applying UML: Diagrams • “Use case diagrams and use case relationships are secondary in use case work. Use cases are text documents. Doing use case work means to write text.” P. 89. • Do not use diagrams as a substitute for thinking. CS6359 Fall 2012 John Cole

29. A simple diagram can add clarity CS6359 Fall 2012 John Cole

30. Activity Diagrams CS6359 Fall 2012 John Cole

31. Requirements in Context • Use cases organize a set of requirements in the context of a typical use of the system • Replace low-level feature lists • High-level feature lists are acceptable • Some applications need feature-driven viewpoint; don’t create use cases for these CS6359 Fall 2012 John Cole

32. Use Cases in Iterative Methods • Functional requirements are in use cases • Use-case realizations drive design • Use cases influence organization of user manuals • Testing corresponds to use case scenarios • UI shortcuts may be created for most common scenarios CS6359 Fall 2012 John Cole

33. When should UP artifacts be created? • Table on P. 96 CS6359 Fall 2012 John Cole

34. Chapter 30 -- Relating Use Cases • Use cases can be related to each other. For example, Handle Credit Payment can be part of Process Sale and Process Rental CS6359 Fall 2012 John Cole

35. The include Relationship • Don’t duplicate text. Separate it into is own subfunction use case and indicate its inclusion • Paying by credit: include Handle Credit Payment CS6359 Fall 2012 John Cole

36. Handle Credit Payment Level Subfunction Main success scenario • Customer enters his credit account information • System send payment authorization request to external system • System receives payment approval and signals cashier Extensions 2a. System cannot communicate with external system … CS6359 Fall 2012 John Cole

37. Terminology • A concrete use case is initiated by an actor and performs the entire behavior • An abstract use case is never instantiated by itself. It is a subfunction. • A base use case includes another use case or is extended or specialized by one • An addition use case is the use case that is the extension, inclusion, or specialization CS6359 Fall 2012 John Cole

38. The extend Relationship • If a use case cannot be modified, it can be extended. • Example: base case is Process Sale. This must be extended to handle gift certificates CS6359 Fall 2012 John Cole

39. Handle Gift Certificate payment • Trigger: Customer wants to pay with gift certificate • Extension points: payment in Process Sale • Main success scenario: Customer gives gift certificate to cashier. Cashier enters certificate ID • … CS6359 Fall 2012 John Cole