Use Cases

Massimo Felici
IF 3.46 0131 650 5899
mfelici@inf.ed.ac.uk
Use Cases
ƒ Support requirements engineering activities and
the requirement process
ƒ Capture 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
ƒ Capture how the system coordinates human actions

© 2004-2008 SEOC - Lecture Notes 03 2

The Benefits of Use Cases
ƒ Relatively easy to write and easy to read
ƒ Comprehensible by users
ƒ Engage the users in the requirements process
ƒ Force developers to think through the design of a
system from a user viewpoint
ƒ Identify a context for the requirements of the
system
ƒ Critical tool in the design, implementation, analysis
and testing process
ƒ Rapid change allows exploratory approach
ƒ Serve as inputs to the user documentation

© 2004-2008 SEOC - Lecture Notes 03 3

Use Cases: Strengths and Weaknesses

ƒ Strengths
• Capture different actors views of the system
• Capture some structures in requirements
• Are comprehensible by naïve users
ƒ Weaknesses
• Lack of non-functional requirements
• Lack of what the system shall not do

© 2004-2008 SEOC - Lecture Notes 03 4

Use Cases at a Glance
Use Cases Relationships

Use Case Generalization Actors

Use Case

Actor

Abstract Use case <<include>> System

Boundaries
Abstract Use Case <<include>>

Use Case with Extension Points <<extend>> Extension

Conditions
<<extend>>
Use Case with extension points Extension Condition

Extension Point:

© 2004-2008 SEOC - Lecture Notes 03 5

Actors and Use Cases

Warnings and Hints

Register for SEOC

ƒ Finding nonhuman actors

• Incorporating other
Students
systems (e.g., databases)
Sign-up for Tutorials • Ignoring internal
components
• Input/Output Devices
ƒ Roles of the Actors
Register for Courses

ƒ Naming the Actors

Sign-up for Tutorials

Students

Modify Timetables

ITO
View Timetables

© 2004-2008 SEOC - Lecture Notes 03 6

Generalizations between Use Cases

ƒ Indicate that the more

specific use case
receives or inherits the
actors, behavior
Bill Payment sequences, and extension
points of the more
general use case
ƒ Payment, for instance, is
Payment by credit cards
Payment by cash
a generalization of
Payment by credit cards
and payment by cash

© 2004-2008 SEOC - Lecture Notes 03 7

 Generalization between Actors

ƒ Actors may be similar in

how they use the system
More general actor role name Specialized actor role name
(e.g., project and system
managers)
ƒ An Actor generalization
indicates that instances
of the more specific
Students
actor may be
Visiting Students substituted for
Undergraduate Students
instances of the more
general actor
Master Students

© 2004-2008 SEOC - Lecture Notes 03 8

<<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-2008 SEOC - Lecture Notes 03 9

<<extend>> Relationship
"Add Joint Account Holder" extends "Open Bank Account"
by adding extra functionality, but "Open Bank Account"
is a valid use case on its own.

Condition: {NUmber of Account Holder(s)>1}

Extension Point: Add Joint Account Holder

Open Bank Account <<extend>> Add Joint Account Holder

ƒ 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-2008 SEOC - Lecture Notes 03 10

System Boundaries

Informatics Course
1
Registration System
Students 1..*

Register for Courses

0..1
ITO
1..*

Approve Course Registrations

<<include>>
1

1
University Registry
Check Student Matriculation

ƒ Identify an implicit separation between actors (external to the

system) and use cases (internal to the system)

© 2004-2008 SEOC - Lecture Notes 03 11

Use Case Descriptions

ƒ A use case description should be attached to each

case in the diagram
ƒ Complement use case diagrams
ƒ Identify use case information
• Warnings: avoid to specify design information
ƒ A use case main course (of actions) is a generic
sequence of actions undertaken in using the system
• Identify pre and post conditions
• Identify alternate courses
ƒ Provide generic test scenarios for the full system
ƒ Templates capture/structure use case information
© 2004-2008 SEOC - Lecture Notes 03 12
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-2008 SEOC - Lecture Notes 03 13
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-2008 SEOC - Lecture Notes 03 14
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-2008 SEOC - Lecture Notes 03 15

Creating Use Cases

ƒ Step 1. Identify and Describe the Actors

ƒ Step 2. Identify and Describe the Use
Cases
ƒ Step 3. Identify the (Actor and Use Case)
Relationships
ƒ Step 4. individually Outline Use Cases
ƒ Step 5. Prioritize the Use Cases
ƒ Step 6. Refine the Use Cases

© 2004-2008 SEOC - Lecture Notes 03 16

Building the Right System

ƒ Tracing Requirements
ƒ Managing Changes
ƒ Assessing Requirements Quality in Iterative
Development

© 2004-2008 SEOC - Lecture Notes 03 17

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-2008 SEOC - Lecture Notes 03 18
VolBank: Incomplete Use Cases

© 2004-2008 SEOC - Lecture Notes 03 19

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-2008 SEOC - Lecture Notes 03 20
Readings

ƒ UML course textbook

• Chapter 3 on Use Cases
ƒ Alistair Cockburn. Structuring Use Cases
with Goals.
• The paper introduces a Basic Use Case Template

© 2004-2008 SEOC - Lecture Notes 03 21

Summary

ƒ Use Cases in UML capture (to a certain

extent) system requirements and support
requirements engineering activities and
processes
ƒ Use Case notations and examples
ƒ Describing use cases
ƒ Developing use cases

© 2004-2008 SEOC - Lecture Notes 03 22