Building Requirements Quality throurh Coverage and Testability

As we look to deploy or improve a requirements practice, the output should lead to a set of complete and quality requirements. A way to get there is to ensure that requirements have been captured in all pertinent categories and are testable.  Often times, requirements focus on user needs and limited functional areas.  But what may be overlooked are lesser requirements categories (e.g., security, usability, etc). It is therefore essential to capture requirements that ensure coverage in the requirements space.

Once requirements cover all pertinent areas, it is critical to ensure that the requirements are testable.  Testability implies that the requirements are understood enough that a test case can be established and then run to prove that a requirement has or has not been met.  Having a requirement written at this level ensures that developers can build something that aligns with the requirement, reducing the gap of what the requirement specifies versus what gets built. 
    
With this in mind, this article provides a straight forward approach to requirements
coverage and testability.  More advanced techniques and practices exist in this area. 
The important thing to consider is what level of practice your organization is ready to address.  Once a solid step has been made, then advancements should be considered.       

Requirements Coverage
Requirements Coverage is an approach to capturing requirements in all pertinent requirements categories.  This ensures a set of robust requirements that are encompassing for the project.  Assuming a project will test the requirements, this also helps ensure that during the testing phase, a range of testing occurs for the project that alleviates concerns around insufficient testing in key areas. 

The question becomes, "How does a person approach establishing Requirements Coverage?"  Key contributors to defining this include Analysts and Testers.  A sequence of activities would include:

Identify core Requirements Categories
The first activity is to identify the common requirements categories.  This, unfortunately, is not as easy as it sounds.  The reason is that there is no conclusive set of requirements categories.  Terminology varies among organization and what requirements categories
are needed also ranges.  Searches on the internet reveal that there are various ways to articulate requirements categories.  Some examples include:

• In "Isn't Someone Coding Yet (WISCY)? Avoiding Ineffective Requirements" by Charlene Gross (SEI), she lists the traditional requirements
  categories of: Business, User, Functional, Non-functional.  In Non-functional requirements categories, she lists numerous sub-categories including government regulations, platform, legacy interfaces, usability, performance, scalability, security, flexibility, and portability.
• On the Ludwig Consulting site, Ludwig lists some requirements categories to include: Functional, Operational, Development process/Project, Performance, and Contract.  In Performance, he lists numerous sub-categories as efficiency, expandability, flexibility, integrity, interoperability, maintainability, portability, usability, reliability, throughput, response times, capacity, availability, and growth.
• In the article, " ABCs of Requirements Engineering ", by Mario Moreira on CM Crossroads, he writes, "some examples of the category of requirements are user requirements, system requirements, performance requirements, and security requirements. 

With this in mind, the important thing to do is to collaboratively determine the list of requirements categories within your organization.  Getting a small group of Analysts and Testers is a good way to begin.  Brainstorm potential requirements categories with this small team.  Then consider validating these against the common root causes of the defects that are often found in testing phase and when the product is released (customer defects).  See if they align with any existing requirements categories or that a new requirements category is needed. 

For example, if you see a lot of defects relating to access (e.g., easy to access areas that are not supposed to be accessed), then this may mean that "security" should be a requirements category.  Once a robust set of requirements categories is captured, then they can either be prioritized to the top 12 core requirements categories (e.g., since it may be hard to manage too many categories) or they all can be used. 

Incorporate Requirements Categories