Use Case Analysis
Dr. Zhen Jiang
West Chester University
E-mail: zjiang@wcupa.edu
url: www.cs.wcupa.edu/~zjiang
Outline

What are use cases?
 How to do it?
 Tips!
What are use cases?

An use case is
– A way of

One way direction
– capturing

Co-creating (User and designer)
– functional

No performance or usability
– requirement for a
 Goals, not design
– system
What are use cases?

Each use case defines an interaction
between an actor and the system
Use case
Use case
Use case
Use case
What are use cases?

A use case is an envelope of scenarios

Use case name is goal statement


Scenarios are the stories of attempts at the goal




Order product from catalogue
“sunny day”-everything works out
Agent is not authorized
Customer has insufficient credit
Use case is goal plus scenarios




Each use case has many scenarios
Each scenarios is described in terms of steps
The scenario steps form a directed graph, and every path
(scenario) either succeeds in realising the goal, or fails in
some way
Use cases represent (textually) the graph as a whole rather
than each scenario separately
What are use cases?

Scenarios of a use case (stories)
Reception
Check
Waiting
Failure
Authorized
Success
Failure
What are use cases?

Use Case template
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Name and unique ID
Version info.
Scope & level
Goal in context
Preconditions
Successful outcome
Failure outcome
Primary actor
Secondary actors
Main scenario
Alternatives
Variations
Related info.
Issues
What are use cases?
 Use case model
– Preamble

is made up of
Introducing any general considerations, style,
assumptions that will aid the reader
– Actor list
 Role names and brief descriptions
– Use case list
 Names and unique ids
– Set of use cases
 Using the template
– Issues
 For the use case model (not for the project)
How to do it – four steps

Identify primary actors and goals
 Write a scenario (path) in which the goal is
delivered
 Identify failure conditions for scenario steps
 Follow each alternative (exception) until it
ends or rejoins
Step ¼ Primary actors and goals

Identify primary actors and goals




Ask: what people and other systems will
drive our system?


Actors are roles, not people or things
A single person may be many actors
Any interaction across a system boundary implies an
actor
Result: a list of actor names and brief descriptions
Ask: what does each actor want our system
to do? (The goal of each actor when using
our system)

Result: a list of use case names, top-level coverage of
Capturing Actors

An actor is a role



Simple to capture



Actor name
Brief description
Listing the actors helps with completeness


Financial Planning Manager (insurance salesman
Bank teller
Covering all the uses of the system
Primary actors are those which initiate use
cases
Advice & guidance

Name the use cases
 Remember to think about actors
 Express goals from point of view of actor
 Use the “1 person, 1 place, 1 time” rule of
thumb to judge the appropriate granularity at
which to identify business goals / use cases
 The system doesn’t know which actor is the
user (do not include name of actor in use case name)
 Don’t worry too much about secondary
actors
Secondary actors

Secondary actors are used by the system
under design
 Will appear on the system context diagram
 May be mentioned in the Non-functional
requirements
 Usually secondary actors are system roles
Discussion

Home shopping assignment
Think about …

How big is a use case?
 What if there are multiple access channels?
 Relationship of use cases to business processes?
Step 2/4 Simple goal delivered

For each use case, write a scenario in which
the goal is delivered
 The main success scenario, the happy day
case



Capture the actor intent and system
responsibility through to goal delivery




Easies to read and understand
Everything else is a complication on this
Say what information passes between them
Number each line
User, system, user, system, …
Result: coverage of function of each use
case
Example

Place an order (UC1)
 Clerk identifies customer
 System lists customer account details
 Clerk creates order
 System verifies and submits order
 Use case end successfully
Preconditions

A precondition is an assumption which must
be true before a use case is used
 Preconditions are not checked within a use
case
 Use preconditions to express dependencies
between use cases
 What
must have happened before the start of the
main scenario? For example: clerk is logged
on.
Steps refer to lower-level
goals

Main scenario: clerk identifies customer (UC7)
 UC77:






System prompts for customer name
Clerk enters customer name
System lists matching customer name and address
Clerk selects customer
End successfully
Alternatives (exceptions)


Customer name is not found
 System reports
 Continue at step 1
Use case ends in failure (account expired)
Advice & guidance

Assume all steps succeed
 Include a final “Use case ends successfully” step
 Start each step “System…” or “Actor…”
 Choose just one success scenario (It is only a staring
point from which to think about alternatives later)

Preserve system/Actor alternation by joining
actions (System validates PIN and prompts for withdrawal
amount)
Use language which doesn’t imply a solution,
unless that particular solution is required
 Preconditions should show dependencies

Discussion

Home shopping assignment
 No exception
 No details
 Maybe no relationship
 Pay more attention on assumption and
precondition
Step ¾ Failure conditions
Identify potential failure conditions for scenario
steps
 Ask: what can go wrong?
 Result: list of conditions which will be used to
develop alternative scenarios

Failure scenarios help with
completeness

Particular questions we might ask
What if their credit is too low?
 What if they run over the extended credit limit?
 What if we cannot deliver the quantity?
 What if the order is placed too late?


Such questions are commonly overlooked
Advice & guidance

Brainstorm first

Failures of whole system, individual use case, or steps in
scenarios
Don’t worry about effect of failures on use cases
 Then review list to exclude:


Failures which are ruled out by preconditions
 IT failures
 Failures which cannot be detected by system
 Failures which cannot be acted upon by the system

Use this step to be creative

Push boundaries of requirements
Discussion

Home shopping assignment
Step 4/4 Alternative scenarios






Each failure condition introduces an alternative
scenario
Decide at which step the new scenario diverges
Follow the alternative until it ends or rejoins
Recoverable alternatives rejoin the main course
Non-recoverable alternatives end use case in
failure
Result: use cases expressed as set of scenarios
Advice & guidance




Numbering of steps is important
A step may have several alternatives
Alternative step may themselves have alternatives
End each alternative either:
– Use case ends successfully
– Use case ends in failure
– Use case continues at step N


Looping is allowed
Finally-fill in the failure table with the failure
types
Summary

Functional requirements have got to be
captured somehow
 It encourages asking the right questions at
the right time
 It’s systematic


To check coverage or evenness of details
The results are quickly navigated



Top-level is absorbed very quickly
Explore details where needed
Uniformity of format simplifies exploration of details
Tips







Dealing with data
Connection to business rules
Using generic use cases
Writing the preamble
Forward to the analysis model
Envisioning and designing
When use cases aren’t suitable
Dealing with data

Keep the data abstract
 Catalogue the data under “Related information”
 This works because



Keeps focus on the systems’ use
Keeps data descriptions together
Encourages sharing these descriptions within and
across use cases
Connection to business rules
Clue – detailed conditions or actions that might
change
 Fear – use cases will change often
 Solution – explicit business rules – back to the
business!

Using generic use cases
Clue – Lots of similar things and new ones
 Fear – Endless new use cases, interactions and
objects
 Solution – Generic (abstract) use case

Writing the preamble

Vital to set context for the reader/reviewer
 Typical content

Role of use case model in this project
 Level of detail
 Style
 Navigation, order of steps
 Assumptions on input error handling
Forward to the analysis model


Analysis model (AM)

Classes, associations, responsibilities, interactions

Entities, relationships, processes (functional)
AM delivers behavior described in the use cases
 Keep the AM in view when doing use cases
 Begin to identify data relationships
(objects/entities)
 Begin to identify common behavior
 So-Backwards from the analysis model
Envisioning and designing

Use cases require a vision of the system




Can you imagine it?
Can you say yes/no quickly on scope?
Are you wondering what the solution is like?
Envisioning techniques

Storyboarding


Narrative for a whole business process
Screen shots to indicate system contributions
When use cases aren’t
suitable

Lots of state ->statechart
 Automated processing->time sequence diagram
 Infrastructure->technical document