How to Avoid Writing

Stupid Use Cases

Ian Spence
ispence@ivarjacobson.com
 How to avoid writing stupid use cases

1. Go on holiday
2. Spend all your time attending conferences
3. Just start coding
4. Write stupid declarative requirements documents instead
5. Read use-case modeling by Kurt Bittner and Ian Spence

2005 Ivar Jacobson International 2

 Agenda

Useless Cases and Useless Models

Avoiding Useless Models
Avoiding Useless Cases
Questions and Answers

2005 Ivar Jacobson International 3

 What is a Use Case?

A use case describes a sequence of actions a

system performs that yields an observable
result of value to a particular actor

Use cases are shown in Use cases are described

UML diagrams in text
They tell the story of the
interactions between
actors and the system
Bank Customer Withdraw Cash Use Case
Specification

2005 Ivar Jacobson International 4

 Looking Inside a Use Case

Basic Flow
Alternative Flows

1. Insert Card
2. Validate Card
3. Select Cash Withdrawal
4. Select Amount
5. Confirm Availability of
Funds
6. Return Card
7. Dispense Cash
A1 Invalid Card
A2 Non-Standard Amount
A3 Receipt Required
A4 Insufficient Funds in ATM
A5 Insufficient Funds in Acct
A6 Would Cause Overdraft
A7 Card Stuck
A8 Cash Left Behind
Etc

2005 Ivar Jacobson International 5

 Useful use cases

Are easy to understand

Facilitate communication with the stakeholders
Are shared by everyone on the project
Capture the requirements of the system
Support the development of the solution
Support the testing and development of the system
Support the scope management of the system
Support the planning of the project

2005 Ivar Jacobson International 6

 Useless use cases

Are either too complicated to understand or say nothing

Alienate the stakeholders
Are only used by the people who write them
Contain no requirements
Do not support the development of the solution
Cannot be used to support the testing and development of the system
Cannot be used for scope management or planning

2005 Ivar Jacobson International 7

 Useless Case #1 No Added Value

Maintain Reference Information

The use case starts when the actor selects the maintain
reference date option from the menu
The actor selects the information to be maintained
The system displays the information
The actor changes the information
The system saves the changes
The use case ends

2005 Ivar Jacobson International 8

 Useless Case #2 All Screen Design
1. The use case starts when the Customer selects the browse product catalogue menu
item. The system displays the catalogue browsing window with the available
products displayed in a scrolling list box.

2. The Customer selects one or more product in the list box.

3. The Customer clicks on the buy products button.

4. For each selected item the system displays a modal dialog displaying the number of
items in stock and an entry field to capture the number of items required.

a. The customer enters the number of items required and click the order button.
The system records the items and quantity required, reserving them in
inventory.

5. The system displays the payment instructions capture screen.

6. The Customer selects their method of payment from the drop-down list of credit card
types.

7. The Customer selects the no marketing check box

2005 Ivar Jacobson International 9

 Useful use-case models

Are easy to understand

Facilitate communication with the stakeholders
Are shared by everyone on the project
Provide an overview of what the system will do
Describe what the system will do to provide business value

2005 Ivar Jacobson International 10

 Useless use case models

Are either too abstract or too complicated

Alienate the stakeholders
Are only used by the people who create them
Try to design the system
Describe how the system will do things

2005 Ivar Jacobson International 11

 A useful use-case model

Purchase Goods Refill and Service

Purchase Tickets
the Machine

Withdraw Cash ATM Engineer Configure the Machine

Check the Machine is in

Working Order
Customer Deposit Funds

Transfer Funds Analyze System Performance

Reconcile Transaction Logs

Manage Account
Charge Device With
ATM Operator
Funds Run Advertising Campaign

Update System Configuration

Burglar Break Into Machine

Change Pricing

2005 Ivar Jacobson International 12

 Useless Model #1

Actor 2

Actor 3

Actor 1
Just Do It User
Use the System

Actor 4

Actor 5

2005 Ivar Jacobson International 13

 Useless Model #2
Business Fact F inding
extends
DT Making Diary appointment
Reviewing your needs
Fact Finding
DT Updating client details
uses
Identifying priorities
uses extends
Adviser uses
DT Add Prospect details Entering Client Objectives
Full Financial Analysis Projection extends
uses
extends
Protection fact finding
uses
extends
Connecting to Head Office uses
extends & Loans fact finding
Mortgages
uses
Illustrating AVC
uses extends
Personal Fact Finding uses
uses
uses
uses Fact findillustrating
notes group pension
uses Retirement fact finding
extends uses extends Illustrate EPA
extends
uses extends extends
Tax fact finding Illustrate Income Withdrawal Plan
uses uses uses
uses uses uses extends extends Illustrate PPA
Long term care fact finding
uses
uses
extends
Investement, Savings and Assets illustrating personal pension
illustrating retirement Illustrating Health Care to a group
fact finding uses member
extends
Issuing copy extends Illustrate Lifestyle Plus Cash
Inheritence fact finding uses
Adviser uses extends
extends Illustrating Mortgage Illustrating Lifestyle Plus
extends
uses Anticipated Receipts & Outgoings illustrating protection extends
extends extends uses uses extends Illustrating Lifestyle
Surrendering Product uses extends
Illustrating LTC
extends
Calculation and Presentation uses Illustrating AEP
Assessing new risk extends
F acility
illustrating investment
extends
Designing A solution
Reporting suspect case extends
Illustrating Maximun Ivestment
uses Plan
uses extends
uses
Entering Personal Supplimental Illustrating PEP
extends
uses Details
Entering occupational details
uses extends
uses Entering AVC details
uses extends
usesuses
Entering Hazardous Activities
Retired directors renumeration extends
Entering EPA Details Illustrating Investment Bond
extends Entering Life of Another Detailsuses
uses extends
Entering APP Details uses Illustrating GEB
Entering PPA Details
extends
Entering Applicant details
uses
Illustrating DB
usescompleting retirement app
Authorising reason for replacement extends extends
extends
uses
extends uses uses
extends Completing GP Scheme extends uses
Completing Application uses
uses extends
Determine suspect case status Adding new memberEntering
GP PEPCash
to Entering App
Withdrawal Plan
uses uses
extends uses
Compiling Reason for Replacement
Compiling Reason for uses
uses Recommendationuses extends extends Entering Distribution Bond
extends uses
uses extends
uses extends
Entering Guaranteed Equity Bond
block fraudulent case extends uses extends
Personalising Reason for extends extends
completing investment app Entering SPB App
Recommendation Complete Declaration
Entering Investment Bond
extends
extends
extends uses
Entering Bank account details uses
Entering Unit Trust App uses
Entering MIP Details
Entering Fund Choices
Entering Entering
Initial Payment
RegularDetails
payment details
Converting plan
Replacing Product
uses
uses

Entering Assured health details

uses Entering AEP App
extends

extends
completing protection app Completing PPP LTC App
extends

extends
Entering Lifestyle
Entering
App Lifestyle Plus App

2005 Ivar Jacobson International 14

 Agenda

Useless Cases and Useless Models

Avoiding Useless Models
Avoiding Useless Cases
Questions and Answers

2005 Ivar Jacobson International 15

 Focus on the System Boundary

Considering other systems as actors forces you to confront the boundary of

the system you are creating

Where is the
information that
Transfer Funds
will be required
to support the
behavior?

Bank Customer
Withdraw Cash

Bank System

Check Balances

Big problems occur if you

do not identify your
system boundaries

2005 Ivar Jacobson International 16

 Dont pre-empt the Design

Is the other system really an actor or part of the systems

assembly?

Middleware Bank System

If the system is required to

communicate with another
system, represent it as an actor
in the model

Operating System
Web Browser

Use-Case Modelers must never pre-empt

designers and try to use the use-case model
to design the system

2005 Ivar Jacobson International 17

 Dont Confuse the Actors with the Devices They Use

Disk Drive

Keyboard System

Mouse

2005 Ivar Jacobson International 18

 Dont Confuse Use Cases with Functions

Incorrect Use of use cases as menu options or functions:

Delete Order

Add Order Change Order

Customer

Approve Order Order Inquiry

2005 Ivar Jacobson International 19

 Dont Confuse Use Cases with Functions

Use cases that combine functions to reflect the real value to the actor:

Browse Products and Place

Orders
Customer

Track Orders

Take care to focus on value to the user

The communicative value of the model will soon be lost if functional
decomposition creeps it.
Dont end up drowning in hundreds of use cases

2005 Ivar Jacobson International 20

 Derive the Use Cases from the Systems Vision

As with actors, All existing requirements information should be leveraged to

help identify candidate Use Cases
Are all the users
Do the use
rs,
responsibilities
cases Ot e
conform to Re her o ld er sufficiently
P eh hold ser
q addressed by the
any
Co uire rodu a k U system?
constraints ns me ct St take nd
placed upon tra nts
int , S s a es
the system? s ole yp
R T

Are the set of

Does the
system ld er Ide identified use
provide the o
eh and Sy ntifie cases capable
k s d of delivering
behavior to a
St eeds lem t (C Feat tem all the
satisfy the
N rob en ap ur
stakeholder P tem ab es features
ilit defined?
needs and a ies
solve the St )
problem?

2005 Ivar Jacobson International 21

 Dont forget the Supporting and Operational Use Cases

These primary
Get New and Special Offers use cases
cannot provide
Shopper their value
without the
Browse Products and Place Orders information
provided by the
supporting use
cases

Marketer Set Product Offers

Maintain Products and Availability

Product Manager

2005 Ivar Jacobson International 22

 Handling Common Problems

Evolve the set of actors alongside the set of use cases

The two activities go hand-in-hand, simultaneously and iteratively
Avoid functional decomposition
Maintain focus
Synthesize dont analyze
Dont describe outside the system
Dont just draw pictures
Dont mix business and system use cases
Remember good use-case models have no levels
Ensure that each use case provides something of value

2005 Ivar Jacobson International 23

 Dont Over Structure the Model.

If there is one thing that

sets teams down the
wrong path, its the misuse
of the use-case
relationships: include and
extend

<<include>>

<<extend>>

Here there be Dragons

2005 Ivar Jacobson International 24

 A Good Model Helps to Create Good Use Cases

The key to a successful start with use cases:

Understand the purpose and boundary of the system
When Identifying Actors work from the specific to the general
Dont forget external systems that interact with the system being developed
A use case should provide independent value to the actor, if you have to
execute several use cases in a sequence to add value, you have gone
wrong
Use the vision and the high level requirements it contains to validate your
use case model.
Evolve the set of actors and use cases alongside each other in an iterative
and incremental fashion.

2005 Ivar Jacobson International 25

 Agenda

Useless Cases and Useless Models

Avoiding Useless Models
Avoiding Useless Cases
Questions and Answers

2005 Ivar Jacobson International 26

 Write Simply, Directly and Deliberately

Write in active voice:

Direct declarative statements, the system validates the amount entered rather
than the amount entered should be validated by the system
Write in present tense:
What the system does, not what it will do, the system validates the amount
entered rather than the system will validate the amount entered, when will in
do it?
Write in newspaper style:
Simple sentences in a top down format. From major to minor issues.

2005 Ivar Jacobson International 27

 Treat the Use-Case Like a Story

The use case starts when the

actor [Actor] does [something]

The [Actor] does [xxx]; then the
system does [yyy] in response

They all lived The system does [xxx]; then the

happily ever [Actor] does [yyy] in response
after.

The use case [xxx] ends when

[yyy].

2005 Ivar Jacobson International 28

 Make a Conscious Decision about the Depth of Detail

Use Cases can be considered a technique for Limited Detail

reducing risk that people might misunderstand
what the system should do
The amount of detail you need is dependant on a
number of factors including:
The level of legal / contractual / safety / regulatory
requirements
The amount of domain expertise you have in the
team
The need to record complex decision making
The detail required to support testing activities

Lots of Detail

2005 Ivar Jacobson International 29

 Sometimes an Outline is Enough

Briefly
Discovered
Described

Bulleted Essential
Outline Outline

Detailed
Fully Described
Description

Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002
2005 Ivar Jacobson International 30
 Describe what Happens when the Actors / System Interact

You will have to describe what the system does

Do not describe how the user interface or internal components collaborate to
do what the system does

The system
The system The system
pops up a
prompts the determines that
dialog box.
user the entered PIN
The user is correct
selects from a The system
drop-down displays a list
The user box
list. enters
The cash dispenser
The card reader The system
component records the
subsystem determines records the
amount of cash
whether the PIN amount of
dispensed as a null
entered is correct money
terminated string in the
dispensed
transaction database

2005 Ivar Jacobson International 31

 Dont rely on Just Text

Use the appropriate Class (Domain) models, help

illuminate the use case by
visual techniques to
explaining complex concepts
supplement and
support your use
cases

Activity Diagrams,
provide a way to
visualize a complex flow
of events

Use-Case storyboards, a series of screen shots

from a prototype to depict the flow of events of
the use case

2005 Ivar Jacobson International 32

 Dont Ask People to Describe Things They Dont Understand

Dont force people to make up requirements

Use other techniques to support your use cases
Observation
Business Models
A picture is worth a thousand words
A prototype is an invaluable tool to describe a user interface, leaving the
use case to describe what happens behind the scenes.
Great for generating user feedback
Great for presenting to stakeholders
The prototype should evolve in parallel with the use case
descriptions
Great for instantiating scenarios
Can be a good basis for usability testing

2005 Ivar Jacobson International 33

 Adapt the Description to Your Intended Audience

Different Audiences need different information presented in different ways

Audience = Users: Audience = Designers:

2005 Ivar Jacobson International 34

 Use the Glossary and Domain Model to Capture Definitions

Anytime you see a lengthy discussion or definition that serves mostly to

explain background information, consider putting it into the glossary
Enlightened use of a glossary will simplify the use-case descriptions by
allowing the use case to focus on describing behavior not terminology.
Details Matter
What is customer information, better define it as Name, Address, Order
History and so on..

2005 Ivar Jacobson International 35

 Dont Forget There Are Other Places to Put Things

The system shall

The system must

The system shall

Use Cases Supplementary Specifications

?
Which one to choose?
Balance is the key!
A large amount of
actor interaction
(ATM / UI) = majority
of requirements in
use cases

A small amount of
actor interaction (a
compiler) = majority
of requirements in
supplementary
specification

2005 Ivar Jacobson International 36

 Start from an outline Start from the basic flow

Good writing typically proceeds from an

outline; use cases are no different:
Outlines will help clarify the purpose of the use
case and help you think through each step 2
As you evolve the use case from the outline, 1

focus first on the basic flow

Evolve the alternative flows only when there is
the framework of the basic flow upon which to
build

Basic flow,
then
alternates

2005 Ivar Jacobson International 37

 Dont Write Them On Your Own

Involve other people in the creation of the use cases

Subject matter experts
Developers
Testers
Always share and walkthrough the outlines before adding more
detail

2005 Ivar Jacobson International 38

 Write down the requirements

Dont be scared of detail

A use case with no detail truly is a useless case
The trick is to include it without obscuring the use-case
message..

2005 Ivar Jacobson International 39

 Agenda

Useless Cases and Useless Models

Avoiding Useless Models
Avoiding Useless Cases
Questions and Answers

2005 Ivar Jacobson International 40

The End

ispence@ivarjacobson.com

2005 Ivar Jacobson International 41