Agile Use Cases

Alistair Cockburn 2005
Slide 1
Use Cases for Agile
and Traditional Development

Writing Effective Use Cases
meets
Agile Software Development

Alistair Cockburn
http://Alistair.Cockburn.us
Slide 2
Use case: text of scenarios of user succeeding
or failing to achieve a goal using the system.

Place an order (User-level goal for Clerk)

Main scenario:
1. Clerk identifies customer, item and quantity.
2. System accepts and queues the order.

Extensions:
1a. Low credit & Customer is Preferred:
System gives them credit anyway.

1b. Low credit & not Preferred customer:
Clerk accepts only prepayment.

2a. Low on stock: Customer accepts rain-check:
Clerk reduces order to available stock level.
(goal of primary actor)
(level of goal [summary | user | subfunction])
(action steps:
full sentences showing
who takes the action!
3 - 9 steps.)
(condition causing different actions)
(action steps to handle that condition)
(primary actor)
Robert Martin: It shouldnt take longer than 15 minutes to teach someone how to write a use case!
Slide 3
Schedule of events
1. What is(nt) a use case (good for)

2. What is(nt) agile (good for)

3. Communication games

4. Exercises in use case writing

5. Writing agile use cases agile-ly
Slide 4
Can use cases be agile?
Do use cases contradict Agile ?
: Use cases / UCs vs stories
: Agile / value of agile
When should we use agile use cases ?
: document faster, later, cheaper,
: plan on changing your mind along the way,
: always.
Exercising dimensions of freedom
: Write less, more clearly (tips).
: Shortcut process & use case structure ... (tips,
tradeoffs)
: Tools
Q&A
Slide 5
Coming from agile non-use-cases to agile UCs
is easier than coming from non-agile UCs
Overly complex use case writing is hard to change,
tied to overly complex process (hard to change!)

Already understanding Agile means
: already have a lighter process
: already have mindset to simplify the writing
: ... leads to agile use case writing.

Need to understand
: (A) Simple use cases
: (B) Agility as energy savings
Slide 6
Part 1:

What is(nt)
a
use case

(good for)
Slide 7
Good use cases
are arent
Text
No GUI
No data formats
3 - 9 steps in main scenario
Easy to read
At users goal level
Record of decisions made
UML use case diagrams
describing the GUI
describing data formats
multiple-page main scenario
complicated to read
at program-feature level
tutorial on the domain
Use cases *can be* written --
all up front --or-- just-in-time
each to completion --or-- in (usable) increments
(Most UCs in the world
are sadly like this :-(
Not good for any project)
(This should be true for
all UCs, agile or not)
(This is more agile)
Slide 8
Good use cases ...
: Communicate in a language that crosses specialties
(technical -- non-technical -- cross-technical)
: Describe what the system will do
(a contract for all stakeholders in the systems behavior)
: Record decisions made
: Allow check for completeness
: Contextualize requirements
: Give advance notice of items needing research

: ... dont subdivide ...
(A user story cut in half makes two smaller user stories, as a
flatworm cut in half makes two smaller flatworms,
but a use case cut in half doesnt make two small UCs, as a
horse cut in half doesnt make two small horses.)
Slide 9
Use cases summarize end-users desires,
not programmers tasks.
1980s: Lets write requirements in features!
: Users dont understand...
...user pressure to write in use cases...

1990s: Lets write requirements in use cases!
: Programmers work units are features, not use
cases...
...programmer pressure to write in features...

2000: So lets write requirements in features!
: FDD & XP user stories...
...lose the end user experience again ...

A pendulum of features vs. use cases
Slide 10
1. Use cases hold functional requirements in an easy-
to-read text format

2. They make a good framework for
non-functional requirements & project scheduling.

3. Use cases show only the Functional reqts.

4. Design is not done only in use case units.
Use cases have strong & weak points
(as anything)
Slide 11
Use cases do not collect formulae, state,
cardinality, performance, uptime, ...
Examples:
1. Order cost = order item costs * 1.06 tax
2. Promotions may not run longer than 6 months.
3. Customers only become Preferred after 1 year.
4. A customer has one and only one sales contact.
5. Response time is less than 2 seconds.
6. Uptime requirement is 99.8%.
7. Number of simultaneous users will be 200 max.

Capture those in any form available,
*somewhere* in your requirements files !
(Agile teams: write as supporting detail for your
story card)
Slide 12
Goals make a good structure on which to hang
requirements & project details.
Project planning capitalizes on goal structure:
: Useable Releases.
: Priorities,
: Schedule, staffing

Name P. Actor Pr. Diff. Release
Update customer Customer high med 1
Scan products Customer high high 1
Generate invoice Finance high high 3
Funds transfer Finance med high 4
(Note: spreadsheets are perfect for this!)
Slide 13
Use cases provide values at different times:
1. The list of goal names provides executives:
: Shortest summary of what system will contribute
: Project planning skeleton (priorities & timing)
2. The main success scenario provides all:
: Agreement as to the systems responsibilities
: (Agile teams: context for the user stories)
3. The extension conditions provide devt team:
: Things programmers have to watch for
: Advance warning of things analysts have to investigate
4. The extension handling steps provide devt team:
: Record of (tricky) business policy decisions
5. The full use case set provide devt team:
: Completeness check on the requested functionality
Slide 14
The hard parts about use cases is not typing,
but thinking and agreeing.
~ 3 days construction
: ~ 2 hours typing
: 2.75 days spent thinking & arguing about policies

1. Is each step correct?
2. Are there any system responsibilities between
steps?
3. Are there any outside systems this system should
use?
4. Are there any other stakeholders whose interests
we missed?
5. Did we catch every extension condition?
Slide 15
Dont try to teach a tutorial on the subject
domain within the use cases!
In any text, receiver must always jump a gap.
: Experts jump larger gaps
: Novices jump smaller gaps.

To teach a domain, you need a textbook, not use
cases.
: Textbooks use smaller gaps.
: Think of use cases as documenting decisions,
not teaching the domain.

Target the gap for the people: sufficient
communication with a small-enoughgap.
: More experienced people need less writing !
Slide 16
Part 2:

What agile development
is(nt)

(good for)
Slide 17
History: How did agile arise?
Agile techniques were in use since the beginning.

Agile (mobility-based) techniques did not show
competitive advantage in the 1970s / 1980s,
but did during the 1990s and do now.

1994: trials of semi-formal agile methodologies
RAD DSDM
XP Crystal
Scrum Adaptive

2001: term agile coined to describe the approach
(3-1/2)
Slide 18
Development approaches are only attitudes,
centering of the attention.
Declarations of core values declare an attitude

An attitude cannot promise success in the future,
it can only be spoken successfully in the past tense.
it is only a wish to be a certain way

A would-be agile process
A would-be predictable process
A would-be repeatable process
A would-be inexpensive process
(4-1/2)
Slide 19
2001 Agile Software Development Manifesto
- a declaration of values
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
: Individuals and interactions over Processes and Tools.
: Working software over Comprehensive documentation.
: Customer collaboration over Contract negotiation.
: Responding to change over Following a plan.

That is, while there is value in the items on the right, we value the
items on the left more.
Slide 20
2005 Declaration of Inter-dependence
for agile-adaptive project management
We increase return on investment by making
continuous flow of value our focus;
...deliver reliable results by engaging customers in frequent
interactions and shared ownership;

...manage for uncertainty through iterations, anticipation and
adaptation;

...unleash creativity and innovation by recognizing that
individuals are the ultimate source of value, and creating
an environment where they can make a difference;

...boost performance through group accountability for results
and shared responsibility for team effectiveness;

...improve effectiveness and reliability through
situationally specific strategies, processes and practices."
Slide 21
Agile development works because
software development is an economic game
Economic consequences to each choice.
: Less is usually better... sufficient is enough.

(Project success factors reviewed:)
Nourishment
Skills
Citizenship
Communication
Focus
Increments
(Agility resides Here!)
(Includes developers AND users!)
Slide 22
Agile = shortcutting the process (cheating legally to win)
Scope
Time Resources
Process
(Some people use agile to handle late-breaking requirements changes
. . . you can also use it to improve development efficiency)
Scope
Time Resources
The iron triangle isnt a triangle at all --
Process is the 4th dimension !
Slide 23
Agile development: short-circuiting process
steps without compromising final product.
Focus on *early* & *frequent* delivery of *useful*
software to real users using *just-in-time*
techniques.

Focus on *feedback* loops at all levels
(requirements, design, code, test, communication)

Replace fanfare around the process with
people checking in with other people.

*Talk* to users / sponsors, find out what they need!

Adjust your working habits *monthly or quarterly* to
fit your particular situation!
Slide 24
The Agile attitude focuses on:

1. Talent & Skill (fewer better people)
2. Proximity (developers - developers - users)
3. Communication (morale, daily standup)
4. Just-in-time requirements and design
5. Frequent Delivery (incremental development)
6. Reflection
7. Less paper, more tacit / verbal communication
8. Tools
9. Quality in work
10. Different strategies for different projects
Slide 25
Agility *can*
Be heavier or lighter, depending on circumstances
Use various requirements techniques
(e.g., use cases, stories, features)

In agile development we value
following the principles over following specific practices !
Good agile development
is / does isnt / doesnt
Efficient
Lots of just in time
Adjust to circumstances
(Re)Plan regularly
Lots of person-to-person comm.
Adaptively cut fat in the process
hacking
Giant Energy Up Front (GEUF)
only XP (XP is one alternate)
plan-less
People sitting in isolation
rigid adherence
Slide 26
Problem Size
Light methodology
Heavy
methodology
# people needed
Lighter-agile vs. Heavier-agile :
Light is good, but has limits.
fewer people
more people
(Never forget this!)
Slide 27
Number of people involved

C
r
i
t
i
c
a
l
i
t
y

(
d
e
f
e
c
t
s

c
a
u
s
e

l
o
s
s

o
f
.
.
.
)

Comfort
(C)
Essential
money
(E)
Life
(L)
+20%
. . .
Prioritized for Legal Liability
1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000
C6 C20 C40 C100 C200 C500 C1000
D6 D20 D40 D100 D200 D500 D1000
E6 E20 E40 E100 E200 E500 E1000
L6 L20 L40 L100 L200 L500 L1000
Prioritized for Productivity & Tolerance
Discretionary
money
(D)
Suit the process to the occasion
project size & priorities, system criticality
Slide 28
Is / Isnt: Misconstruing the message
1. Agile SD is cheating

2. Agile SD requires the best developers

3. Agile SD is hacking

4. Agile SD wont work for all projects
Slide 29
1. Agile techniques are cheating.

Hire good people;
Seat them close together to help each other out;
Get them close to the customers and users;
Arrange for rapid feedback on decisions;
Let them find fast ways to document their work;
Cut out the bureaucracy.

This is:
cheating
stacking the deck
a good idea
the heart of agile software development
Slide 30
2. Agile only works with the best developers.

Every project needs at least one experienced and
competent lead person. (Critical Success Factor)

Each experienced and competent person on the team
permits the presence of 4-5 average or learning
people.

With that skill mix, agile techniques have been shown
to work many times.
Slide 31
3. Agile is hacking.
(Hacker interpretations are inevitable.)
Hackers: ...spend all their time coding
Agilists: ...test according to project priorities,
recheck results with users often.

Hackers: ...talk to each other when they are stuck
Agilists: ...talk to each other and customers as
a matter of practice.

Hackers: ...avoid planning
Agilists: ...plan regularly

Hackers: ...management caves in out of fear
Agilists: ...expect management to provide priorities,
& participate jointly project adjustments.
Slide 32
4. Agile wont work for all projects.

Agile is an attitude prioritizing:
Project evaluation based on delivered code
Rapid feedback
People as a value center
Creativity in overcoming obstacles

Not every team
... values the Agile value set.
... can set up the needed trust and communication

Right. (Business isnt fair).
(5-6/6)
Slide 33
Groups tolerance for ambiguity / uncertainty
P
r
o
d
u
c
t
i
v
i
t
y
:

(
F
l
u
x

&

U
n
c
e
r
t
a
i
n
t
y
)

Reality Check: Work as parallel & light as
project features and personalites permit.
e-projects
old-school
projects
Project requires at least this much
productivity to succeed
Where is
your group,
your project
on this graph??
Slide 34
Part 3:

Communication Games
Slide 35
Perfect communication is impossible

You try to communicate what you know

You dont know what it is you do know;

What you know depends on your individualized parsing of
the world around you;

You dont actually know the thing you are trying to
communicate;

You dont know what you are actually communicating;

Your listener sees only a part of what you are saying;

What your listener learns depends on his/her internal state.

(How is it we communicate at all?)
Slide 36
COMMUNICATION is
touching into shared experience
Linked sequences of shared experience becomes a
shared experience

: Project colleagues have rich shared
experiences, a shortcut vocabulary

Implications for documentation:
: You can never fully specify requirements
or document a design
: must assume readers experiences
more => can write less
less => must write more.

Our task is to manage the incompleteness of
communications
the program
theory
design
patterns
UML
source code
Slide 37
Face-to-face allows vocal, subvocal, gestural
information to flow, with fast feedback
Richness of communication channel
C
o
m
m
u
n
i
c
a
t
i
o
n

E
f
f
e
c
t
i
v
e
n
e
s
s

2 people at
whiteboard
2 people
on phone
2 people
on chat
Videotaped
Paper
Audiotaped
(Courtesy of Thoughtworks, inc.)
cooler warmer
Slide 38
Experience incommunicability and
elementary agile techniques for yourselves

Divide each into Specifiers and Artists.

The Specifiers will ask the Artists
to draw a drawing for them.
Slide 39
Draw a Drawing
1st round -- 10 minutes
1. Specifiers and Artists move to opposite ends of the
room. (this corresponds to distributed virtual teams)
2. Specifiers WRITE instructions to their Artists on
what to do (no drawings or photos).

3. One Specifier carries messages back and forth,
can watch but NOT speak or gesture at Artist side.

4. Artists may write messages back.

5. NO speaking, gesturing, photos or drawing between
Specifiers and Artists.

Slide 40
PAUSE
5 MINUTES
1. Pause. Most teams do not create a way to change
process on the fly. We need a way to evolve the
process.

2. Discuss and reflect: what went good and bad.

3. Adjust your strategy for the next round.

4. Use the reflection technique & chart.

(this corresponds to iterative development
with process feedback.)
Slide 41
Reflection technique: Write in this chart.
What worked? What might you try next time?
(this is a core technique you should use
every month on every project !)
Try These Keep These

Ongoing Problems

Slide 42
Draw a Drawing
2nd round -- 5 minutes
1. As before, but use incremental technique
Specifiers describe only ONE shape.
(Advanced teams: two people one shape each.)

2. After Artists have drawn the shape,
they cand send it (or copy) to the Specifiers to see.

3. Specifiers can decide whether to correct that shape,
or go on with the next shape.

(this corresponds to incremental delivery
with product feedback.)
Slide 43
Reflection technique: Write in this chart.
What worked? What might you try next time?
(this is a core technique you should use
every month on every project !)
Try These Keep These

Ongoing Problems

Slide 44
PAUSE
5 MINUTES
1. Pause and reflect one more team.

2. Discuss and reflect: what went good and bad.

3. Look for creative ways to cheat legally.

4. Use the reflection technique & chart.

5. What would be actually the Best way to work?
(if you could do anything)
Slide 45
End. You have just seen a cooperative game of
invention & communication in action.
8 things you may have observed:

Distance hurts. (So DONT DO IT !)
Sitting together, multimodal communication help.
Communication has its limits.
What you write depends on your shared vocabulary.
A process needs to allow for its own evolution.
Action & Feedback help reduce ambiguities.
Both Process and Product feedback are needed.
One possible reflection workshop technique.
Slide 46
Part 4:

Exercises in
use-case writing
Slide 47
Precision = How much you care to say.
Precision is expensive ...
Control when you add it and how much you add.

We work in four levels of precision with use cases:

Level 1: Actor's name and goal.
Level 2: The brief or the main success scenario.
Level 3: The extension conditions
Level 4: The extension handling steps.

Slide 48
How to do it:
(1). Identify the actors and their goals.
An actor is anything with behavior.
What computers, subsystems and people will drive
our system?

What does each actor need our system to do?
: Each need shows up as a trigger to our system.

Result: a list of actors & use cases.
: Short, fairly complete list of usable system
function.
: Low precision (not much detail), but very
useful.

Slide 49
How to do it: For each use case...
(2). Write the simple case: goal delivers.
The main success scenario, the happy day case.
: Easiest to read and understand.
: Everything else is a complication on this.

Capture each actors intent and responsibility, from
trigger to goal delivery.
: Say what information passes between them.
: Number each line.

Result: readable description of systems function.
Slide 50
How to do it:
(3). Capture conditions needing other handling.
Usually, each step can fail.
Note the condition after the main success scenario.

The value of extension scenarios is completeness,
detecting unusual situations.

What if their credit is too low?
What if they run over the extended credit
limit?
What if we cannot deliver the quantity?
What if data is corrupt in the database?
(These are commonly overlooked situations)

Result: list of alternate scenarios to work out
(over time)
Slide 51
How to do it: For each extension condition,
(4). Follow the extension till it ends or rejoins.

Recoverable extensions rejoin main course.
Non-recoverable extensions fail directly.

Each scenario goes from trigger to completion
(success or failure)

Result: Complete use case
Slide 52
Write the recoverable and failure scenarios as
extensions to the ideal one.

UC 4: Place an order
1. Clerk identifies the customer, each item and quantity.
2. System accepts and queues the order.

Extensions:
1a. Low credit & Preferred customer: Extend credit.
1b. Low credit & not Preferred customer: Cash only.
2a. Low on stock: Customer accepts reduced...
Slide 53
Final Process:
Write the use cases in 4 distinct steps
Step (1). Identify the actors and their goals.
Result: a list of actors & use cases, a sketch of the system.
Value: overview of system, useful for prioritizing, estimating.

Step (2). Write the simple case: goal delivers.
Result: readable description of systems function.
Value: team alignment on systems responsibilities.

Step (3). Name the conditions needing other handling.
Result: list of alternate scenarios to research over time.
Value: beat the programmers to the resolution!

Step (4). Follow the extension till it ends or rejoins.
Result: complete use case.
Value: business rule written down for programmers &
testers.
Slide 54
Place an Order
1. Clerk identifies customer
2. ...

Identify Customer
1. Operator enters name.
2. System finds near matches.

Extensions:
2a. No match found: ...
Note the active verbs!
A scenario refers to lower-level goals
(sub-use cases or common functions).
(user-level or sea-level goal)
(subfunction or fish-level goal)
Slide 55
UC 4: Place an Order
1. Clerk identifies customer <- (assumes success)
2. ...
Extensions:
1a. Customer not found: <-(does not care why
it failed, only if it
is recoverable)
The outer use case only cares if the inner one
succeeds, avoiding proliferation.
Slide 56
User Goals
advertise order invoice
set up
promotion
reference
promotion
monitor
promotio
n
place
order
create
invoice
send
invoice
identify
promotion
identify
customer
register user
identify
product
make money
Summary Goals
Subfunctions
Level: Summary --- user-goal --- subfunction
( or kite --- sea-level --- fish )
The Altitude metaphor: User goals are at sea level.
put cursor in
entry field
Slide 57
Summary use cases show how functions interact
-- very few, but very important
Buy Goods+ Scope: All Sales Systems Level: Kite

1. Buyer researches on website, requests sales rep assistance.
2. Webserver has ProcessServer send lead information to a salesperson.
3. Salesperson establishes a new opportunity in SalesManager.
4. Salesperson has SalesManager contact the lead, discusses with Buyer, and
validates they could possibly provide a solution.
5. Salesperson using SalesSupport develops product recommendations based
on analysis information and recommendation provided by Webserver.
6. Salesperson develops presentation in SalesSupport and presents to buyer
using SalesSupport.
7. Buyer requests a proposal.
8. Salesperson develops a proposal and sends to buyer.
9. Salesperson negotiates with the Buyer to close the deal as a win.
10. Salesperson updates forecast and commission using SalesManager.
11. Salesperson places an order for items using SalesSupport.
12. The Company assembles and ships the products purchased.
13. Company invoices buyer and buyer pays.
Slide 58
You will need all of kite, sea, and fish use
cases at some point in the project.
scope
goal-level (time)
1-2
2-5 1-3
80%
days
years
hours
days
2-20
min.
secs.
mins.
20%
1
2
2
3
3
4
5
Slide 59
Open Practice (Process Miniature):

Create the use cases for a
library-user counting device
Slide 60
The university wants to understand the
traffic in the library.
A student will use a Palm and note when anyone enters or exits.
... The student shouldnt reset the device to zero -- a
supervisor should do that each morning. ... Eventually, the
handheld will notify a server every time the number changes.
Write the use cases for the librarys user counter system.

For full system :
Step 1. design scope ... primary and secondary actors .
Step 2. summary and sea-level use cases for the system.
Step 3. project release plan with tiny first release.

For "Register entry" :
Step 1. stakeholders and interests.
Step 2. main success scenario. (Check stakeholders' interests)
Step 3. extension handling conditions.
Step 4. extension handling steps.
Slide 61
STANDARD MISTAKES: Register for Courses
(Patterns for Effective Use Cases, Steve Adolph & Paul Bramble, UC 1.1)
1. Display a blank schedule.
2. Display a list of all classes in the following way: The left window lists all
the courses in the system in alphabetical order. The lower window
displays the times the highlighted course is available. The third window
shows all the courses currently in the schedule.
3. Do
4. Student clicks on a course.
5. Update the lower window to show the times the course is available.
6. Student clicks on a course time and then on the Add Course button.
7. Check if the Student has the necessary prerequisites and that the course
offering is open.
8. If the course is open and the Student has the necessary prerequisites, add
the Student to the course. Display the updated schedule showing the new
course. If no, put up a message, You are missing the prerequisites.
Choose another course.
9. Mark the course offering as enrolled in the schedule.
10. End do when the Student clicks on Save Schedule.
11. Save the schedule and return to the main selection screen.
Slide 62
Corrected Register for Courses
(Patterns for Effective Use Cases, Steve Adolph & Paul Bramble, UC 1.3)
System: Course Enrollment System Goal level: User Goal

1. Student requests to construct a schedule.
2. The system prepares a blank schedule form.
3. The system gets available courses from the Course Catalog System.
4. Student selects up to 4 primary and 2 alternate course offerings.
5. For each course, the system verifies that the Student has the necessary
prerequisites, adds the Student to the course, marking Student as
enrolled for that course in the schedule.
6. When the Student indicates the schedule is complete, the system saves it.

Extensions:
1a. Student already has a schedule: System brings up the current version of
the Students schedule for editing instead of creating a new one.
1b. Current semester is closed and next semester is not yet open: System lets
Student look at existing schedules, but not create new ones.
3a. Course Catalog System does not respond: The system notifies the
Student and the use case ends.
5a. Course full or Student has not fulfilled all prerequisites: System disables
selection of that course and notifies the Student.
Slide 63
Part 5:

Using agile use cases
Agile-ly
Slide 64
Using use cases agile-ly :
increments, just-in-time, close communication
Write just enough content to plan the needed horizon
: Long (project) horizon -> use case names or briefs.
: Short (iteration) horizon -> also extension handling.

Just barely beat the programmers to the extension
handling decisions

Write just enough content for the team to understand.

Show the UCs & system to users&sponsors, get feedback!

Adjust your working habits each iteration to fit your
particular situation!
Slide 65
Always question how much to write at any
given time

How much do we need to write at this time?
When do we need to write more?
What is the fastest way to write/convey them?
Who benefits from more information or more detail?
Slide 66
Take advantage of available degrees of
freedom in your process
1. Write less more clearly (always)
2. Write less (sometimes)
3. Shortcut the use case structure (sometimes)
4. Write later & shortcut the process (usually)
Slide 67
1. Write less more clearly (always)

Text
No GUI
No data formats
3 - 9 steps in main scenario
Easy to read
At users goal level
Record of decisions made
UML use case diagrams
describing the GUI
describing data formats
multiple-page main scenario
complicated to read
at program-feature level
tutorial on the domain
(shorter,
more economic
& more readable!)
Slide 68
2. Write less (sometimes)
the economics of communication
Fully dressed use cases (exhaustive, numbered)
Casual use cases (approximate, paragraph form)
Use case briefs (1-2 sentences)

The correct form to use depends on your
projects priorities and properties !

Slide 69
Economics of communication:
Fully Dressed (expensive, complete)
Use Case 12. Buy stocks over the web
Primary Actor: Purchaser (user) Scope: PAF
Level: user goal Precondition: User already has PAF open.
Guarantees: sufficient log information exists that PAF can detect what went wrong.
Success Guarantees: remote web site acknowledged purchase, user's portfolio
updated.
Main success scenario:
1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade, Schwabb, etc.)
3. PAF opens web connection to the site, retaining control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and updates the user's portfolio.
6. PAF shows the user the new portfolio standing.
Extensions:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to cancel use case.
3a. ...
Slide 70
Casual (less expensive, less complete)
Buy something (Purchaser / user-goal level)

The Requestor initiates a request and sends it to her or his Approver,
who completes the request for submission and sends it to the Buyer.
The Buyer finds the best vendor, initiates PO with Vendor.
At any time prior to receiving goods, Requestor can change or
cancel the request. Canceling it removes it from any active
processing.

Slide 71
Brief (inexpensive, just a short note)
Actor
Goal Brief Description
Production
Staff
Prepare
digital
cartographic
source
Convert external digital data to
standard format, validate &
correct in preparation for
merging with operational
database.
... ... ...
... ... ...
(Note: spreadsheets again!)
Slide 72
3. Shortcut the use case structure (sometimes)

Use cases are not read by a compiler but by a human...
--> so,
Dont be rule-bound, but adapt the form to your needs.
Slide 73
Test department needs detailed requirements.
Development can usually use agile ones.
Use
cases
Data
formats
UI
descr.
Program
Tests
Domain
expert
Usage
expert
R D
R D
(Detailed, expensive, long, tedious, brittle use cases)
(Shorter, cheaper, easier to read, more stable (agile) use cases)
(Test department)
R D
[generic process model]
(Development department)
Slide 74
4. Write later and shortcut the process
(usually)
Use cases *can be* written --
just-in-time --or-- all up front
in (usable) increments --or-- each to completion
(more Agile)
(more common)
Req'ts
Design
Validate syntax
Validate req'ts
Code
Validate logic
Use the Validation V view of increments
Slide 75
Project horizon -> all use case briefs or casual
Iteration horizon -> full use case, just-in-time
Full Project
S S
S
E E E E E E
Iteration Iteration Iteration
(all UCs, ultra-light content, estimation purposes)
(just-in-time, complete) (just-in-time, complete) (just-in-time, complete)
(10 use cases) (10 more use cases) (10 more use cases)
Slide 76
Split use cases into user stories for iterations
UC 7: Register for Courses Patterns for Effective Use Cases, Adolph-Bramble)
System: Course Enrollment System Goal level: User Goal

[1] 1. Student requests to construct a schedule.
[1] 2. The system prepares a blank schedule form.
[2] 3. The system gets available courses from the Course Catalog System.
[2] 4. Student selects up to 4 primary and 2 alternate course offerings.
[3,4] 5. For each course, the system verifies that the Student has the
necessary prerequisites, adds the Student to the course, marking Student
as enrolled for that course in the schedule.
[1] 6. The Student indicates the schedule is complete, the system saves it.

Extensions:
[5] 1a. Student already has a schedule: System brings up the current version
of the Students schedule for editing instead of creating a new one.
[6] 1b. Current semester is closed and next semester is not yet open: System
lets Student look at existing schedules, but not create new ones.
[7] 3a. Course Catalog System does not respond: The system notifies the
Student and the use case ends.
[4] 5a. Course full or Student has not fulfilled all prerequisites: System
disables selection of that course and notifies the Student.
(user stories)
Slide 77
user stories subdivide into smaller user
stories ad infinitum to fit iteration length
(At this point user stories is an increasingly
misfitting term, since there is no story about
them, and often no user, but the term has stuck -
until someone coins a better one.)

[2] 4. Student selects up to 4 primary and 2 alternate course offerings.

becomes

[2'] 4. Student selects up to 4 primary and 2 alternate course offerings.
[Allow selection using mouse]

[2''] 4. Student selects up to 4 primary and 2 alternate course offerings.
[Allow selection using keyboard]

Slide 78
Track progress according to completed code
and report using burn-up chart
Estimation of relative size in ideal work-weeks
iterations
accomplishments
expected
done
Burn-up chart
UC steps tests
plus
function
UI
plus
function
UI plus
DB plus
function
7 1,2,6 2 1 1
7 3,4 1 1 1
7 5' 2 1 0
7 5'', 5a 1 0 0
7 1a 1 .5 .5
7 1b .5 .5 0
7 3a .5 .5 0
SUM 8 4.5 2.5 15
Slide 79
Summary of Agile Use Cases

Users goal level - Text - 3-9-step main scenario
No GUI - No data formats - Easy to read -
Record of decisions made (not a tutorial)

Write briefs and casuals to estimate & plan project
Maybe write full use cases just-in-time per iteration

Just-in-time = extension-handling decisions made
before the programmer asks for them.

Spreadsheets good for briefs & planning activities.

Focus on communicating, not filling templates
Slide 80
Agile &
Use Cases
Alistair Cockburn
Humans and Technology

acockburn@aol.com
http://Alistair.Cockburn.us

Agile Use Cases

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Use Cases

Uploaded by

Copyright:

Available Formats

Alistair Cockburn 2005

You might also like