There is sometimes confusion over requirements validation and verification.
This slide provides some important context for the rest of the lecture.
Validation of requirements is the investigation of the specified requirements
(for example in VOLERE shells, use case specifications and i* models)
against stakeholders’ perceptions of their requirements to determine
whether the correct requirements have been specified. Although seemingly
trivial, translating a perceived requirement into a documented and specified
one is frequently problematic, and validation is needed of both individual
requirements and of the specified system as a whole, to examine the
emergent properties of the system to see whether system-level
requirements can be satisfied. It is this validation that we will focus on in this
Verification of requirements is the investigation, normally by requirements
engineers, of requirements models and specifications to discover
undesirable properties of these specifications, for example inconsistencies,
conflicts and omissions. Examples include analysis of an i* SR model to
investigate whether all actor goals can be achieved, or quality gateway
checks on VOLERE requirements to avoid common requirements problems.
Finally, there is verification of architectures, designs and implementations
against specified and measurable requirements. This is not explicitly a
requirements activity, and beyond the scope of this lecture.
Requirements research and practice has identified and investigated different
requirements validation and verification techniques. One of the most common
requirements validation techniques is for stakeholders to read through requirements
documents to validate each requirement in turn. This can be time-consuming and
tedious. In our example structuring requirements with use cases tends to make the
specification more readable (as the requirements as reported as a story) and easier
to understand as they are in context). A more rigorous technique is a formal review
that leads to key stakeholders signing off requirements specifications for authorised
use in subsequent phases of the life cycle. Prototyping also has a role here – use
case specifications can often be combined with simple prototypes to demonstrate
requirements and give stakeholders a vision of the future system that complies with
these requirements, to check whether the system does what they want. More on this
Verification techniques can be broken down into two broad types. The first is
verification of individual requirements. A classic approach here is the VOLERE
Quality Gateway (Robertson & Robertson 1999), which asks a number of questions
of each VOLERE requirement, and only once the quality of the requirement is
assured can it be moved from the pending specification to the actual requirement
specification. The second type explores emergent properties of the future system as
specified. Requirements are often developed bottom-up, and it is difficult to check
what the overall, or emergent behaviour of the system, will be. Two available
techniques are model-based analysis, which uses formal non-functional properties of
models such as i* to discover new properties of the system, and reviewing
satisfaction arguments to investigate whether the arguments hold.
Robertson S & Robertson J., 1999, ‘Mastering the Requirements Process, Addison-Wesley.
Reference: Reference: Neil Maiden (2011) Requirements Engineering Lecture Notes