.NET executable requirements


Published on

Talk and Great Lakes .Net User Group 10 yr celebration 10/1/11

Published in: Technology
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 PINhttp://alistair.cockburn.us/Sampler+of+good+and+bad+use+cases
  • Gherkin format
  • http://www.mehdi-khalili.com/executable-requirements
  • .NET executable requirements

    1. 1. EXECUTABLEREQUIREMENTSGodfrey NolanRIIS LLCGANG 10 Year Celebration10/1/11
    2. 2. RIIS• IT Consultants and Developers since ‘98 • Based in Southfield, MI • Contact godfrey@riis.com• Skills • Requirements, Development, Testing • iOS/Android, Java/C#, Oracle/SQL Server• Clients • Fandango, Comerica, Cengage, Broadsoft, DTE, BondDesk, Proctor Financial, Blue Cross, TK, Hanson• Godfrey Nolan • godfrey@riis.com • 10 years ago – Unraveling the .Net executable
    3. 3. Agenda
    4. 4. What Makes a Good Requirement?• Unique – address one thing only• Complete – no missing information• Consistent – doesn’t contradict other req.• Traceable back to business need• Current – not obsolete• Feasible – can be implemented• Unambiguous – objective not subjective• Mandatory – not a nice to have• Verifiable – testable
    5. 5. What makes a Bad Requirement?• Lengthy• Unfocused• Ambiguous• Verified Manually
    6. 6. Attempts at Fixing the Problem• Company Wide Templates• Use Cases or User Stories• Requirement Reviews• Traceability Matrix• Requirements Metrics• Visualization/Simulation – iRise, Axure, Balsamiq• Agile Development – TDD, Scrum, Kanban• ALM, CLM
    7. 7. Use CaseScope: ATMLevel: User Goal1. 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, cashremoved, account debited, screen reset.
    8. 8. User Story1. User checks balance2. User logs into the machine3. User get "Fast Cash"4. User makes a deposit5. User withdraws from checking6. User withdraws from savings
    9. 9. Traceability Matrix
    10. 10. Visualization
    11. 11. But inevitably…• Some or all the following happen • Scope change • Requirements confusion • Developer interprets the requirement • Business stakeholder doesn’t get what they’re expecting • Completely missed some crucial requirement • Requirements never kept up to date
    12. 12. But What if?Imagine a world where developers get detailedrequirements in a format and mechanism that is readableby the business facing people......completely devoid of ambiguity in terms of what thecorrect behavior is......and can also be used as an automated test within yourteams continuous integration processes. (Tim Wingfield)
    13. 13. But What If? (TechTalk)
    14. 14. But What If?
    15. 15. TDD
    16. 16. Executable Requirements
    17. 17. 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
    18. 18. Outside In Development
    19. 19. Manual Testing (Matt Stine)
    20. 20. Testing Pyramid (Lisa Crispin)
    21. 21. Continuous Integration
    22. 22. Continuous Integration• Automated Build Process• Code gets checked in• Unit tests run• Executable tests run• Code gets deployed only if everything passes• Requirements are kept up to date!
    23. 23. Writing Executable Requirements• Features file • Written in DSL called Gherkin • Feature description • Scenario Outline • Given/When/Then • Examples (optional) • Sample test data• Step Definitions • Setup • Tear down • Regular Expressions for each Given/When/Then • Executable C# test code
    24. 24. Writing Executable Requirements
    25. 25. Given/When/Then
    26. 26. What is SpecFlow• .Net tool to write Executable Requirement in Gherkin format• Integrates with Visual Studio • Use File->New templates for creating new feature files • 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 • NUnit • Selenium • WatiN
    27. 27. Good Executable Requirements• Understandable to developer• Understandable to business• Unambiguous• Automated• Run frequently
    28. 28. Writing Executable Requirements
    29. 29. Writing Executable Requirements• Features file • Feature description • Scenario Outline • Given/When/Then • Examples • Sample test data
    30. 30. Feature File
    31. 31. Writing Executable Requirements• Step Definitions • Setup • Tear down • Regular Expressions for each Given/When/Then • Executable C# test code
    32. 32. SpecFlow Glue
    33. 33. Demo• SpecFlow demo
    34. 34. Sample Features filesFeature: Account Holder withdraws cash In order to have access to my money As an Account Holder I want to withdraw cash from an ATMScenario: 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
    35. 35. Sample Features filesFeature: Serve coffee In order to earn money Customers should be able to buy coffee at all times Scenario: Buy last coffee Given there are 1 coffees left in the machine And I have deposited $1 When I press the coffee button Then I should be served a coffee
    36. 36. What Languages are supported• Languages • C# - Specflow, Cuke4Nuke, StorEvil • Ruby – Cucumber • Java – Cuke4Duke • Also Phython, PHP etc.• Tools • Cucumber • Selenium RC • Fitnesse
    37. 37. Tear Down• BDD or Coding the right thing• Outside in Development• Works well in Scrum teams • BA does feature file • Developer/tester does step definitions and C# test files• Works well with VS10
    38. 38. ResourcesURLshttp://www.specflow.orghttp://dannorth.net/whats-in-a-story/http://www.codeproject.com/KB/architecture/BddWithSpecFlow.aspxhttp://cukes.infoBooks