Use Case Analysis

1
Use Case Analysis

• Dr. Zhen Jiang
• West Chester University
• E-mail zjiang_at_wcupa.edu
• url www.cs.wcupa.edu/zjiang

2
Outline

• What are use cases?
• How to do it?
• Tips!

3
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

4
What are use cases?

• Each use case defines an interaction between an
  actor and the system

Use case
Use case
Use case
Use case
5
What are use cases?

• A use case is an envelope of scenarios
• Use case name is goal statement
• Order product from catalogue
• Scenarios are the stories of attempts at the
  goal
  
• 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

6
What are use cases?

• Scenarios of a use case (stories)

Reception
Check
Waiting
Failure
Authorized
Success
Failure
7
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

8
What are use cases?

• Use case model is made up of
• Preamble
• 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)

9
How to do it 4 steps

• Identify primary actors and goals
• Write a scenario (path) in which the goal is
  delivered, including multilayer design
  
• Identify failure conditions for scenario steps
• Follow each alternative (exception) until it ends
  or rejoins
  

10
Step 1 Primary actors and goals

• Identify primary actors and goals
• Actors are roles, not people or things
• A single person may be many actors
• Any interaction across a system boundary implies
  an actor
  
• Ask what people and other systems will drive our
  system?
  
• 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 functional requirements

11
Capturing Actors

• An actor is a role
• Financial Planning Manager (insurance salesman
• Bank teller
• Simple to capture
• Actor name
• Brief description
• Listing the actors helps with completeness
• Covering all the uses of the system
• Primary actors are those which initiate use
  cases
  

12
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 doesnt know which actor is the user
  (do not include name of actor in use case name)
  
• Dont worry too much about secondary actors

13
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 systems

14
Discussion

• Home shopping assignment

15
Think about

• How big is a use case?
• What if there are multiple access channels?
• Relationship of use cases to business processes?

16
Step 2 Simple goal delivered

• For each use case, write a scenario in which the
  goal is delivered
  
• The main success scenario, the happy day case
• Easies to read and understand
• Everything else is a complication on this
• Capture the actor intent and system
  responsibility through to goal delivery
  
• Say what information passes between them
• Number each line
• User, system, user, system,
• Result coverage of function of each use case

17
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

18
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.
  

19
Steps refer to lower-level goals Multilayer
design

• 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)

20
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 doesnt imply a solution,
  unless that particular solution is required
  
• Preconditions should show dependencies

21
Discussion

• Home shopping assignment
• No exception
• No details
• Maybe no relationship
• Pay more attention on assumption and precondition

22
Step 3 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

23
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

24
Advice guidance

• Brainstorm first
• Failures of whole system, individual use case, or
  steps in scenarios
  
• Dont 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

25
Discussion

• Home shopping assignment

26
Step 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

27
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

28
Summary

• Functional requirements have got to be captured
  somehow
  
• It encourages asking the right questions at the
  right time
  
• Its 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
  

29
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 arent suitable

30
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
  

31
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!
  

32
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

33
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

34
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

35
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

36
When use cases arent suitable

• Lots of state -statechart
• Automated processing-time sequence diagram
• Infrastructure-technical document

37
Tips for UC design (from common mistakes)

• UC diagram is not data flow chart, no parallel
  process (or data flow) illustrated.
  
• UC diagram does not need to show (primary)
  actors action.
  
• UC diagram describes the actions, not statuses.
• UC diagram is directional. One directional
  diagram is for one primary actor.
  
• UC diagram is the place to locate the secondary
  actor.