The Rules of Requirements - April 2012
•Download as PPTX, PDF•
6 likes•637 views
Presentation delivered to the Austin, TX IIBA chapter on 20 Apr 2012. Thanks again to everyone who attended, engaged, and provided great feedback and contributed to the discussion!
Recommended
Recommended
More Related Content
What's hot
What's hot (12)
Viewers also liked
Viewers also liked (10)
Similar to The Rules of Requirements - April 2012
Similar to The Rules of Requirements - April 2012 (20)
Recently uploaded
Recently uploaded (20)
The Rules of Requirements - April 2012
- 1. Austin IIBA 20 April, 2012 The Rules of Requirements International Institute of Business Analysis
- 2. Scott Sehlhorst Product management & strategy consultant 8 Years electromechanical design engineering (1990-1997) IBM, Texas Instruments, Eaton 8 Years software development & requirements (1997-2005) > 20 clients in Telecom, Computer HW, Heavy Eq., Consumer Durables 7 Years product management consulting (2005-????) >20 clients in B2B, B2C, B2B2C, ecommerce, global, mobile Agile since 2001 Started Tyner Blain in 2005 Helping companies Build the right thing, right 2
- 3. Why Do We Care… …About Writing Good Requirements?
- 4. Track Record (Standish Group CHAOS Report) 4
- 5. Root Cause Analysis Failure reasons Success factors What have you seen? What have you seen? 5
- 6. Root Cause Analysis Failure reasons Success factors Lack of user input User involvement Incomplete requirements Exec support Changing requirements Clear requirements Lack of exec support Proper planning Tech. incompetence Realistic expectations 6
- 7. Rules of Requirements 1. Valuable 7. Unambiguous 2. Concise 8. Verifiable 3. Design Free 9. Atomic 4. Attainable 10. Passionate 5. Complete 11. Correct 6. Consistent 12. Stylish
- 10. 3. Design-Free Requirements This is really about trust. The “stack” of problem decomposition alternates between requirements and design. A business is designed to focus on solving particular problems. A user designs an approach to solving problems. A product manager designs a set of target capabilities that (should) help the user and business. The engineering team designs solutions that embody those capabilities
- 11. 4. Attainable Requirements Can You Build It? Existing Team Available Technology Internal Political Environment Can You Launch It? Organizational Dependencies Legal Restrictions (National, Local, IP)
- 12. 5. Complete Requirements You Cannot Absolutely Determine Completeness Objective Assessment Have you identified all of the problems to succeed in the market? Heuristic Assessment Have you identified how to completely solve the problems?
- 13. 6. Consistent Requirements Strategic Consistency Does this requirement work in concert with others to achieve our strategic goals? Logical Consistency A requires B Must have A Must not have B Grammatical Consistency Writing with the same tone, structure, phrasing…
- 14. 7. Unambiguous Requirements Language Introduces Ambiguity When Writing Identify the user, the context, the goal Be precise in language (avoid jargon, symbols) When Reading Shared language (e.g. “must” vs. “shall”) Read The Ambiguity Handbook and you’ll be forever paranoid about misinterpretation of everything you ever write again. Ever.
- 15. 8. Verifiable Requirements Does it Have a Measurable Aspect? If not, how do you know if you delivered? Do You Know the Measure of Success? If not, how do you know what you need to deliver? Do You Have the Ability to Measure It? Aha! Time to write another requirement.
- 16. 9. Atomic Requirements Every Requirement Stands on its Own The Defining Characteristic: A Requirement Cannot Be Half-Done. It is Either Done, or Not Done.
- 17. 10. Passionate Requirements Be Excited. Be Committed. Care About Your Customers & Their Problems Your Company & Its Strategy Your Team & Their Enrichment Your Work & Its Quality Have Passion …It Will Show in Your Requirements
- 18. 11. Correct Requirements Are You Focusing on the Correct Market Segments, Customers, Proble ms? Do You Know That These Are the Right Requirements? Can We Achieve Our Goals Without These Requirements?
- 19. 12. Stylish Requirements Write Consistently Use Good Style And With Good Style-> The System Must… Prioritize Explicitly Intentional Perspective Ordered Backlog, not Non-Negative MoSCoW Reference, Don’t Repeat Write for Your Audience Gender Indifference Syntactic Parallelism
- 20. Thank You! Scott Sehlhorst http://twitter.com/#!/sehlhorst Twitter https://plus.google.com/110352820346292209511 Google + http://go.tynerblain.com/sehlhorst About Me http://www.slideshare.net/ssehlhorst Slideshare http://tynerblain.com/blog Blog scott@tynerblain.com Email scott.sehlhorst Skype Agile since 2001 Started Tyner Blain in 2005 Helping Companies Build The Right Thing, Right 20
Editor's Notes
- Standish Group, CHAOS Report
- Walk through all of the failure reasons and success factorsFailureLack of user input -> go back to stage gate flow. Fix it how? DiscussionIncomplete Requirements -> adds time to analysisChanging Requirements -> Waterfall breaks. Best case, the dreaded “scope creep” and “tradeoff discussions”SuccessUser Involvement -> key to good product management, baked into agileClear Requirements -> needed regardless of processProper Planning -> what does that mean, exactly? Good at predicting, or picking the right things to do?Realistic Expectations -> Think back to the uncertainty grid
- Walk through all of the failure reasons and success factorsFailureLack of user input -> go back to stage gate flow. Fix it how? DiscussionIncomplete Requirements -> adds time to analysisChanging Requirements -> Waterfall breaks. Best case, the dreaded “scope creep” and “tradeoff discussions”SuccessUser Involvement -> key to good product management, baked into agileClear Requirements -> needed regardless of processProper Planning -> what does that mean, exactly? Good at predicting, or picking the right things to do?Realistic Expectations -> Think back to the uncertainty grid
- The key aspect of a requirement is that you’re asking the team to do something worth doing. When you’ve got a roadmap that is focusing efforts on the problems people are willing to pay to solve, and you’re tying user goals to achieving particular objectives, you sort of implicitly get this.When folks talk about traceability of requirements, traceability is the tracking of association of the value of a particular requirement with the ultimate user goal it is intended to support.
- Brevity provides a few key benefitsScannable for future reference – especially when the nuances are communicated via conversation (versus documentation)Drive focusMinimize opportunities to “miss the point” and focus on the extraneous elementsEasier to reviewLess constraining on innovation
- Each level of abstraction makes “design decisions” that constrain the problem space for those levels below it.The key aspect of “design free requirements” is that you are not constraining the solution-space of the lower-levels of abstraction. You have to trust whoever is focused at that next level to make the right design decisions.User story + acceptance criteria -> Whatever the team does, if it meets the acceptance criteria, it is “good.” Maybe I missed an acceptance criteria. If so, I’ll add it in the next sprint.
- Simply put, be feasible.
- Ambiguous Use of LanguageI had the privilege to attend a presentation by professor Daniel M. Berry in 2007, on the ambiguous use of language in business rules and requirements. In that presentation he referenced The Ambiguity Handbook that he authored (80 page pdf), which I just re-read last week. There are many good examples of ambiguity in the use of English in business documents.The following are some of the sources of ambiguity, for which I entirely credit professor Berry for pointing out to me. I’ve only added some illustrative examples:Plurality Causes Ambiguity. Consider “Emails must include sender addresses” and “emails must include recipient addresses.” Must each email include one sender address and one recipient address? Must each email include multiple sender addresses? Solution – don’t use plural subjects. ”Each email must include a sender address” and “each email must include recipient addresses.”Associative Ambiguity. Professor Berry calls this the parenthesis problem. What does “A and B or C” mean to you? Does it mean “A, and either of B or C” or does it mean “either C, or both A and B” when you read it? In math and programming, we learn very specific rules for how to interpret these types of structures. We are also given parentheses, that we can use when we want to be specific and unambiguous. The reader of your requirements is not a compiler, so don’t assume that she will interpret this the same way that you do. Solution – use parentheses and explicit language to eliminate ambiguity that would arise from ignorance of the associative property.Anaphor Ambiguity. For non-linguists: “don’t use pronouns.” I love the example thatwikipedia uses – “We gave the bananas to the monkeys because they were hungry. We gave the bananas to the monkeys because they were ripe.We gave the bananas to the monkeys because they were here.” The pronoun, “they,” has an ambiguous binding. Should “they” be a reference to the bananas or the monkeys? In each of the first two sentences, you could reasonably assume that the reader will properly bind “they” to the monkeys and bananas respectively. In the third sentence, an assumption of how the reader will interpret “they” is not reasonable. Reasonable assumptions are still ambiguous – and the context is less likely to be obvious – so don’t use pronouns and rely on readers to bind them to the appropriate nouns. Solution – repeat the noun for every reference.