Incomplete and unclear requirements may result in project failure. Moreover a significant part of project rework is attributable to problems with the project requirements.
On the other hand, requirements that are clear, complete and understood by all the parties are of “high quality.” They build a solid foundation for the project work.
Collecting high quality requirements can be a challenging endeavor for several reasons:
• Stakeholders often don’t speak the same language (business vs. technical)
• Stakeholders have different understandings and views of the product
• Stakeholders have different backgrounds and expertise on the matter
It may not be the project manager’s role to collect, qualify and write requirements. But he or she is often the one planning the framework and determining or approving the guidelines by which requirements are elicited, qualified and accepted.
The following guidelines should help in collecting high-quality project requirements:
1. No requirements without a use case
Usually, requirements can be linked to concrete business cases, which are generally task- and user-centric. Use cases help understanding the requirements’ context and purpose.
2. Requirements language
Pay attention to the wording. Avoid ambiguous words. Use words and terms consistently.
You might consider using a glossary of terms to ensure common understanding.
Avoid words that have subjective meaning (nice, substantial, safe, simple) and that enforce direction weakly or that undermine commitment (often, always, partially, usually). Use “shall” or “must” instead of “should” or “might.”
Remove any room for interpretation. Avoid the usage of “and/or” together or “including but not limited to.”
3. Requirements characteristics checklist
Build a checklist of requirements characteristics that are relevant to your project’s quality standards. Evaluate each requirement against the checklist.
Here are 10 characteristics that I successfully use to evaluate the quality of requirements:
Atomic: Is this a single requirement or multiple requirements in one?
Complete: Is this comprehensive enough to start working on it?
Traceable: Is this related to a use-case or need?
Logical and Clear: Does it make sense? Does it leave no room for interpretation?
Consistent: Is this consistent with the project objectives and other related requirements?
Measurable: Is this measurable once a solution is delivered?
Compliant: Is this aligned to the current product features, system architecture and legal framework?
Feasible: Is this realistic and doable given the complexity and the project context and constraints?
Necessary: Is this really required given the project objectives and constraints? Or is it more of a want than a need?
Prioritized: What are critical and urgent?
What best practices do you use to ensure that project requirements are of high quality?
