Spring 2007

Session 3: Specifying Requirements

with Use Case Diagrams

Eran Toch
http://www.technion.ac.il/~erant

Specification and Analysis of Information Systems Spring 2005 1

Outline

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

2
Where are we?
Outcome Actions Phase
Business
documents
Raising a business need Initiation
Organized Interviewing stakeholders, exploring
documentation the system environment
Requirements
Formal Analyze the engineering aspect of the
specification system, building system concepts
Specification
Formal Define architecture, components, data
Specification types, algorithms
Design
Testable Program, build, unit-testing, integrate,
system documentation
Implementation
Testing results, Integrate all components, verification, Testing &
Working sys validation, installation, guidance Integration
System
versions
Bug fixes, modifications, adaptation Maintenance

Introduction | Diagrams | Writing | Guidelines 3

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 4

Requirements vs. Design

• Requirements:
– What the system
should do
– More abstract

• Design:
– How the system
should do it
– More detailed

Introduction | Diagrams | Writing | Guidelines 5

Types of Requirements
• Visible Functional Requirements
– “The system will deliver cash to the
customer”
– “Cash will be delivered after card Functional
was taken out” Visible
Requirements
• Qualitative Requirements
Hidden
– “The authorization process will take Functional
Requirements
no more than 1 sec” Qualitative
Requirements
– “The user interface will be easy to
use”
• Hidden Requirements
– “Database maintenance processes
will occur every night”

Introduction | Diagrams | Writing | Guidelines 6

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 7

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 8

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 9

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 Actors
Association Use Case
boundary Example

Introduction | Diagrams | Writing | Guidelines 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 Database Printer

Introduction | Diagrams | Writing | Guidelines 13

Actors can be generalized
The child actor
inherits all use-cases
Perform Sale
associations

Register Client
Sales Person
Should be used if (and only
if), the specific actor has
more responsibility than the Perform
Business Sale
generalized one (i.e.,
associated with more use- Institutional
cases) 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 Fill-in
Products 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 <<include>> Fill-in billing

Sale 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 Gift wrap
After checkout Products

Example

Introduction | Diagrams | Writing | Guidelines 18

Example: Amazon

Shopping Cart
Product Page

Review Writing

Introduction | Diagrams | Writing | Guidelines 19

 Example – cont’d
«extend» Rank
Search «include» Supplier
Product View
Product
Details
After page
Write
generation
«extend»
Revie
«include»
Navigate w
Deals
«extend» Add to
cart
Customer
«include»
Checkou
t «extend»
user is not
a member
Login Register

Handle Order
Status «include»

Introduction | Diagrams | Writing | Guidelines 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

1. Transfer call to available

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

Handle Technical
Handle Sale Call Assistance Call

Customer Tech Assistant

Representative Representative
Example

Introduction | Diagrams | Writing | Guidelines 21

Generalization Hazards
• Combining generalizations of actors and use-
cases can be dangerous

Submit and Get

Grade
Submit Exam

Undergrad Student
Undergrad Student
Submit Exam

Submit Thesis
Submit Thesis

Graduate Student Graduate Student

Bad: Undergrad can submit Good: Only graduate

thesis student can submit thesis

Introduction | Diagrams | Writing | Guidelines 22

Example: Phone Company Operational System

Orange’s 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 External Phone companies

Introduction | Diagrams | Writing | Guidelines 23

Example: Cell Company System

External Phone
Company

Handle Cell
Migration

<<include>> <<include>>
Handle SMS Handle Call
Message
while talking

<<extend>>
Cellular Phone Handle Voice <<extend>> {phone initiate call}
Call {incoming call}

Handle
Conference Call
Handle Multiple
Handle Video Calls
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

Alistair Cockburn
“Writing Effective
Alternatives flows Use Cases”

Introduction | Diagrams | Writing | Guidelines 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. Administrator enters course name, code and description Validation

2. System validates course code Step
3. System adds the course to the db and shows a confirmation message
Internal Change (plus) Interaction
Step Step

Introduction | Diagrams | Writing | Guidelines 30

Guidelines for Effective Writing
• Use simple grammar
• Only one side (system or actor)
is doing something in a single
System Actor
step
Actor asks for money
• Write from an “objective” point
of view System asks for amount

– Bad: “Get the amount form the user Actor gives the amount

and give him the money”

System produce the money
• Any step should lead to some
progress
– Bad: “User click the enter key”

Introduction | Diagrams | Writing | Guidelines 31

Steps – cont’d
• Branches:
– If the user has more than 10000$ in her account, the system
presents a list of commercials
– Otherwise…

• Repeats:
1. User enters the name of the item he wishes to buy
2. System presents the items
3. User selects items to buy
4. Systems adds the item to the shopping cart
5. 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 Starting points
functionality
• Examples:
– Errors Exceptions
Shortcuts
– Unusual or rare Success
cases Scenario
– Failures
Endpoints
– Starting points
– Endpoints
– Shortcuts

Introduction | Diagrams | Writing | Guidelines 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 Top-down Process

Starting with throwing all Starting with an overview of

scenarios on the page, and the system, and then splitting
then combining them: Use-cases

Bullets File
save format Paragraph action
print format s
Save
Font Formattin
load as Viewing
forma g actions
t Actions
preview

39
How to Model – cont’d
• 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 UC

Introduction | Diagrams | Writing | Guidelines 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:
Out In Topic

 Any non-software parts of the system

 Statistical analysis of logs

 Interfacing with credit card systems

 Database cleaning processes

 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 C
Class A
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