Writing Requirements Right
3 likes635 views
The document discusses behavior-driven development (BDD) for writing testable requirements. It describes BDD as specifying desired system behaviors through features, user stories, scenarios, and examples. Features represent high-level goals, stories define specific user needs, scenarios outline examples and edge cases, and concrete examples serve as acceptance tests. If implemented properly, this leads to requirements that improve communication, allow automated testing, and act as living documentation of the system. Some investment is required for training, tools, development time, and ongoing maintenance to realize these benefits.
Writing Requirements Right
- 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 systems 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