How to Use Behavior Based Requirements to Build Understanding & Save Your Project Jeffrey Davidson [email protected] @JeffreyGoodReq IIBA MSP Professional Development Day April 15, 2013 

© 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 

© Jeffrey Davidson, 2013 Jeffrey tries Scrum 

© Jeffrey Davidson, 2013 Business Analysts should be . . . !  Masters of Communication 

© Jeffrey Davidson, 2013 Business Analysts should be . . . ! Masters of Communication !  Masters of Value 

© Jeffrey Davidson, 2013 My realization Value comes from understanding 

© Jeffrey Davidson, 2013 My realization There is no difference between requirements and understanding 

© 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 

© 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 

© Jeffrey Davidson, 2013 A (pretend) historical event 

© Jeffrey Davidson, 2013 Business Analysts should be . . . ! Masters of Communication !  Master Storytellers 

© Jeffrey Davidson, 2013 – – context You & Your condition What you do What you see Story Structure event response 

© Jeffrey Davidson, 2013 What are Behavior Based Requirements? !  Fine grained, focused bits of behavior !  Told in a story format 

© Jeffrey Davidson, 2013 – – Given You & Your condition What you do What you see Simple Structure When Then 

© 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 

© Jeffrey Davidson, 2013 Business Terms & Natural Language !  Make it understandable Imagine your grandmother following these directions 

© Jeffrey Davidson, 2013 Generic over Specific !  Generic behavior (no design) Imagine performing the same actions on a telephone interface! 

© Jeffrey Davidson, 2013 Behavior Based Requirements: Let’s practice! !  Given: !  When: !  Then: 

© Jeffrey Davidson, 2013 How did we do? Were you design agnostic? Did you use natural language? Was everything in business terms? 

© 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 

© Jeffrey Davidson, 2013 Behavior Based Requirements: Let’s amplify! !  Given: !  When: !  Then: 

© 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 

© 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 

© 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 

© Jeffrey Davidson, 2013 Who Benefits? !  Everyone! !  Seriously, it helps everyone. •  Business •  Users •  Testers •  Developers •  Analysts 

© 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 

© 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 

© Jeffrey Davidson, 2013 My realization There is no difference between requirements and understanding 

© Jeffrey Davidson, 2013 Business Analysts should be . . . ! Masters of Communication !  Facilitators of Understanding 

© Jeffrey Davidson, 2013 Ferry Boats & Bridges 

© Jeffrey Davidson, 2013 – – Given You & Your condition What you do What you see When Then 

© 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 

© 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 

How to Use Behavior Based Requirements to Build Understanding & Save Your Project Jeffrey Davidson email: [email protected] twitter: @JeffreyGoodReq blog: goodrequirements.com IIBA MSP Professional Development Day 2013 April 15, 2013