Chapter 6: Use Cases

1. Chapter 6: Use Cases

2. 6.1. Introduction • Use cases are text stories, widely used to discover and record requirements; they are the F in FURPS+: other artifacts will complete the requirements of the application. • Use cases are not diagrams they are text : UML use case diagrams are trivial to learn; the real analysis skill is to identify and write good use cases. • A use case diagram is useful as an overview of the functionalities of an application; it also defines the application’s context (what is part of it and what isn’t). • Use cases have nothing to do with objects … they are nonetheless very useful : simple, user-centric; they form a kind of contract of how an application should behave from a user point-of-view. • Use Cases influence many UP artifacts : see Fig 6.1.

3. Fig 6.1 Use Cases within the UP

4. 6.2 Example • Informally, use cases are text stories of some actor using a system to meet goals. Here is an example brief format 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 then leaves with the items. • More detailed use cases are usually also needed, but even at such a high-level, use cases are very useful as communication tool during requirements analysis. • Instead of recording requirements as a list (the system will do : …), use cases capture the requirements in the following style: This actor does this and the system responds this way etc. by little stories … (advantages?)

5. 6.3 Definitions • An actor is something with behavior, such as a person (identified by role), computer system, or organization; e.g. a cashier, a player. • A scenario (aka a use case instance) is a specific sequence of actions and interactions between actors and the system : it is one particular story of using a system, or one path through a use case. • So a use case can be seen as a collection of related success and failure scenarios that describe an actor using a system to support a goal.

6. 6.3 Definitions (cont) • Example a casual format use case with alternate scenarios: Handle Returns • Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item … (as before) • Alternate Scenarios: • If the customer paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. • If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted). • If the system detects failure to communicate with the external accounting system, … • Hence a use case contains a set of scenarios.

7. 6.4 Definition: What are Three Kinds of Actors? • Actors are roles played by people, organizations, other software and devices that interact with the application.

8. 6.5 Notation: What are Three Common Use Case Formats? • Use cases can be written in different formats and levels of formality: • Brief Use Case : Terse one-paragraph summary, usually of the main success scenario. Created during early requirements analysis, to get a quick sense of subject and scope. May take only a few minutes to create; • Casual Use Case : Informal paragraph format. Multiple paragraphs that cover various scenarios. A refinement of a brief use case; • Fully Dressed Use Case : All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. Created after many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in this format.

9. 6.6 Example: Process Sale, Fully Dressed Style • Roughly 10% of the use cases should be written in this style during the inception phase. • Example of a possible template:

10. 6.6 Example: Process Sale, Fully Dressed Style (cont)

11. … continued • Use Case UC1 : Process Sale • Scope: NextGen POS application • Level: user goal • Primary Actor: Cashier • Stakeholders and Interests: • Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer shortages are deducted from his/her salary. • Salesperson: Wants sales commissions updated. The following is an example for our POS application:

12. … continued • Customer: Wants purchase and fast service with minimal effort. Wants easily visible display of entered items and prices. Wants proof of purchase to support returns. • Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components (e.g., remote credit validation) are unavailable. Wants automatic and fast update of accounting and inventory. • Manager: Wants to be able to quickly perform override operations, and easily debug Cashier problems. • Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such as national, state, and county. • Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. • Preconditions: Cashier is identified and authenticated. • Success Guarantee (aka Post conditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded.

13. … continued • Main Success Scenario (or Basic Flow): • Customer arrives at POS checkout with goods and/or services to purchase. • Cashier starts a new sale. • Cashier enters item identifier. • System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. • System presents total with taxes calculated. • Cashier tells Customer the total, and asks for payment. • Customer pays and System handles payment. • System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory). • System presents receipt. • Customer leaves with receipt and goods (if any).

14. … continued • This is a very detailed Use Case: • You may not require this level of details; • The sections probably need to be customised to your application domain; • It would take a long time to arrive at this level of details; • The more details the more likely that contradictions have crept in; • You cannot produce something like this on your own: all relevant stakeholders must be heavily and directly involved (e.g. in a workshop); • A detailed, fully-dressed, consistent, use case that has been approved by everyone is very valuable; See rest of UC1 on separate document …

15. Scope : because we can apply use cases to various entities (SW, SW+HW, SW+HW+Business etc.) we can clarify the scope of the current use case. Level : A user-goal level use case is the common kind that describe the scenarios to fulfill the goals of a primary actor to get work done; A subfunction-level use case describes substeps required to support a user goal, and is usually created to factor out duplicate substeps shared by several regular use cases; e.g. ‘Pay by Credit’ use cases. Primary Actor : the principal actor. Stakeholders and Interests List (Important) : The use cases detail the functional part of the contract between the application and all the stakeholders: by focusing on what the stakeholders want out of a given use case we are less likely to miss important requirements. 6.9 What do the Sections Mean?

16. Preconditions : What must always be true before any of the scenarios in the use case can begin. Preconditions are not tested within the use case; rather, they are conditions that are assumed to be true. Success Guarantees (aka Post conditions) : What must be true on successful completion of the use case either the main success scenario or some alternate path. The guarantee should meet the needs of all stakeholders (for consistency and cross-checking). Main Success Scenario (aka Basic Flow) : It describes a typical successful flow path of execution that satisfies all stakeholders involved; It does not usually includes branching conditions; It can contain description of internal system processes if known at this stage (e.g. the financial transaction is logged, the best scores are recorded);

17. Extensions (aka Alternate Flows) : Usually the longest part of a use case; They indicate all the other scenarios (either successful or failed); Extensions scenarios are branches from the main success scenario : hence the numbering is based on it. E.g. at Step 3, of the main success scenario, there may be an invalid item identifier, either because it was incorrectly entered or unknown to the system. An extension is labelled "3a"; it first identifies the condition and then the response. Alternate extensions at Step 3 are labelled "3b" and so forth; In UC1, the example given, the extensions are themselves quite detailed: they may include extensions themselves … (see 3a); Steps annotated *a, *b etc. can occur at any time; Other use cases can be ‘called’ within an extension (e.g. to perform a common non-trivial activity);

18. Special Requirements : Notwithstanding the fact that other artifacts are necessary to record other, mainly non-functional, requirements, if a specific quality or constraint relates specifically to a use case (and is therefore not application-wide) then they should be mentioned here (e.g. connection to game server must be established within 5s seconds maximum); All the use cases’ special requirements sections can always be summarized and collected later in the supplementary specification document; Technology and Data Variations List : Often there are technical variations in how something must be done, but not what. A common example is a technical constraint imposed by input or output technologies. For example, a stakeholder might say, "The POS system must support credit account input using a card reader and the keyboard." Note that these are examples of early design decisions or constraints; in general, it is skilful to avoid premature design decisions : just make a decision of them in this section;

19. What we presented is just one possible use case notation; many alternatives exist : the specific do not matter; A main alternative use case notation is to present the use case as a conversation between the actors and the system in a two column format: Main Success Scenario: Actor Action (or Intention)System Responsibility 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale 3. Cashier enters item identifier. 4. Records each sale line item, presents item description and running total. Cashier repeats steps 3-4 until indicates done. 5.Presents total with taxes calculated. 6.Cashier tells Customer the total, and asks for payment. 7.Customer pays. 8.Handles payment.  9… 6.10 Notation: Alternatives

20. At this stage it is important (at least when writing the use cases) not to mention UI specifics: we are investigating the requirements (and capturing the functional ones in use cases), deciding on specific UI aspects too early is making design decisions too early; A UI-free use case: Is simpler and shorter; Allows you to focus on the goals of the actors rather than how they will be achieved at a UI-level; Does not preclude the development of UI prototype to help eliciting the requirements and record them in use cases; If a strict constraint exists (for whatever reason) it must be recorded in the Supplementary Specification document; Also try to write short (but complete!) Use Cases (why?); 6.11 Guideline: Write Use Cases in UI-Free Style

21. Consider the system as a black-box at this stage. Use cases should detail the responsibilities of the system (‘what’ the system should do : analysis phase) rather than the specific mechanics of responding to an external event generated by an actor (‘how’ the system will implement the solution : design phase): Don’t jump the guns!! (there is enough to do in this phase!) Do write ‘the system records the sale’ rather than ‘The system writes the sale to the database via …’ or even worse ‘the system generates an SQL INSERT statement for the sale’ We must consider the uses cases from the actors point of view only : to stress observable user value and focus on users’ typical goals. We must concentrate at this early stage on what the user needs not on how it will work internally. 6.12 Guideline: Write Black-Box Use Cases

22. Use cases are defined to satisfy the goals of the primary actors. Hence, the basic procedure is: Choose the system boundary. (Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization?) Identify the primary actors those that have goals fulfilled through using services of the system. Identify the goals for each primary actor. Define use cases that satisfy user goals; name them according to their goal. Of course, in iterative and evolutionary development, not all goals or use cases will be fully or correctly identified near the start. It's an evolving discovery. 6.13 How to Find Use Cases

23. Step 1: Choose the System Boundary For this case study, the POS system itself is the system under design; everything outside of it is outside the system boundary, including the cashier, payment authorization service, and so on. If the definition of the boundary of the system under design is not clear, it can be clarified by further definition of what is outside the external primary and supporting actors. Once the external actors are identified, the boundary becomes clearer. For example, is the complete responsibility for payment authorization within the system boundary? No, there is an external payment authorization service actor. Steps 2 and 3: Find Primary Actors and Goals Guideline: Brainstorm the primary actors first, as this sets up the framework for further investigation. In addition to obvious primary actors and goals, the following questions help identify others that may be missed: Who starts and stops the system? Who does system administration? Who does user and security management? Is "time" an actor because the system does something in response to a time event? In addition to human primary actors, are there any external software that call upon services of the system?

24. We can create use case diagrams (see later) to record the results of the brainstorming session in a table:

25. The customer is not viewed as a primary actor because he/she does not interact with the system directly (everything goes through the Cashier): A self-checkout system would be different …\ Another approach to aid in finding actors, goals, and use cases is to identify external events. What are they, where from, and why?

26. Step 4: Define Use Cases Start the name of use cases with a verb. Some of the goals may overlap and can be re-grouped into single use cases: we do not want use case that are too small at this stage (e.g. ‘Move Avatar’ rather than ‘Move left’, ‘Move right’, ‘Jump’ etc.)

27. The focus should really be on writing use cases: use case diagrams are useful (as communication tool, and summary help) but much less so than the use cases themselves … A use case diagram is an excellent picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. See figure 6.2: Partial Use Case Diagram 6.14 Use Case Diagrams

28. Figure 6.2: Partial Use Case Diagram

29. <<actor>> is an example of a UML keyword or stereotype. We can also relate use cases to each other: the include and extend relationships. Examples of usages:

30. Use cases are not the only necessary requirements artifact. Non-functional requirements, report layouts, domain rules, and other hard-to-place elements are better captured in the UP Supplementary Specification.

31. The UP encourages use-case driven development : The main way to record requirements is via use cases (The Supplementary Specification is secondary) ; We schedule iterations according to entire use cases (or at least use case scenarios) ; Use cases drive the design : we try to fulfill the requirements of a use case See separate document for an example of effort across early iterations. Only about 10% of use cases are written in details during inception (those that are risky, architecturally significant or represent the selling point of the software) : in our POS case study this may mean Process Sale and Handle Returns . 6.15 Use Cases in an Iterative Process

32. At the end of the elaborations most of the use cases are available in a detailed format; the very core of the software has also been designed and implemented (it is important for these to be of high quality so that they withstand future expansions …) During the UP Construction phase, use cases need to be kept up to date with any changes necessary. Maybe minor remaining use case are fully detailed. Brainstorming sessions are useful to discover and flesh-out use cases, especially during the inception phase. If possible these should involve : End Users Customers Developers Software Architect Project Manager …

33. POS use cases for the inception phase:

34. Use Cases are very useful but not the complete requirements, use cases should not be too small, use case diagrams are useful summaries. Resources: 6.16 Conclusion “Writing Effective Use Cases”, Alistair Cockburn, Addison Wesley, 2000, ISBN : 0201702258