In this talk, Fred Heath will explain how to capture and model Requirements and translate them to Executable Specifications, using a combination of Behaviour-Driven Development, some established techniques like Impact Mapping and some new ones such as Business Process Alignment and the D3 method. It will also illustrate how to correctly create Features and will outline an algorithmic approach for creating code that realizes the client's requirements.

1. Agile Software
Requirements Management
Software Crafters, Bucharest, July 2020

2. Fred Heath
http://bootstrap.me.uk
https://dev.to/redfred7

3. This talk is about
Goals
1. Eliciting and modeling requirements
2. Creating executable specifications from
requirements
Topics
● Requirements Domain
● Impact Mapping
● Behavior Driven Development
● D3, structured conversation, Business
Process mapping

4. Why do software projects fail?

5. Requirements mis-management is the biggest
cause of project failure
● https://www.wrike.com/blog/complete-collection-project-management-
statistics-2015/
● https://www.askspoke.com/blog/it/reasons-for-it-project-failure/
● https://www.researchgate.net/publication/288260664_Understanding_the_sou
rces_of_information_systems_project_failure_see_BCS_wwwbcsorgcontentC
onWebDoc19584

6. Requirements mis-management is the biggest
cause of project failure
1. The requirements were inaccurate or unclear
2. The requirements were not translated into specifications
3. The project goals did not align with business goals
4. Requirements or requirement priorities changed without the project changing
accordingly

7. Requirements vs Specifications
Requirement = the expression of a need, wish
desire or expectation
Specification = a description of the system
behaviour required in order to fulfill or realise a
requirement
“Failing to write a spec is the single biggest
unnecessary risk you take in a software project.
It’s as stupid as setting off to cross the Mojave
desert with just the clothes on your back, hoping
to ‘wing it’.”
Joel on Software

8. What’s a Requirement?
● A formal statement ("The system shall provide a document searching facility")
● Unstructured statement (“Admin can bulk upload CSVs into their company’s account,
or add individual users into the account.“.
● A business rule (" accounts with monthly deposits larger than $1000 receive a 10%
discount")
● An example ("Joe didn't have to pay for his coffee because it was his 11th coffee in
that store")
● A Business Process
● A screen mockup or wireframe
● A Flow-chart, activity chart, or some other type of diagram

9. The fog of agile software development
What’s a User Story?
A requirement, a feature, a description, an end-
goal, a high-level abstraction, a small piece of
business value..??
What’s a Feature?
Epic?
Requirement?
[many conflicting opinions]
https://dev.to/redfred7/enough-with-the-user-stories-already-2a8a

10. Requirements Domain entities

11. The Requirements Domain
Entities:
● Stakeholder: affect or benefit from with our system
● Goal: something of benefit to a Stakeholder
● Capability: impact of the Stakeholder to our system
● Feature: functionality needed to deliver Capability

12. Impact Map

14. Requirements Domain: Stakeholders
Stakeholder: someone/something
that derives value, benefits from or
influences our system
Actor: A Stakeholder who interacts
with the system, either directly or
indirectly

15. Business Goals vs Domain Goals
Non-acting Stakeholders (Business
Sponsors) CEO, CTO, Director, etc =>
Business Goals
Actors =>
Domain Goals

16. Domain Goals
A goal that adds value to an Actor.
Domain Goals are usually defined by Actors
Good Domain Goals add value to Stakeholders
by specifying goals tangential or extrinsic to the
system's intended abilities and functionality.
Example 1: Sell my stuff
Example 2: Make money
Example 3: Get rid of things I don’t need

17. Requirements Domain: Capabilities
● A system ability that directly helps a Stakeholder achieve a Goal
● Capabilities define how the stakeholder impacts the system
● Our job as System Builders is to deliver capabilities

18. Requirements Domain: Features
● A system functionality that helps deliver a Capability
● Features define what the system will do to support Capabilities
● Our job as System Builders is to deliver capabilities

19. Capabilities vs Features
Capability Feature
Granularity Coarse Fine
Type Impact Functionality
POV Stakeholder System
Association Goal Capability
Directly Actionable No Yes

21. “ User Stories are just descriptive devices for
Requirements Domain Entities. Nothing more,
nothing less.”

22. User Story Hell

24. Behavior Driven Development

25. Behaviour-Driven Development: what is it?
● BDD is an outside-in development methodology
● It’s about collaboration and communication
● Cucumber, JBehave, SpecFlow, etc. are BDD tools
● It is NOT. ABOUT. TESTING !!!

26. Behaviour-Driven Development: Features
● Features outline behaviour
● Features are the Specification
● Features are living documentation
● Features drive the development
Feature: User Authentication
As a Head of School
I want to log into the system
So I can see attendance records
Scenario: successful authentication
Given I am at the login page
When I enter my credentials
Then I see a welcome message

27. Behaviour-Driven Development: some rules
● Features use Domain language
● Features must be readable by all
stakeholders
● Features do not contain technical
information
● Features described in Gherkin DSL
(natural language subset)
Feature: User Authentication
Rule: passwords must be over 8 characters
Scenario: successful authentication
Given I go to the login page
When I enter my credentials
Then I see a welcome message

28. Behaviour-Driven Development: Scenarios
● Scenarios are just context switching
● Scenarios are atomic
● Not many scenarios needed. Often just
‘happy day’ + a couple of
error/alternative contexts. 80/20 rule
● NEVER go for 100% coverage. BDD
isn’t about testing !

29. Executable Specifications
STEPS
Scenario: Successful
withdrawal from an account in
credit
Given I have $100 in my account
When I request $20
Then $20 should be dispensed
And my account balance is $80
STEP DEFINITIONS
Given /I have $100 in my
Account/ do
my_account.clear &&
my_account.deposit(100)
And /my account balance
is $80/ do
assert(my_account.balance
== 80)

31. BDD Patterns

32. Pattern: CRUD Features

33. Pattern: CRUD Features - fixed

34. Pattern: Composite Features

35. Pattern: Composite Features - fixed

36. Pattern: Feature Interpolation

37. Pattern: Feature Interpolation
Background:
#--> existing step
Given the user is logged in as a Writer
#--> new step below:
And the Writer is using a:
| device |
| MacBook |
| Windows laptop |
| iPhone |
| Android phone |
| Android tablet |
| iPad |

38. Pattern: Feature Interpolation - fixed

39. BDD Anti-Patterns

40. BDD Anti-Pattern: Thinking like developers
Scenario: simple search
Given I am a Reviewer
When I go to ‘http://ierd.com/search’
And I click on the Search button
And I see a search text box
And I enter ‘morrison + assessment’
Then I’m redirected to the results page
And I see a link to the ‘IB assessment practices.doc’ by J.Morrison

41. BDD Anti-Pattern: Thinking like developers -fixed
Scenario: simple search
Given I am a Reviewer
When I go to the search page
And I search for ‘morrison’ and ‘assessment’
Then I can see ‘IB assessment practices.doc’ by J.Morrison

42. BDD Anti-Pattern: Incidentals details
Scenario: successful login
Given I am an Event Coordinator
When I go to the login page
And I enter ‘Fred’ as the username
And I enter ‘qwerty’ as the password
Then I see a message:
“””
Welcome to the app, Fred. Have fun
“””

43. BDD Anti-Pattern: Incidentals - fixed
Scenario: successful login
Given I am an Event Coordinator
When I go to the login page
And I enter a valid username and password
Then I see a welcome message

44. BDD Anti-Pattern: A flood of Scenarios
More than 10 Scenarios per Feature indicate a problem
Cause #1: BDD isn’t testing, don’t go for 100% coverage!
Cause #2: It’s a CRUD or Composite Feature
Cause #3: It’s a Capability

47. Code: 20AGILEWAY