Chapter 6
Use Cases
The first step in getting what you want is to decide
what you want.
CS6359 Fall 2012 John Cole
1
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
2
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
3
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
4
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
CS6359 Fall 2012 John Cole
6
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.
2.
3.
4.
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
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 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
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 Payment
Level Subfunction
Main success scenario
1. Customer enters his credit account information
2. System send payment authorization request to
external system
3. System receives payment approval and signals
cashier
Extensions
2a. 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