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?
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
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
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
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
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 – cont’d
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
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
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 – cont’d
•
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 – 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
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