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

1. EXECUTABLE
REQUIREMENTS
Godfrey Nolan
RIIS LLC
GANG 10 Year Celebration
10/1/11

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. Agenda

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. What makes a Bad Requirement?
• Lengthy
• Unfocused
• Ambiguous
• Verified Manually

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. 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. 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

9. Traceability Matrix

10. Visualization

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. 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)

13. But What If? (TechTalk)

14. But What If?

15. TDD

16. Executable Requirements

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

19. Outside In Development

20. Manual Testing (Matt Stine)

21. Testing Pyramid (Lisa Crispin)

22. Continuous Integration

23. 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!

24. 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

25. Writing Executable Requirements

26. Given/When/Then

27. 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

28. Good Executable Requirements
• Understandable to developer
• Understandable to business
• Unambiguous
• Automated
• Run frequently

29. Writing Executable Requirements

30. Writing Executable Requirements
• Features file
• Feature description
• Scenario Outline
• Given/When/Then
• Examples
• Sample test data

31. Feature File

32. Writing Executable Requirements
• Step Definitions
• Setup
• Tear down
• Regular Expressions for each Given/When/Then
• Executable C# test code

34. SpecFlow Glue

35. Demo
• SpecFlow demo

36. 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

37. 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 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

38. What Languages are supported
• Languages
• C# - Specflow, Cuke4Nuke, StorEvil
• Ruby – Cucumber
• Java – Cuke4Duke
• Also Phython, PHP etc.
• Tools
• Cucumber
• Selenium RC
• Fitnesse

39. 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

40. Resources
URLs
http://www.specflow.org
http://dannorth.net/whats-in-a-story/
http://www.codeproject.com/KB/architecture/BddWithSpecFlow.aspx
http://cukes.info
Books