Requirements Validation (Page 33)

[Down] [Contents] [Course Plan] [Reading List] [Help]

Requirements Validation

is aimed at ensuring that a requirements specification is correct with respect to the user's (or client's) intentions. The aim in requirements validation is to obtain agreement between all stakeholders including developers, clients and users regarding the nature of the problem and the way in which it is to be solved. Activities involved in requirements validation include: It makes sense to begin checking this early on in the requirements process, as the later mistakes are discovered, the more expensive they are to correct.

In requirements validation, we must ensure that the specification is both: We can, if necessary, produce formal proofs that a requirements specification possesses certain formal properties eg we can test for logical inconsistencies. However, it is not possible to prove in any formal sense that the requirements specification is correct with respect to the user's intentions: instead, we must aim simply to increase our confidence, and that of the client, that the view we have specified is the right one.

Techniques for Requirements Validation

Choosing a Technique

The choice of technique(s) for requirements validation should depend on:

Fagan Inspections

A Fagan inspection is a structured and systematic approach to checking through the outputs of any stage in software development. Fagan inspections can be carried out on various components of a requirements specification, as discussed in Gough et al, though they are amore appropriate to some components (eg scenarios) than others (eg domain objects). See Sommerville 92 for a brief summary.

Fagan inspections aim at defect discovery. They are carried out by small teams of people including:
Fagan suggested that they should be carried out in 6 stages:
  1. planning - selection of the inspection team etc
  2. overview - presentation of general material to the inspection team
  3. individual preparation - each team member studies the component alone
  4. inspection meeting - components are reviewed by a team composed as above
  5. component re-work - the defects identified and agreed by the inspection team are addressed
  6. re-inspection - possibly just by the inspection team chair
Maximum time spent per inspection meeting should be around 2 hours - after that inspection efficiency falls. Meetings should be carried out regularly on small components.
It is important that inspections are seen as part of the verification and validation process and aimed at quality assurance, rather than being taken as personal assessments of the component authors.

FAROAS Project: A Case Study in Requirements Validation

McCluskey et al combine several different techniques for requirements validation in order to maximise confidence in the specification of requirements for a system in the safety-critical domain of air traffic control.
The validation process used in this case consists of 5 separate checks:
  1. syntactic checking- removal of spelling mistakes, typos, illegal use of operators, type mis-matches etc. This is done automatically by a parsing tool
  2. dynamic testing - generation of a prototype and test harness to validate functional requirements
  3. hand validation - algorithmic translation of the specification into structured natural language, with checks being carried out and discussed in 4 validation meetings, each lasting 2 - 3 days and involving 4 - 5 domain experts
  4. formal reasoning - desirable properties of the specification were formulated as theorems and proved both by hand and using a theorem prover
  5. using a simulator - allowing users to test the requirements models for themselves


P. Gough, F. Fodemski, S. Higgins and S. Ray, 'Scenarios - an Industrial Case Study and Hypermedia Enhancements', in Proceedings of RE95, Second IEEE International Symposium on Requirements Engineering, IEEE, 1995 (handout week 3).

L. McCluskey, J. Porteous, Y Naik, C. Taylor and S. Jones, 'A Requirements Capture Method and its Use in an Air Traffic Control Application', in Software Practice and Experience, vol 25, no 1, 1995.

I. Sommerville, Software Engineering (4th ed), Addison-Wesley, 1992, pp92 - 97.

Query Libertas

[Up] [Contents] [Help]