Chapter 5

Requirement Validation

Kelemework K.
1
 Contents
Introduction
Analysis & negotiation Vs Validation
Inputs and Outputs of Requirement Validation
Validation framework – Activities
Review
Reading Techniques
Translating requirements to alternative forms
User manual
Visualizations, e.g. diagrams
Lightweight formal models
Prototypes
2  Test cases
 Introduction
 The goal of requirement validation is to check the requirements to
certify that the requirements document is an acceptable description
of the system to be implemented.
 It determines whether the requirements are substantial to design the
system.
 It involves checking a requirements document
if it correctly describes the intended system capabilities and
characteristics that will satisfy the various stakeholders' needs.
for completeness and consistency,
for conformance to standards,
for requirements conflicts,
for technical errors,
for ambiguous requirements etc
3 if the requirements provide an adequate basis to proceed with
Analysis & negotiation Vs Validation
Requirement validation is different from the
requirements analysis and negotiation (How?)
Analysis and Negotiations
 focus on ensuring that the requirements are correctly understood
and reflect the needs of the stakeholders.
 Concerned with the “raw” requirements gathered from the
stakeholders.
o Rather than the details of correct articulation of the
requirements.
 Analysis & Negotiation focus on “have we got the right
requirements?”
Validation
 focuses on the documented requirements i.e. with negotiated
and agreed requirements and how they are represented.
 Validation focuses on “have we represented requirements right
4
(correctly)?”
 Analysis & negotiation Vs Validation…
Some stakeholder problems are inevitably discovered
during requirements validation & these must be corrected
before the requirement document is approved & used as
basis for development.
Problems that could be discovered during validation are
 Documentation problems
 Flaws in requirement elicitation, analysis & modeling.
……………………….………
Requirement validation is a difficult process.
 There is no way to demonstrate that a requirement specification is
correct with respect to some other system representation.
So requirements validation asks two questions:
 requirements meet stakeholders needs represented ?
 requirements clear enough for others to use ?
5
 Inputs & Outputs of Requirement Validation
List of problems to be
resolved
Some “typical” problems:
- conformance to standards
Requirements
- ambiguous wording
document - error in the actual model
Organizational Standard
- undetected conflicts
Organizational List of agreed actions
Inputs
Knowledge Outputs

Requirements
Validation

6
 How long does validation take?
Validation is a prolonged processes it involves people
reading and thinking about a lengthy document.
Meeting may have to be arranged and experiments carried
out with prototype.
So it may take several weeks or sometimes months for
complex systems.
This is particularly likely if stakeholders from different
organizations are involved.

7
 How long does validation take?...
Validation isn't a single discrete phase that you perform
after gathering and documenting all the requirements.
Some validation activities, such as incremental reviews
of the growing SRS, are threaded throughout the
iterative elicitation, analysis, and specification processes.
Other activities, such as formal SRS inspection, provide
a final quality gate prior to baselining the SRS.
Include requirements validation activities as discrete
tasks in your project plan.
Requirement validation activities can be categorized as
Review activities

8
Activities involved translation
 Validation framework - Activities
Review - relies on human intelligence in hope that people
might find some problems with requirements.
If the requirements document or some part of it is in a sufficiently
formal language, some properties can be automatically checked
by software.
Translation - translate requirements to an alternative form.
This has a double advantage:
The translation process may fail (rewriting turns out to be
partially impossible),thereby pointing to some ambiguity,
completeness, consistency, etc. defects.
 If two or more persons accomplish rewriting independently and the results
are significantly different, this also points to problems (mainly ambiguity) in
the document.
After rewriting, requirements in the new form are again reviewed.
9 The idea is that this form is believed to be better understandable
to a specific group of reviewers. Also, the rewritten form may be
 Requirements reviews
A group of people (excluding those who are involved in
requirement document preparation) read and analyze the
requirements, look for problems, meet and discuss the
problems and agree on actions to address these problems
A widely used requirements validation technique.
 lots of evidence of effectiveness of the technique.
Can be expensive
Careful planning and preparation
Pre-review checking
Use of checklists

10
 Requirements reviews process

11
 Requirements reviews process…
Actions which might be decided for each problem are as
follows
Requirements clarification - The requirement may be badly
expressed or may have accidentally omitted information which
has been collected during requirements elicitation.
Missing information - Some information is missing from the
requirements document. It is the responsibility of the
requirements engineers who are revising the document to discover
this information from system stakeholders.
 Requirements conflict - There is a significant conflict between
requirements. The stakeholders involved must negotiate to resolve
the conflict.
 Unrealistic requirement - The requirement does not appear to be
implementable with the technology available or given other
12
constraints on the system. Stakeholders must be consulted to
decide how to make the requirement more realistic.
 Pre-review checking
Reviews are expensive because they involve a number of
people spending time reading and checking the requirements
document.
Expense can be reduced by using pre-review checking.
One person checks the document and looks for straightforward
problems such as missing requirements, lack of conformance
to standards, typographical errors, etc.
Document may be returned for correction or the list of
problems distributed to other reviewers.

13
 Types of Review
There are different types of reviews with varying degree of formality
 Reading and signing off:
 reading the document and signing of to endorse it.
 Walkthroughs
 Informal, often high-level overview.
 Can be led by author/expert to educate others on his/her work.
 Formal inspections
 Very structured and detailed review, defined roles for participants and
preparation is needed.
 Focused inspections
 reviewers have roles and each looks only for specific types of errors.
 Active reviews
 reviewer is asked to use the specification.
 the author poses questions for the reviewer to answer that can be
14 answered only by reading the document.
 Reading Techniques
In both formal and informal reviews, an important factor is the
level of guidance the reviewers receive for accomplishing their
task, or reading technique.
Reading techniques:
Ad-hoc
Checklist-based
Not only a list of review questions but
Defect-based
also a collection of procedures to follow
Perspective-based is provided, which describe the steps to
Scenario-based be accomplished in order to answer the
Pattern-based questions.
Ad-hoc reading – no guidance is provided, reviewers use only
their own knowledge and experience to identify defects.
Perspective-based reading – each procedure is based on the
15
viewpoint of a particular stakeholder. E.g. designer, tester, end-
 Checklist-based Reading Techniques
a list of questions is provided specifying what properties of
the document must be checked and what specific problems
should be searched for.
The inspector is given a checklist consisting of several
questions.
Essential tool for an effective review process – list common
problem area and guide reviewers
Every relevant requirements quality criterion is rewritten in the
form of a question, or refined into two or more questions.
A checklist works just as a reminder for reviewers of those
quality criteria.
Each organization should establish their own check list
A sample checklists are shown in the next slides
16
 Checklist-based Reading Techniques…
 Understandability
 Can readers of the document understand what the
requirements mean?
 Redundancy
 Is information unnecessarily repeated in the requirements
document?
 Completeness
 Does the checker know of any missing requirements or is
there any information missing from individual requirement
descriptions?
 Ambiguity
 Are the requirements expressed using terms which are
clearly defined? Could readers from different backgrounds
17
make different interpretations of the requirements?
 Checklist-based Reading Techniques…
 Consistency
 Do the descriptions of different requirements include
contradictions? Are there contradictions between individual
requirements and overall system requirements?
 Organization
 Is the document structured in a sensible way? Are the
descriptions of requirements organized so that related
requirements are grouped?
 Conformance to standards
 Does the requirements document and individual requirements
conform to defined standards? Are departures from the
standards, justified?
 Traceability
 Are requirements unambiguously identified, include links to
18
related requirements and to the reasons why these requirements
 Defect-based Reading Techniques
The starting point for defect-based reading is a model of
possible defects in requirements documents.
For each defect class, a set of questions was developed
that would characterize the defect class.
Examples of defects that could be detected includes data type
inconsistencies, incorrect functionalities, ambiguities or missing
functionality.
Some empirical evidence exists that this may outperform
checklist-based and ad-hoc approaches.
“The defect detection rate of individuals and teams using defect
based reading is superior to that obtained with ad-hoc or
checklist methods.”

19
 Defect-based Reading Techniques…


Defect-based procedure example

20
 Scenario-based Reading Techniques
Scenario-based reading - a set of concrete scenarios are provided.
Reviewers walk through the sequence of events in each scenario and
examine the requirements document for presence, correctness, etc. of
requirement statements that cover those.
scenarios may be usage scenarios, maintenance work scenarios, etc.
often mentioned as a separate validation technique.
McGregor and Syke’s “guided inspection” is variant of
scenario-based reading
Inspectors prepare scenarios, then
The authors of the reviewed document explain how the system
described by the document is assumed to handle these cases.
Inspectors follow explanations and look for problems:
Inappropriate system’s behavior,
Information has left in the head of the author and was not written
21
down.
 Pattern-based Reading Techniques
a set of patterns is provided to reviewers that they can use
when validating requirements against scenarios.
Example of requirements patterns
‘MACHINE-FUNCTION’ pattern – a good requirements
document shall include at least one functional requirement
statement for each action in which the software system is
involved.
Implementing the functional requirement will thus ensure that
the system undertakes the action described in the scenario.
For example, consider a dealer who uses a financial foreign
currencies trading system to record information about a
currencies deal:

22
 Pattern-based Reading Techniques…
 ‘COLLECT-FIRST-OBJECTIVE-LAST’ pattern – a good
mechanical device with which a person interacts using one or
more personal items must ensure that the person will not go
away leaving those personal items at the device.
E.g. Consider a passenger who uses a travel ticket to pass
through automatic gates

23
 Requirements reviews: Walkthroughs
A requirements walk-through is a meeting where you gather all of
your stakeholders together and walk-through the requirements
documentation, page-by-page, line-by-line, to ensure that the
document represents everyone’s complete understanding of what
is to be accomplished in this particular project.
Simple but valuable enough that it just simply
has to be done.
Why is the walkthrough valuable?
 Your stakeholders will actually read the document and ask questions
about what they don’t understand.
 Your stakeholders will hear the comments that others have, and this
often creates new thoughts on the requirements.
 Your stakeholders will have to look you in the eye and say that
24 everything they need is there.
 Requirements reviews: Inspection
Requirements inspection involves creating a team of inspectors
that should represent different perspectives.
Therefore, a requirements inspection team should include
requirements engineers (authors), design engineers (will do
work based on requirements), and various other stakeholders
(sources of requirements).
Inspection is a formal review because it proceeds in a sequence
of well defined stages. E.g. Fagan's Inspection Process

25
 Translating requirements to alternative forms
In practice, requirements are usually documented in
structured natural language.
 All natural languages are inherently ambiguous.
The requirements are often written in English although
many stakeholders are not fluent in it.
Presenting the requirements as a collection of separate
statements is probably not the best understandable form for
either customers or developers.
It is not considered feasible to maintain several concurrent
representations of requirements because of modifiability
problems.
However, for validating them, rewriting natural language
26
into other forms is considered very useful.
 Translation…
 Requirements may be translated to:
User manual, Visualizations, e.g. diagrams, Lightweight formal
models, Prototypes, Test cases
 User manual
A good manual describes all user-visible functionality in easily
understandable language.
It is still a natural language document, but with all ‘shall’
statements rewritten as if they were already implemented.
It presents requirements in a more tangible and more coherent
form than an SRS.
 Information in the user manual
 Description of the functionality and how it is implemented
 How to install and get started with the system
 Which parts of the system have not been implemented
27
 How to get out of trouble
 Translation…
Visualizations
Visualization is often seen as a way to help people gain insight from
large and complex data sets.
Graphical presentations link individual statements together and
present a coherent picture of a slice of the system.
Decision trees, data flow diagrams, state transition diagrams are
some of the Graphical presentations for visualization.

28
 Translation…
Lightweight formal models
Involves expressing requirements in formal logic and mathematically
using formal models like e.g. Vienna Development Method (VDM).
They have not been widely accepted in requirement engineering
practice.
The methods can be used for partial analysis on partial specifications,
without a commitment to developing and baselining a complete,
consistent formal specification (lightweight way).
i.e. some critical parts of a requirements specification are
translated into a formal model for e.g. validation needs.
Sufficient empirical evidence exists that just the attempt to translate
requirements into a formal model helps to reveal a lot of defects.
After translating, some properties of the partial formal specification
can be automatically verified by software.
29
 Translation…
Prototyping
A prototype makes requirements tangible.
Users, managers, and other non-technical stakeholders usually
find it very difficult to visualize how a written statement of
requirements will translate into an executable software system.
If a prototype is developed to demonstrate requirements, they
find it easier to discover problems and suggest how the
requirements may be improved.
Prototyping based validation steps:


30
 Translation…
Test cases
 A desirable attribute of every requirement statement is that it
should be verifiable, i.e. it should be possible to define one or
more test cases that can check whether the requirement has
been met.
 Even though the tests will be applied to the system only after
implementation, designing tests at an early stage is an effective
way of revealing requirements defects.
 A test case usually tests several related requirements, both
functional and non-functional.
 Therefore, test cases may make the expected system behaviors
clearer to all the stakeholders.
 Test cases designed for validation of requirements may also be
31 only theoretical, e.g. be too expensive to run in practice.