Requirements Audits

The Importance of Requirements

Requirements form the backbone of any successful project, setting the scope for all subsequent work and providing the measure of success or failure.  User requirements define stakeholders' needs whilst the system requirements define the functional and non-functional aspects of the system that will realise this need.  If these requirements are wrong or mis-interpreted there will be confusion, the product will not meet the customers' expectations and the increasing costs could result in the project failing[1].  With 70% of project costs committed before full scale development starts[2], it is easy to see why the costs of correcting mistakes after production can be 100 times the cost of getting the requirements right.

Getting the Right Requirement Right

Considerable effort can be expended in capturing and managing requirements - getting the right requirements.  However, if the right requirement is mis-interpreted, is not related to other requirements or is incomplete, the content will be lost and the requirement will fail.  Requirements engineering employs systematic and repeatable techniques to ensure requirements are complete, consistent and relevant - getting the right requirement right.  Requirement engineering mitigates the risk that the project will fail because the requirements are incomplete, will be mis-interpreted or are incorrect.

Auditing Requirements

A requirement-engineering based audit identifies strengths and weaknesses, giving guidance to focus limited resources in developing a robust and agreed set of requirements.  It is an objective review, providing a project and domain independent perspective at any stage in the life cycle to give confidence in the requirements.  A requirement audit analyses several criteria using a variety of techniques at the levels of the individual requirement and of the whole requirement set:

Criteria	Description	Audit Technique
Ambiguity	Consistent and defined use of natural language words, phrases and domain-specific terminology.  Can readers from diverse backgrounds interpret the requirements?	Create dictionary and link definitions to each requirement.
Clarity	The requirement is written clearly, precisely, and without using complex conditional phrases.	Objective and subjective review.  Introduction of standard templates or boilerplates and atomised statements.  Grammatical & natural language analysis.
Correctness	Each requirement has the set of attributes required by a corporate process or recognised guidance, or has adequate information to express a correct requirement.	Define agreed requirement model and compare.  Numerical analysis of blank/incomplete attributes to generate metrics
Completeness	The system requirement contains all necessary functions.  All functions should have an input coming from either another function or from an external entity, and every output should go to another function or to an external entity.	Create functional and object-oriented models and hierarchy diagrams to illustrate and explore internal relationships between requirements.  Check for consistency of input and output and identify gaps or excessive requirements.
Coverage	Each statement should be cross-referenced with or linked to a superior statement, demonstrating top-down derivation.  Each user requirement should be linked to a source or justification, each system requirement must be derived from one or more user requirements, and each user requirement is being delivered by one or more system requirements.	Traceability matrix.
Consistency	No duplication, redundancy or contradiction between individual requirements.  Requirements should be mutually consistent.	Interaction matrix and requirement model to analyse functional inputs and outputs.
Structure	Are the requirements organised in a sensible way, and are related requirements grouped?  Has the requirement structure been decomposed consistently and completely?	Hierarchy and object oriented modelling to analyse decomposition.
Testable	Does each requirement have defined and realistic acceptance/verification criteria?	Analysis of acceptance criteria and mapping to acceptance events.
Priority	Are requirements prioritised?  Is the priority cascaded correctly?	Basic QFD analysis.

Requirement Audits and Cradle

3SL can support a project by conducting a comprehensive requirements audit within Cradle.  Following an initial study, the requirements and all supporting documentation can be imported and analysed using built-in cross-referencing, matrix generation and modelling tools.  The results can be provided as a formal audit report describing the method employed, the results and any recommendations for improvement.  Alternatively, 3SL can implement agreed recommendations and return the modified requirements in the original data format with full justification for all changes.  The result is an increased confidence in the requirements based on external, objective analysis.

The outputs of the techniques employed during a requirements engineering audit can also be re-used by other activities.  A simple model developed to analyse completeness and consistency can facilitate further requirement capture where gaps exist, provide the basis for functional allocation and architecture design, or be used to identify external and internal interfaces.  The identification and calculation of relevant metrics can be used as a management control, the audit providing a baseline against which to set targets and monitor progress.