How do you assess the quality of your requirements? We know that requirements change over time. We know that sometimes we are working on projects in areas where we are not subject matter experts. We know that there can be many unknown unknowns. So how do we know we have a solid set of requirements?
A while ago I posted a series on characteristics of good requirements. These characteristics can be used as measurement criteria for quality.
Items to consider:
Clarity - You should be able to provide your requirements to an uninvolved third party and they should be able to understand what you're trying to say.
- Is there a lot of jargon being used?
- Is the language used simple and concise?
- Can alternative meanings be derived (e.g., ambiguity)?
- Do the requirements provide a sufficient level of detail and understanding to the business need?
- Do you understand the context and how groups of requirements fit in with the entire body of work?
- Are there contradictions in the requirements?
- Is the terminology used consistent in it's meaning?
- Is there a way to test the requirement? Are there proxy tests?
- Are there many requirements joined together (e.g., the word "and" is used often)?
- Can you determine which high-level requirement a low-level one belongs to?
- Can you determine what are the higher-level requirements that lead to a low-level one?
- If you have to make a change, do you only need to make it in one place or must you correct many different places in the document?
- How realistic are the requirements based on your understanding of the client's goals, objectives and capabilities?
- Is it even possible to do what is being asked?
- Do the requirements answer the "what" questions or the "how" questions?
- Are the requirements trying to fix a problem with an existing system rather than defining a business need?
- Is everything legal? What guidelines or legislation must be followed?
- Is everything ethical?
When examining requirements documentation these questions can help you get a grasp on the quality of the requirements. High quality requirements contribute significantly to better products. A previous post, Why you need good requirements, explained the rationale for wanting solid documentation and the potential consequences of poor requirements.