6. Use Cases II

1. 6. Use Cases II CSE 5324 Quiz 5 due at 5 PM, Thursday, 4 September 2014

2. 6.12-14 More Guidelines • Write terse use cases (like highway signs). • Write black-box use cases: • Tell system’s (external) responsibilities. • No internal details. • Describe collaborations with other elements. • Tell what (requirements analysis), not how (design). • Take actor & actor-goal perspective: • Sequence of actions in typical situation. • Observable results. • Valuable to a particular actor. • Not a simple feature and function list.

3. 6.15 How to Find Use Cases Figure 6.2 Primary actors and goals at different system boundaries. • Choose the system boundary; e.g., software only, hardware and application, plus human operator, or plus an entire organization. • Brainstorm to identify primary actors, whose goals the system fulfills. • Brainstorm to identify each actor’s goals, whose results (will) have measureable value. • Define a use case that satisfies each goal. • Repeat steps 1-4, adding needed use cases and improving existing use cases forever. Discovery Questions (steps 2 & 3): Who starts/stops system? Who does system Admin, security management? Does it respond to time-actor events? Who gets failure notes? Organizing Actors & Goals: List actors’ current and future goals (not current tasks), and edit list before or after drawing use cases. Scope: The cashier is the primary actor in traditional POS checkout systems, but the customer could be the primary actor at a self-service kiosk (Fig. 6.2). Event analysis: Sometimes many use cases (e.g., Edit User, Delete User) can be collapsed into one “manage <X>” use case.

4. 6.16 Tests To Find Use Cases • Find the most useful abstraction level for each use case: • Boss Test: Your boss must see the goal’s value. • Size Test: A good use cases’ many steps generally fill 3-10 fully-dressed pages. • Elementary Business Process (EBP) Test: A task performed by 1 person in 1 place at 1 time, in response to a business event, which adds measureable business value and leaves the data in a consistent state; e.g., Approve Credit, Price Order. • Examples: • Negotiate a Supplier Contract should be modeled as a business use case, not a system use case. • Handle Returned Merchandize is good sized EBP and OK with the boss. • Move Piece on Monopoly Board fails the size test. • Authenticate User may be OK based only on length and EBP. • Sub-function use cases are OK, if they are called many times.

5. 6.17 UML Use Case Diagrams Figure 6.3 Partial use case context diagram of the NextGen POS system. Figure 6.4. Notation suggestions. • While handy in describing your text use cases to others, use case diagrams(Fig. 6.3) should not play a part in use case analyses. • Notation (Fig. 6.4): • Big box shows system boundary. • Internal bubbles name all of the use cases. • Stick figures on left are primary human actors. • Little <<actor>> boxes on right are external system interfaces (supporting actors). • Connecting lines signify essential communications.

6. R U O K ? • Which of the following does NOT describe a good use case? __ • It tells a system’s external responsibilities, without providing internal details. • It describes collaborations with other elements. • It tells how the system works, not what it does. • It describes a sequence of actions in typical situation. • It produces observable results of value to a particular actor.

7. R U O K ? 2. Which of the following helps identify use cases? __ • Choose the system boundary. • Identify primary actors, whose goals the system fulfills. • Identify each actor’s goals, whose results have or could have measureable value. • Define a use case that satisfies each goal. • All of the above.

8. R U O K ? 3. Which of the following is the LEAST effective criterion for judging a use case’s abstraction level? __ • Can others see the goal’s value? • Is it 3-10 pages long when fully dressed? • Does it describe tasks performed by 2 people in 1 place at 1 time? • Is it a response to a business event? • Does it leave data in a consistent state?

9. R U O K ? Name the parts of the context diagram below: 4. __ 5. __ 6. __ 7. __ 8. __ • Use case. • Primary actor. • Communication. • Supporting actor. • Context boundary and title. 8 6 NextGen 4 Process Sale 7 5

10. 6.18 UML Activity Diagrams Figure 28.1. UML activity diagram notation (p. 478). • UML activity diagrams are useful in use case analysis. • Use them to visualize and understand workflows and complex business processes, which involve many actors and their concurrent goals.

11. 6.19 Use Case Pros & Cons Figure 6.6. Monopoly system use case (context) diagram. • Use cases help cluster requirements into typical system usage scenarios, whose time dimensions become engaging stories. • Short, high-level feature lists still can play an important sales role on product specification sheets. • And non-functional (-ility) requirements are captured in Unified Process (UP) Supplementary Specifications (SS), not in use cases. • Monopoly Example: All game rules are listed in the SS, and the single use case (Fig. 6.6) story is short and boring.

12. 6.21a Use Cases in Iterative Methods • UP encourages use case-driven development: • Use cases record virtually all requirements. • Initial collection of use cases estimates effort. • Each iteration begins with choosing 10% of them. • Collaborations among object and subsystems are designed to realize the selected use cases. • User manuals are organized around use cases. • Functional system testing follows use case scenarios. • User shortcuts (e.g., Install Wizard) arise from most common use case scenarios.

13. 6.21b Use Cases Evolve in Iterations Table 6.1. Requirements effort levels in early iterations. Figure 6.7. Process and setting for writing use cases. • Requirements analyses start strong in iteration 1 (Inception) and decline in the next 3 (Table 6.1). • The first iteration begins development of only the most important (i.e., core architecture, highest business value and risk) 10% of requirements. • The top 30% are written in detail in iteration 2’s requirements workshop (i.e., initial Elaboration, Fig. 6.7), after iteration 1’s testing and user feedback have answered important questions. • Elaboration phase concludes with 80-90% of use cases understood and elaborated in full-dressed format.

14. R U O K ? Name the parts of this activity diagram: 9. __ 10. __ 11. __ 12. __ 13. __ 14. __ 15. __ • End. • Start. • Action. • Object. • Fork (concurrency). • Join (exit thread). • Partition (between actors). 13 12 15 11 9 14 10

15. R U O K ? 16. Which of the following are good use case applications? __ • Product specification sheets. • Capturing non-functional (-ility) requirements. • Clustering requirements into typical system usage scenarios, whose time dimensions become engaging stories. • Your textbook author’s Monopoly game example. • All of the above. • None of the above.

16. R U O K ? 17. Which of the following does NOT describe use case-drivendevelopment? __ • Use cases record 10% of all requirements. • Initial collection of use cases estimates effort. • Each iteration begins with choosing their top 10%. • Collaborations among object and subsystems are designed to realize the selected use cases. • User manuals are organized around use cases. • Functional system testing follows use case scenarios. • User shortcut Wizards arise from common use case scenarios.

17. R U O K ? 18. Which of the following does NOT describe use caseevolution from one iteration to the next? __ • In the Inception iteration, 90% of requirements get brief use cases, and 10% get fully dressed. • Another 10% get dressed in each Elaboration phase iteration, as testing and user feedback answer important questions. • The Elaboration phase concludes with 80-90% of use cases understood and fully dressed. • None of the above describes use case evolution.