Use Cases
Object Oriented Analysis & Design
Use-Cases: an Example
Object Oriented Analysis & Design
Using use cases to describe requirements
• Use cases can show the
sets of possible interactions
between the system and the
people who use it
• Use cases can also show
interactions between
computer systems
• Use cases can also be used
at the subsystem level (to
show interactions between
subsystems)
Example use case diagram
Student
My system
register
Administrator
create new
course
Instructor
actors
delete
offering
use cases
Object Oriented Analysis & Design
What is Requirements Engineering About?
•
•
•
correct
consistent
complete
Effectively generating High Quality Requirements:
• modifiable
• non-ambiguous
• traceable
• understandable
• verifiable
• annotated
Requirements Engineering
Requirements Development
Requirements Management
Elicitation
Change Control
Analysis
Version Control
Modeling & Specification
Tracing & Impact Analysis
Verification & Validation
Status Tracking
Best Practices, Methods,Tools and Processes for Requirements Engineering
Object Oriented Analysis & Design
Use Cases & Early Testing Paradigm
Requirements
Requirements Validation
Quality Assurance
Faster Time to Market
System Design
Detailed Design
Implementation
System Test
Integration Test
Module Test
Build
Object Oriented Analysis & Design
Software Production Cycle
Design Specification
(Design Model
Generation)
Design
Specifications &
Models
Design
Tools
Code
Creation
Build
SDE, SCM Tools
Requirements
Specifications & Models
(Use Cases)
Documentation
Build-triggered
Installation
Requirements
Tools
Shipped Product
Capture with
Customers
Requirements
“validation”
Test
Plans,
Scenarios,
Cases
Test
Tools
Testable version
Test Execution
Traceability, Change Management,
Impact Analysis
Object Oriented Analysis & Design
What is a Use Case?
• A Use Case captures a contract between the stakeholders of a
system about its behavior. Use cases describes the system’s
behavior under various conditions as the system responds to
requests from its users (actors) specifying how the actors’ goals
get delivered or fail.
• A use case is:
– a set of scenarios that describe the behavior of the system and its users
– at a high level of detail
– with “sunny-day” and “rainy-day” scenarios being defined
• A use case gathers the scenarios related to the (primary) actor’s
goal
• Actors are the people and/or computer systems that are outside
the system under development (SuD)and interact with it:
– Primary actor – a stakeholder who requests that the system deliver a goal
– Supporting/secondary actor – an external system against which the SuD
has a goal
• Scenarios are dialogs between actors and the system
Object Oriented Analysis & Design
Actors
• An actor is an entity that is outside of the system
• Actors will interact with the system:
– an actor will often request the system to perform some
actions on behalf of the actor
– an actor may also receive responses from the system
• An actor plays a “role” in the use of the system
– the name given to an actor is usually the “role name”: for
example, an actor who is a Person will usually be called a
User, Operator, Administrator, or something like that
– each role might be treated as a different actor in the use
cases
Object Oriented Analysis & Design
Goals
• A goal is a result that one of the actors wants to achieve
• Example goals:
– An administrator wants to add a new user to the system
– A pilot wants to land a plane
– A customer wants to file a claim on an insurance policy
– A service person wants to file a trouble report
Object Oriented Analysis & Design
Scenarios
• A scenario is a little story
– it is an outline of some
expected sequence of events
• A scenario is used to convey the
fundamentals of “how things
work”
• It usually includes at least one
actor
• Each actor can make requests of
the system or respond to system
activity
I would like a
book of stamps,
please.
OK. Will
that be all?
Yes.
That will be
$7.40.
Here is $10.
Thanks. Here
are your stamps
and your change.
Object Oriented Analysis & Design
Identifying actors
• An Automated Teller Machine (ATM) permits customers to withdraw
money from their accounts, make deposits, and check their account
balances. The ATM machine communicates with a computer system in the
bank’s central office to validate passwords and account information. The
ATM is serviced on a regular basis by bank employees, to collect deposit
envelopes and to load in more cash and receipt paper.
• Question: who are the actors in this system?
–
–
–
–
Object Oriented Analysis & Design
Creating a simple scenario
• Draw a sequence diagram for one of the scenarios in the ATM
system. One prominent use case in this system is “customer
performs an ATM transaction,” and one scenario in that use
case is “customer withdraws money”. Assume we are in the
sunny-day scenario.
Customer
ATM
1. Customer inserts card
???
Object Oriented Analysis & Design
Scenario - Example
• A scenario is a little story
• It describes one possible course of events:
 Customer puts ATM card into machine and types password
 System validates the card and password
 System prompts the customer for a transaction type and amount
 Customer selects “withdraw $100 from checking”
 System checks with the central bank make sure customer has
sufficient funds
 System dispenses the cash, returns card, and prints receipt
 System asks customer if he/she would like another transaction
Object Oriented Analysis & Design
Representing Use cases
• Text templates:
– Informal text
• informal paragraph summary – the paragraph will describe who
starts the scenario, the key actions by the actors and the system, and
how to handle failures
• numbered list of steps – in this format, the main scenario is a list of
sentences describing the sequence of actions by each actor and/or
the system; failure scenarios can be written as branch scenarios at
the end
– Tables – informal text
– Structured templates – one popular example (A. Cockburn)
– Structured (“semi-formal”) DOORS template
• Graphical formats:
– UML Use Case diagrams capturing the system boundary,
use cases(names), actors, channels and use case
relationships
– UML Sequence Diagrams (also known as message
sequence charts, MSC) to represent scenarios
Object Oriented Analysis & Design
Showing a scenario in text format …
• A scenario can be written as a series of sentences:
– each sentence shows one step of the scenario
– each step needs to explain
•
•
•
•
who does the operation
what operation is performed
when the operation is performed
are there any side conditions?
– one important thing that is not included in the description of each step
of a scenario: how the operation is performed (this is left for the
design phase)
• Important style points:
– each step in the scenario must have a subject (either the system or an
actor is performing the step)
– no passive or impersonal voice allowed (e.g., “the results are
displayed”)
Object Oriented Analysis & Design
Example of a text format scenario
Customer buys a single item:
1. Customer asks for an item
2. Postal clerk acknowledges customer request, checks if the
requested item is available
3. Postal clerk asks the Customer if there will be anything else in
this transaction
4. Customer indicates that they don’t want anything else
5. Postal clerk determines the price of the requested items and
tells the customer
6. Customer pays
7. Postal clerk gives the Customer the items and change
• Note: this is not yet a use case, just a single scenario.
Object Oriented Analysis & Design
Showing a scenario in graphical form
• Scenarios can be shown in a standard graphical notation – this
notation has many different names
– Sequence diagram, Event trace diagram, Interaction
diagram, Fence post diagram
Customer
Postal clerk
Ask for item
Acknowledge request
Anything else?
No
Respond with price
Give money
Give item and change
Object Oriented Analysis & Design
Writing a use case
Step 1: Pick one of the potential goals of one of the actors
Step 2: Write down the preconditions for that goal
Step 3: Write the “sunny-day” scenario for the interaction
between actors and system
Step 4: Identify the possible failures at each step - think about
the alternative scenarios that might result
Step 5: For the main failure situations, either create entire
scenarios or create extensions of the main scenario
optional step: Find common chunks that occur in several
scenarios that can be factored out to make the scenarios
simpler
Object Oriented Analysis & Design
Example use case
Use case name: Ticket Buyer buys a lottery ticket
Primary actor: Ticket Buyer
Precondition: Ticket Buyer has $1
Main scenario:
1. Ticket Buyer tells the system (person or machine) that he/she wants to buy a
ticket
2. System asks the Ticket Buyer for his/her choice of lucky number
3. Ticket Buyer chooses a number
4. System asks for $1
5. Ticket Buyer supplies $1
6. System prints a lottery ticket and gives it to the Ticket Buyer
Variations:
2. Ticket Buyer chooses a number:
2a. using keypad
2b. fills in circles on card
2c. asks for a “quick pick”
Object Oriented Analysis & Design
Example use case - scenario
Alternative format
for a scenario:
UML Sequence
Diagram (also
known as
Message
sequence chart)
Note: the
scenario explains
“what” happens
but not “how” it
happens (that will
be in the design)
Ticket
buyer
Ticket
machine
Sell me a ticket
Prompt for lucky number
Number choice
Prompt for $1
Insert $1
Dispense ticket
Object Oriented Analysis & Design
Example use case (continued)
• The use case isn’t finished…
– still need to handle failures
– go through the steps, list the various ways that they could
fail:
• Ticket Buyer can’t decide on a number, changes his/her mind
• Ticket Buyer fills in too many circles on the card
• System can’t print a ticket because it is out of ticket paper
– from some failures, the system can recover
– from other failures, the use case will “fail”
Object Oriented Analysis & Design
Making scenarios more elaborate
• There are three ways to create more elaborate scenarios:
– Variations
– Extensions
– Chunks (subfunctions)
Object Oriented Analysis & Design
Variations
•
•
•
•
A variation is a way to avoid “scenario explosion”
A variation is a list of alternatives that is tied to a specific line of a scenario
Each variation could turn into a lower-level scenario
An example variation (for the post office scenario):
1. Item is
a. stamps
b. postage on an item that the customer
is mailing
c. postage due on an item that the
customer is receiving
d. post office box rental
e. mugs, t-shirts, and other Postal
Service merchandise
6. Payment is
a. ______________
b. ______________
c. ______________
Main scenario:
1. Customer asks for an item
2. Postal clerk acknowledges customer request,
checks if the requested item is available
3. Postal clerk asks the Customer if there will be
anything else in this transaction
4. Customer indicates that they don’t want
anything else
5. Postal clerk determines the price of the
requested items and tells the customer
6. Customer pays
7. Postal clerk gives the Customer the items and
change
Object Oriented Analysis & Design
Extensions
• An extension is a short scenario that “branches off” from another scenario
• Extensions are used to describe recovery actions when something goes
wrong
– extensions might rejoin the main scenario
– or extensions might just terminate because the goal can’t be achieved
• An example extension (for the post office scenario):
2a. Item is not available:
2a1. Postal clerk looks for an
equivalent item
2a2. If an equivalent item is
found, the Postal clerk asks
customer if the equivalent item
is OK
Main scenario:
1. Customer asks for an item
2. Postal clerk acknowledges customer
request, checks if the requested item is
available
3. Postal clerk asks the Customer if there will
be anything else in this transaction
4. …
Object Oriented Analysis & Design
Chunks
• A chunk is a “sub-scenario” - a sequence of messages that
appears in several scenarios for one or more use cases.
– A chunk is a scenario that addresses a specific subgoal
• for example: logging in, searching for a specific product, etc.
– They are the “subroutines” of the use case family
– They may express some common “user interface” subscenarios
– Alistair Cockburn calls them “subfunctions” (but we don’t
want to think of them as associated with low-level code)
Object Oriented Analysis & Design
The UML Use Case Diagram
• In UML (Unified Modeling
Language), it is possible to
show a picture of the system
as a group of use cases:
– each stick figure is an
actor
– each ellipse represents a
use case
• The diagram is deceptively
simple
– behind each ellipse, there
might be a whole bunch
of scenarios – sunny-day,
alternatives, failures
– the diagram is only a
“summary”
withdraw cash
Customer
check balance
Bank Employee
service ATM
Object Oriented Analysis & Design
A simple format for a use case
Use case 1: Employee opens door
Office Security
System
Employee
open
door
reset
alarm
Security
Guard
Repair
Person
test
alarm
Goal: An Employee wants to unlock a door to pass from one room
to another.
Preconditions: The Employee has valid identification to open the
door.
Success end condition: Employee has successfully opened the door.
Failed end condition: Door remains closed and the Security Guard
on duty is notified.
Actors: Employee, Security Guard
Main scenario:
1. Employee’s identification and door identification is sent to
system
2. Door is unlocked
3. Employee opens door, passes through the door, and recloses
door, SUCCESS
Extensions:
2a. Employee’s identification is not valid
2a1. System notifies Security Guard, FAIL
Object Oriented Analysis & Design
More Notations and Examples
Object Oriented Analysis & Design
Use-Case diagrams - actors
Textual stereotype (class)
“actor“
cellular network
Visual stereotypes (classes)
boundary/interface
actor
persons & roles
control
entity
passive objects
data stores
Object Oriented Analysis & Design
Representing use cases - more details
Use- Case diagramms - use-cases
Use-Case Number (ID) & Name
place
phone call
–
–
–
–
Actors
Pre- & postconditions
Non-functional requirements
Behavior - main scenario
• sequence diagram(s)
• decomposition in smaller UC diagrams
UC description
–
–
–
–
–
Error-handling & exceptions
Other
examples, prototypes, etc.
open questions & contacts
other diagrams
Object Oriented Analysis & Design
More on Use-Case diagrams
• Show use-cases & actors
• connected by „associations“
• refined by inheritance stereotypes
– “uses”
• re-use of a set of activities (use-case)
• partitioning of activities
• points to the re-used use-case
– “extends”
• variation of a use-case
• points to the standard use-case
elicit customer
needs
“extends “
make an
interview
“uses “
produce a
SRS
Object Oriented Analysis & Design
Use-Case diagrams: Example
anybody
check
travel options
clerk
“uses”
flight db
search for
a flight
traveler
book
a flight
pay
with cc
customer
“actor“
flight res-sys
“uses”
clerk
“extends”
Pay a
bill
“actor“
credit-card sys
prepare-travel
Object Oriented Analysis & Design
On Use Case Levels
• It is possible to write
– “business-level” use cases –
• organizational goals (marketing, finance, systems engineering,
installation)
– or “system-level” use cases
• goals of specific users
– or “subsystem-level” use cases
• goals of the other subsystems
Object Oriented Analysis & Design
Levels of scope (A. Cockburn)
Summary-level goals
• “cloud-level”
Upgrade all
customers
Add new
service
Find list of
services
User goals
• “sea-level”
• usually 2 to 20 minutes
Sub-functions
• “under water”
• not a real “user goal”:
these scenarios
describe common suboperations
Object Oriented Analysis & Design
Goals & Sub-goals
• Each use case represents a “goal” of one of the actors
– the use case is “the set of all scenarios that might happen”
in trying to reach that goal – success or failure scenarios
– each scenario is a series of smaller sub-goals
• if you can succeed in each step, you will reach the goal
• if a step fails, then there might be an alternative series of steps that
get to the goal
• the substeps might be lower-level use cases, or they might just be
“things implemented in the design”
Object Oriented Analysis & Design
Use- Case diagrams: Hiearachies
diagram name: anything
uc-1
uc-2
Use Case
diagram
decomposition
uc-3
uc-4
Diagram name: anything-level2-for-uc4
uc-4.1
uc-4.2
Object Oriented Analysis & Design
Use Case Process
Step 1: Create a list of Actors
Customer
Support
hotline person
Administrator
Repair person
Step 2: Create a list of Goals
Web-based music distribution system:
UC1: Customer downloads a song
UC2: Customer searches music directory
UC3: Administrator adds a new user
UC4: Administrator updates directory
UC5: Support hotline person investigates
a Customer problem
UC6: Support hotline person authorizes
Customer refund
UC7: Repair person runs diagnostics
Step 3: Write simple use cases
with only sunny-day scenarios
UC1: Customer downloads a song
Precondition: Song file is on a server
Main scenario:
1. Customer chooses song
2. System checks availability and
price; prompts Customer for
payment
3. Customer enters credit card info
4. System sends credit card
transaction to Bank
5. Bank returns transaction number
6. System transmits the song to
Customer’s computer
Step 4: Review the use cases with
customer (or customer surrogate)
Object Oriented Analysis & Design
Use Case Process (Cont.)
Step 5: Identify failure conditions
2a. Song is not available
3a. Customer quits without entering
credit card info
4a. Link to Bank is down
5a. Credit card is rejected by Bank
6a. Server fails during transmission
6b. Customer cancels during
transmission
Step 6: Write a selected set of
failure scenarios and alternatives
5a. Credit card is rejected by Bank:
5a1. System reports failure to the
Customer, prompts Customer for
a different credit card
5a2. Customer enters card info
5a3. go to step 4
Step 7: Internal review
• review the scenarios and
failure branches with testers,
developers, project managers
Ongoing: make links to other
requirements, update use case
model as needed
• define the business rules and
non-functional requirements
(in text documents, with links
to the use case model)
• add new use cases and new
scenarios for new actors and
goals; new variations for
existing use cases
Object Oriented Analysis & Design
How many use cases is enough?
• It depends…
– make sure you cover the
major goals of each actor
– don’t forget OA&M –
administrative use cases
usually include initialization,
running backups, diagnosing
problems, and reporting
current status to another
system
– some systems might need
100-200 use cases, but most
only have 20-40
– do some “abstraction” to
reduce the number of
scenarios
Object Oriented Analysis & Design
Use Cases contribute to agility
• It is important to be “agile”
– Requirements
• get direct customer involvement in documenting
the requirements – using scenarios and use cases
– Architecture
• make better architectural decisions – use the
high-runner, high-priority scenarios to assess
“candidate architectures”
– Project management
• use cases can help to plan an iterative
development process
– Test
• update the tests as the requirements change
Object Oriented Analysis & Design
Use cases and requirements
• Use cases are requirements
– a use case will specify the essential behavior that the system must deliver
• Use cases are usually about 1/3 of the total volume of
requirements
• The use cases are supplemented by other kinds of requirements
information
– Business Rules: conditions, policies, and conventions
– Operational Profiles: how many scenarios
– Architectural Requirements: “-ilities” (reliability, usability, performance)
Business Rules
Operational Profiles
Architectural
Requirements
BR1. Each employee
has a unique
identification number.
OP1. During the busy hour (8-9am),
the system should be able to handle
500 “open-door” requests (UC1
sunny-day).
AR1. Maximum time to
process an “open-door”
request is 15 seconds.
BR2. Each “open-door”
request is logged.
OP2. The “test alarm” use case will
be executed every weekend.
AR2. No more than 5
minutes downtime per year.
Object Oriented Analysis & Design
Why use cases?
• Why write use cases instead of “normal” functional
requirements?
– Use cases hold functional requirements in an easy-to-read,
easy-to-track format
– Each use case gives information on how the system will
deliver a “goal” to one of the users of the system
• a use case explains how a goal succeeds/fails using scenarios
• the scenarios provide context – traditional requirements are often
too ambiguous
• “If you have a requirement that doesn’t help meet any of the users’
goals, why do you have the requirement in the system?”
• also need to look at the goals of the “stakeholders”
– Use cases show only the Functional requirements
• the use cases are a framework to attach non-functional
requirements and other project details
Object Oriented Analysis & Design
After the use cases are written, what next?
• Jumpstart the OOAD – CRC and models
– use cases describe the “externally-visible behavior” of the
system
– an object model describes the internal behavior
– Design decisions can be linked back to a use case
• Jumpstart test cases
– Scenarios provide excellent start for “early testing”
– Test planning – RTP and RSTP
– DOORS-based traceability
• Use the Use Case list to manage your project
– Use cases provide excellent basis for structuring and
monitoring your project iterations
• It is important to be “agile”
Object Oriented Analysis & Design
Iteration management with use cases
• A use case model can be very useful in a project with rapid
iteration
– for each iteration, identify which use cases are “in” the iteration
• that is, will some or all of the use case’s scenarios work?
• track progress by counting scenarios (with priority weighting)
– typical iteration scheme:
• first iteration: highest priority use cases, sunny-day scenarios only
• second iteration: add a few second-tier use cases, start
implementing the failure scenarios that fail completely
• later iterations: add a few more use cases, start filling in the
“recovery” scenarios
– you might choose certain use cases as “high-priority” because they
help validate key parts of the architecture
Object Oriented Analysis & Design
References
• Books:
– Alistair Cockburn, Writing Effective Use Cases
– Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in
Context
– Steve Adolph and Paul Bramble, Patterns for Effective Use Cases
– Kurt Bittner and Ian Spence, Use Case Modeling
• Web sites:
–
–
–
–
http://www.usecases.org
http://agilealliance.org
http://members.aol.com/acockburn
http://members.aol.com/acockburn/papers/usecases.htm
Object Oriented Analysis & Design
Extra ....
• Use Cases and Tools …
Object Oriented Analysis & Design
Use cases and RM Tools
Object Oriented Analysis & Design
Storing Use Cases in DOORS
A Use Case is stored in the DOORS “hierarchical object structure”:
entire DOORS module
a Use Case object in DOORS
Object Oriented Analysis & Design
Object Oriented Analysis & Design
Object Oriented Analysis & Design
Object Oriented Analysis & Design
Object Oriented Analysis & Design
Extra ....
• Modeling …
Object Oriented Analysis & Design
Why build models?
• To organize the work
– Building software is a time-consuming and complex operation
– Good quality software can have a long lifetime
• To improve communication among team members
– Software is very labor-intensive: many people play a part in the
construction of a software product
– Ordinary text documentation is inherently imprecise and ambiguous
• To aid in the “thinking process”
– In most software development projects, the actual form of the “thing to
be built” is initially very vague
– Iterative and incremental development will focus on changes to the
models - it is easier to “rebuild the model” than to “rebuild the
system”
Object Oriented Analysis & Design
Some traditional modeling techniques
•
Data modeling (using Entity-Relationship Diagrams)
– the system is viewed as a set of “data
entities” and “relationships”
– the model includes the “transactions” that
are applied to the system
•
Data flow
Airport
– the system is viewed as a group of data
sources, data stores, and active processes
that exchange data messages on a regular
basis
– the model emphasizes the frequency and
data content of the messages
•
served
by
City
registration
valirequest
Student
dation
request
update
registration
DB
course
offering
data
student info
registration DB
State machines
– each element of the system has a “internal”
state
– there can be transitions from one state to
another when certain key “events” are
received by an element
turn on
idle
open
door
open door
cancel
cooking
timer
beeping
Object Oriented Analysis & Design
System-level static data model
• In the process of creating a set of use cases for a
system, it is useful to think about the major data
entities in the system
– these data entities and their connections can be
drawn using Entity-Relationship diagrams or
Class diagrams
– the names of the entities are often used in the
descriptions of the actions in the use case
scenarios
• Be careful not to “over-specify” the data entities
– you should only specify the key data attributes
(not all of the attributes)
– it is sometimes useful to describe some of the
fundamental responsibilities of the data entities
(using CRC cards or other OO techniques)
Transaction
1
1
1
Receipt
0..*
Item
Object Oriented Analysis & Design
Extra ...
• Example …
Object Oriented Analysis & Design
Exercise
• What are the main actors and use cases for an Online
Banking System?
– Actors:
•
•
•
•
– Use cases
•
•
•
Object Oriented Analysis & Design
Lottery system exercise
•
•
The system to be built is a distributed
computer system for a state lottery.
The system will be used by three kinds of
users: ticket buyers, lottery ticket agents,
and lottery staff people.
– Ticket buyers use the system to buy
lottery tickets. Each ticket costs $1.
– Lottery ticket agents pay prizes to
ticket buyers who turn in winning
lottery tickets.
– A lottery staff person will post the
winning number of the day on the
computer system, check on the day’s
revenue, and disable ticket sales one
minute before the drawing.
• List the actors for the whole
system:
– Ticket buyer
–
–
• List the actors for the lottery
ticket machine subsystem:
– Ticket buyer
–
–
Object Oriented Analysis & Design
A lottery system use case
• Use case for the “ticket buyer buys a ticket” situation (assume that we are
considering the whole system and not just the lottery ticket machine
subsystem):
Use case name:Ticket buyer buys a ticket
Actors: (a list of all the actors involved in this use case) ????
Authors of this use case: me
Summary:
Preconditions: (what has to be true before this use case can be initiated?)
????
Frequency: (how often will this use case happen? – once per week, once per hour, …)
????
Description: (in words or as one or more sequence diagrams – use more pages if needed)
1.
2.
Exceptions, Variations, Extensions, and Chunks:
Object Oriented Analysis & Design
Sample list of actors
• Actors for the whole system
– Ticket buyer
– Lottery ticket agent
– Lottery staff person
• Actors for the ticket machine subsystem
– Ticket buyer
– Central computer
– Machine service person
Object Oriented Analysis & Design
Sample lottery system use case
Use case name: Ticket buyer buys a ticket
Actors: Ticket buyer
Authors of this use case: me
Summary: The Ticket buyer wants to buy a $1 lottery ticket, and the ticket machine will take
the money and ask the Ticket buyer to enter his/her choice of number.
Preconditions:
• Ticket machine has been initialized
• Ticket buyer has $1
Frequency: maximum: 5,000,000 per day for the entire lottery system; 10,000 per ticket
machine per day
Description:
1. Ticket buyer inserts $1 into ticket machine
2. Ticket machine prompts the ticket buyer for a number
3. Ticket buyer chooses a number
4. Ticket machine prints the ticket
Variations:
1. Ticket buyer can insert $1 as
3. Choosing a number can be
1a. dollar bill
3a. typing a set of digits on machine’s keyboard
1b. coins
3b. hitting the machine’s “quick pick” button
Object Oriented Analysis & Design
Extra ...
• Summary …
Object Oriented Analysis & Design
Better Requirements and Product Quality
through Use Cases (UC)
• Summary of Characteristics
and Benefits
– UCs capture a contract between the
stakeholders of a system about its
behavior
– UCs specify system’s behavior under
various conditions (success & failure
modes) in a way that is concise and
easy to understand, track, and
validate
– UCs are collections of scenarios;
scenarios provide context –
traditional requirements are often too
ambiguous
– UCs are a key to the creation/
generation of quality test cases and
system verification
Industry data:
•
Use cases improved developer
productivity by 40%
(DaimlerChrysler)
•
35% increase in developer
productivity at Merrill Lynch
achieved through: Tool-based
Requirements Management
and Use cases
Object Oriented Analysis & Design
Vocabulary in this section
•
•
•
•
•
•
use case: collection of scenarios
related to a goal
goal: what the actor is trying to
accomplish when using the system
(this might succeed or fail)
scenario: a sequence of interactions
sunny-day scenario: a scenario
where everything works
failure scenario: a scenario that
explains what happens when
something goes wrong
variation: a set of choices for a
single scenario step
•
•
•
•
•
•
extension: a branch scenario that
starts with an extension condition
actor: a person or system outside of
the system under development
precondition: one of the conditions
that must be true when a scenario of
the use case is triggered
chunk or subfunction: a set of
scenario steps that are repeated in
several different use cases
business rule: one of the rules that
describes how the business is run
operational profile: description of
which use cases will be run at the
same time
Object Oriented Analysis & Design
Useful books
• Writing Effective Use Cases by Alistair Cockburn
• Patterns for Effective Use Cases by Steve Adolph
and Paul Bramble
• Use Case Modeling by Kurt Bittner and Ian Spence
Object Oriented Analysis & Design