Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 1
Agile Requirements By Example
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010Keith Braithwaite
Slide 2
Keith Braithwaite
Business Unit Leader
• Centre for Agile Practice, Zuhlke Ltd.
Formerly:
• Head of Development, WDS (A-PAC)– First successful globally distributed Agile team
• Senior Software Engineer, Penrillian– Pioneered automated testing on hand-held devices
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 3
Problems with Requirements
credited to Alex Gorbatchev on codinghorror.com
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 4
What are Requirements For?
• One of the most significant causes of project failure in study after study (e.g. Standish Group) has been “the lack of clear requirements”
• Requirements specify what the system should be, how it should behave, what it should look like and criteria such as its availability, reliability, performance and security – but not how to meet these demands
• Every requirement should be matched by one or more acceptance tests that prove compliance
• Theoretically, the system can be demonstrated to be “finished” when it passes every acceptance test
• Writing unambiguous and complete requirements is very hard or impossible
Managing Requirements through User Stories
© Zühlke 2009
Examples, not rules
The education of a programmer is all about rules
• ∀� ∈ Dog
• barks �
A problem:�∃� ∈ Customer ∙ understandsthisstuff �
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 5
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 6
Another Approach - Exemplars
• Human beings instinctively group things into categories based on some representative examples
• Even without explicit recognition rules you can easily categorise the following:
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 7
Search for HotelsSearch for Hotels
As a traveller,
I wish to search for hotels close enough to my destination with vacancies on my dates of travel
so that I can choose the one that best suits my needs
Format for Capturing a User Story
RAG – Role, Action, Goal
Advertise Availability
as
Advertise Availability
As a hotel manager,
I wish to advertise my hotel as prominently as possible
so that I can maximiseoccupancy
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 8
Evaluating the Story Quality
The INVEST test was devised by Bill Wake:
• Independent: can the user story be built without requiring other stories before we can see and test functionality?
• Negotiable: can specific details of the story be resolved through conversation so we can maximize benefit while minimizing development costs?
• Valuable: does the story add value to the software for either or both user and business?
• Estimable: do we know enough about the story to estimate the time to construct the software?
• Small: is the story as small as it can be but still valuable?
• Testable: can others easily verify that the story is complete?
Every story should have a meaningful title, so that you can refer to it in discussions.
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 9
When is a Story Done?
Acceptance Criteria
• A way of judging when a requirement has been met
• Each user story gives rise to several scenarios
• Example: Search for Hotels– Scenario 1: no hotels found– Scenario 2: one hotel found– Scenario 3: one pageful of hotels found– Scenario 4: multiple pagefuls of hotels found– Scenario 5: destination not recognised
• Each scenario must be documented so that a tester can verify that the system handles it correctly
• The acceptance criteria must be written by the time a story is accepted into a sprint for development
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 10
Acceptance Criteria – Checked Examples
Brian Marick defined checked examples as “the use of tests and examples as tools for thinking about a piece of what the product owner wants with results that help the programmers.”
(www.exampler.com)
There are two main forms:
• Table format
• Given / When / Then format
These can be combined.
Advantages of Checked Examples include:
• Intuitively easier to understand (see examples below)
• Acceptance tests can be derived from them directly
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 11
Tabular Acceptance Criteria: Example
From http://fit.c2.com/
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 12
Narrative Acceptance Criteria: Example
Search for Hotels – Scenario 1
• Given– The only hotel in our database within 3km of the centre of
OneHorseTown is The Buckaroo– The hotel has at least one vacant room on 18th April
• When– User searches for hotels with parameters:
– Date of arrival = 18th April– Destination city = OneHorseTown– Acceptable distance = 3km
• Then– Result set has length 1– Result set contains The Buckaroo
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Testing or Checking?
To “check” is to check against a specification
• machines are very good at this
To “test” is to learn and explore
• people are very good at this
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Checked Examples
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Checked Examples
Examples are:
• relational (mostly)
• give a binary result
many tuples of this shape
green = check OK
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Gauges
Give a binary result
• quickly
• without human intervention
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Inside the System
In general, systems do not have a top and a bottom
UI
Web server
Middle tier
DB
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Inside the System
Domain/Logic
DB
Web Server
Browser
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Inside the System
Domain/Logic
DB
Web Server
Browser
Managing Requirements through User Stories
© Zühlke 2009
Automating Checked Examples
© Zühlke 2010
Where examples live
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 21
Givens
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 22
Expected Trades
Users and testers built some expected trades by hand
`
We used FitLibrary
• Finance industry workers familiar with spreadsheets
• Formulae made them self-checking
• The colours relate to different equivalence classes
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 23
Test Results
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 24
What happened?
Several hundred scenarios tested for
Defects in existing systems were revealed
• And were found very early
The presence of the tests before features were implemented encouraged incremental development
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 25
What happened?
Infelicities in the proposed design were revealed
• A design that’s hard to instrument is questionable
If it’s hard to even tell whether or not it works, what are the chances that it doesn’t?
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 26
What happened?
The delivery was defect-free
• That is, no failures were (or have been) reported
• This was a first for the team
• Found themselves at a loose end after the release– It wasn’t broke, so they weren’t fixing it
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 27
Why Was That easy?
“Checked Examples” delay abstraction
Concrete is better
Operational Semantics Win?
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 28
What about correctness?
Is the system as delivered correct?
In the “Dijkstra” sense, probably not
• Certainly the mere passing of tests doesn’t tell us so
But no failures are seen…
• If a latent defect never causes a failure, is it a defect?
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 29
Defect Free?
Developers make errors, so
The system contains defects, so
Users experience failures
If users never experience failures…
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 30
A Messaging System
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 31
Criteria
Given an input containing valid trades
• Do the right messages go to the right place?
• And none other
On invalid input
• No messages leave the institution
• Application Support team is notified
On a failure to process valid input
• No messages leave the institution
• Application Support team is notified
• Trades are re-submitted
Managing Requirements through User Stories
© Zühlke 2009
27 January 2008
Keith Braithwaite
Slide 32
Tests
xxx
xxx
xxxxx
Managing Requirements through User Stories
© Zühlke 2009
11 March 2009
Keith Braithwaite, Richard Emerson, Immo Hüneke
Slide 33
Questions