The Rules of Requirements - Tyner Blain


Published on

We write requirements because we need to communicate (and remember) _why_ we're doing something, not because we need documents. These 12 rules will help you make sure your requirements work effectively to build the right product, right.

Slides are from Enfocus Solutions webinar - 25 Sep 2012

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Rules of Requirements - Tyner Blain

  1. 1. Powering Business ValueThe Rules of Requirements 25 September, 2012
  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 products, 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 factorsLack of user input User involvementIncomplete requirements Exec supportChanging requirements Clear requirementsLack of exec support Proper planningTech. incompetence Realistic expectations 5
  6. 6. Rules of Requirements1. Valuable 7. Unambiguous2. Concise 8. Verifiable3. Design Free 9. Atomic4. Attainable 10. Passionate5. Complete 11. Correct6. Consistent 12. Stylish
  7. 7. 1. Valuable Requirements
  8. 8. 2. Concise Requirements
  9. 9. 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
  10. 10. 4. Attainable RequirementsCan You Build It? Existing Team Available Technology Internal Political EnvironmentCan You Launch It? Organizational Dependencies Legal Restrictions (National, Local, IP)
  11. 11. 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?
  12. 12. 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…
  13. 13. 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.
  14. 14. 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.
  15. 15. 9. Atomic RequirementsEvery Requirement Stands on its OwnThe Defining Characteristic: A Requirement Cannot Be Half-Done. It is Either Done, or Not Done.
  16. 16. 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
  17. 17. 11. Correct RequirementsAre You Focusing on theCorrect Market Segments, Customers, Problems?Do You Know That These Arethe Right Requirements?Can We Achieve Our GoalsWithout TheseRequirements?
  18. 18. 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
  19. 19. Thank You!Scott Sehlhorst Twitter Google + About Me Slideshare Blog Email scott.sehlhorst Skype Agile since 2001Enfocus Solutions: Started Tyner Blain in 2005 Helping Companies Build The Right Thing, Right 20