A Use Case Primer
1
The Benefits of Use Cases
 Compared to traditional methods, use cases are easy to




write and to read.
Use cases force the developers to think through the
design of a system from the perspective of a user.
Use cases engage the users in the requirements
process, helping them to understand the proposed
system and giving them a way to communicate their
needs.
Use cases give context for the requirements of the
system.
Use cases provide an ordering mechanism for
requirements; they show the ordering of things.
2
The Benefits of Use Cases
(Cont’d)
 In most cases, developers write use cases. That shows




they understand the requirements and accept
responsibility for them.
Use cases are a critical tool in the analysis process,
helping to understand what the system needs to do.
Use cases are a critical tool in the design and
implementation process, reducing the risk of
inconsistencies when moving from requirement to design
to implementation.
Use cases carry over directly into the testing process.
Use cases serve as inputs to the user documentation.
3
What is a Use Case?
A use case describes sequences of
actions a system performs that yield
an observable result of value to a
particular actor. (In UML, a use case
is represented by an oval.)
4
Use Case Basics
 Sequences of actions:



The sequences of actions describe a set
of functions performed, an algorithmic
procedure, or any other internal process
that produces a result.
The set is invoked when the actor
initiates the use case by providing some
input to the system.
An action is atomic; that is, it is
performed entirely or not at all.
5
Use Case Basics (Cont’d)
 System performs:


The system works for the actor.
It exhibits the functionality described in
the use case and takes its orders from
the actor as to when to do what.
 An observable result of value:


The use case must be “of value” to a
user.
The system must do something for the
user.
6
Use Case Basics (Cont’d)
 A particular actor:

The particular actor is the individual or
device that initiates the action.
7
What is an Actor?
An actor is someone or something that
interacts with the system. (In UML an
actor is represented as a simple stick
figure.)
8
Types of Actors
 Users:

Users act on the system and this is the
most common type of actors.
 Other Systems or Applications:
 Most software systems interact with other
systems or applications. These are also
actors.
 A Device:
 Input and output devices can also be
actors.
9
Mandatory Elements of a Use
Case
1.
2.
3.
Name: Each use case has a name which
describes what is accomplished by interaction
with the actor. It must be unique for each use
case.
Brief Description: The purpose of the use case
should be described in one or two sentences.
Actors: Since a use case has no meaning
outside its use by an actor, each actor that
participates in the use case must be listed.
10
Mandatory Elements of a Use
Case (Cont’d)
4. Flow of Events: The heart of the use
case is the event flow, usually
expressed as a textual description of the
interactions between the system and the
actor. The flow of events can consist of
both the basic flow, or main path through
the use case and alternate flows which
are executed only under certain
circumstances.
11
Optional Use Case Elements
 Pre-conditions: Those conditions that must
be true before a use case can start.
 Post-conditions: Conditions that describe the
state of the system after a use case has
completed.
 System or Subsystem: In a system
comprised of many subsystems, it must be
specified whether a use case is a systemlevel use case or which subsystem it is
identified with.
12
Optional Use Case Elements
(Cont’d)
 Other Stakeholders: It may be useful to
identify other stakeholders who are
affected by the use case.
 Special Requirements: There may be
special requirements (e.g.,
performance or throughput) that may
be related to a use case that should be
specified.
13
Optional Use Case Elements
(Cont’d)
 Other Stakeholders: It may be useful to
identify other stakeholders who are
affected by the use case.
 Special Requirements: There may be
special requirements (e.g.,
performance or throughput) that may
be related to a use case that should be
specified.
14
Building the Use Case Model

It is a top down process that depends on
first building a context model of the system.
 That model is successively refined until the
detailed behaviors are understood.
 It is an iterative process in which the various
steps are revisited over time.
15
Steps in Building the UseCase Model
1.
Identify and Describe the Actors: Identify all
actors that interact with the system.
Who uses the system?
Who gets information from the system?
Who provides information to the system?
Where in the organization is the system used?
Who supports and maintains the system?
What other systems use the system?
16
Steps in Building the UseCase Model (Cont’d)
2.
Identify the Use Cases and Write a Brief
Description: Identify what actors need to do
to accomplish their tasks.
What will the actor use the system for?
Will the actor create, store, change, remove, or
read data in the system?
Will the actor need to inform the system about
external events or changes?
Will the actor need to be informed about
certain occurrences in the system?
17
Steps in Building the UseCase Model (Cont’d)
 Choose Use-Case names carefully –
a few words beginning with a verb is
usually a good idea, e.g., “Change
Password”.
 Consider the following template:
Use-Case Name
Actor(s):
Description:
18
Steps in Building the UseCase Model (Cont’d)
3. Identify the Actor and Use-Case
Relationship: Although only one
actor can initiate a use-case, many
use-cases involve the participation of
multiple actors. Each use-case must
be analyzed to see what actors
interact with it.
19
Steps in Building the UseCase Model (Cont’d)
4. Outline the Individual Use Cases:
Before developing detailed use-cases
for the system, outlines of each
should be developed. Of particular
interest at this point is the flow of
events, including the basic and
alternate flows.
20
Steps in Building the UseCase Model (Cont’d)

Basic flow:




What event starts the use case?
How does the use case end?
How does the use case repeat some behavior?
Alternate flow:






Are there optional situations in the use case?
What odd cases might happen?
What variants might happen?
What may go wrong?
What may not happen?
What kind of resources can be blocked?
21
Steps in Building the UseCase Model (Cont’d)
5. Refine the Use Cases: At some point
later in the project lifecycle, the time
will be right to refine the use cases
developed. At that time there are a
number of additional factors to be
considered.
22
Steps in Building the UseCase Model (Cont’d)

All alternate flows, including exception
conditions: Identifying primary alternate
flows is straightforward, but flows due to
exception conditions may not be clear
initially.
 Pre- and Post-conditions: The refinement
process will start to identify state information
that controls the behavior of the system
23
Use Cases and User
Interfaces
 The world of use-case specification and
user interface design tend to lead
parallel lives.
 The development team must decide
what choices the user makes given the
screens, dialog boxes, and so on that we
have presented to the user, what the
system does based on those selections,
and what screens, choices, and so on
the system presents to the user.
24
The Use Cases and User
Interfaces Conundrum
 How can a use case be specified if the
user interface hasn’t been designed yet?
 How can the user interface be designed
to implement use case that have yet to
be specified?
25
Use Cases and Storyboarding
 A Storyboard Defines:
 Who the players are
 What happens to them
 How it happens
 If the player is a specific user and the
interaction is between that user and the user
interface, then storyboarding can help us
describe how we are approaching the
interaction.
 We can use iterative and incremental
techniques to converge on the user interface
and the use case at the same time.
26
Use Case Storyboard Example
Use Case Sequence: Inserting Online Clip Art
(This series of steps within a larger use case allows the
user to access an online clip art repository and select
and insert a new clip art item.)
1.
2.
3.
4.
5.
The user puts the cursor at the desired clip art location
and selects the function for inserting clip art.
The system displays the clip art source locations.
The user selects the “Clip Online” choice.
The system launches the browser and automatically
navigates to the online library.
The user navigates to the selected art item.
...
27