Transcript Document
Use Case Analysis
Dr. Zhen Jiang
West Chester University
E-mail: [email protected]
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