O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Writing Requirements Right

548 visualizações

Publicada em

  • Seja o primeiro a comentar

Writing Requirements Right

  1. 1. Writing Requirements Right HANI MASSOUD 1
  2. 2. ©2014HaniMassoud.Allrightsreserved. Table of Contents  Behaviour-driven Development (BDD)  Testable Requirements (the BDD way)  Benefits  Investment 2
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. ©2014HaniMassoud.Allrightsreserved. Thank You  Hani Massoud  http://au.linkedin.com/in/hanimassoud/ 12