1. Writing Requirements
Right
HANI MASSOUD
1

2. ©2014HaniMassoud.Allrightsreserved.
Table of Contents
 Behaviour-driven Development (BDD)
 Testable Requirements (the BDD way)
 Benefits
 Investment
2

3. ©2014HaniMassoud.Allrightsreserved.
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

4. ©2014HaniMassoud.Allrightsreserved.
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/

5. ©2014HaniMassoud.Allrightsreserved.
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

6. ©2014HaniMassoud.Allrightsreserved.
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

7. ©2014HaniMassoud.Allrightsreserved.
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

8. ©2014HaniMassoud.Allrightsreserved.
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

9. ©2014HaniMassoud.Allrightsreserved.
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.

10. ©2014HaniMassoud.Allrightsreserved.
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

11. ©2014HaniMassoud.Allrightsreserved.
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

12. ©2014HaniMassoud.Allrightsreserved.
Thank You
 Hani Massoud
 http://au.linkedin.com/in/hanimassoud/
12