Specifying Requirements

with Use Case Diagrams

Specification and Analysis of Information Systems

Spring 2005

Outline

Introduction
Use Case Diagrams
Writing Use Cases
Guidelines for Effective Use Cases

Where are we?

Phase

Actions

Outcome

Initiation

Raising a business need

Business
documents

Requirements

Interviewing stakeholders, exploring

the system environment

Organized
documentation

Specification

Analyze the engineering aspect of the

system, building system concepts

Formal
specification

Design

Define architecture, components, data

types, algorithms

Formal
Specification

Program, build, unit-testing, integrate,

Implementation documentation

Testable system

Testing &
Integration

Integrate all components, verification,

validation, installation, guidance

Testing results,
Working sys

Maintenance

Bug fixes, modifications, adaptation

System
versions

Introduction | Diagrams | Writing | Guidelines

Source of Requirements
Initial requirements come from the customer, by:
Documents, such as RFI/RFP
Meetings, reports

Advanced requirements come from the analysts,

after studying:
Scope and price
Feasibility (technological, organizational etc)
Prototypes

Final requirements are stabilized in an iterative

process.
Introduction | Diagrams | Writing | Guidelines

Requirements vs. Design

Requirements:
What the system
should do
More abstract

Design:
How the system
should do it
More detailed

Introduction | Diagrams | Writing | Guidelines

Types of Requirements
Visible Functional Requirements
The system will deliver cash to the
customer
Cash will be delivered after card
was taken out

Qualitative Requirements
The authorization process will take
no more than 1 sec
The user interface will be easy to
use

Functional
Visible
Requirements
Hidden
Functional
Requirements

Qualitative
Requirements

Hidden Requirements
Database maintenance processes
will occur every night
Introduction | Diagrams | Writing | Guidelines

Use Cases

Register User
admin
Use case in diagram

Use Case in script

Illustration

A use case is a contract of an interaction between

the system and an actor.
A full use-case model comprise of:
A diagram, describing relations between use-cases and
actors.
A document describing the use case in details

Introduction | Diagrams | Writing | Guidelines

Use Case Diagram Objective

1. Create a semi-formal model of the functional
requirements
2. Analyze and define:
Scope
External interfaces
Scenarios and reactions

Introduction | Diagrams | Writing | Guidelines

What Makes Good Use-Case Specification?

Lack of ambiguity
Each requirement must be interpreted in a single manner.

Completeness
They should cater for all current demands of the system.

Consistency
Requirements should not conflict with each other. If there
are, tradeoffs must be detected and discussed.

Avoid design
Requirements should raise a need, not answer it. (Why?)

Introduction | Diagrams | Writing | Guidelines

Use Cases as Means of Communication

Customers

Designers

Users

The use case should stimulate a discussion about

what the system should do, mainly with people
who are outside of the development team.

Introduction | Diagrams | Writing | Guidelines

10

Outline

Introduction
Use Case Diagrams
Writing Use Cases
Guidelines for Effective Use Cases

11

A Simple Example

Handle Message

Cellular Phone

Handle Call

External Phone
Company

Bill Management
Customer

System
boundary

Association

Introduction | Diagrams | Writing | Guidelines

Use Case

Actors
Example

12

Finding Actors
External objects that produce/consume data:
Must serve as sources and destinations for data
Must be external to the system

Humans

Machines External systems Sensors

Organizational Units
Introduction | Diagrams | Writing | Guidelines

Database

Printer
13

Actors can be generalized

The child actor
inherits all use-cases
associations

Perform Sale

Register Client
Sales Person

Should be used if (and only

if), the specific actor has
more responsibility than the
generalized one (i.e.,
associated with more usecases)

Perform
Business Sale

Institutional
Sales Person

Cancel Sale

Sales Manager

Example

Introduction | Diagrams | Writing | Guidelines

14

Linking Use-Cases
Linking enables flexibility in requirements
specification
Isolating functionality
Enabling functionality sharing
Breaking functionality into manageable chunks

Three mechanism are used:

Include
Extend
Inheritance

Introduction | Diagrams | Writing | Guidelines

15

Use-Case Levels
Base Use Case:
Used directly by
the user

Perform
Sale

User goals
Sub-functionality
Choose
Products

Fill-in
billing info

Alistair Cockburn Writing Effective Use Cases

Introduction | Diagrams | Writing | Guidelines

16

The Include Construct

Include is used when:
Decomposing complicated behavior
Centralizing common behavior

The base use case explicitly incorporates the

behavior of another use case at a location specified
in the base.

Perform
Sale

<<include>>

Fill-in billing
info
Example

Introduction | Diagrams | Writing | Guidelines

17

Extend Graphical Representation

The base use case can incorporate another use
case at certain points, called extension points.
Note the direction of the arrow
The base use-case does not know which use-case
extends it

<<extend>>
Product is a gift

Perform Sale
After checkout

Gift wrap
Products
Example

Introduction | Diagrams | Writing | Guidelines

18

Example: Amazon

Shopping Cart
Product Page

Review Writing
Introduction | Diagrams | Writing | Guidelines

19

Example contd
Rank
Supplier

extend

Search
Product

include

View
Product
Details
After
page
generation

Navigate
Deals

include

extend

extend

Write
Revie
w

Add to
cart

Customer
Checkou
t

include
extend
user is not
a member

Login
Handle Order
Status

Introduction | Diagrams | Writing | Guidelines

Register

include

20

Generalization between Use-Cases

The child use case inherits the behavior parent use case:
The interaction (described in the textual description)
Use case links (associations, include, extend, generalization)

Child use-case can substitute parent Use case

Overriding occurs through the textual description

Handle Call

Handle Sale Call

Customer
Representative

Introduction | Diagrams | Writing | Guidelines

1. Transfer call to available

representative
2. Mark representative as busy
3. Start record call
4. Stop record call
5. Log call details
6. Mark representative as free

Handle Technical
Assistance Call
Tech Assistant
Representative

Example

21

Generalization Hazards
Combining generalizations of actors and usecases can be dangerous
Submit and Get
Grade
Submit Exam
Undergrad Student

Undergrad Student

Submit Exam

Submit Thesis

Graduate Student

Submit Thesis

Graduate Student

Bad: Undergrad can submit

Good: Only graduate

thesis

student can submit thesis

Introduction | Diagrams | Writing | Guidelines

22

Example: Phone Company Operational System

Oranges objective: Build a system that handles SMS
messages, handles calls (for 2 and 3 generation
phones), including conference calls and multiple calls
from a single phone. The system must support users on
the move.
Who are the actors?

The Cellular Phone

Introduction | Diagrams | Writing | Guidelines

External Phone companies

23

Example: Cell Company System

External Phone
Company

Handle Cell
Migration
<<include>>
Handle SMS
Message

<<include>>
Handle Call
while talking

Cellular Phone

Handle Voice
Call

Handle Video
Call

<<extend>>
<<extend>> {phone initiate call}
{incoming call}

Handle Multiple
Calls

Handle
Conference Call

3G Phone

Introduction | Diagrams | Writing | Guidelines

24

Outline

Introduction
Use Case Diagrams
Writing Use Cases
Guidelines for Effective Use Cases

25

Structure of a Use Case Specification

Name
Actors
Trigger
Preconditions

Post conditions

Success Scenario

Alternatives flows

Introduction | Diagrams | Writing | Guidelines

Alistair Cockburn
Writing Effective
Use Cases

26

Triggers
What starts the use-case?
Examples:
Customer reports a claim
Customer inserts card
System clock is 10:00

Introduction | Diagrams | Writing | Guidelines

27

Preconditions
What the system needs to be true before running
the use-case.
Examples
User account exists
User has enough money in her account
There is enough disk space

Introduction | Diagrams | Writing | Guidelines

28

Post-Conditions
A post-condition is the outcome of the use-case.
Examples
Money was transferred to the user account
User is logged in
The file is saved to the hard-disk

Minimal guarantee
The minimal things a system can promise, holding even when
the use case execution ended in failure
Examples: Money is not transferred unless authorization is
granted by the user

Success guarantee
What happens after a successful conclusion of the use-case.
Examples: The file is saved; Money is transferred

Introduction | Diagrams | Writing | Guidelines

29

Success Scenario
The success scenario is the main story-line of the
use-case
It is written under the assumption that everything is
okay, no errors or problems occur, and it leads
directly to the desired outcome of the use-case
It is composed of a sequence of action steps
Example:
Interaction
step
1.
2.
3.

Administrator enters course name, code and description

Validation
System validates course code
Step
System adds the course to the db and shows a confirmation message
Internal Change
Step

Introduction | Diagrams | Writing | Guidelines

(plus) Interaction
Step
30

Guidelines for Effective Writing

Use simple grammar
Only one side (system or actor)
is doing something in a single
step
Write from an objective point
of view
Bad: Get the amount form the user
and give him the money

Any step should lead to some

progress

System

Actor

Actor asks for money

System asks for amount

Actor gives the amount

System produce the money

Bad: User click the enter key

Introduction | Diagrams | Writing | Guidelines

31

Steps contd

Branches:
If the user has more than 10000$ in her account, the system
presents a list of commercials
Otherwise

Repeats:
1.
2.
3.
4.
5.

User enters the name of the item he wishes to buy

System presents the items
User selects items to buy
Systems adds the item to the shopping cart
User repeats steps 1-4 until indicating he is done

Introduction | Diagrams | Writing | Guidelines

32

Use-Cases Common Mistakes

Complex diagram
No system
No actor
Too many user interface details
User types ID and password, clicks OK or hits Enter

Very low goal details

User provides name

User provides address
User provides telephone number

Introduction | Diagrams | Writing | Guidelines

33

Alternative Flows
Used to describe
exceptional
functionality
Examples:
Errors
Unusual or rare
cases
Failures
Starting points
Endpoints
Shortcuts

Introduction | Diagrams | Writing | Guidelines

Starting points

Exceptions
Success Shortcuts
Scenario
Endpoints

34

Alternative Flows - Example

Errors:
Case did not eject properly
Any network error occurred during steps 4-7
Any type of error occurred

Unusual or rare cases

Credit card is defined as stolen
User selects to add a new word to the dictionary

Endpoints
The system detects no more open issues

Shortcuts:
The user can leave the use-case by clicking on the esc key

Introduction | Diagrams | Writing | Guidelines

35

Writing Include

If a base use-case include another use-case, we

will add a reference as a step:
1. System presents homepage
2. User performs login to the system
OR

<include: login to the system>

Introduction | Diagrams | Writing | Guidelines

36

Writing Extend
Scenarios do not include direct references
Instead, they include extension points, such as:
User enters search string
System presents search results
Extension point: results presentations
OR
<extension point: results presentations>

The extension use-case includes conditions in which

the extension is being committed
Example: if the user belongs to the rich clients group
If more than two commercials were found

Introduction | Diagrams | Writing | Guidelines

37

Outline

Introduction
Use Case Diagrams
Writing Use Cases
Guidelines for Effective Use Cases

38

How to Model?
Bottom-up Process
Starting with throwing all
scenarios on the page, and
then combining them:

save

print
load

Bullets
format

Save
as
preview

Paragraph
format
Font
forma
t

Top-down Process
Starting with an overview of
the system, and then splitting
Use-cases
File
action
s
Formattin
g actions

Viewing
Actions

39

How to Model contd

Most of the analysis process are actually

Combined

40

Combining Processes
Number Limit:
The diagram should have between 3 to 10 base use-case. No
more than 15 use cases (base + included + extending).

Abstraction:
All use-cases should be in similar abstraction levels.

Size:
Use cases should be described in half a page or more.

Interaction:
Use-cases which are carried out as part of the same interaction.
UC
UC

Introduction | Diagrams | Writing | Guidelines

UC

41

Dividing Processes
Size:
If a use-cases takes more than a page, consider
include/extend

Weak dependency:
If the dependency between two parts of a use-case is weak,
they should be divided.

UC

Introduction | Diagrams | Writing | Guidelines

42

More Guidelines
Factor out common usages that are required by
multiple use cases
If the usage is required use <<include>>
If the base use case is complete and the usage may be
optional, consider use <<extend>>

A use case diagram should:

contain only use cases at the same level of abstraction
include only actors who are required

Introduction | Diagrams | Writing | Guidelines

43

Scope
A good way to decide on the scope is by in/out lists:
Topic

In

Any non-software parts of the system

Statistical analysis of logs
Interfacing with credit card systems
Database cleaning processes

Out

Backup of logs

Alistair Cockburn Writing Effective Use Cases

Introduction | Diagrams | Writing | Guidelines

44

When Are we Done?

When every actor is specified.
When every functional requirement has a use-case
which satisfies it.
A tractability matrix can help us determine it:

Use Cases

Requirements
Introduction | Diagrams | Writing | Guidelines

45

Moving on
Data entering and exiting the system is represented
by data entities in structural diagrams.
Behavior induced by use cases can be captured in
behavioral diagrams.

Use Case 1
Class A

Class C

Use Case 3

Use Case 2

Class D
Class B

Introduction | Diagrams | Writing | Guidelines

46

Summary
Introduction
to the Unified Modeling Language (UML)
To Use Case Diagram

Use Case Diagrams

Dual presentation of use-cases
Include, Extend, Inheritance

Writing Use Cases

Preconditions & Post-conditions
Main scenario vs. Alternative Flow

Guidelines for Effective Use Cases

47