Systems Analysis II
Use Cases
INFO 355
Glenn Booker
INFO 355
Week #2
1
Use Cases


INFO 355
As part of the activity to define
functional requirements, we can
capture those requirements in “use
cases”
“A use case is an activity the
system performs, usually in
response to a request by the user”
(text, 69)
Week #2
2
Use Cases and OO


INFO 355
Though use cases are often
associated with object oriented
analysis, use cases are not
object oriented
They could be used to help
capture functional requirements
for any type of system
Week #2
3
Finding use cases

Two methods (at least) for finding
use cases for a system



INFO 355
User goal technique
Event decomposition technique
To validate a draft list of use cases,
the CRUD technique can be used
Week #2
4
User goal technique


INFO 355
The main idea behind this technique
is to identify the types of users of a
system, then determine what goals
or assigned tasks each type of user
has when using the system
Those goals often correspond to use
cases
Week #2
5
User goal technique

The user goal technique is:



INFO 355
Identify all potential users for a system
(Optional) Classify users by functional
role (shipping, marketing, sales) and
operational level (operational,
management, executive)
Interview each user and determine
what goals they have when using the
system
Week #2
6
User goal technique




INFO 355
Make a preliminary list of use cases for
each type of user
Look for duplicates and inconsistencies
across users
Identify when multiple users need the
same use case
Review completed list with users and
other stakeholders for validation
Week #2
7
Event Decomposition

This approach looks for all events
that would lead to the information
system being used



INFO 355
Each event typically leads to a use case
Simplify events to ones that have a
clearly defined start and end, and
achieve a clear business purpose
Those are Elementary Business
Processes (EBPs) = use cases
Week #2
8
Event Decomposition


Focusing on events keeps attention
on the macro scale purpose of the
system, not internal details
Events can be



INFO 355
External – caused by an actor
Temporal – done at fixed time intervals
State – triggered by an internal
condition, e.g. low inventory
Week #2
9
Event Decomposition

Focus on events that directly cause
the system to be used



Not prior conditions that are invisible to
the system
Many important business processes do
not involve the system directly!
Avoid trivial use cases (logging on)
but DO include system controls
(admin functions such as backup)
The last point differs from the text!
INFO 355
Week #2
10
Event Decomposition

The event decomposition process is

Identify relevant external events


Identify relevant temporal events


INFO 355
For each, name a use case and define
when it occurs
Identify relevant state events


For each, name a use case
For each, name a use case
Omit trivial use cases, but keep system
controls
Week #2
11
CRUD technique



Use this technique for verifying an
existing list of use cases
Recall CRUD – create, read, update,
or delete data
The goal of this technique is to
verify at least one use case has
been identified to perform all
relevant aspects of CRUD

INFO 355
Relevant aspects?
Week #2
12
CRUD technique steps




INFO 355
Identify major data entities for your
system
For each, verify that at least one
use case does each of CRUD, as
appropriate to your system
Add use cases if needed
Make sure data ownership is clear if
more than one application interacts
Week #2
13
Naming use cases

Give use cases a short name (2-4
words), starting with an action verb




INFO 355
Track shipment
Create new user
Produce monthly sales report
The reason for brevity is so we can
put them on a use case diagram
Week #2
14
Use Case Diagram


A use case diagram summarizes all
the major use cases for a system
To define a use case diagram, need:




INFO 355
List of Use Cases
Actors
External Systems (if any)
System Boundary (automation
boundary)
Week #2
15
Actors


Actors are types of users of the
system – the role of someone who
uses the system
Actors must interact directly with
the system

INFO 355
Interaction could be through any
mechanism – keyboard, mouse, touch
screen, card reader, voice, biometric,…
Week #2
16
Actors

Examples of actors include





INFO 355
Customer/Client/Patient/Patron/Donor/
Subscriber (if they interact directly)
Manager (should be more specific)
System Administrator
Clerk
Foreman
Week #2
17
External Systems

External systems are any nonhuman (generally computerized)
actor which your system needs to
perform one or more use cases


INFO 355
Can be a Timer, to initiate
automatically repeating use cases
Are systems you don’t control, and
are outside the scope of your
system development
Week #2
18
External Systems

Could include systems owned
by vendors


Could be a custom legacy system
which isn’t being replaced

INFO 355
E.g. a service to maintain your
online catalog
E.g. an existing human resource
system, or accounting system
Week #2
19
System Boundary

The use case diagram includes a
box to show the boundaries of
your system




INFO 355
Actors are not within the boundary
External systems are not within
the boundary
Box is labeled with your system’s name
(not just “System”)
The use case diagram acts like a
context diagram
Week #2
20
Naming Use Cases


Each use case should have a brief
name, typically 2-4 words
Start with a verb, and end with
a noun




INFO 355

Cancel Customer Order
Place Order
Validate New Customer
Number use cases sequentially
Week #2
21
Use Case Diagram Notation



Actors are represented by stick
people, with their role below them
Use cases are represented by ovals
External systems are represented
by rectangles, with “<<actor>>”
before the system name


INFO 355
“<<actor>>” is a stereotype
The “<< >>” should be guillemets
Week #2
22
Sample Use Case Diagram
Sale Processing System
<<Actor>>
Tax Calculator
1. Process Sale
<<Actor>>
Accounting
System
Cashier
2. Handle Returns
Tip: Straight lines
are easier to use!
INFO 355
Payment Service
Week #2
23
Use Case Diagram Notation

Lines connect actors to the use
cases they can perform


INFO 355
Hence a major purpose of the use
case diagram is to show what functions
the system can perform, and who can
use them
Notice there is no indication of when
use cases are performed, or any of
the logic behind them
Week #2
24
Generalization

A common concept for the use case
diagram is when one actor has
some special use cases, but also
can do everything some other
actors can


INFO 355
A manager or supervisor can do
everything their staff can do, plus
additional functions
Show this using generalization
Week #2
25
Generalization

Notice the triangle at the top of the
line between Manager and Staff

Staff


This means that Manager inherits
all use cases which Staff can do
(Also can use generalization in
Class diagrams)
Helps keep use case diagram
simpler and easier to read
Manager
INFO 355
Week #2
26
“Included” Use Cases


When documenting use cases,
might find a clear set of activities
that appears in two or more
use cases
Can pull those activities out and
make that an included use case


INFO 355
In Visio, lines to an included use case
have the stereotype “<<uses>>”
In other applications, stereotype is
“<<includes>>”
Week #2
27
“Included” Use Cases

The included use case is
documented separately from
the use cases which use it
Place Order
«uses»
«uses»
Use case
numbering and
system boundary
omitted
INFO 355
Sales Clerk
Validate Credit
Card
Change Existing
Order
Week #2
28
Subsystem use case diagram


Ideally all actors and use cases
should fit on one diagram
If not, it’s ok to have a separate use
case diagram for each major
subsystem

INFO 355
Specify whether the diagram includes
all users (preferred) or a limited subset
of them
Week #2
29
Documenting Use Cases


Use cases can be documented to
varying levels of detail
We’ll define two of them



These are local terms for the level
of documentation, not Cockburn’s


INFO 355
Casual use case documentation
Detailed use case documentation
(that’s pronounced CO-burn)
The text uses ‘Brief’ and ‘Fully developed’
Week #2
30
Casual Use Case Documentation

Consists of:




INFO 355
Use case number and name
Objective – A sentence to elaborate on
the main purpose of the use case
Primary Actor – what actor initiates the
use case
Main Success Scenario – a step-by-step
description of the events which should
occur during this use case
Week #2
31
Detailed Use Case Documentation

Consists of:






INFO 355
Use case number and name
Objective
Primary Actor
Secondary Actor(s) – other actors who
play a significant role in this use case
Trigger – what event forces the start of
this use case?
Main Success Scenario (MSS)
Week #2
32
Detailed Use Case Documentation

Extensions – when performing the
MSS, what other events could occur?




INFO 355
Extensions often include alternate
methods of processing, different ways to
do the same thing, and error conditions
Performance time – how long it should
typically take to perform this use case
Frequency – how often will this use
case be performed?
Open Issues – for scope issues, if any
Week #2
33
Beyond Detailed


INFO 355
The MSS and/or extensions should
cite included use cases, where
appropriate
Additional documentation is possible
beyond the detailed template just
given – see Cockburn’s site
Week #2
34
Main Success Scenario

The Main Success Scenario
describes the interaction between
actors and the system in order to
perform a use case


INFO 355
They are critical to write well, since
later documentation depends upon
them (e.g. sequence diagrams)
See Summary of UML Diagrams
handout for details on MSS writing
Week #2
35
Main Success Scenario

Where to begin?


INFO 355
For most use cases, you can assume
the actor has logged into the system
(if needed) and are starting at the
application’s Main Menu or its
equivalent
A MSS describes a use case in more
detail than you would typically
consider necessary
Week #2
36
Main Success Scenario

The MSS describes the most common way
a use case will be performed successfully



The MSS is the Disney version of the use
case

INFO 355
If there are multiple processing options, pick
the most frequent one for the MSS, and
describe the rest in the Extensions
In the MSS, assume all actions will be
successful; describe how to handle
unsuccessful outcomes in the Extensions
Extensions are the Tim Burton version
Week #2
37
Main Success Scenario

Typical actor activities in a MSS are:

Navigate through the interface to a
defined objective
“Shipping clerk navigates to the New
Shipment Screen.”
 Notice we didn’t say HOW they navigate,
just that it’s accomplished somehow


Enter data onto an interface
“Shipping clerk enters the data for a new
shipment.”
 Notice every field entered is not specified

INFO 355
Week #2
38
Main Success Scenario

Describe when an actor selects
something on an interface


“Dispatch manager selects the number
of drivers needed.”
Indicate when an actor completes an
activity, such as by submitting data
“Shipping clerk submits the new
shipment data.”
 This prompts the system to do something
with the data

INFO 355
Week #2
39
Main Success Scenario



INFO 355
The only remaining type of actor action
is to exit the application, which often
isn’t part of a MSS (assume you can
always cancel or exit from the system)
So there are few types of things an
actor might do during a MSS
System actions can be much
more complex
Week #2
40
Main Success Scenario

Typical system actions include:

Create a new interface screen


Change or update the contents of an
existing screen

INFO 355
“System displays Define Shipment
screen.”
“System updates the screen to show the
list of artifacts.”
Week #2
41
Main Success Scenario

Communicate with an external system
“System gets current stock price from
NYSE.”
 “System emails drivers with shipment
info.”


Perform an included use case


“System performs Validate Credit Card
use case.”
Perform background processing
“System validates new customer data.”
 “System computes the sales tax.”

INFO 355
Week #2
42
Main Success Scenario

Notice that the MSS includes steps
which aren’t visible to the actors!

Other background processing might
include
“System prioritizes the list of drivers.”
 “System produces weekly sales
summary.”


INFO 355
Background processing can include any
activity needed to prepare data for
presenting the results to the actor
Week #2
43
Main Success Scenario

Finally, make sure a MSS achieves the
overall objective of the use case!
“System saves new customer data.”
 “System updates order status.”
 “System deletes completed orders.”


INFO 355
These steps are typically performing
one of the CRUD functions
Week #2
44
Main Success Scenario

Writing a MSS might involve
making assumptions about
where or how data is stored



INFO 355
Can assume there is a place that stores
Customer Data, or Shipment Data, etc.
External systems should be labeled
consistently throughout the design
Can name interfaces (New Customer
Screen), but don’t design them (‘click
on the submit button’ = no!)
Week #2
45
Main Success Scenario


Throughout a MSS, look for actions
which need to be repeated
Specify in generic terms how many
times steps need to be repeated



INFO 355
For each book to be checked out, …
For each driver assigned to a shipment,
Repeat five times, or until login is
successful
Week #2
46
Extensions

Extensions, or alternate scenarios,
handle when something doesn’t go
normally during a use case

Extensions are numbered, starting with
the MSS step from which they depart
If an extension starts from step 5, the
first extension is a condition called 5.a
 Then the steps to respond to that
condition are 5.a.1, 5.a.2, etc.
 A second extension from step 5 is
condition 5.b and has steps 5.b.1, 5.b.2,
5.b.3, etc.

INFO 355
Week #2
47
Extensions Handle

So the lettered step (5.a) describes the
condition under which you perform that
extension


And the steps under it (5.a.1, 5.a.2, …)
are the actor and system actions that
follow
Optional processing steps can be an
extension; the rest of the MSS
isn’t affected if they aren’t used
Adding sales tax to an order
 Adding gift wrapping to an order

INFO 355
Week #2
48
Extensions Handle

Failure conditions – when a MSS step
can’t be performed successfully
If a search yields no results
 If payment is insufficient
 Can’t connect to an external system


Alternate processing – when a MSS
step can be processed differently
Handle domestic versus international
orders
 Handle different forms of payment

INFO 355
Week #2
49
Extensions

Assume that interfaces and data
transactions inside your system are
successful, and won’t result in an
extension, e.g.



INFO 355
Saving or reading data locally
Creating or updating interfaces
Otherwise every system step could
be an extension!
Week #2
50