Use Cases for Requirements
Today’s material: Arlow and Neustadt
ch. 4 and 5 Larman: part of chapter 6
What are requirements?
Use Cases for Requirements
Today’s material: Arlow and Neustadt ch. 4
What are requirements?
Larman: part of chapter 6
Requirements (or specifications, or requirements
specifications)
“…are capabilities…to which the system…must conform”
“Requirements” also names a UP discipline
– Larman p. 41 (2nd), p. 54 (3rd)
See Fig. next
(or L. sect. 2.4 in 2nd ed., and 2.7 in 3rd ed.)
…it is done throughout the project
Unlike in non-iterative life cycle models
(e.g. waterfall model, fountain model)
Disciplines in the RUP
Domain diagrams
Use
cases
Sequence
& Design
class
diagrams
Modified from: http://dn.codegear.com/article/images/33319/RUP.JPG
Use Cases - Background
A use case is a “case of use”
…that is, (generalized) example of usage
Precise translation from the Swedish is “usage
case”
Invented by Ivar Jacobson in 1986
Major advance in the book:
Writing Effective Use Cases,
Alistair Cockburn (“Coburn”), 2000
What is a Use Case?
A use case is a story about using the
system
A use case is a set of related system use
scenarios
A use case is a set of related system use
instances
As a way to communicate among
humans…
Stories are
flexible and human-friendly
Use Cases for System Needs
Because use cases are human friendly…
…they are a good way to capture needs
They are stories about how a system can
meet needs
Example for POS system (what’s another?)
Customer brings items to checkout counter.
Cashier records each item. System displays each
item & price, and current total. Customer provides
payment somehow. System validates it, logs it,
and updates inventory data. System prints receipt
and customer waves a cheery goodbye.
the “somehow” can be expanded into multiple scenarios
E.g. L. p. 46 2nd ed., p. 63 3rd ed.
Stories Can Have Titles…
The title of that use case could be
“Process a customer with items to buy”
Consider a course registration system
A title of a use case might be
“Process a student with courses to sign up for”
Consider a project planning, or general UML
editor system, or _______ system
Write down a title for one use case…
(We’ll have more to say about these in the future)
Use Case – What Is It?
Set of related scenarios
(i.e. set of related use case instances)…
…in which actor(s) use the system…
…to meet some need
Actor: something that behaves in some way
E.g. a cashier, a computer(?), a retail store, a customer…
Not the system itself though
What actors exist in a _____ or UML editing system?
Need: a goal that the system can support
Buying things
Returning things
Determining what to order to restock inventory
Use Cases are Appropriately General
Too specific: Joe Schmoe goes to the grocery store at
11:00 a.m. on Thursday to buy stuff for breakfast. In
his basket he puts beer, chips, and the book “All
About Healthy Breakfasts.” Then he…
A use case instance (specific but not too specific):
one path through a use case.
Example: someone goes to the store, puts items into a cart,
proceeds to the cash only express line…
Another example: . . .
(scenario: same as a use case instance)
A use case: set of “related…scenarios”
The Use Case
as a
Set of Use Case Instances/Scenarios
Use case title: Handle Returns
There is a main use case instance (scenario)
Main success scenario
Credit card expired use case instance
Customer has items to return, cashier scans in each, gets
total, gives refund
Customer paid with credit card, but now can’t refund to
the credit card account, so give cash
Bar code missing scenario
…
Use Case Instances
in the Use Case
Write down a use case instance
(scenario) for a project planning system
use case, UML editor use case, or ____
use case
…then…we’ll put a few on the board…
A Couple of Scenarios…
Make new SSD or use case diagram
E.g. Create, drag, drop a stick figure
(User, mouse, computer have behaviors)
Load and modify previously created
diagram
Use file browser to search the right .uml file,
click to bring it up, ….
(Monitor, file system have behaviors)
Recall ‘Actor’: something that
behaves in some way
What is the actor for each of these?
Make SSD or use case diagram
Load and modify previously created diagram
Create, drag, drop a stick figure
User, mouse, computer
Use file browser to search for diagram in a .uml file,
click to bring it up, ….
Monitor, file system
How about some other examples?
Use Cases – One
Requirements Tool
In the FURPS+ model, use cases…
…are primarily oriented toward one letter
Which letter? (See next slide to figure out)
FURPS+ Model for
Requirements
F is for Functionality
U is for Usability
Speed, resource consumption, accuracy, response delay, etc.
S is for Supportability
MTBF, availability, fail softness, etc.
P is for Performance
Things that help people use it: help, documentation, ergonomics
R is for Reliability
Things it does: features, etc.
Maintenance friendly, configuration support, international issues
+ is for other stuff
Like what?
Functionality:
features vs. valuable features
“…the software industry is littered with failed
projects that did not deliver what people really
needed” – Larman p. 48 (2nd ed.)
Requirements (hence, use cases) should
“Lack of user involvement …is near the top of the list of
reasons for project failure” – p. 65 (3rd ed.)
…focus on reaching goals and adding value
(…not on laundry lists of features)
Otherwise, the system could end up with:
features that don’t add much value; and
important goals that aren’t actually met
Types of Use Cases I
What-based (“black box”) use cases
Describe what system does
Do not describe how system does it
Example of a step:
How-based (“glass box”) use cases
Describe mechanism – how the system does it
Example of a step:
“system records sale to database”
Example 2:
“system records the sale”
“system issues SQL INSERT command”
Which is better?
Types of Use Cases II:
Essential Vs. Concrete Style
Essential: “user is authenticated”
Concrete: “user types name and
password”
Which captures intent?
Which impacts UI?
Which is good to do first?
Which is good to do later?
Use Cases:
Concrete Vs. Essential
versus
What-Based Vs. How-Based
Which pairs of terms are more-or-less
synonymous?
Types of Use Cases III
Brief – 1 paragraph of main use case instance
Casual – Multiple paragraphs
each is a different use case instance (scenario)
Fully dressed – Full details
…of each step
…of each variation
…with preconditions and postconditions
(what are those?)
What is a precondition/postcondition for the UML editor?
See: Arlow and Neustadt Figs. 4.9-4.11, 4.13-4.15, 5,5-5.6,
5.8-5.9, 5.11-5.13, etc.; Larman table on pp. 50-53 (2nd ed.), 68-72 (3rd ed.)
A&N examples are short; reality can be over 1 or 2 pages
Which might one write first? Second? Third?
Example of Use Case –
brief format
Customer brings items to checkout
counter. Cashier records each item.
System displays each item & price, and
current total. Customer provides payment
somehow. System validates it, logs it,
and updates inventory data. System
prints receipt and customer waves a
cheery goodbye.
This “brief format” use case actually
contains several use case instances…
(e.g. L. p. 46 (2nd), 63 (3rd))
Casual Format for Use Cases
Like brief format, except:
Multiple paragraphs instead of one
Each paragraph covers a different scenario
One paragraph is the main success scenario
Other alternatives are in other paragraphs
Fully Dressed
Use Case
Has multiple scenarios
Has numbered steps
(Like casual format)
(Formal, not casual)
Has extra sections
Is fully detailed
http://api.ning.com/files/iaBxrA602vVRgcJuQTS1k*p088*NcQhp87iZ6VY1VFILwH
PGN*9ub*xBTW2VLoGSMcsTjf82l94E9JIaPA3MPR7rEEeG*h/dog.jpg
Examples
See several figures in Arlow and Neustadt
-
Note: you can have alternate subsections
-
Step 6, alternate step 6a, and 6b
Steps can have substeps
In Larman see Fig. p. 50 ff., 2nd ed.; p. 68 ff., 3rd ed.
Types of Use Cases IV:
1-Column Vs. 2-Column
Used for “fully dressed” use cases
2-Column (see e.g. L. p. 53, 2 ; p. 79, 3 ):
nd
Left column is for things outside actors do
Right column is for things the system does
Makes the interaction with the system clear
1-Column:
rd
More compact
Various other format options exist
More Parts of the Use Case
Main Success Scenario
“Happy path” typically with no branches
It’s what you hope will happen
Extension (to alternative paths)
All the (“not-so-happy”) branches off the main
success scenario
Can be several of them
steps numerically keyed to Basic Flow
(5a instead of 5, etc.)
longer than Basic Flow
The Fully Dressed Use Case
Primary actor – the main system user
Stakeholders and their interests –
A use case should describe all behaviors
needed to serve the stakeholder(s)
…that is what should be in a use case
More Use Case Sections…
Precondition –
something that must hold
…before a use case begins
Postcondition –
something that must hold
…after a use case ends
(Postcondition is also called
success guarantee)
Example?
More Parts of the Use Case
Special Requirements
Constraints that aren’t things the system does
Technology and Data Variations List
Requirements that are almost design-like in
flavor
We’re not designing yet
but when we can’t avoid it entirely…
…this is where these aspects go
…If Time Allows
List some use cases for the _______
sysetm or UML editor system
For one of them, list use case instances