Requirements Validation

Requirements Validation (Page 33)

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:

checking for accuracy, consistency, relevance etc in
meetings between requirements engineer and stakeholders using
appropriate representations eg mock-ups, prototypes, graphical models

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:

correct in itself (see week 5) ts validation, weg (see week 5) eg that it is:
- - unambiguous - statements should have only one interpretation
- - complete - includes all requirements, defines responses to all inputs, is fully referenced etc
- - consistent - should not contain factual, logical or temporal contradictions
- - factually correct - information about the domain is correct
correct with respect to the user's intentions ie that it says what he or she intended it to say

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

hand checking - reading through the specification document (see McCluskey et al 94)
Fagan inspections (see Gough et al, 95) - structured hand checking
using a prototype
- - as a test harness to validate functional requirements (see McCluskey et al 94)
- - as a simulator to validate functional and usability requirements (see McCluskey et al 94)
specification animation - like using a prototype a simulator
formal proofs of important properties (see McCluskey et al 94)

Choosing a Technique

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

who will sign off the requirements specification (how much time they have, what their experience of requirements specification notations is etc)
how much time is available for validation activities
how critical it is (eg to safety or security) that requirements should be right
how easy it will be to make modifications once the system is in place

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:

a moderator, or chair
a note-taker, or secretary
the author of the components being inspected
one or more checkers of the components being inspected

Fagan suggested that they should be carried out in 6 stages:

planning - selection of the inspection team etc
overview - presentation of general material to the inspection team
individual preparation - each team member studies the component alone
inspection meeting - components are reviewed by a team composed as above
component re-work - the defects identified and agreed by the inspection team are addressed
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:

syntactic checking- removal of spelling mistakes, typos, illegal use of operators, type mis-matches etc. This is done automatically by a parsing tool
dynamic testing - generation of a prototype and test harness to validate functional requirements
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
formal reasoning - desirable properties of the specification were formulated as theorems and proved both by hand and using a theorem prover
using a simulator - allowing users to test the requirements models for themselves

References

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