I have to admit that I have a rather eclectic music collection, with tracks covering almost every conceivable genre. Every time I hit the “Shuffle” button on my MP3 player, there’s a tense moment of jeopardy.
Will the next track be by an epic rock legend, or will it be a remix of some trashy 90’s pop song?
The mystery is part of the fun!
After hitting the “shuffle” button this morning I was rewarded with the excellent 80’s track, “Atomic” by Blondie. In a moment of lateral thinking, this 80’s new-wave song prompted me to think about requirements, and specifically about requirements quality.
Let me explain…
Good quality requirements have a number of characteristics. Many authors have produced guidance around requirements quality, and as an example, the BABOK guide suggests good requirements should be:
- Cohesive
- Complete
- Consistent
- Correct
- Feasible
- Modifiable
- Unambiguous
- Testable
(See “A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) BABOK v2.0”, sec 6.5.4)
As part of cohesiveness, BABOK states:
“A cohesive set of requirements relates to only one thing,”
I would extend this definition and say that each individual requirement within the set should relate to one and only one thing. Or, put another way, each requirement should be atomic. This is of relevance to detailed textural requirement artefacts – for example, declarative requirement statements (“The system shall…” or “A user can…”) or textural business rules. It wouldn’t normally apply to a model or a high level scoping statement.
The Importance of Atomic Requirements
If you are using declarative requirement statements or similar artefacts, there are several advantages to ensuring each requirement is expressed atomically. One of the most significant advantages is it helps to avoid prioritisation anomalies. When several requirements masquerade as one, it makes prioritisation difficult. For example, imagine a requirement was stated as:
“A user must be able to add, edit and delete a new customer record”
This is actually several requirements bundled into one. Perhaps the most important priority is to add (create) the record. Edit might be important, but not critical for day 1 (perhaps it could wait for a second release, depending on the nature of the system). It might be possible to defer the “delete” function even further. This level of prioritisation can only happen if the requirements are split out. Otherwise, it’s likely the whole requirement will be seen as a “critical” day one requirement, even though elements of it could wait.
Muddled and combined requirements also create issues with traceability. What if a different person “owns” each part of the combined requirement above? It would be difficult to show this relationship. Equally, showing relationships and dependencies between requirements becomes more difficult, as it isn’t clear which part of the requirement has the dependency. Muddling requirements makes requirements analysis and requirements management more difficult and causes problems further down the project lifecycle.
So, when you’re using declarative requirement statements, think “atomic” as well as “cohesive”!
>>Improve Your Requirements Writing Skills
When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.
>> Click here for more information about The Blueprint <<
