Download to read offline
![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](https://image.slidesharecdn.com/agilesoftwarerequirementsmanagement-200709203055/75/Agile-software-requirements-management-with-Impact-Mapping-and-BDD-9-2048.jpg)
![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](https://crownmelresort.com/image.slidesharecdn.com/agilesoftwarerequirementsmanagement-200709203055/75/Agile-software-requirements-management-with-Impact-Mapping-and-BDD-9-2048.jpg)
Uploaded byFred Heath
Agile software requirements management with Impact Mapping and BDD
This document discusses the management of software requirements and the reasons for project failures, particularly emphasizing that mismanagement of requirements is a significant cause. It outlines the importance of eliciting and modeling requirements, creating executable specifications, and utilizing behavior-driven development (BDD) methodologies. Additionally, it highlights key concepts such as requirements, specifications, stakeholders, goals, and capabilities within the software development process.
More Related Content
Similar to Agile software requirements management with Impact Mapping and BDD
Agile software requirements management with Impact Mapping and BDD
- 1. Agile Software Requirements Management SoftwareCrafters, Bucharest, July 2020
- 2.
- 3. This talk isabout 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 softwareprojects fail?
- 5. Requirements mis-management isthe 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 isthe 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 ofagile 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.
- 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.
- 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 vsDomain Goals Non-acting Stakeholders (Business Sponsors) CEO, CTO, Director, etc => Business Goals Actors => Domain Goals
- 16. Domain Goals A goalthat 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 CapabilityFeature Granularity Coarse Fine Type Impact Functionality POV Stakeholder System Association Goal Capability Directly Actionable No Yes
- 21. “ User Storiesare just descriptive devices for Requirements Domain Entities. Nothing more, nothing less.”
- 22.
- 24.
- 25. Behaviour-Driven Development: whatis 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: somerules ● 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 withdrawalfrom 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.
- 32.
- 33. Pattern: CRUD Features- fixed
- 34.
- 35. Pattern: Composite Features- fixed
- 36.
- 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.
- 39.
- 40. BDD Anti-Pattern: Thinkinglike 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: Thinkinglike 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: Incidentalsdetails 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: Aflood 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.