2. SPAM RIIS LLC - IT Consultants and Developers since ‘98 Based in Southfield, MI Skills Requirements, Development, Testing iOS/Android, Java/C#, Oracle/SQL Server Clients Fandango, Federal APD, Comerica, Cengage, Broadsoft, DTE, BondDesk, Proctor Financial, Blue Cross Blue Shield MI, TK, Hanson Godfrey Nolan godfrey@riis.com 10 years ago – Unraveling the .Net executable
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? Lengthy Unfocused Ambiguous 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
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)
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
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 Given/When/Then Examples (optional) Sample test data Step Definitions Setup Regular Expressions for each Given/When/Then Executable C# test code Tear down
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 NUnit Selenium WatiN
29. Good Executable Requirements Understandable to developer Understandable to business Unambiguous Automated Run frequently
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 Languages C# - Specflow, Cuke4Nuke, StorEvil Ruby – Cucumber Java – Cuke4Duke Also Phython, PHP etc. Tools Cucumber Selenium RC Fitnesse
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?
