Requirements Validation (Page 33)
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.
- checking for accuracy, consistency, relevance etc in
- meetings between requirements engineer and stakeholders using
- appropriate representations eg mock-ups, prototypes, graphical models
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.
- 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
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
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:
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.
- 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
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
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.