Building Requirements Quality throurh Coverage and Testability

are any additional elements that
are expected in the test case.  For example, the test case may want to know exactly where the expected output should live.  This will make it easier to know if the test case passes.  In this example, the additional element of location can be added.  Now the language construct would read:   <actor> <action> <system> <expected output> <location of output>.   

Incorporate Language Construct
Once a language construct has been defined, consider incorporating this into several
areas.  The first is to incorporate the language construct into the Requirements Gathering procedure.  Secondly, incorporate the language construct into the Requirements List template as a prompt or reminder.  Finally, incorporate the language construct into the requirements technique training materials as appropriate. 

Please note that there may be a different language construct for some of the  requirements.  For example, for a user requirement, the <actor> is important to know. 
However for a performance requirement relating to systems, the <actor> may not be needed. 

Requirements Peer Review
There is a danger that peer reviews get seen as a nice informal exercise when there are no guidelines used to evaluate the work product.  It becomes essential that the requirement peer review has a formal closed loop process with criteria for evaluation.  Often times, this can be known as Requirements Inspection to promote its formality.  Key contributors to defining a Requirements Peer Review Practice would include Analysts and Testers.  The following provides outline of steps that can be followed

Identify concrete criteria in performing a Peer Review
Establish a Requirements Peer Review Practice that ensures a methodical review of the
requirements that meet the guidelines of the requirements technique and the
requirements language construct.  In this case, when a peer review occurs, ensure that all of the core elements of the language construct appear in each requirement. 

In addition to using the language construct as criteria, there are other criteria that can be
added.  In his article, " On-Track Requirements: How to evaluate requirements for testability ", Rodger Drabick suggests evaluating each requirements against several quality characteristics.  These characteristics include: complete, consistent, correct, not-ambiguous, and noncompound.  If a requirement meets these characteristics, then it can be considered testable.  Consider reading his article for more details.   

Identify key personnel to perform Peer Review
There are probably three key roles that should attend a requirements peer review
session.  The first are other Analysts not involved on this project.  The second are testers since testers will have to test from the requirements so they will need to ensure that all elements are present for testability.  Thirdly, consider identifying key development
personnel since they have to build the product release based on the requirement. 

Deploy a Requirements Peer Review Practice
As mentioned above, it is important to document the Requirements Peer Review Practice that has a formal closed loop process with criteria for evaluation.  In this case, the evaluation criteria are two-fold: 1) whether all of the core elements of the language construct are in place and 2) whether they meet the quality characteristics (both discussed above).  It is advisable to have a peer review worksheet with the criteria to evaluate against.

Note: Two big factors to consider in deploying a peer review practice.  It does take time so ensure time is built into the schedule for this activity.  However, time expended in the peer review should reduce time in development and testing since requirements are clearer after the peer review.  Also, ensure that personnel attending the peer review are prepared.  They should have already walked thru the list of requirements against the criteria so that the peer review is a quick exercise of identifying areas where criteria is not met.      

Summary
Introducing a Requirements Gathering practice usually includes steps to identify requirements and document them.  To ensure that complete and quality requirements are delivered, consideration should be given to specifying what elements should be in each