Powering Business ValueThe Rules of Requirements                25 September, 2012
Scott SehlhorstProduct management & strategy consultant   8 Years electromechanical design engineering (1990-1997)       I...
Why Do We Care……About Writing Good Requirements?
Track Record(Standish Group CHAOS Report)                                4
Root Cause AnalysisFailure reasons           Success factorsLack of user input        User involvementIncomplete requireme...
Rules of Requirements1.   Valuable      7. Unambiguous2.   Concise       8. Verifiable3.   Design Free   9. Atomic4.   Att...
1. Valuable Requirements
2. Concise Requirements
3. Design-Free RequirementsThis is really about trust.The “stack” of problemdecomposition alternatesbetween requirements a...
4. Attainable RequirementsCan You Build It?  Existing Team  Available Technology  Internal Political EnvironmentCan You La...
5. Complete RequirementsYou Cannot AbsolutelyDetermine CompletenessObjective Assessment  Have you identified all of  the p...
6. Consistent RequirementsStrategic Consistency  Does this requirement work in concert with others  to achieve our strateg...
7. Unambiguous RequirementsLanguage Introduces AmbiguityWhen Writing  Identify the user, the context, the goal  Be precise...
8. Verifiable RequirementsDoes it Have a Measurable Aspect?  If not, how do you know if you delivered?Do You Know the Meas...
9. Atomic RequirementsEvery Requirement Stands on its OwnThe Defining Characteristic:  A Requirement Cannot Be Half-Done. ...
10. Passionate RequirementsBe Excited. Be Committed.Care About  Your Customers & Their Problems  Your Company & Its Strate...
11. Correct RequirementsAre You Focusing on theCorrect   Market Segments,   Customers, Problems?Do You Know That These Are...
12. Stylish RequirementsWrite Consistently         Use Good Style   And With Good Style->     The System Must…Prioritize E...
Thank You!Scott Sehlhorst  http://twitter.com/sehlhorst Twitter  https://plus.google.com/110352820346292209511 Google +  h...
The Rules of Requirements - Tyner Blain
Upcoming SlideShare
Loading in...5
×

The Rules of Requirements - Tyner Blain

1,260

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,260
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
54
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "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 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 2001Enfocus Solutions: Started Tyner Blain in 2005 http://enfocussolutions.com Helping Companies Build The Right Thing, Right 20
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×