Published on

Published in: Technology, Economy & Finance
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Where’s the PIN
  • Too many scenarios
  • Gherkin format
  • BDD

    1. 1. Executable Requirements<br />Godfrey Nolan<br />RIIS LLC<br />GANG 10 Year Celebration<br />10/1/11<br />
    2. 2. SPAM<br />RIIS LLC - IT Consultants and Developers since ‘98<br />Based in Southfield, MI<br />Skills<br />Requirements, Development, Testing<br />iOS/Android, Java/C#, Oracle/SQL Server<br />Clients<br />Fandango, Federal APD, Comerica, Cengage, Broadsoft, DTE, BondDesk, Proctor Financial, Blue Cross Blue Shield MI, TK, Hanson<br />Godfrey Nolan<br /><br />10 years ago – Unraveling the .Net executable<br />
    3. 3. Agenda<br />
    4. 4. What Makes a Good Requirement?<br />Unique – address one thing only<br />Complete – no missing information<br />Consistent – doesn’t contradict other requirement<br />Traceable back to business need<br />Current – not obsolete<br />Feasible – can be implemented<br />Unambiguous – objective facts not subjective opinions<br />Mandatory – not a nice to have<br />Verifiable – testable<br />
    5. 5. What makes a Bad Requirement?<br />Lengthy<br />Unfocused<br />Ambiguous<br />Verified Manually<br />
    6. 6. Attempts at Writing Good Requirements<br />RIIS History – yours may be different<br />Company Wide Templates<br />Use Cases or User Stories<br />Requirement Reviews<br />Traceability Matrix tools<br />Requirement Metrics tools <br />Visualization/Simulation tools – iRise, Axure, Balsamiq<br />Agile Development – TDD, Scrum, Kanban<br />ALM, CLM tools<br />
    7. 7. Use Case <br />Scope: ATM<br />Level: User Goal<br />1. The card gets inserted.<br />2. The card information gets validated.<br />3. The transaction information gets collected and validated.<br />4. The cash is issued, card returned, cash removed, account debited, screen reset.<br />
    8. 8. Use Cases <br />1. Customer runs ATM card through the card reader.<br />2. ATM reads the bank id and account number.<br />3. ATM asks customer whether to proceed in Spanish/English.<br />4. Customer selects language.<br />5. ATM asks for PIN number and to press Enter.<br />6. Customer enters PIN number, presses Enter.<br />7. ATM presents list of activities for the Customer to perform.<br />8. Customer selects “withdraw cash”.<br />9. ATM asks customer to say how much to withdraw, in multiples of $5, and to press Enter.<br />10. Customer enters an amount, a multiple of $5, presses Enter.<br />11. ATM notifies main banking system of customer account, amount being withdrawn.<br />12. Main banking system accepts the withdrawal, tells ATM new balance.<br />13. ATM delivers the cash.<br />14. ATM asks whether customer would like a receipt.<br />15. Customer replies, yes.<br />16. ATM issues receipt showing new balance.<br />17. ATM logs the transaction.<br />
    9. 9. User Story<br />1. User checks balance<br />2. User logs into the machine<br />3. User get "Fast Cash"<br />4. User makes a deposit<br />5. User withdraws from checking<br />6. User withdraws from savings<br />
    10. 10. Traceability Matrix<br />
    11. 11. Visualization<br />
    12. 12. But inevitably…<br />Some or all the following happen<br />Scope change<br />Requirements confusion, opinions not facts<br />Developer interprets the requirement<br />Business stakeholder doesn’t get what they’re expecting<br />Completelymissed some crucial requirement<br />Requirements never kept up to date<br />
    13. 13. But What if?<br />Imagine a world where developers get detailed requirements in a format and mechanism that is readable by the business facing people...<br />...completely devoid of ambiguity in terms of what the correct behavior is...<br />...and can also be used as an automated test within your team's continuous integration processes. (Tim Wingfield)<br />
    14. 14. But What If? (TechTalk)<br />
    15. 15. But What If?<br />
    16. 16. TDD<br />
    17. 17. Executable Requirements <br />
    18. 18. Executable Requirements<br />These were the Droids you were looking for..<br />BDD or Behavior Driven Design<br />Functional Tests<br />Integration Tests<br />Acceptance Tests<br />ATDD or Acceptance Test Driven Design<br />Specification by Example<br />Outside In Development<br />Executable Requirements<br />
    19. 19.
    20. 20. Outside In Development<br />
    21. 21. Manual Testing Problem (Matt Stine)<br />
    22. 22. Testing Pyramid (Lisa Crispin)<br />
    23. 23. Continuous Integration<br />
    24. 24. Continuous Integration<br />Automated Build Process<br />Code gets checked in<br />Unit tests run<br />Executable Requirements tests run<br />Code gets deployed only if everything passes<br />Requirements are kept up to date!<br />
    25. 25. Writing Executable Requirements<br />Features file <br />Written in DSL called Gherkin<br />Feature description<br />Scenario Outline<br />Given/When/Then<br />Examples (optional)<br />Sample test data<br />Step Definitions<br />Setup<br />Regular Expressions for each Given/When/Then<br />Executable C# test code<br />Tear down<br />
    26. 26. Writing Executable Requirements<br />
    27. 27. Given/When/Then<br />
    28. 28. What is SpecFlow<br />.Nettool to write Executable Requirement in Gherkin format<br />Integrates with Visual Studio 2010<br />File->New templates for creating new feature files<br />Code generation Glue between Feature and Step Definition files<br />Gives VS debugger support<br />Set breakpoints on Given/When/Then lines in your .feature files<br />Integrates with your existing CI infrastructure<br />Also integrates with<br />NUnit<br />Selenium<br />WatiN<br />
    29. 29. Good Executable Requirements<br />Understandable to developer<br />Understandable to business<br />Unambiguous<br />Automated<br />Run frequently<br />
    30. 30. Writing Executable Requirements<br />
    31. 31. Writing Executable Requirements<br />Features file<br />Feature description<br />Scenario Outline<br />Given/When/Then<br />Examples<br />Sample test data<br />
    32. 32. Feature File<br />
    33. 33. Writing Executable Requirements<br />Step Definitions<br />Setup<br />Regular Expressions for each Given/When/Then<br />Executable C# test code<br />Tear down<br />
    34. 34.
    35. 35. SpecFlow Glue<br />
    36. 36. Demo<br />SpecFlow demo<br />
    37. 37. Sample Features files<br />Feature: Account Holder withdraws cash <br />In order to have access to my money <br />As an Account Holder <br />I want to withdraw cash from an ATM <br />Scenario: Card has been disabled <br />Given card is disabled <br />When the account holder requests money <br />Then the ATM should retain the card <br />And the ATM should say the card has been retained <br />
    38. 38. Sample Features files<br />Feature: Serve coffee<br /> In order to earn money<br /> Customers should be able to <br /> buy coffee at all times<br /> Scenario: Buy last coffee<br /> Given there is 1 coffee left in the machine<br /> And I have deposited $1<br /> When I press the coffee button<br /> Then I should be served a coffee<br />
    39. 39. Languages and Tools<br />Languages<br />C# - Specflow, Cuke4Nuke, StorEvil<br />Ruby – Cucumber<br />Java – Cuke4Duke<br />Also Phython, PHP etc.<br />Tools<br />Cucumber<br />Selenium RC<br />Fitnesse<br />
    40. 40. Tear Down<br />Executable Requirements or Coding the right thing<br />Outside In Development<br />Works well in Scrum teams<br />BA does feature file<br />Developer/tester does step definitions <br />Works well with VS10<br />Evolutionary not Revolutionary<br />Might be for you if you’re asking the question?<br />What business requirement does code coverage really provide?<br />
    41. 41. Resources<br />URLs<br /><br /><br /><br /><br />Books<br />