Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Rules of Requirements - April 2012

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!

  • Login to see the comments

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!/sehlhorst Twitter Google + About Me Slideshare Blog Email scott.sehlhorst Skype Agile since 2001 Started Tyner Blain in 2005 Helping Companies Build The Right Thing, Right 20