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

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

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

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

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

Use Case Exercise This is to be done in class. Give them some simple object, such as a phone, pen, or calculator, and, with class participation, construct a use case for it. Use NotePad to record the use case. CS6359 Fall 2012 John Cole

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

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

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

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

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

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

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

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

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

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

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

Write Terse Use Cases Enough said CS6359 Fall 2012 John Cole

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

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

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

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

Actor-Goal List Actor Goal Cashier Process Sales Process rentals Handle returns Cash in Cash out Manager Start up Shut down System administrator Add/Modify/Delete users Manage security Manage System tables … CS6359 Fall 2012 John Cole

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

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

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

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

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

A simple diagram can add clarity CS6359 Fall 2012 John Cole

Activity Diagrams CS6359 Fall 2012 John Cole

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

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

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

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

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

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

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

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

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