One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.
The Big Rule of Writing Atomic Requirements
From our previous article, Writing Good Requirements – Big Ten Rules:
Every requirement should be a single requirement. If we can say “Half of this requirement is implemented†then this needs to be two or more requirements. If a requirement read “Sales reps can manage their client list and generate custom reports†it expresses two atomic ideas (list management and report generation). Those ideas need to be separated
Determining Atomicity
There is a very simple test – can a subset of the requirement be implemented? Phrases like ‘the user will be able to X and Y‘ are tell-tale signs that a requirement is probably not atomic.
Why Atomicity Matters
Atomicity matters when developing a product roadmap. We can’t prioritize half a requirement for one release and the other half for another. Each requirement should be scheduled for a single release.
Testing of requirements should result in either a “pass” or a “fail.” A requirement should not partially pass its verification test.
Tracability of requirements is also simplified when each requirement is unique.
