Chapter 6

Use CasesThe first step in getting what you want is to

decide what you want.

1CS6359 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

2CS6359 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

3CS6359 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.

4CS6359 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 5

Use Case Exercise

6CS6359 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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

Essential Style

• Focus on the essence, or basic idea, not the details of implementation

• Contrast with concrete style

CS6359 Fall 2012 John Cole 17

Write Terse Use Cases

• Enough said

CS6359 Fall 2012 John Cole 18

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 19

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 20

Finding Use Cases

1. Choose the system boundary2. Identify the primary actors3. Identify the goals for each primary actor4. Define use cases that satisfy these goals

CS6359 Fall 2012 John Cole 21

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 22

Actor-Goal ListActor Goal

Cashier Process SalesProcess rentalsHandle returnsCash inCash out

Manager Start upShut down

System administrator Add/Modify/Delete usersManage securityManage System tables

… …

CS6359 Fall 2012 John Cole 23

Who is the Primary Actor?

• Cashier? Why?• Customer? Why• Depends upon the system boundary

CS6359 Fall 2012 John Cole 24

Event Analysis

• Look at external events. E. g. “Enter sale line items” or “enter payment.”

CS6359 Fall 2012 John Cole 25

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 26

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 27

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 28

A simple diagram can add clarity

CS6359 Fall 2012 John Cole 29

Activity Diagrams

CS6359 Fall 2012 John Cole 30

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 31

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 32

When should UP artifacts be created?

• Table on P. 96

CS6359 Fall 2012 John Cole 33

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 34

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 35

Handle Credit PaymentLevel Subfunction

Main success scenario 1. Customer enters his credit account information2. System send payment authorization request to

external system3. System receives payment approval and signals cashier

Extensions2a. System cannot communicate with external system…

CS6359 Fall 2012 John Cole 36

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 37

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 38

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 39