The document outlines essential rules for writing effective product requirements to ensure business success, emphasizing the importance of user input, clarity, and measurability. Key characteristics of robust requirements include being valuable, concise, unambiguous, verifiable, and consistent. Scott Sehlhorst, the author, draws on his extensive experience in product management and engineering to provide guidance aimed at helping organizations build the right products.

1. Powering Business Value
The Rules of Requirements
25 September, 2012

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 products, 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
Lack of user input User involvement
Incomplete requirements Exec support
Changing requirements Clear requirements
Lack of exec support Proper planning
Tech. incompetence Realistic expectations
5

6. 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

7. 1. Valuable Requirements

8. 2. Concise Requirements

9. 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

10. 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)

11. 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?

12. 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…

13. 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.

14. 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.

15. 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.

16. 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

17. 11. Correct Requirements
Are You Focusing on the
Correct
Market Segments,
Customers, Problems?
Do You Know That These Are
the Right Requirements?
Can We Achieve Our Goals
Without These
Requirements?

18. 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
Enfocus Solutions: Started Tyner Blain in 2005
http://enfocussolutions.com Helping Companies
Build The Right Thing, Right
20