Building Requirements Quality throurh Coverage and Testability

Once a set of requirements categories is established, build this list into the requirements process that is used within the organization.  Common places to include the  requirements categories are in a:

• Requirements Elicitation (or similar) process.  The ideal spot is the step where requirements are being gathered.  This reminds folks that there are numerous requirements categories to consider.
• Requirements List template.  The ideal spot is to include a column or field called Requirements Categories and include the common requirements categories as a reminder. 

Note: if no process Requirements Elicitation (or similar) process and/or Requirements List template exists, then one should be established.   

Establish Requirements Coverage Metrics
Requirements coverage metrics provide the team with a view of the number of requirements in the requirements categories.  The aim is to identify if there are any categories that have few or no requirements and validate if this is reasonable. 

Considering a scenario, let us say that an organization has decided on 6 requirements
categories.  They are: business, user, functional, performance, security, and usability.   What should be produced is a metric chart that illustrates the number of requirements in each requirements category.  Below is an example of the Requirements Coverage metric that can be produced (see Chart #1).  This chart highlights that both Performance category and the Security category have very few requirements.  After more work in
identifying performance and security requirements, Chart #2 illustrates the increase in requirements in these areas. 

Chart #1                                                            Chart #2
Initially what will be obvious in a Requirement Coverage metric is when there are few or no requirements in a given category.  However, it does not help determine the "normal" number of requirements that should be in a given requirements category to ensure you really do have coverage.  For example, would you expect to have more business requirements than usability requirements?  Over time, additional metrics can be tracked
to determine, based on a project size and type, how many requirements are normal (or average) for a given requirements category.  Another enhancement to improve the robustness of this metric is to prioritize the requirements categories in general or by
project type (e.g., a web project may place a higher priority on usability requirements then a back-end system processing project). 

Requirements Testability
Requirements Testability is an approach that can take many forms, two of which are
considered here.  The first form is to establish a language construct for articulating requirements that ensure all elements of a requirement are available to ensure effective testing.  The second form is to establish a requirements peer review technique that ensures a methodical review of the requirements to a set of criteria. 

Requirements Language Construct
The basis for a Requirements Language Construct may depend on the requirements gathering technique that is used.  There are many good techniques.  The better techniques ask the analyst to include various core elements to a requirements string.  Even if it is not in the form of text, but in diagram form (e.g., Use Cases), a good technique will ask for certain elements within the diagram.  These elements can form the core of a language construct.  The question becomes, how does a person approach establishing a Requirements Language Construct?  Key contributors to defining this include Analysts and Testers.  A sequence of activities would include:

Identify the elements of a Requirements Language Construct
Review some of the common requirements gathering technique.  Identify the elements that are typically considered when articulating a requirement.  When identifying elements
from various techniques, some common and consistent elements appear.  For example, the actor is referenced in various techniques and so are the elements of action, system, and output.  Stringing these together establish a simple but solid requirements language construct that looks like: <actor> <action> <system> <expected output>. 

Identify elements of a Test Case
Once core elements are identified via a review of the requirements gathering techniques, review the Test Case approach and identify if there