Writing Requirements

RightHANI MASSOUD

1

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Table of Contents

Behaviour-driven Development (BDD)

Testable Requirements (the BDD way)

Benefits

Investment

2

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Behaviour-driven Development

“Behaviour” is a more useful word than “test”Dan North, father of Behaviour-driven Development

http://dannorth.net/introducing-bdd/

Behaviour-driven Development (BDD) emerged from insights gained

during Test Driven Development.

This presentation explains a BDD approach to writing requirements that

specify the desired system behaviour.

3

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Testable Requirements

Describe system behaviour within a business context

Define Business Context

Why does the business want this system?

Who are the users and stakeholders of the system?

What business process will the system support?

What features should the system have?

Describe System Behaviour

Feature User Story Scenarios Examples

The examples are the Acceptance Tests for the system

4

Testable requirements are

the responsibility of the

Business Analyst with the

support of the Business Users,

Developers and Testers.

Recommended Reading:

• Specification by Example, Gojko Adzic,

Manning, 2011

• Lean-Agile Acceptance Test Driven

Development, Ken Pugh, Addison

Wesley, 2011

• http://dannorth.net/introducing-bdd/

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Testable Requirements

5

Feature Description 1st Release /

Iteration

Product

Catalogue

In order to make sales

As a Sales & Marketing Director

I want Visitors to be able to view products

online

1 / 1

Shopping

Cart

In order to make sales

As a Sales & Marketing Director

I want Shoppers to be able to manage Products

in their Shopping Cart

1 / 1

Daily Deals In order to make sales

As a Sales & Marketing Director

I want Subscribers to receive Daily Deals

1 / 2

Online

Payments

In order to make sales

As a Sales & Marketing Director

I want Shoppers to be able to make online

payments for their Products

1 / 3

Etc…

Features

Feature Name: <put name of feature >In order to <achieve some goal >As a <put title of stakeholder for this goal >I want <to do or enable something>.

We identify features by thinking from

the point-of-view of the stakeholders

(rather than the users).

What features do you want to buy?

Identify Features for Stakeholders

Feature Description Template

Features Stories Scenarios Examples

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Testable Requirements

6

User Stories

Title: <descriptive name of story>

Narrative:In order to <attain benefit>As a <user role>I want to <do something>.

We identify stories by thinking from

the point-of-view of the users (rather

than the stakeholders).

How will you use the system?

Identify Stories for Users

User Story Template

Note: Typically, the title describes the <do something>

part of the narrative.

Feature Story Title Story Narrative Release /

Iteration

Product

Catalogue

View Products

by Category

In order to find Products of

interest to me

As a Visitor

I want to browse Products

by Category.

1 / 1

Product

Catalogue

Add Products

to my Cart

In order to buy Products

As a signed in Shopper

I want to add Products to

my Cart.

1 / 1

Etc…

Features Stories Scenarios Examples

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Testable Requirements

7

Scenarios

Title: <descriptive name of scenario>

Description:Given <some initial context>When <an event occurs>Then <expect some outcomes>.

Scenarios are variations on a Story. Think of

the possible dimensions that affect a Story

(e.g. normal scenarios, negative scenarios,

special cases, different products, different

user role, etc.)

Identify Scenarios for each Story

Scenario Template

Source: http://dannorth.net/introducing-bdd/

Story Scenario Story Narrative Release /

Iteration

View Products

by Category

Visitor views

Products by

Category

Given a Catalogue with

multiple Categories

When the Visitor selects a Category

Then the system should display the

Products for the selected Category

1 / 1

View Products

by Category

Visitor views an

Empty

Category

Given a Category with no Products

When the Visitor selects the empty

Category

Then the system should display a

friendly message to ask the user to

select a different Category.

1 / 1

Etc…

Features Stories Scenarios Examples

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Testable Requirements

8

Examples

Typically, Examples take the form of data tables that describe the initial state (Given), the event (When) and the expected outcome (Then) for each Scenario.

Comprehensively illustrate each Scenario

with worked examples.

Examples help improve communication

between business users, developers and

testers. Examples are also the User

Acceptance Tests for each Scenario.

Comprehensive Examples by Scenario

Examples Template

Recommended Reference: Specification by Example,

Gojko Adzic, Manning, 2011

User Role User Name User Email Status

Visitor Bill Cosby bill@nosuchemail.com Not signed in

Shopper Fred Astaire fred@nosuchemail.com Signed in

Etc…

Categories Products

Shoes Glitter Strap, Flat Trendy, Snake Eyes

Dresses Sundowner, Dark Lightning

Hats Top Hat

Tops

User Action Description Selected Category

Bill Cosby (Visitor) Select a Category to browse in

the Product Catalogue

Dresses

Products

Sundowner, Dark Lightning

Given the following Users in the System

And the following Categories and Products

When the User performs the following action

Then the system should display the Products from the selected Category

Features Stories Scenarios Examples

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Testable Requirements

9

Features Stories Scenarios Examples

Living Documentation

Examples are functional

specifications and automated

acceptance tests at the same time.

They can be executed against the

system and will be Green if the test

passes or Red if the test fails. Unlike

traditional functional specifications

(which are typically incomplete and

out-of-date before the system goes

live) these are “Living” specifications

that show what the system does.

Investment in these documents is an

investment in smart documentation.

Testable Requirements are

“Living” documentation

Functional Specification is

executable. So we can run it to see if

the System behaves as specified.

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Benefits

Testable Requirements (Specifications)

Improve communication between business users, developers and testers

Are Automated by Developers and become Acceptance Tests of the system

System must pass all tests BEFORE start of UAT

UAT can reuse automated tests and add manual exploratory testing

Automated tests are necessary for DevOps

Are reusable for Regression Testing

Are “living documentation” of the system’s capabilities

10

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Investment

Behaviour-driven Requirements (Specifications)

Training – Behaviour-driven Development training, Developer tools training, etc.

Tools – Selenium WebDriver, Jasmine, Protractor, etc. (most are free, open

source projects but commercial products are needed for Mainframe, Cobol

and other legacy applications, managing test data stores, etc.)

Development - Additional development time and effort to build automated

tests

Maintenance – Automated Specifications are code and require maintenance

along with other parts of the application.

11

© 2

01

4 H

an

i Ma

ssou

d. A

ll righ

ts rese

rve

d.

Thank You

Hani Massoud

http://au.linkedin.com/in/hanimassoud/

12