Assessing requirement quality

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)?

Completeness - Understanding whether a body of work is complete may be a little tricky. If there are common industry models that relate to your project compare and contrast them with what you have. Gaps may emerge that indicate missing requirements.

• 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?

Consistency - Inconsistent messages are like bad driving directions, you may never get to where you wanted to be.

• Are there contradictions in the requirements?
• Is the terminology used consistent in it's meaning?

Testability - Requirements must be determined to be fulfilled or not.

• 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)?

Traceability - You can trace forwards and backwards and prove that your needs are being accounted for.

• 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?

Modularity - Making changes as simple as possible.

• 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?

Feasibility - Add a touch of realism. If you are a marketing company, it is probably not feasible for your team to design a rocket ship.

• 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?

Design Independence - Requirements should be agnostic of technology and speak only of business need.

• 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?

Correctness - Everything must be in accordance with legislation and client guidelines.

• Is everything legal? What guidelines or legislation must be followed?
• Is everything ethical?

Epilogue

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.