The 3 Most Powerful Requirements Principles

Type: Principles


A lot has been written about how requirements should look like, on what they are and what they are not, on what you should do to capture them etc. These 3 principles take you 80% of the way. They are grounded in sound systems engineering.

Principles and Notes

P1: My requirements are re-useable.

This means

  • every requirement is unique. No copying please! 'I. e. I write requirements so that they have a unique name, and use the name in order to re-use the requirement in a different context, instead of copying the requirements text to the other context. Dick Karpinsky calls this the DRY rule: Don't Repeat Yourself.
  • every requirement (not the whole document) provides information on version, author, stakeholder, owner, and status
  • every requirement refers to s. th. and is referred to by s. th., e.g. designs, tests, suggestions/solutions, use cases, …
P2: My requirements are intelligible.

This means

  • every requirement has a type, e. g. one of {vision, function requirement, peformance requirement, resource requirement, design constraint, condition constraint} (courtesy of T. Gilb's basic requirement types)
  • every requirement has a clear structure, i. e. unique, unchanging number or tag, scale, goal (= core specification attributes)
  • complex requirements have a clear hierarchy, not some cloudy abstract
  • no requirement in any non-commentary part uses words that are just fraught with significance, like 'high performance', 'good reliability', 'reduced costs', 'flexible'
P3: My requirements are relevant.

This means

  • every requirement clearly indicates owner, author, stakeholder (in order to be able to judge relevance)
  • every requirement clearly indicates its sources (in order to be able to check them)
  • every requirement clearly indicates its relative priority (for a specific release, for a specific stakeholder)
  • every requirement clearly indicates its constraints and goals
  • every requirement clearly indicates what happens if it is not satisfied
  • no requirement states a design to some problem, but every requirement declares a future state



Related Pages

Where to go from here? Link other pages in bullet list.

rating: +1+x

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


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License