How to Use Behavior Based Requirements to Build Understanding and Save Your Project

77d585b881102ee229be5d5af4a11b8b?s=47 Jeffrey
April 15, 2013

How to Use Behavior Based Requirements to Build Understanding and Save Your Project

There is confusion on your projects and you struggle to get people to understand what needs to be built and why. It doesn’t have to be this way--you can build a common understanding with your team and your stakeholders using Behavior Based Requirements.

Using this new technique, you will capture more from your partners and stakeholders. You will find developers understanding more. You will build a common understanding from user to tester. Oh, and you will save your project.

77d585b881102ee229be5d5af4a11b8b?s=128

Jeffrey

April 15, 2013
Tweet

Transcript

  1. 1.

    How to Use Behavior Based Requirements to Build Understanding &

    Save Your Project Jeffrey Davidson jeffrey@davidson.net @JeffreyGoodReq IIBA MSP Professional Development Day April 15, 2013
  2. 2.

    © Jeffrey Davidson, 2013 It’s not easy !  We can

    only hope to make reliable those things that we can understand. !  We can only consider a few things at a time. !  Intertwined things must be considered together. !  Complexity undermines understanding. Rich Hickey in Simple Made Easy @ StrangeLoop 2011
  3. 5.

    © Jeffrey Davidson, 2013 Business Analysts should be . .

    . ! Masters of Communication !  Masters of Value
  4. 7.
  5. 8.

    © Jeffrey Davidson, 2013 My principles of good business analysis

    !  We build better software when we understand the goals of what we are building !  We are working on difficult concepts and need to use every tool possible to increase our understanding !  We want a common understanding for everyone involved; from user to stakeholder to analyst to developer to tester to user
  6. 9.

    © Jeffrey Davidson, 2013 Corollaries to the principles !  We

    build a common understanding best when we communicate using natural language and business terms !  Functional requirements are best understood in context with actors, actions, and results !  These things are called Stories
  7. 11.

    © Jeffrey Davidson, 2013 Business Analysts should be . .

    . ! Masters of Communication !  Master Storytellers
  8. 12.

    © Jeffrey Davidson, 2013 – – context You & Your

    condition What you do What you see Story Structure event response
  9. 13.

    © Jeffrey Davidson, 2013 What are Behavior Based Requirements? !

     Fine grained, focused bits of behavior !  Told in a story format
  10. 14.

    © Jeffrey Davidson, 2013 – – Given You & Your

    condition What you do What you see Simple Structure When Then
  11. 15.

    © Jeffrey Davidson, 2013 What is it? !  It’s a

    bunch of tiny stories, using a particular grammatical structure !  It’s finding places of misunderstanding, and filling it with understanding !  It’s a conversation, captured
  12. 16.

    © Jeffrey Davidson, 2013 Business Terms & Natural Language !

     Make it understandable Imagine your grandmother following these directions
  13. 17.

    © Jeffrey Davidson, 2013 Generic over Specific !  Generic behavior

    (no design) Imagine performing the same actions on a telephone interface!
  14. 19.

    © Jeffrey Davidson, 2013 How did we do? Were you

    design agnostic? Did you use natural language? Was everything in business terms?
  15. 20.

    © Jeffrey Davidson, 2013 Examples versus Requirements Examples . .

    . !  . . . amplify what we know !  . . . point out holes in our understanding !  . . . are easy to test !  . . . take requirements and make them real
  16. 22.

    © Jeffrey Davidson, 2013 Benefits To build the right product

    effectively, software dev practices need: !  Assurance all stakeholders & delivery team members understand what needs to be delivered in the same way Gojko Adzic in Specification by Example, 2011
  17. 23.

    © Jeffrey Davidson, 2013 Benefits To build the right product

    effectively, software dev practices need: !  Precise specifications so delivery teams avoid wasteful rework caused by ambiguities and functional gaps Gojko Adzic in Specification by Example, 2011
  18. 24.

    © Jeffrey Davidson, 2013 Benefits To build the right product

    effectively, software dev practices need: !  An objective means to measure when a piece of work is complete Gojko Adzic in Specification by Example, 2011
  19. 25.

    © Jeffrey Davidson, 2013 Who Benefits? !  Everyone! !  Seriously,

    it helps everyone. •  Business •  Users •  Testers •  Developers •  Analysts
  20. 26.

    © Jeffrey Davidson, 2013 It’s not about tools “These tools

    are intended for use by programmers to guide coding, but they can also be used to express business facing tests that drive development, involving customers more closely in the process.” Lisa Crispin in Agile Testing, 2009
  21. 27.

    © Jeffrey Davidson, 2013 Downsides !  May not help velocity

    !  New-ish (to lots of BAs) !  Tools (and all that jazz) may cause clutter, slow-down, new learning, other stuff
  22. 28.
  23. 29.

    © Jeffrey Davidson, 2013 Business Analysts should be . .

    . ! Masters of Communication !  Facilitators of Understanding
  24. 31.

    © Jeffrey Davidson, 2013 – – Given You & Your

    condition What you do What you see When Then
  25. 32.

    © Jeffrey Davidson, 2013 My Primary Sources !   Gojko

    Adzic BDD / Specification by Example gojko.net !   Martin Fowler Crevasse of Doom (ferry boats & bridges) martinfowler.com !   Liz Keogh BDD lunivore.com !   Chris Matts Invented: Feature Injection theitriskmanager.wordpress.com !   Dan North Crevasse of Doom & Invented: BDD dannorth.net
  26. 33.

    © Jeffrey Davidson, 2013 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
  27. 34.

    How to Use Behavior Based Requirements to Build Understanding &

    Save Your Project Jeffrey Davidson email: jeffrey@davidson.net twitter: @JeffreyGoodReq blog: goodrequirements.com IIBA MSP Professional Development Day 2013 April 15, 2013