4 Strategies Towards Good Requirements

Type: Rules

Gist

Left with the 3 Most Powerful Requirements Principles, what should you do? The following 4 rules can help you adhere to them.

Rules and Notes

R1: You should get to the point.

• find the priority stakeholders and use their point of view
• don't write requirements that arbitrarily constrain the scope
• seperate strategic requirements from basics, and from solutions or designs
• ask 'why' a couple of times (root-cause analysis)

R2: You should quantify requirements.

'don't be weary, it's less work than you think, once you tried

• every quality requirement can be expressed in numbers (by definition)
• every functional requirement is associated with at least one quality requirement (just ask 'how good?')

R3: You should give your requirements time to evolve, nobody really knows them completely and consistently, now.

• you will find the real requirements by frequent delivery of your product to the stakeholders, e. g. by feedback
• don't get trapped by the idea someone knows all the requirements just because you specify an existing system ' the world kept turning in the meantime, yielding 2-10% requirements creep per month.

R4. You should analyse the value of your requirements and then focus on the ones with best ROI.

• the real requirements are the profitable ones
• it is economic to focus on the top ten (max) requirements

Costs, Savings

<Would be great. What does it take to implement those rules? What does it give?>

Side effects

<Is there anything that happend or will happen as one implements the rules? This relates to both wanted and unwanted effects ('unwanted' does not imply 'negative').>

Quotes

optional

Related Pages

• Root Causes of Poor Requirements (on Inside Architecture)
• finding the right cycle time - 10 rules
• go agile enterprise wide
• communicating plans in agile development

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!