Use Cases

Massimo Felici
Room 1402, JCMB, KB
0131 650 5899
mfelici@inf.ed.ac.uk
Use Cases
ƒ Specify only what a system is supposed to do, i.e.,
system’s functional requirements
ƒ Describe sequences of actions a system performs
that yield an observable result of value to a
particular actor
ƒ Model actions of the system at its external
interface
• High level view of the system
• Capture some structure
ƒ Capture how the system coordinates human action
• Link to scenarios keeps the activity concrete
ƒ Rapid change allows exploratory approach
ƒ Comprehensible by users

© 2004-2006 SEOC - Lecture Note 03 2

Use Cases
ƒ Support Requirements Engineering
• It is an effective means of communicating with
users and other stakeholders about the system
and what is intended to do
ƒ Strengths
• capture different actors views of the system
• comprehensible by naïve users
• capture some elements of structure in
requirements
ƒ Weaknesses
• Fail to capture non- functional requirements
• Fail to capture what the system shall not do
• Do not support analysis particularly well

© 2004-2006 SEOC - Lecture Note 03 3

The Benefits of Use Cases

ƒ Relatively easy to write and easy to read

ƒ Force developers to think through the design of a
system from a user viewpoint
ƒ Engage the users in the requirements process
ƒ Identify a context for the requirements of the
system
ƒ Support the requirement process
ƒ Critical tool in the design, implementation, analysis
and testing process
ƒ Serve as inputs to the user documentation

© 2004-2006 SEOC - Lecture Note 03 4

Use Cases at a Glance

ƒ A use case describes

sequences of actions a
system performs that
yield an observable
result of value to a
particular actor
• Sequence of actions: set
of functions, algorithmic
procedures, internal
processes, etc.
• System performs: system
functionalities
• An observable result of
value to a user
• A particular actor:
individual or device
© 2004-2006 SEOC - Lecture Note 03 5
Anatomy of Use Cases
ƒ Basic Diagrams
• actors are represented as stick figures
• use cases as ellipses
• lines represent associations between these things
• basic use case diagrams show who is involved with what.
ƒ Can be used to help in structuring systems
• For example, the scheduler and patient more or less form a
sub-system – look at delegating appointment management to a
single component or sub-system.
ƒ Take care to identify generic actors who do a
particular task
• Do not get confused with job titles, etc.
ƒ Use case diagrams should not be too complex
• Aim for reasonably generic use cases
• try not be too detailed at first
© 2004-2006 SEOC - Lecture Note 03 6
Use Case Basics
ƒ Actors
• An Actor is external to a system, interacts with the system,
may be a human user or another system, and has a goals and
responsibilities to satisfy in interacting with the system.
ƒ Use Cases
• identify functional requirements, which are described as a
sequence of steps
• describe actions performed by a system
• capture interactions between the system and actors.
ƒ Relationships
• Actors are connected to the use cases with which they
interact by a line which represents a relationship between
the actors and the use cases.
ƒ System Boundaries
• Identify an implicit separation between actors (external to
the system) and use cases (internal to the system)
© 2004-2006 SEOC - Lecture Note 03 7
 Generalizations
ƒ Actor Generalizations:
• Actors may be similar in how they
use the system (e.g., project and
system managers)
• An Actor generalization indicates
that instances of the more
specific actor may be substituted
for instances of the more general
actor
• E.g., A “health worker” is a
generalization of “nurse”, “doctor”
etc.
ƒ Use Case Generalizations:
• Indicate that the more specific
use case receives or inherits the
actors, behavior sequences, and
extension points of the more
general use case
• E.g., pay bill is a generalization of
bill insurance
© 2004-2006 SEOC - Lecture Note 03 8
The <<include>> Relationship
ƒ The <<include>>
relationship holds when
one use case is included
in others
ƒ The <<include>>
relationship declares
that a use case reuses
another one being
included
ƒ The included use case is
(typically not complete
on its own) a required
part of other use cases

© 2004-2006 SEOC - Lecture Note 03 9

The <<extend>> Relationship

ƒ The <<extend>> relationship holds when use cases extend, i.e.,

optionally provide other functionalities to extended use cases
ƒ A use case may be extend by (i.e., completely reuse) another use
case, but this is optional and depends on runtime conditions or
implementation decisions
ƒ Any use case you want to extent must have clearly defined
extensions points

© 2004-2006 SEOC - Lecture Note 03 10

Use Case Descriptions
ƒ A use case description should be ƒ A use case main flow is a
attached to each case in the generic sequence of actions
diagram undertaken in using the system
ƒ Provide further details for 1. Patient: request
design appointment to scheduler
2. Scheduler: queries System
ƒ Identify use case information
for available times
ƒ Complement use case diagrams 3. System: responds with
ƒ Provide generic test scenarios times
for the full system 4. Scheduler: negotiates with
Patient on suitable time
ƒ Templates capture/structure 5. Scheduler: confirms time
use case information
with system
• Some types of information, 6. System: responds with
e.g., actors, related confirmation of appointment
requirements, preconditions, (e.g. booking number)
successful/failed end 7. Scheduler: communicates
conditions, etc. confirmation to Patient

© 2004-2006 SEOC - Lecture Note 03 11

Basic Use Case Template
Use Case: <number> <the name should be the goal as
a short active verb phrase>
Goal in Context: <a longer statement of the goal, if
needed>
Scope: <What system is being considered black-box
under design>
Level: <one of Summary, Primary task, Subfunction>
Primary Actor: <A role name for the primary actor,
or description>
Priority: <How critical to your system/organisation>
Frequency: <How often it is expected to happen>
© 2004-2006 SEOC - Lecture Note 03 12
Another Use Case Template
Use Case: Use case identifier and reference number and
modification history
Description: Goal to be achieved by use case and sources for
requirements
Actors: List of actors involved in use case

Assumptions: Conditions that must be true for use case to

terminate successfully
Steps: Interactions between actors and system that are
necessary to achieve the goal
Variations (optional): any variations in the steps of a use case

Non-Functional (optional): List of non-functional requirements

that the use case must meet.
Issues: List of issues that remain to be solved
© 2004-2006 SEOC - Lecture Note 03 13
Using a Use Case Template

1. Learn to fill in all the fields of the

template in several passes
2. Stare at what you have so far
3. Check your project’s scope
4. Identify the open issues and a deadline for
the implementation
5. Identify all the systems to which you have
to build interfaces

© 2004-2006 SEOC - Lecture Note 03 14

 Creating Use Cases

ƒ Step 1. Identify and ƒ Step 3. Identify the Actor and

Describe the Actors: the Use Case Relationships

• can use checklists: who uses ƒ Step 4. Outline the individual

the system? who manages Use Cases
the system? who maintains
the system? Who provides ƒ Step 5. Prioritize the use
information to the system? cases
Who gets information from
the system? etc. • for instance, on the basis of
utility or frequency of use
ƒ Step 2. Identify and • depending on the process this
may be closely linked to what
Describes the Use Cases: is needed in the process
• What will the actor use the ƒ Step 6. Refine the Use Cases
system for? Will the actor • Develop each use case
create, store, change, (starting with the priority
remove or read information ones)
in the system? etc. • develop the associated use
case
© 2004-2006 SEOC - Lecture Note• 03structure the use case 15
VolBank: Creating Use Cases
ƒ Who are the main actors in the VolBank
example?
ƒ Can you identify all the main use case names
in the system?
ƒ What opportunities are there to structure
the use case diagram?
ƒ Can you see any non-functional requirements
that are present in the specification?
ƒ How well are non-functional requirements
represented in the use case diagram?
© 2004-2006 SEOC - Lecture Note 03 16
VolBank: Incomplete Use Cases

© 2004-2006 SEOC - Lecture Note 03 17

VolBank: Using Use Case Template
Use Case: 01 - deposit time
Goal in Context: The
VolBank system allows
volunteers to deposit their availabilities in terms of
time
Scope: volunteers’ profiles are unavailable
Level: Primary task
Primary Actor: Volunteers
Priority: It supports one of the major
functionalities of the VolBank system
Frequency: Every time volunteers provide
information about their availability
© 2004-2006 SEOC - Lecture Note 03 18
Building the Right System
ƒ Tracing Requirements ƒ Managing Change
• From Use Cases to • Stakeholders interaction,
Implementation business constraints,
• Mapping requirements to
design and code implementation issues,
• Orthogonality problem: the system usage and so on
structure of requirements may trigger requirements
and the structure of design
changes
and implementation are
different ƒ Assessing Requirements
• System architecture Quality in Iterative
• From Use Cases to Test
Cases
Development
• A scenario, or an instance of • Successive refinement,
use case, is an use case rather than absolute
execution wherein a specific completeness, or
user executes the use case
in a specific way
specificity, is the goal
• Requirements dependencies

© 2004-2006 SEOC - Lecture Note 03 19

Reading/Activity

ƒ Please read
• The Volere template
• You may want to use the Volere Template as support
to structure your course project’s requirements
• Alistair Cockburn’s paper Structuring Use Cases
with Goals
• You may want to use a Use Case Template to collect
and represent your course project’s use cases
• Articles on Modeling

© 2004-2006 SEOC - Lecture Note 03 20