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

How to Improve Your Requirements with Tiny Stories

77d585b881102ee229be5d5af4a11b8b?s=47 Jeffrey
April 07, 2014

How to Improve Your Requirements with Tiny Stories

Presented at Project Summit * Business Analyst World in Philadelphia

Stop writing boring requirements! No matter how much you love them, they often get in the way of communicating. The secret to good communication isn't is writing more, it's in doing it differently. Instead of stale requirements you should tell tiny stories! During this presentation we will talk about writing requirements with little stories, sometimes known as Behavior Driven Development / BDD, Specification by Example, or Given-When-Then. (In the IIBA Agile Extension to the BABOK, it's called Get Real Using Examples.) The key isn't the many different names, it's about structuring your requirements based upon behavior and using this to ensure everyone from user - to - developer - to - stakeholder understands the functionality and goals. Come and learn about Tiny Stories and how they will help you keep your project on track.

Learning Objectives
1. Practice building requirements using the Given-When-Then structure.
2. Understand why it is important to use natural language & business terms.
3. Learn why scenarios add huge power to requirements and enable living requirement documentation.

77d585b881102ee229be5d5af4a11b8b?s=128

Jeffrey

April 07, 2014
Tweet

Transcript

  1. How to Improve Your Requirements with Tiny Stories

  2. Jeffrey Davidson twitter: @JeffreyGoodReq blog: goodrequirements.com email: jeffrey@davidson.net

  3. None
  4. None
  5. Pick a role §  Princess §  Fireman §  Singer § 

    Scientist
  6. Pick a sidekick §  Cousin §  Pet §  Stuffed animal

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

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

    ocean §  On the roof §  In town
  9. 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
  10. Pick a response §  Say “Not again!” §  Pull a

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

    ________. As you were ________ they ________ and ________. Then you ________. role sidekick respond event activity event activity location
  12. None
  13. We can only consider a few things at a time.

  14. 7 ± 2

  15. 4 – 5

  16. Intertwined things must be considered together

  17. None
  18. Complexity undermines understanding

  19. None
  20. What is a good requirement?

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

    §  Consistent §  Unambiguous §  Verifiable §  Atomic §  Understandable
  22. Clear, unambiguous definition of done

  23. Value comes from understanding . . .

  24. Value comes from understanding

  25. There is no difference between requirements and understanding

  26. Common understanding Stakeholder Analyst & UX Developer Tester User

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

    with actors, actions, and results
  28. Functional requirements are best understood . . . as Stories

  29. How Tiny Stories will save our broken Requirements

  30. D A D D Y !

  31. You & your condition Context What you do What you

    see Event Response When Given Then
  32. Given is Personable

  33. When is Actionable

  34. Then is Visible

  35. Behavior

  36. Conversation

  37. Misunderstanding Misunderstanding

  38. “Hi, Grandma”

  39. Design free

  40. None
  41. §  Origin & Destination §  Date §  Seats §  Name

    & credit card
  42. §  Given: §  When: §  Then: §  Given: I want

    to fly to the Bahamas §  When: I select my travel city pair §  Then: I see the dates available
  43. §  Given: I see the available travel dates §  When:

    I choose my travel date §  Then: I see how many seats are available
  44. Examples …

  45. Examples … are provable

  46. Examples … amplify what we know

  47. Examples … point out holes

  48. None
  49. Given: I have chosen a travel itinerary When: I submit

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

    Apr 15, 2014 Lynn Submit Itinerary Payment confirmation Valid Good Display “Congratulations, Lynn. You are ready for your trip! Your confirmation numbers are NNNNNN” Conf# 000001 Then When Given
  51. None
  52. §  Multiple travelers §  Invalid itinerary §  Missing payment info

    §  Confirmation failure
  53. Given: I have chosen a travel itinerary When: I submit

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

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

  56. How’d we get here?

  57. Understanding

  58. There is no difference between requirements and understanding

  59. – – Given You & Your condition What you do

    What you see When Then
  60. My Primary Sources "   Gojko Adzic BDD / Specification

    by Example gojko.net "   Liz Keogh BDD lunivore.com "   Dan North BDD & Crevasse of Doom dannorth.net
  61. Share & Tell This is licensed under Creative Commons Sharealike

    [CC BY 3.0] "  Please use it "  Please share it "  Please improve it "  As long as you credit me somewhere
  62. How to Improve Your Requirements with Tiny Stories ® Jeffrey

    Davidson twitter: @JeffreyGoodReq blog: goodrequirements.com email: jeffrey@davidson.net ProjectSummit * BusinessAnalystWorld | Philadelphia, PA | April 7, 2014