agile requirements by example - amazon s3microsoft powerpoint - agile requirements by example.pptx...

Managing Requirements through User Stories

© Zühlke 2009

11 March 2009

Keith Braithwaite, Richard Emerson, Immo Hüneke

Slide 1

Agile Requirements By Example


© 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


© Zühlke 2009

11 March 2009


Slide 3

Problems with Requirements

credited to Alex Gorbatchev on codinghorror.com


© Zühlke 2009

11 March 2009


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


© Zühlke 2009

Examples, not rules

The education of a programmer is all about rules

• ∀� ∈ Dog

• barks �

A problem:�∃� ∈ Customer ∙ understandsthisstuff �

11 March 2009


Slide 5


© Zühlke 2009

11 March 2009


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:


© Zühlke 2009

11 March 2009


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


© Zühlke 2009

11 March 2009


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.


© Zühlke 2009

11 March 2009


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


© Zühlke 2009

11 March 2009


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


© Zühlke 2009

11 March 2009


Slide 11

Tabular Acceptance Criteria: Example

From http://fit.c2.com/


© Zühlke 2009

11 March 2009


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


© Zühlke 2009


© 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


© Zühlke 2009


© Zühlke 2010

Checked Examples


© Zühlke 2009


© Zühlke 2010

Checked Examples

Examples are:

• relational (mostly)

• give a binary result

many tuples of this shape

green = check OK


© Zühlke 2009


© Zühlke 2010

Gauges

Give a binary result

• quickly

• without human intervention


© Zühlke 2009


© Zühlke 2010

Inside the System

In general, systems do not have a top and a bottom

UI

Web server

Middle tier

DB


© Zühlke 2009


© Zühlke 2010

Inside the System

Domain/Logic

DB

Web Server

Browser


© Zühlke 2009


© Zühlke 2010

Where examples live


© Zühlke 2009

27 January 2008

Keith Braithwaite

Slide 21

Givens


© 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


© Zühlke 2009

27 January 2008

Keith Braithwaite

Slide 23

Test Results


© 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


© 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?


© 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


© Zühlke 2009

27 January 2008

Keith Braithwaite

Slide 27

Why Was That easy?

“Checked Examples” delay abstraction

Concrete is better

Operational Semantics Win?


© 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?


© 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…


© 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

agile requirements by example - amazon s3microsoft powerpoint - agile requirements by example.pptx...

Documents