The Rules of Requirements - April 2012

1,490 views

Published on

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!

Published in: Business, Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,490
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
58
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • 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.
  • The Rules of Requirements - April 2012

    1. 1. Austin IIBA20 April, 2012The Rules of Requirements International Institute of Business Analysis
    2. 2. Scott SehlhorstProduct 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. 3. Why Do We Care……About Writing Good Requirements?
    4. 4. Track Record(Standish Group CHAOS Report) 4
    5. 5. Root Cause AnalysisFailure reasons Success factorsWhat have you seen? What have you seen? 5
    6. 6. Root Cause AnalysisFailure reasons Success factorsLack of user input User involvementIncomplete requirements Exec supportChanging requirements Clear requirementsLack of exec support Proper planningTech. incompetence Realistic expectations 6
    7. 7. Rules of Requirements1. Valuable 7. Unambiguous2. Concise 8. Verifiable3. Design Free 9. Atomic4. Attainable 10. Passionate5. Complete 11. Correct6. Consistent 12. Stylish
    8. 8. 1. Valuable Requirements
    9. 9. 2. Concise Requirements
    10. 10. 3. Design-Free RequirementsThis is really about trust.The “stack” of problemdecomposition alternatesbetween requirements anddesign. 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. 11. 4. Attainable RequirementsCan You Build It? Existing Team Available Technology Internal Political EnvironmentCan You Launch It? Organizational Dependencies Legal Restrictions (National, Local, IP)
    12. 12. 5. Complete RequirementsYou Cannot AbsolutelyDetermine CompletenessObjective 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. 13. 6. Consistent RequirementsStrategic 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 BGrammatical Consistency Writing with the same tone, structure, phrasing…
    14. 14. 7. Unambiguous RequirementsLanguage Introduces AmbiguityWhen 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. 15. 8. Verifiable RequirementsDoes 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. 16. 9. Atomic RequirementsEvery Requirement Stands on its OwnThe Defining Characteristic: A Requirement Cannot Be Half-Done. It is Either Done, or Not Done.
    17. 17. 10. Passionate RequirementsBe Excited. Be Committed.Care About Your Customers & Their Problems Your Company & Its Strategy Your Team & Their Enrichment Your Work & Its QualityHave Passion…It Will Show in Your Requirements
    18. 18. 11. Correct RequirementsAre You Focusing on theCorrect Market Segments, Customers, Proble ms?Do You Know That These Arethe Right Requirements?Can We Achieve Our GoalsWithout TheseRequirements?
    19. 19. 12. Stylish RequirementsWrite Consistently Use Good Style And With Good Style-> The System Must…Prioritize Explicitly Intentional Perspective Ordered Backlog, not Non-Negative MoSCoW Reference, Don’t RepeatWrite for Your Audience Gender Indifference Syntactic Parallelism
    20. 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

    ×