Use Cases

Massimo Felici
Room 1402, JCMB, KB
0131 650 5899
mfelici@inf.ed.ac.uk
Use Case Diagrams
§ Intended to 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:
• not particularly strong in capturing non-functional
aspects; doesn’t support analysis particularly well.

SEOC1 Lecture Note 03 2

Why Use Case Diagrams?
§ Model actions of the system at its external
interface
§ High level view of the system
§ Capture how the system coordinates human
action
§ Rapid change allows exploratory approach
§ Link to scenarios keeps the activity
concrete
§ Comprehensible by users
§ Capture some structure
SEOC1 Lecture Note 03 3
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.
SEOC1 Lecture Note 03 4
Specimen Use Case Diagram

A use case
describes sequences
of actions a system
performs that yield
an observable result
of value to a
particular actor.

SEOC1 Lecture Note 03 5

Anatomy of a use Case Diagram
§ 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
• don’t get confused with job titles, etc.
§ Aim for reasonably generic use cases
• try not be too detailed at first.
§ Use case diagrams should not be too complex.
SEOC1 Lecture Note 03 6
Attaching Use Cases
§ Use cases should be attached to each case
in the diagram
§ Use case is a generic sequence of actions
undertaken in using the system, e.g.:
• Patient: request appointment to scheduler
• Scheduler: queries System for available times
• System: responds with times
• Scheduler: negotiates with Patient on suitable time
• Scheduler: confirms time with system
• System: responds with confirmation of
appointment (e.g. booking number).
• Scheduler: communicates confirmation to Patient
§ Provided generic test scenarios for the full
system
SEOC1 Lecture Note 03 7
Structure in Use Cases
§ Generalisations:
• between use cases;
• between actors in use cases
• pay bill is a generalisation of bill insurance.
• A “health worker” is a generalisation of “nurse”, “doctor”
etc.
§ Include relationships hold when one use case
is included in others
• For example, looking up medical records is included
in many other use cases.
§ One use case extends another when it has
the same function but is more particular
• For example, deferring payment as a means of
paying.
SEOC1 Lecture Note 03 8
Generalisations
§ Actor Generalisations:
• Actors may be similar in how they use the system
• For example: project and system managers
• An Actor generalisation indicates that instances of
the more specific actor may be substituted for
instances of the more general actor.
§ Use Case Generalisations:
• Indicate that the more specific use case receives
or inherits the actors, behaviour sequences, and
extension points of the more general use case.

SEOC1 Lecture Note 03 9

Creating Use Cases…
§ Step 1. Identify and Describe the Actors:
• can use checklists: who uses the system? who
manages the system? who maintains the system?
Who provides information to the system? Who
gets information from the system? etc.
§ Step 2. Identify and Describes the Use
Cases:
• What will the actor use the system for? Will the
actor create, store, change, remove or read
information in the system? etc.
§ Step 3. Identify the Actor and the Use
Case Relationships

SEOC1 Lecture Note 03 10

…Creating Use Cases continued
§ Step 4. Outline the individual Use Cases
§ Step 5. Prioritize the use cases
• for instance, on the basis of utility or frequency of
use
• depending on the process this may be closely linked
to what is needed in the process
§ Step 6. Refine the Use Cases
• Develop each use case (starting with the priority
ones)
• develop the associated use case
• structure the use case

SEOC1 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>
SEOC1 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
SEOC1 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

SEOC1 Lecture Note 03 14

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
SEOC1 Lecture Note 03 15
VolBank: Incomplete Diagram

SEOC1 Lecture Note 03 16

VolBank: Activity
§ In class, or afterwards if it is not completed
in class:
• 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?

SEOC1 Lecture Note 03 17

Reading/Activity
§ Please read the Volere template that is linked off
the notes page on the course web page. You may
want to use the Volere Template as support to
structure your course project’s requirements.
§ Please read Alistair Cockburn’s paper Structuring
Use Cases with Goals which is also available off
the notes page. You may want to use a Use Case
Template to collect and represent your course
project’s use cases.
§ Read the outline of the practical activity in
preparation for next week tutorials.

SEOC1 Lecture Note 03 18