Type: Principles
Status: final
Version: 2008-09-08
Gist: 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.
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
Suggested Reading:
_BW_besser.jpg)
Posts
4 comments:
This seems wrong. How can requirements be both reusable and unique?
>>Examples?
{s. th.}?
Another friend of mine also asked the very same question. I'll update the principles.
Ahhh, reusable and unique, here, are like DRY, Don't Repeat Yourself. That rule discourages copying chunks of code, but instead making them into macros or subroutines. This means that when you update or correct something, you only have to do that one time in one place.
I still don't understand "s. th.".
Gist: A lot has been written about what requirements should look like, what they are and what they are not, how you should capture them, etc. These 3 principles take you 80% of the way. They are grounded in sound systems engineering.
Smoother and briefer?
Post a Comment