Use Cases

1. Use Cases

2. Use-Cases: an Example

3. Student Administrator Instructor Using use cases to describe requirements • Use cases can show the sets of possible interactions between the system and the people who use it • Use cases can also show interactions between computer systems • Use cases can also be used at the subsystem level (to show interactions between subsystems) Example use case diagram My system register create new course delete offering actors use cases

4. What is a Use Case? • A Use Case captures a contract between the stakeholders of a system about its behavior. Use cases describes the system’s behavior under various conditions as the system responds to requests from its users (actors) specifying how the actors’ goals get delivered or fail. • A use case is: • a set of scenarios that describe the behavior of the system and its users • at a high level of detail • with “sunny-day” and “rainy-day” scenarios being defined • A use case gathers the scenarios related to the (primary) actor’s goal • Actors are the people and/or computer systems that are outside the system under development (SuD)and interact with it: • Primary actor – a stakeholder who requests that the system deliver a goal • Supporting/secondary actor – an external system against which the SuD has a goal • Scenarios are dialogs between actors and the system

5. What is a Use Case (cont)? • A Use Case is the set of scenarios that provides positive value to one or more external actors • actors are the people and/or computer systems that are outside the system under development • scenarios are dialogs between actors and the system • no information about the internal design

6. More about Use-Cases • A use-case is • a set of activities within a system • presented from the point of view of the associated actors • leading to an externally visible result • a (simplified) part ofa business process model • A use defines WHAT is the system supposed to do • not for functional decomposition • simplified and limited graphical notation • other diagrams and text templates used to support it • combined with prototypes

7. Actors • An actor is an entity that is outside of the system • Actors will interact with the system: • an actor will often request the system to perform some actions on behalf of the actor • an actor may also receive responses from the system • An actor plays a “role” in the use of the system • the name given to an actor is usually the “role name”: for example, an actor who is a Person will usually be called a User, Operator, Administrator, or something like that • each role might be treated as a different actor in the use cases

8. Communication between actors and the system • In each use case, a “primary actor” starts things off: that actor initiates an interaction with the system • The system will then respond to messages and might send messages of its own to other actors • In a use case, the primary actor is trying to achieve a specific goal: • the use case consists of all the possible interactions that take place in the attempt to reach the goal • there may be many scenarios in a use case - each scenario shows an alternative “course” that is based on the success or failure of some of the intermediate steps • the goal might not be reached (because of some of the failures)

9. Goals • A goal is a result that one of the actors wants to achieve • Example goals: • An administrator wants to add a new user to the system • A pilot wants to land a plane • A customer wants to file a claim on an insurance policy • A service person wants to file a trouble report

10. I would like a book of stamps, please. Here is $10. Thanks. Here are your stamps and your change. Scenarios • A scenario is a little story • it is an outline of some expected sequence of events • A scenario is used to convey the fundamentals of “how things work” • It usually includes at least one actor • Each actor can make requests of the system or respond to system activity OK. Will that be all? Yes. That will be $7.40.

11. Identifying actors • An Automated Teller Machine (ATM) permits customers to withdraw money from their accounts, make deposits, and check their account balances. The ATM machine communicates with a computer system in the bank’s central office to validate passwords and account information. The ATM is serviced on a regular basis by bank employees, to collect deposit envelopes and to load in more cash and receipt paper. • Question: who are the actors in this system?

12. 1. Customer inserts card ??? Creating a simple scenario • Draw a sequence diagram for one of the scenarios in the ATM system. One prominent use case in this system is “customer performs an ATM transaction,” and one scenario in that use case is “customer withdraws money”. Assume we are in the sunny-day scenario. Customer ATM

13. Scenario - Example • A scenario is a little story • It describes one possible course of events: • Customer puts ATM card into machine and types password • System validates the card and password • System prompts the customer for a transaction type and amount • Customer selects “withdraw $100 from checking” • System checks with the central bank make sure customer has sufficient funds • System dispenses the cash, returns card, and prints receipt • System asks customer if he/she would like another transaction

14. Representing Use cases • Text templates: • Informal text • informal paragraph summary – the paragraph will describe who starts the scenario, the key actions by the actors and the system, and how to handle failures • numbered list of steps – in this format, the main scenario is a list of sentences describing the sequence of actions by each actor and/or the system; failure scenarios can be written as branch scenarios at the end • Tables – informal text • Structured templates – one popular example (A. Cockburn) • Structured (“semi-formal”) DOORS template • Graphical formats: • UML Use Case diagrams capturing the system boundary, use cases(names), actors, channels and use case relationships • UML Sequence Diagrams (also known as message sequence charts, MSC) to represent scenarios

15. Showing a scenario in text format … • A scenario can be written as a series of sentences: • each sentence shows one step of the scenario • each step needs to explain • who does the operation • what operation is performed • when the operation is performed • are there any side conditions? • one important thing that is not included in the description of each step of a scenario: how the operation is performed (this is left for the design phase) • Important style points: • each step in the scenario must have a subject (either the system or an actor is performing the step) • no passive or impersonal voice allowed (e.g., “the results are displayed”)

16. Example of a text format scenario Customer buys a single item: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4. Customer indicates that they don’t want anything else 5. Postal clerk determines the price of the requested items and tells the customer 6. Customer pays 7. Postal clerk gives the Customer the items and change • Note: this is not yet a use case, just a single scenario.

17. Customer Postal clerk Showing a scenario in graphical form • Scenarios can be shown in a standard graphical notation – this notation has many different names • Sequence diagram, Event trace diagram, Interaction diagram, Fence post diagram Ask for item Acknowledge request Anything else? No Respond with price Give money Give item and change

18. Writing a use case Step 1: Pick one of the potential goals of one of the actors Step 2: Write down the preconditions for that goal Step 3: Write the “sunny-day” scenario for the interaction between actors and system Step 4: Identify the possible failures at each step - think about the alternative scenarios that might result Step 5: For the main failure situations, either create entire scenarios or create extensions of the main scenario optional step: Find common chunks that occur in several scenarios that can be factored out to make the scenarios simpler

19. Example use case Use case name: Ticket Buyer buys a lottery ticket Primary actor: Ticket Buyer Precondition: Ticket Buyer has $1 Main scenario: 1. Ticket Buyer tells the system (person or machine) that he/she wants to buy a ticket 2. System asks the Ticket Buyer for his/her choice of lucky number 3. Ticket Buyer chooses a number 4. System asks for $1 5. Ticket Buyer supplies $1 6. System prints a lottery ticket and gives it to the Ticket Buyer Variations: 2. Ticket Buyer chooses a number: 2a. using keypad 2b. fills in circles on card 2c. asks for a “quick pick”

20. Ticket buyer Ticket machine Sell me a ticket Alternative format for a scenario: UML Sequence Diagram (also known as Message sequence chart) Prompt for lucky number Number choice Prompt for $1 Note: the scenario explains “what” happens but not “how” it happens (that will be in the design) Insert $1 Dispense ticket Example use case - scenario

21. Example use case (continued) • The use case isn’t finished… • still need to handle failures • go through the steps, list the various ways that they could fail: • Ticket Buyer can’t decide on a number, changes his/her mind • Ticket Buyer fills in too many circles on the card • System can’t print a ticket because it is out of ticket paper • from some failures, the system can recover • from other failures, the use case will “fail”

22. Making scenarios more elaborate • There are three ways to create more elaborate scenarios: • Variations • Extensions • Chunks (subfunctions)

23. Variations • A variation is a way to avoid “scenario explosion” • A variation is a list of alternatives that is tied to a specific line of a scenario • Each variation could turn into a lower-level scenario • An example variation (for the post office scenario): • 1. Item is • a. stamps • b. postage on an item that the customer is mailing • c. postage due on an item that the customer is receiving • d. post office box rental • e. mugs, t-shirts, and other Postal Service merchandise • 6. Payment is • a. ______________ • b. ______________ • c. ______________ Main scenario: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4. Customer indicates that they don’t want anything else 5. Postal clerk determines the price of the requested items and tells the customer 6. Customer pays 7. Postal clerk gives the Customer the items and change

24. Extensions • An extension is a short scenario that “branches off” from another scenario • Extensions are used to describe recovery actions when something goes wrong • extensions might rejoin the main scenario • or extensions might just terminate because the goal can’t be achieved • An example extension (for the post office scenario): • 2a. Item is not available: • 2a1. Postal clerk looks for an equivalent item • 2a2. If an equivalent item is found, the Postal clerk asks customer if the equivalent item is OK Main scenario: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4. …

25. Chunks • A chunk is a “sub-scenario” - a sequence of messages that appears in several scenarios for one or more use cases. • A chunk is a scenario that addresses a specific subgoal • for example: logging in, searching for a specific product, etc. • They are the “subroutines” of the use case family • They may express some common “user interface” sub-scenarios • Alistair Cockburn calls them “subfunctions” (but we don’t want to think of them as associated with low-level code)

26. The UML Use Case Diagram • In UML (Unified Modeling Language), it is possible to show a picture of the system as a group of use cases: • each stick figure is an actor • each ellipse represents a use case • The diagram is deceptively simple • behind each ellipse, there might be a whole bunch of scenarios – sunny-day, alternatives, failures • the diagram is only a “summary” withdraw cash Customer check balance Bank Employee service ATM

27. Office Security System open door Employee reset alarm Security Guard test alarm Repair Person A simple format for a use case Use case 1: Employee opens door Goal: An Employee wants to unlock a door to pass from one room to another. Preconditions: The Employee has valid identification to open the door. Success end condition: Employee has successfully opened the door. Failed end condition: Door remains closed and the Security Guard on duty is notified. Actors: Employee, Security Guard Main scenario: 1. Employee’s identification and door identification is sent to system 2. Door is unlocked 3. Employee opens door, passes through the door, and recloses door, SUCCESS Extensions: 2a. Employee’s identification is not valid 2a1. System notifies Security Guard, FAIL

28. More Notations and Examples

29. “actor“ cellular network Textual stereotype (class) Visual stereotypes (classes) boundary/interface entity passive objects data stores control actor persons & roles Use-Case diagrams - actors

30. More on Use-Case diagrams • Show use-cases & actors • connected by „associations“ • refined by inheritance stereotypes • “uses” • re-use of a set of activities (use-case) • partitioning of activities • points to the re-used use-case • “extends” • variation of a use-case • points to the standard use-case elicit customer needs “extends “ make an interview “uses “ produce a SRS

31. “uses” check travel options search for a flight pay with cc book a flight Pay a bill “actor“ flight res-sys “uses” “extends” “actor“ credit-card sys flight db customer traveler anybody clerk clerk prepare-travel Use-Case diagrams: Example

32. On Use Case Levels • It is possible to write • “business-level” use cases – • organizational goals (marketing, finance, systems engineering, installation) • or “system-level” use cases • goals of specific users • or “subsystem-level” use cases • goals of the other subsystems

33. Levels of scope (A. Cockburn) • Summary-level goals • “cloud-level” Upgrade all customers • User goals • “sea-level” • usually 2 to 20 minutes Add new service • Sub-functions • “under water” • not a real “user goal”: these scenarios describe common sub-operations Find list of services

34. Goals & Sub-goals • Each use case represents a “goal” of one of the actors • the use case is “the set of all scenarios that might happen” in trying to reach that goal – success or failure scenarios • each scenario is a series of smaller sub-goals • if you can succeed in each step, you will reach the goal • if a step fails, then there might be an alternative series of steps that get to the goal • the substeps might be lower-level use cases, or they might just be “things implemented in the design”

35. uc-1 uc-4.1 uc-2 uc-4.2 uc-3 uc-4 Use Case diagram decomposition Use- Case diagrams: Hiearachies diagram name: anything Diagram name: anything-level2-for-uc4

36. Step 1: Create a list of Actors Step 3: Write simple use cases with only sunny-day scenarios UC1: Customer downloads a song Precondition: Song file is on a server Main scenario: 1. Customer chooses song 2. System checks availability and price; prompts Customer for payment 3. Customer enters credit card info 4. System sends credit card transaction to Bank 5. Bank returns transaction number 6. System transmits the song to Customer’s computer Support hotline person Administrator Repair person Customer Step 2: Create a list of Goals Web-based music distribution system: UC1: Customer downloads a song UC2: Customer searches music directory UC3: Administrator adds a new user UC4: Administrator updates directory UC5: Support hotline person investigates a Customer problem UC6: Support hotline person authorizes Customer refund UC7: Repair person runs diagnostics Step 4: Review the use cases with customer (or customer surrogate) Use Case Process

37. Step 5: Identify failure conditions • Step 7: Internal review • review the scenarios and failure branches with testers, developers, project managers • Ongoing: make links to other requirements, update use case model as needed • define the business rules and non-functional requirements (in text documents, with links to the use case model) • add new use cases and new scenarios for new actors and goals; new variations for existing use cases 2a. Song is not available 3a. Customer quits without entering credit card info 4a. Link to Bank is down 5a. Credit card is rejected by Bank 6a. Server fails during transmission 6b. Customer cancels during transmission Step 6: Write a selected set of failure scenarios and alternatives 5a. Credit card is rejected by Bank: 5a1. System reports failure to the Customer, prompts Customer for a different credit card 5a2. Customer enters card info 5a3. go to step 4 Use Case Process (Cont.)

38. How many use cases is enough? • It depends… • make sure you cover the major goals of each actor • don’t forget OA&M – administrative use cases usually include initialization, running backups, diagnosing problems, and reporting current status to another system • some systems might need 100-200 use cases, but most only have 20-40 • do some “abstraction” to reduce the number of scenarios

39. Use Cases contribute to agility • It is important to be “agile” • Requirements • get direct customer involvement in documenting the requirements – using scenarios and use cases • Architecture • make better architectural decisions – use the high-runner, high-priority scenarios to assess “candidate architectures” • Project management • use cases can help to plan an iterative development process • Test • update the tests as the requirements change

40. Scenarios and use cases in design, coding, and test • The use cases are a very useful form of requirements • they attempt to describe the externally visible behavior of the system • they are concise enough for everyone to read (customers, developers, testers) • Use cases can be kept under change control • Design-level and code-level comments ought to refer to individual use cases, so that individual design decisions can be revisited when the use cases are changed • System-level tests will use the information from use cases

41. Impact of Use Cases on Software Teams • Systems engineers: improve communication with development team • SEs will write the key functional requirements as use cases (typically, 20 to 200 use cases for a system) • the set of system-level use cases (a subset of the overall requirements) can be constructed and reviewed quickly • customers can validate the main scenarios • Architects: benefit from using the most important “failure scenarios” to evaluate the architecture • Development managers: “iterative and incremental development” can start with the high-priority use cases – focus on the scenarios that deliver the maximum value to customers • Developers: code inspections can narrow the focus on the most important scenarios • Testers: integration and system tests are guided by the use cases

42. Use cases and requirements • Use cases are requirements • a use case will specify the essential behavior that the system must deliver • Use cases are usually about 1/3 of the total volume of requirements • The use cases are supplemented by other kinds of requirements information • Business Rules: conditions, policies, and conventions • Operational Profiles: how many scenarios • Architectural Requirements: “-ilities” (reliability, usability, performance)

43. Why use cases? • Why write use cases instead of “normal” functional requirements? • Use cases hold functional requirements in an easy-to-read, easy-to-track format • Each use case gives information on how the system will deliver a “goal” to one of the users of the system • a use case explains how a goal succeeds/fails using scenarios • the scenarios provide context – traditional requirements are often too ambiguous • “If you have a requirement that doesn’t help meet any of the users’ goals, why do you have the requirement in the system?” • also need to look at the goals of the “stakeholders” • Use cases show only the Functional requirements • the use cases are a framework to attach non-functional requirements and other project details

44. After the use cases are written, what next? • Jumpstart the OOAD – CRC and models • use cases describe the “externally-visible behavior” of the system • an object model describes the internal behavior • Design decisions can be linked back to a use case • Jumpstart test cases • Scenarios provide excellent start for “early testing” • Test planning – RTP and RSTP • DOORS-based traceability • Use the Use Case list to manage your project • Use cases provide excellent basis for structuring and monitoring your project iterations • It is important to be “agile”

45. Iteration management with use cases • A use case model can be very useful in a project with rapid iteration • for each iteration, identify which use cases are “in” the iteration • that is, will some or all of the use case’s scenarios work? • track progress by counting scenarios (with priority weighting) • typical iteration scheme: • first iteration: highest priority use cases, sunny-day scenarios only • second iteration: add a few second-tier use cases, start implementing the failure scenarios that fail completely • later iterations: add a few more use cases, start filling in the “recovery” scenarios • you might choose certain use cases as “high-priority” because they help validate key parts of the architecture

46. References • Books: • Alistair Cockburn, Writing Effective Use Cases • Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in Context • Steve Adolph and Paul Bramble, Patterns for Effective Use Cases • Kurt Bittner and Ian Spence, Use Case Modeling • Web sites: • http://www.usecases.org • http://agilealliance.org • http://members.aol.com/acockburn • http://members.aol.com/acockburn/papers/usecases.htm

47. Extra ... • Summary …

48. Better Requirements and Product Quality through Use Cases (UC) • Summary of Characteristics and Benefits • UCs capture a contract between the stakeholders of a system about its behavior • UCs specify system’s behavior under various conditions (success & failure modes) in a way that is concise and easy to understand, track, and validate • UCs are collections of scenarios; scenarios provide context – traditional requirements are often too ambiguous • UCs are a key to the creation/ generation of quality test cases and system verification • Industry data: • Use cases improved developer productivity by 40% (DaimlerChrysler) • 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases

49. use case: collection of scenarios related to a goal goal: what the actor is trying to accomplish when using the system (this might succeed or fail) scenario: a sequence of interactions sunny-day scenario: a scenario where everything works failure scenario: a scenario that explains what happens when something goes wrong variation: a set of choices for a single scenario step extension: a branch scenario that starts with an extension condition actor: a person or system outside of the system under development precondition: one of the conditions that must be true when a scenario of the use case is triggered chunk or subfunction: a set of scenario steps that are repeated in several different use cases business rule: one of the rules that describes how the business is run operational profile: description of which use cases will be run at the same time Vocabulary in this section

50. Useful books • Writing Effective Use Cases by Alistair Cockburn • Patterns for Effective Use Cases by Steve Adolph and Paul Bramble • Use Case Modeling by Kurt Bittner and Ian Spence