Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How Tiny Examples Will Save Our Broken Requirements

77d585b881102ee229be5d5af4a11b8b?s=47 Jeffrey
March 03, 2014

How Tiny Examples Will Save Our Broken Requirements

Presented at Business Analyst World, Atlanta.

From the promotion materials:
There is a special place where the hidden treasure of great requirements are found. It’s not that what we have today is bad, but it’s time to move beyond writing stodgy requirements no one else is willing to read. Diagrams are great for communicating, but most of the time you need more than just pictures. And user stories a really good step forward, but many of us find they are still missing something. The secret may lie in Behavior Driven Development (BDD). The fabulous thing, besides the cool name, is this is easy to learn, easy to use, and produces better stories, requirements, tests, and code! This presentation is for analysts who already know how to write requirements, but want to move to something more productive. This is an introduction to a new technique, using natural language to describe both the value and features of a system and each interaction. Come learn about writing requirements and acceptance criteria in business language (for your customers) that are clear and complete (for your developers) and super-duper easy to double-check (for the testers)!

77d585b881102ee229be5d5af4a11b8b?s=128

Jeffrey

March 03, 2014
Tweet

Transcript

  1. BEHAVIOR DRIVEN DEVELOPMENT & TINY EXAMPLES Business Analyst World Atlanta,

    GA March 3-4, 2014
  2. @JeffreyGoodReq #BDD at #BAWATL

  3. None
  4. We can only consider a few things at a time.

  5. 7 ± 2

  6. 4 – 5

  7. Intertwined things must be considered together

  8. None
  9. Complexity undermines understanding

  10. None
  11. What is a good requirement?

  12. §  Valuable §  Concise §  Design-free §  Attainable §  Complete

    §  Consistent §  Unambiguous §  Verifiable §  Atomic §  Understandable
  13. Have we helped the situation? NO

  14. HOW TINY EXAMPLES WILL SAVE OUR BROKEN REQUIREMENTS

  15. Clear, unambiguous definition of done

  16. Value comes from understanding

  17. Common understanding Stakeholder Analyst & UX Developer Tester User

  18. Functional requirements are best understood . . . in context

    with actors, actions, and results
  19. Functional requirements are best understood . . . as Examples

  20. None
  21. You & your condition Context What you do What you

    see Event Response
  22. You & your condition What you do What you see

  23. You & your condition What you do What you see

  24. Context Event Response

  25. None
  26. Pick a role §  Princess or Knight §  Olympic Athlete

    §  Singer §  Scientist
  27. Pick a sidekick §  Cousin §  Pet §  Stuffed animal

    §  Talking bird
  28. Pick an activity §  Walking §  Flying §  Having a

    picnic §  Shopping
  29. Pick a place §  In the forest §  By the

    ocean §  On the roof §  In town
  30. Pick 2 events §  You hear a loud roar § 

    Your sidekick chases a bird §  A furry monster walks up §  A horse asks for your help §  You shrink to 4” high
  31. Pick a response §  Say “Not again!” §  Pull a

    biscuit out of your pocket §  Laugh §  Fall into a puddle
  32. Once upon a time _________ and ________ were ________ in

    ________. As they were ________ they ________ and ________. Then you ________. role sidekick respond event activity event activity location
  33. Context Event Response

  34. Context Event Response

  35. Context Event Response When Given Then

  36. Given is Personable

  37. When is Actionable

  38. Then is Visible

  39. Behavior

  40. Conversation

  41. Misunderstanding Misunderstanding

  42. “Hi, Grandma”

  43. Design free

  44. None
  45. Bahamas Balloons §  Travel City Pair (Origin – Destination, OND)

    §  Date §  Seats §  Name & credit card
  46. Given: I want to fly to the Bahamas When: I

    select my travel city pair Then: I see the dates available
  47. Given: I see the available travel dates When: I choose

    my travel date Then: I see how many seats are available
  48. Examples …

  49. Examples … amplify what we know

  50. Examples … point out holes

  51. Examples … are provable

  52. None
  53. Given: I have chosen a travel itinerary When: I submit

    my name and payment information Then: I see a confirmation #
  54. Travel itinerary Origin Dest Pass Date Name Atlanta Bahamas 1

    Mar 15, 2014 Kupe Submit Itinerary Payment confirmation Valid Good Display “Congratulations, you are ready for your trip! Your confirmation numbers are NNNNNN” Conf# 000001 Then When Given
  55. None
  56. Bahamas Balloons §  Multiple travelers §  Invalid itinerary §  Missing

    payment info §  Confirmation failure
  57. Given: I have chosen a travel itinerary When: I submit

    my name and payment information Then: I see a confirmation #
  58. Origin Dest Pass Date Name Atlanta Bahamas 1 Mar 15,

    2014 Kupe Atlanta Bahamas 4 Mar 15, 2014 Mary Bahamas Atlanta 5 Mar 18, 2014 Kent Itinerary Payment confirmation Valid Good Valid Good Valid Failure Message Conf# Confirmation 000001 Confirmation 000002, 000003, 000004, 000005 “Please call” Then When Given
  59. What’s happening?

  60. How’d we get here?

  61. Understanding

  62. Please try:

  63. Business terms & Natural language

  64. Happy path first

  65. Please avoid:

  66. Too many examples

  67. Too many “ands”

  68. Describing how

  69. Jargon

  70. THERE IS NO DIFFERENCE BETWEEN REQUIREMENTS AND UNDERSTANDING

  71. None
  72. When Given Then

  73. Gojko Adzic Specification by Example gojko.net Rich Hickey It’s Not

    Easy Simple Made Easy presented @ StrangeLoop 2001 Liz Keogh BDD lunivore.com Dan North BDD & Crevasse of Doom w/ M. Fowler dannorth.net
  74. This is licensed under CC BY 3.0; Creative Commons Sharealike

    Please use it Please share it Please improve it As long as you credit me somewhere
  75. Appendix

  76. Try: Capturing behavior using a conversation. Make it easy to

    understand by telling a story using business terms in natural language. Avoid: §  Too many examples §  Too many “ands” §  Describing how §  Skipping examples §  Jargon §  Not readable Tiny Examples / #BDD Jeffrey Davidson BA World | Atlanta 2014 goodrequirements.com Tips: §  Input, Action, Output §  Use real data §  Use tables to format examples §  Give multiple cases when Input or Output varies §  Mockups can also be an example §  Give examples for ALL stories §  Reuse your examples / data §  Use automation tools to make examples live §  Do it collaboratively Context – Event – Response §  Given is personable §  When is actionable §  Then is visible
  77. THANK YOU For questions or suggestions: Jeffrey Davidson Consulting Business

    Analyst goodrequirements.com @JeffreyGoodReq jeffrey@davidson.net