Chapter 6
Use Cases
What is a Use Case?
A Use Case is a text story of some actor using a system to
meet one or more goals (or not).
Basic Use Case Components:
•
•
•
•
•
Use Case Diagrams are light on detail
Text Use Cases contain most of the requirements
Use Case Diagrams show only high-level goals
Text Use Cases flesh out the details
Use Cases focus on what user needs are to be fulfilled
Fig. 6.1
A sale consists of selling
one or more items
Sample UP Artifact Relationships
Domain Model
Sale
Business
Modeling
1..*
1
date
...
Sales
LineItem
?
...
...
quantity
objects, attributes,
associations
scope, goals,
actors, features
Use-Case Model
Vision
Process Sale
Process
Sale
use
case
names
Cashier
Use Case Tools
Requirements
Use Case Diagram
1. Customer
arrives ...
2. Cashier
makes new
sale.
3. ...
terms, attributes,
validation
Glossary
Use Case Text
system
events
: System
Operation:
enterItem(…)
Post-conditions:
-...
: Cashier
system
operations
make
NewSale()
Supplementary
Specification
enterItem
(id, quantity)
non-functional reqs,
quality attributes
System Sequence Diagrams
Operation Contracts
requirements
: Register
Design
Design Model
: ProductCatalog
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Example: (POS)
brief format 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 provides payment information, which the system
validates and records.
The system updates inventory.
The customer receives a receipt and leaves the store.
Definitions:
•
Actor: Something with behaviour; person (playing role), computer
system or organization
•
Scenario: Sequence of actions and interactions between actors and
system. Also called use case instance. Just one story of usage, among
many.
•
Use Case: Collection of related success and failure scenarios.
Use Case (Casual Format):
•
typical situation where main scenario
is easy but exceptions make all the work
Handle Returns:
– Success:
• Customer arrives at POS with item to return. Cashier uses
POS system to record return.
– Alternative Scenarios:
• Unreturnable: Item was unreturnable due to special sale
conditions.
• Failed Credit: Customer paid with credit card but card won’t
accept return so pay in cash.
• Unknown Item: Computer can’t find item code, enter by hand
• System Down: Use receipt book to hand-return item.
Use-Case Model (UP def’n):
•
Collection of Use Cases within the Requirements discipline.
•
Not the only UP Requirements artifact: Supplementary Specification,
Glossary, Vision, Business Rules (p 101)
•
Use Case Diagrams just for added context.
•
Nothing OO about Use Cases.
Why Bother?
•
Focusing on user goals early on keeps you looking at “what” and not
“how” too soon.
•
Customers understand their goals more than how a computer system
may help meet them.
•
Domain experts can contribute.
•
User-centric; this is good since this is a document a user may very
well see.
•
Use Case strength is its ability to scale up or down in terms of level of
detail.
Are Use Cases Functional Requirements?
•
Yes, they describe what a system is supposed to do.
•
A Use Case is a contract on how a system should behave.
•
FURPS+ (p56)
•
Use Cases are not a “features list”.
Three Kinds of Actors:
•
Primary: Has goals fulfilled by using the system. Generally drives the
Use Case definition
•
Supporting: Provides a service to a system. Example, credit card
check for POS. Often a computer system.
•
Offstage: Has an interest but only indirectly (NYSTax)
Three Use Case Formats:
•
Brief: One-paragraph summary (with title). We will use WikiTitles
(AllOneWordWithCapitals) since these are also Wiki links.
•
Casual: Multiple, short paragraphs describing various scenarios.
•
Fully Dressed: All steps and variations in detail.
NOTE: After first Requirements Workshop only 10% of Use
Cases are “fully dressed”. Other Use Cases are briefly or casually
described.
Fully Dressed Use Case Format
Use Case Name
WikiName, start with verb
Scope
System boundaries (corp, prog)
Level
Summary, subfunction, etc
Primary Actor
Primary system user
Stakeholders
Who cares and what they want
Preconditions
Must be true to start
Postconditions
What is guaranteed by success
Main Success Scenario
Typical, unconditional path scenario
Extensions
Alternative success or failure scenarios
Special Requirements
Related non-functional requirements (RAM)
Technology & Data
Variations List
Varying IO methods and data formats
Frequency of Occurrence
Is this system used often
Miscellaneous
Open issues; eg unmanageable failure scenarios
Fully Dressed Use Case (1):
•
Scope: NextGenPOSApplication
•
Level: User Goal
•
PrimaryActor: Cashier
•
StakeholdersAndInterests:
–
–
–
–
–
–
cashier wants: …
customer wants: …
company wants: …
manager wants: …
government wants: …
CC company wants: …
Fully Dressed Use Case (2):
•
•
•
Preconditions: Cashier identified and authenticated
Postcondtions: Sale completed, tax calculated, inventory updated,
commission recorded, cc approval recorded
MainSuccessScenario:
1.
2.
3.
4.
Customer arrives with goods
Cashier starts new sale
Cashier enters item identifier
Systems records sale and presents description and
running total
(repeat 3-4 many times)
1. System presents total
2. …
Fully Dressed Use Case (3):
•
Extensions:
…
– 2-4a: Customer tells Cashier of tax-exempt status
1. Cashier verifies, enters tax-exempt code
2. System records tax-exempt status of sale.
…
•
SpecialRequirements:
–
–
–
–
–
touch screen
cc authorization in 30 seconds or less
robustness of remote system (inventory) fails
internationalizable
…
Fully Dressed Use Case (3):
•
TechnologyAndDataVariations:
–
–
–
–
•
manager override is card swipe or keyed entry
item ID is bar coded or keyed in
cc uses card reader or keyboard
signature on paper receipt
Frequency:
– All the time.
•
OpenIssues:
– tax law variations
– remote service recovery issue
– business customization
Section Meanings:
•
Scope: system boundary; two broad types of scope – system and
business.
•
Level: level of detail; user or sub-function.
– User level corresponds to elementary business
process (EBP).
– Sub-function level supports some user level goal and
factors out otherwise redundant description.
•
Actor: Who asks the system to fulfil this goal?
•
Stakeholders: Those interested in the system. System implements a
contract with stakeholders.
What should be in a use case?
That which satisfies all stakeholders’ interests
Section Meanings (2):
•
Preconditions and Success Guarantees: Keep to the non-obvious.
Otherwise, it is just “noise”.
– preconditions: what is true before each instance of the
use case
– postconditions: always true on success.
•
Main Success Scenario: The “happy path”. This often has no
branches. Put conditions in Extension section. Bullets in this section
record:
– an interaction between actors (system also an actor)
that gets the scenario started
– a validation
– a state change
Section Meanings (3):
•
Extensions:
–
–
–
–
Most of the text.
All the special cases.
Failure situations put here.
“Most” stakeholder concerns either here or in Main.
(Non-functional requirements elsewhere)
– Be direct in your expression; not inferential or vague
– Complex extensions can become separate use cases.
– Notation:
•
•
•
•
4a is an exception for main scenario 4.
3-6a extension can happen in main scenario steps 3-6.
*a can happen in every main scenario step.
Subsections of an extension section are “mini”-use cases.
Section Meanings (4):
•
Special Requirements: This is the place for non-functional
requirements, quality attributes or constraints. Include performance,
reliability, usability, etc.
•
Technology and Data Variations:
– Specify alternatives such as “print to file or printer”.
– Specify the data formats, for example “data
exchanged in XML”.
– Can express future plans for the system.
Use Cases: Written and Wrong!!
•
Because of the iterative, evolutionary, time-boxed versus waterfall
approach, initial use case are always “wrong” because they are always
“incomplete”.
•
Fill out your understanding when coding.
•
Good reason for not using Waterfall.
Questions of Style (Essential Use Cases):
•
The user says she needs to “log in”, meaning userID and password;
you describe this as “authentication and authorization”. Don’t be more
specific than you need to be.
•
Results on use cases at right level of abstraction.
•
Use cases should express “goals” not “means”.
•
Use cases should express user “intentions” and system
“responsibilities”, not concrete actions.
•
Use cases are a “design” document; too early to get bogged down in
details.
•
This style results in black-box use cases – use cases that describe
what but not how.
•
“How” includes UI details; to be avoided.
An Actor-Goal Approach:
•
Use cases should always perform an action that results in something
useful for the primary actor.
•
This guarantees that your write the use case at the appropriate level.
•
Compare this to the “feature and function” list of the 1970s.
•
Does it ever hurt to focus on what the customer values?
•
Remember we are still early and still talking to the customer a lot;
shouldn't get into implementation strategies.
How to Find Use Cases:
•
Remember, use cases satisfy goals of primary actors so:
– choose a system boundary and identify the primary
actors (often brainstorming the actors highlights the
system boundaries)
– identify their goals vis-à-vis this system
– define the use cases that achieve those goals
system
actors, both primary
and secondary
Questions to Ask Yourself When Looking for Actors/Goals:
•
Who starts and stops the system?
•
Who does user and security management?
•
Who does system administration?
•
Is “time” an actor? Is the system event driven?
•
Is the system monitored (cron job)?
•
How about updates?
•
Are their non-human primary actors (other systems)?
•
Who evaluates performance and activity?
•
Who looks at the logs?
•
Who gets notified on error?
Organizing Actors and Goals
•
Draw a little picture (Use-Case Diagram) for each (Actor,Goal) pair or
make a list of actors and goals
•
What goes in the picture? system boundary, primary and secondary
actors, their goals; ie, the essence of a Use-Case.
Why focus on Actors and Goals?
•
Don’t ask an actor “What do you do?”, ask “What are your goals?”
•
“What do you do?” will illicit answers that
– describe how they do things, not what they do.
– describe current practices not long-term needs
•
“What are your goals?” will illicit answers that
– offer the opportunity to think of new and improved
solutions
– focus on business value, not business function
– get to the heart of what stakeholders want
– give more opportunity for developer creativity
Example: Worker Punch Clock System Replacement
Actor
What do you do?
What is your goal?
worker
Punch my card when I Accurately record the
get to work, go to and time I am on the job
return from lunch, go
home
Book-keeper
Transfer worker daily
“on-site” hours to
book-keeping system,
calculate hours.
Know how many
hours each worker
has worked
boss
Sign off on bookkeeper Hours and
Wages Report,
resolve disagreements
Pay only for hours
worked. Keep workers
from “punching in” for
one another
Potential Solutions
•
Computerized login/passwd screen.
•
Employee ID card magnetic strip reader
•
Biometric palm reader
Only the “goals” approach directly lead us to the third solution.
Fig. 6.2
system boundary
some actors are
other systems
some actors are
“offstage”
s
g
in
h
gT
llin
e
eS
ris
rp
te
n
E
e
ic
rv
e
tS
u
o
k
c
e
h
C
x
a
sT
le
a
S
y
c
n
e
g
A
t
c
lle
o
l:C
a
o
G
s
le
a
ns
so
e
x
ta
m
te
s
y
SS
O
P
ity
tiv
c
sA
le
a
S
m
te
s
y
S
r
ie
h
s
a
C
r
e
m
to
s
u
C
s
m
yite
u
l:B
a
o
G
s
le
a
es
z
ly
a
n
l:A
a
o
G
ta
a
ed
c
n
a
rm
rfo
e
dp
n
a
s
le
a
ss
s
e
c
ro
l:P
a
o
G
Why is the customer not the primary actor for the POS system?
Depends on system boundary.
Alternatives for Finding Actors/Goals/Use Cases:
•
Start with an External Event Analysis. Responding to external events
is what systems do.
•
One use case per user goal
•
Use Case names should be wiki names starting with a verb
•
Exception: insert/update/delete are grouped as one use case –
manage().
Use Case Tests:
•
Boss Test: Especially for the “architecturally significant” use cases,
your boss should think this is essential to the business.
•
EBP Test: An Elementary Business Process is defined as
•
A task performed by one person in one place at one time,
in response to a business event, that adds measurable value
to the
business
leaves
data in ain
consistent
state.
Test:
Use
casesand
that
youbusiness
can express
less than
a page
Size
are often
not significant. Fully-dressed use cases take 3-10 pages to explain.
Exercise:
•
Test the following possible use cases:
–
–
–
–
negotiate a supplier contract
handle returns
log in
move pieces on a game board
Exercise:
•
Test the following possible use cases:
– negotiate a supplier contract
• broader and longer than an EBP, “business” not “system” use
case
– handle returns
• Boss, EBP and Size all seem to fit
– log in
• never keep boss happy
– move pieces on a game board
• too big
A Use Case Diagram:
Actors (primary and secondary), System Boundary and Goals
Fig. 6.3
system boundary
NextGen POS
communication
Process Sale
Customer
Payment
Authorization
Service
Handle Returns
actor
«actor»
Tax Calculator
Cashier
Cash In
«actor»
Accounting
System
Analyze Activity
«actor»
HR System
Manager
«actor»
Sales Activity
System
Manage Security
System
Administrator
Manage Users
use case
...
alternate
notation for
a computer
system actor
Fig. 6.4
For a use case context
diagram, limit the use cases to
user-goal level use cases.
Show computer system actors
with an alternate notation to
human actors.
NextGen
«actor»
Payment
Authorization
Service
Process Sale
Cashier
...
primary actors on
the left
supporting/offstage
actors on the right
Fig. 6.5
Alternative Notational Systems
N
e
x
t
G
e
n
P
r
o
c
e
s
s
S
a
l
e
.
.
.
«
s
y
s
t
e
m
»
P
a
y
m
e
n
t
P
a
y
m
e
n
t
A
u
t
h
o
r
i
z
a
t
i
o
n
A
u
t
h
o
r
i
z
a
t
i
o
n
S
e
r
v
i
c
e
S
e
r
v
i
c
e
«
a
c
t
o
r
»
P
a
y
m
e
n
t
A
u
t
h
o
r
i
z
a
t
i
o
n
S
e
r
v
i
c
e
S
o
m
e
U
M
L
a
l
t
e
r
n
a
t
i
v
e
s
t
o
i
l
l
u
s
t
r
a
t
e
e
x
t
e
r
n
a
la
c
t
o
r
s
t
h
a
t
a
r
e
o
t
h
e
r
c
o
m
p
u
t
e
r
s
y
s
t
e
m
s
.
T
h
e
c
l
a
s
s
b
o
x
s
t
y
l
e
c
a
n
b
e
u
s
e
d
f
o
r
a
n
y
a
c
t
o
r
,
c
o
m
p
u
t
e
r
o
r
h
u
m
a
n
.U
s
i
n
g
i
t
f
o
r
c
o
m
p
u
t
e
r
a
c
t
o
r
s
p
r
o
v
i
d
e
s
v
i
s
u
a
l
d
i
s
t
i
n
c
t
i
o
n
.
An explanatory note;
ULM provides for these
Activity Diagrams:
•
A UML diagram for visualizing workflows and business processes.
•
Show the inter-relatedness of various use cases
•
page 477
Fig. 28.1
Partitions. Show different
parties involved in the process
start
Fulfillment
Customer
Service
Finance
Action. It does something.
There is an automatic
transition on its completion.
Object Node. An object
produced or used by actions .
This allows us to model data
flows or object flows.
Receive Video
Order
A transition supports
modeling of control flow.
Fork. One incoming
transition, and multiple
outgoing parallel transitions
and/or object flows.
Fill Order
Send Invoice
Invoice
Order
Receive Payment
Deliver
Order
Join. Multiple incoming transitions and/or
object flows; one outgoing transition.
The outgoing continuation does not happen
until all the inputs arrive from all flows.
end of activity
Close Order
Fig. 28.7
actors
Customer
Cashier
NextGen POS
Authorization
Service
Shop and Fill
Cart
Cart
Enter Cart Items
actions
Calculate Taxes
and Discounts
[ cash
payment ]
objects
[ else ]
Submit
Authorization
Request
data flow
Create Receipt
Receipt
Hand Over Items
control flow
Authorize
Payment
Motivation:
•
Focusing on user goals:
– keeps the user happy.
– keeps you from writing a long features list.
•
Writing a use case in a context of a typical scenario
– keeps you working at the right level
– aids in cohesion and reduces coupling
Example: In an Inventory System we have Product and Inventory objects
and the job of adding a product to inventory.
Where to we put the responsibility of adding the Product? Does a Product
add itself? Is the Inventory system responsible for adding things to itself?
An Aside:
A highly cohesive, lowly coupled system
Train-RailCar Example:
add() method; where does it go?
This is a “responsibility” question.
An Aside (continued):
An uncohesive, highly coupled system
One Final Note:
•
The author says that some times a Use Case point-of-view is not
always easy to come up with. In particular, for application servers,
database back-ends and other middleware.
•
This is unfortunate since a lot of work being done today is done on
these kinds of back-end systems.
•
However, many back-end activities are in support of front-end
activities and so the front-end use cases can be an indirect guide to
how these back-ends should evolve.
•
As well, even back-end systems benefit from being developed, first
from a point-of-view of “what” needs to be accomplished and only
later, “how” to do that.
Fig. 6.6
Monopoly Use Case Diagram
Monopoly Use Case Text:
•
Scope: Monopoly Application
•
Level: User Goal
•
Primary Actor: Observer
•
Stakeholders: Observer; easily observe game simulation output
•
Main Scenario:
1. Observer requests new simulation, enters num
players
2. Observer starts play.
3. System displays game trace after each play
4. Repeat 3. until game over or Observer cancels
Monopoly Use Case Text:
•
Extensions:
– *a: At any time, system fails
(System logs each move)
1. Observer restarts system
2. System detects failure and reconstructs correct state,
continues
3. Observer chooses to continue
•
Special Requirements:
– Provide graphical and text trace modes
Use Cases and Iterative Methods:
•
Functional requirements recorded in Use Cases
•
In each iteration some Use Cases are developed, partially or
completely.
•
Use Case realizations drive the design and development.
•
Use Cases influence documentation design
•
Functional and system testing corresponds to Use Case Scenarios
•
Development environment UIs are created to manage the most
important Use Case scenarios
Use Case Evolution across Iterations:
Discipline
Artifact
Inception
1 week
Elab 1
4 weeks
Elab 2
4 weeks
Elab 3
3 weeks
Elab 4
3 weeks
Requirements
Use Case
Model
2-day ReqWS,
most UCs
named,
summarized
10% in detail
Near end, 2day ReqWS
Insight from
devel’ment
30% in detail
Near end, 2day ReqWS
Insight from
devel’ment
50% in detail
Repeat,
complete
70% of Use
Cases in
detail
Repeat,
complete
90% of Use
Cases in
detail
Design
Design
Model
none
Design small
set of high risk
Reqs
repeat
repeat
Repeat, most
things stable
Implementation
Code, etc
none
Implement
these
Repeat,
5% of final
system built.
Repeat,
10% of final
system built.
Repeat,
15% of final
system built.
Project
Management
SW Devel
Plan
Vague
estimates
Estimates take
shape
A little better
A little better
Most
estimates
reationally
committed to.
Two more phases: Construction and Transition
UP Artifacts and their Timing:
Disciplne
Artifact
Incep
I1
Business Domain Model
Modeling
Require- Use Case
ments
Vision
Sup Specs
Glossary
Design
Design Model
SW Architecture
Document
s – start
r - refine
Elab.
E1..En
Const.
C1..Cn
s
s
s
s
s
r
r
r
r
s
s
r
Trans.
T1..Tn
Fig. 6.7
When
Where
Once during inception. Short; do not try to
define or polish all requirements.
At a requirements workshop.
Several times during elaboration iterations.
January
February
Two adjacent projections.
Use Case: Capture a Sale
...
Main Success Scenario:
1. ...
2. ...
3. ...
Extensions:
System
Analyst
End User
Use Case: Handle Returns
...
Main Success Scenario:
1. ...
2. ...
3. ...
Extensions:
Customer
Developer
Software
Architect
How: Tools
Who
Many, including end users and developers, will play
the role of requirements specifier, helping to write
use cases.
Led by system analyst who is responsible for
requirements definition.
Software:
 For use case text, use a web-enabled requirements tool
that integrates with a popular word processor.
For use case diagrams, a UML CASE tool.
Hyperlink the use cases; present them on the project website.
Hardware: Use two projectors attached to dual video cards and
set the display width double to improve the spaciousness of the
drawing area or display 2 adjacent word processor windows .