Chapter 5

Requirement Validation

By Yengusie D.
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
Introduction
 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 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,

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 and how
they are represented.
 Concerned with checking the document that has
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

Inputs & Outputs of Requirement
Validation
List of problems to be
resolved
Some “typical” problems:
Requirements - conformance to
standards
document - ambiguous wording
Organizational
- error in the actual
Standard model
Input
Organizational Outpu
- undetected conflicts
Knowledge
s ts
List of agreed actions
Requirements
Validation
 Inputs and Outputs of Requirement
Validation…
Requirements document
Should be a complete version of the document, not
an unfinished draft.
Formatted and organized according to organizational
standards
Organizational knowledge
Knowledge, often implicit, of the organization which
may be used to judge the realism of the
requirements
Organizational standards
Local standards e.g. for the organization of the
requirements document
Problem list
List of discovered problems in the requirements
document
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
There is always a natural tendency to rush
the validation process so that system
development can be started with out further
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 base lining the SRS.
Include requirements validation activities as
discrete tasks in your project plan.

 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.
Also, if two or more persons accomplish rewriting
independently and the results are significantly
different, this also points to problems (mainly
ambiguity) in the document.
 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
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.
 Requirements reviews process
..
 Requirements reviews process…
Plan the Review (with a moderator) - s election of
review team members, time and place
 Gain agreement on problem definition and problem
severity code
 Determine the condition or criteria for “acceptance”
or “rejection/re-review” of the document
Distribution of Requirements Document and any
other information
Review Preparation - Review team members read
the document for problems
 Record down questions and suspected problem
areas
Hold the Review “meeting” - Discuss the discovered
problems
 Agree on the severity of the problems and action
plan to resolve the problems
Moderator (review chair) - follows up to ensure
 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
 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 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
Not only a list of review
Checklist-based
questions but also a collection of
Defect-based
procedures to follow is provided,
Perspective-based which describe the steps to be
Scenario-based accomplished in order to answer
Pattern-based the questions.
Ad-hoc reading – no guidance is provided,
reviewers use only their own knowledge and
experience to identify defects.
 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.
Essential tool for an effective review process – list
common problem area and guide reviewers
Usually the only alternative that is discussed in
requirements engineering books.
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
Checklist-based Reading
Techniques…
Checklist-based Reading
Techniques…
(Wiegers, 2003)
Checklist-based Reading
Techniques…
(Wiegers, 2003)
 Defect-based Reading
Techniques
Each procedure is aiming for detecting a
particular type of defects different procedures are
usually assigned to different reviewers.
Examples of defects that could be detected includes
data type consistencies, incorrect functionalities,
ambiguities or missing functionality.
Defect-based reading is a technique which is less
overlapping, more systematic and more distinct
than ad-hoc & check list based reading techniques.
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.”
 Defect-based Reading

Techniques…

Defect-based procedure examp

 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
 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:
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

Each requirements pattern can be represented by a

formal validation frame that describes
what a part of a scenario should look like to make the
pattern applicable, and
what should then be searched for in the requirements
document.
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 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
 Translating requirements to
alternative forms
In practice, requirements are usually documented
in structured natural language.
 Allnatural 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 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.
A quality SRS should provide enough information
needed for drafting the user manual.
If the writer finds this (partially) impossible, this
points to some problems with the SRS that must be
investigated.
 Translation…
After the draft is finished, it is to be reviewed by
targeted stakeholders.
However, a user manual is obviously only a partial
view of requirements since it presents only
functionality visible to end users (not performance
or other characteristics).
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.
Translation…
Lightweight formal models
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.
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:
choose prototype testers
develop test scenarios
execute scenarios
document problems - using a problem reporting tool
 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
only theoretical, e.g. be too expensive to run in practice.
Tracing requirements:- shows what code and design components
correspond to specific requirements, so that developers can test only
those requirements or sections to understand whether they work. This
can help catch and fix bugs at an earlier stage of development and to
locate a problem within the coding.
Thank
you