Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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


  • 1. Executable Requirements
    Godfrey Nolan
    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