Professional Documents
Culture Documents
Specifying Requirements With Use Case Diagrams: Analysis and Specification of Information Systems
Specifying Requirements With Use Case Diagrams: Analysis and Specification of Information Systems
Specifying Requirements
with Use Case Diagrams
Analysis and Specification of Information Systems
Winter 2008
Eran Toch
http://www.technion.ac.il/~erant
Specification and Analysis of Information Systems
Spring 2005
Outline
Introduction
Use Case Diagrams
Writing Use Cases
Linking Use Cases
Guidelines for Effective Use Cases
Actions
Outcome
Initiation
Business
documents
Analysis
Organized
documentation
Specification
Logical System
Model
Implementation documentation
Testable system
Testing &
Integration
Testing results,
Working sys
Maintenance
System
versions
Source of Requirements
Initial requirements come from the customer, by:
Documents, such as RFI/RFP
Meetings, reports
Design:
How the system
should do it
More detailed
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 | Linking | Guidelines
Outline
Introduction
Use Case Diagrams
Writing Use Cases
Linking Use Cases
Guidelines for Effective Use Cases
Use Cases
Use Case
Actor
Objective
1. Create a semi-formal model of the functional
requirements
2. Analyze and define:
Scope
External interfaces
Scenarios and reactions
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?)
10
Customers
Designers
Users
11
A Simple Example
System
boundary
Association
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
Organizational Units
Database
Printer
13
Example
14
Outline
Introduction
Use Case Diagrams
Writing Use Cases
Linking Use Cases
Guidelines for Effective Use Cases
15
Success Scenario
Alternatives flows
Introduction | Diagrams | Writing | Linking | Guidelines
Alistair Cockburn
Writing Effective
Use Cases
16
Triggers
What starts the use-case?
Examples:
Customer reports a claim
Customer inserts card
System clock is 10:00
17
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
18
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 | Linking | Guidelines
19
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. User enters product name, SKU and description
Validation
Step
3. System adds the product to the DB and shows a confirmation message
2. System validates product SKU
Internal Change
Step
Introduction | Diagrams | Writing | Linking | Guidelines
(plus) Interaction
Step
20
21
System
Actor
22
Steps contd
Branches:
Repeats:
1.
2.
3.
4.
5.
23
Complex diagram
No system
No actor
Too many user interface details
User types ID and password, clicks OK or hits Enter
24
Alternative Flows
Used to describe
exceptional
functionality
Examples:
Errors
Unusual or rare
cases
Failures
Starting points
Endpoints
Shortcuts
Starting points
Exceptions
Success
Scenario
Shortcuts
Endpoints
25
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 | Linking | Guidelines
26
Outline
Introduction
Use Case Diagrams
Writing Use Cases
Linking Use Cases
Guidelines for Effective Use Cases
27
Linking Use-Cases
Linking enables flexibility in requirements
specification
Isolating functionality
Enabling functionality sharing
Breaking functionality into manageable chunks
28
Perform
Sale
<<include>>
Fill-in billing
info
Example
29
Writing Include
30
Perform Sale
<<extend>>
Product is a gift
After checkout
Gift wrap
Products
Example
31
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>
32
Example: Amazon
Product Page
Shopping Cart
33
Example contd
Rank
Supplier
extend
Search
Product
include
View
Product
Details
After
page
generation
Navigate
Deals
include
extend
Checkou
t
extend
Write
Review
Add to
cart
include
extend
user is not
a member
Login
Handle Order
Status
Register
include
34
Example
35
Generalization Hazards
Combining generalizations of actors and usecases can be dangerous
thesis
36
37
38
Outline
Introduction
Use Case Diagrams
Writing Use Cases
Linking Use Cases
Guidelines for Effective Use Cases
39
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
40
Combined
41
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
42
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
43
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>>
44
Scope
A good way to decide on the scope is by in/out lists:
Topic
In
Out
Backup of logs
45
Use Cases
Requirements
Introduction | Diagrams | Writing | Linking | Guidelines
46
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
47
Summary
Introduction
to the Unified Modeling Language (UML)
To Use Case Diagram
48