Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply



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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

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