Type: Rules
Gist
Atomic requirements are a prerequisite for specs of product lines, of concurrent product releases, and of developments, in which requirements are likely to change during one release of the product, or will have to be re-factored.
Rules and Notes
R1: A requirement is likely to be atomic if you cannot say "this requirement is partially implemented".
R2: A requirement is likely to be atomic if it decomposes a higher-level requirement AND you can justify it by saying "if I don't write it like this, the higher-level requirement wouldn't make sense" (not: is incomplete, or is unspecific).
Note: R2 also tests that the requirement isn't specifying a superfluous solution to the higher-level requirement.
R3: A scalar requirement is atomic (or elementary), if it has only one scale of measure. <- Tom Gilb Glossary
Costs, Savings
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').
Related Pages
- 11 rules for prioritizing features
- avoid requirements related defects in it-systems
- effort needed for product enhancements
If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!
