REQUIREMENT ENGINEERING

JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS

CHAPTER FIVE

REQUIREMENTS VALIDATION
 Topics we will cover

 The need for requirements validation

 Requirements checking

 Resources needed for requirements validation

 Techniques for validating requirements

 Introduction
3
 “A correct requirements document is not necessarily the right

requirements document”
 Requirements validation is the process of certifying the requirements

document for correctness against the user's intention.

 Validation ensures that the requirements:

 Achieve stated business objectives

 Meet the needs of stakeholders
 Validating at the requirements can help to avoid fixing expensive bugs

after the software has been developed.

Validation (in requirements engineering)

 The cost of fixing a requirements problem by making a system

change is usually much greater than repairing design or coding
errors.
 Validation denotes checking whether inputs, performed
activities, and created outputs (requirements document) of the
requirements engineering core activities fulfil defined quality
criteria.
 Validation is performed by involving relevant stakeholders, other
requirement sources (standards, laws, etc.) as well as external
reviewers, if necessary.
 Requirements checking

 During the requirements validation process, different

types of checks should be carried out on the
requirements in the requirements document. These
checks include:
 Validity checks
 Consistency checks
 Completeness checks
 Realism checks
 Verifiability checks
 Non-ambiguity checks
 Traceability Checks
 Modifiability Checks
 Requirements checking

 Validity checks: These check that the requirements

reflect the real needs of system users. Because of changing
circumstances, the user requirements may have changed
since they were originally elicited.
 Consistency checks: Requirements in the document
should not conflict. That is, there should not be
contradictory constraints or different descriptions of the
same system function.
 Completeness checks :The requirements document should
include requirements that define all functions, features and
the constraints intended by the system user.
 Requirements checking

 Realism checks: By using knowledge of existing technologies, the

requirements should be checked to ensure that they can be
implemented within the proposed budget for the system.
 These checks should also take account of the budget and
schedule for the system development.
 Verifiability: To reduce the potential for dispute between
customer and contractor, system requirements should always be
written so that they are verifiable.
 This means that you should be able to write a set of tests that can
demonstrate that the delivered system meets each specified
requirement.
 Non-ambiguity checks: ambiguities can be introduced in a
requirements document , especially when natural language is used.
 Requirements checking

 Traceability Checks: Ensures that the source of each

requirement in the requirement document must be clear.

 Modifiability Checks: Ensures that the source of each

requirement in the requirement document should be mapped.

“The main- problem of requirements validation is that there is

no existing document which can be a basis for the validation”
 Requirements checking
9

Discussion

R1: Employees who earn less than 2000 ETB should not be taxed
R2: For all Employees tax should be deducted from their salaries
The document is inconsistent: Consistent checking
 Requirements checking
10

Discussion

 when the furnace temperature reaches 200 oC or the

environment temperature falls below 5 oC and the water valve is
turned on then the oil valve must be turned on

Do you think that putting the above requirement in an SRS

document leads to requirements problems? If yes, discuss which
requirement checking is suitable for solving it?
 Requirements checking
11
 when the furnace temperature reaches 200 oC or the
environment temperature falls below 5 oC and the water valve is
turned on then the oil valve must be turned on
The above requirements statement is ambiguous because it can be
interpreted in two different ways, i.e. as
1.when the furnace temperature reaches 200 oC and the water
valve is turned on, the oil valve should be turned on. When the
environment temperature falls below 5 oC and the water valve is
turned on then the oil valve should be turned on
2. when the furnace temperature reaches 200 oC the oil valve must
be turned on. When the environment temperature falls below 5 oC
and the water valve is turned on, the oil valve must be turned on.
 Validation Inputs and Outputs

Requirements
document List of problems

Organisational Requ irements

knowledge validation Agreed actions

Organisational
standards
 Validation inputs

 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
 Validation outputs

 Problem list
 List of discovered problems in the requirements document
 Agreed actions
 List of agreed actions in response to requirements problems.
Some problems may have several corrective actions; some
problems may have no associated actions
 The 6 Principles of Validation

 First Principle: Involving the Right Stakeholders

 Ensure that relevant company-internal as well as relevant

external stakeholders participate in validation.
 Pay attention to the reviewers’ independence and appoint
external, independent stakeholders, if necessary.
 Second Principle: Defect Detection vs. Defect Correction

 Separate defect detection from the correction of the

detected defects.
 The 6 Principles of Validation

 Third Principle: Leveraging Multiple Independent Views

 Whenever possible, try to obtain independent views that can be

integrated during requirements validation in order to detect
defects more reliably.
 Fourth Principle: Use of Appropriate Documentation Formats

 Consider changing the documentation format of the

requirements into a format that matches the validation goal and
the preferences of the stakeholders who actually perform the
validation.
 The 6 Principles of Validation

 Fifth Principle: Creation of Development Artefacts during Validation

 If your validation approach generates poor results, try to support

defect detection by creating development artefacts such as
architectural artefacts, test artefacts, user manuals, or goals and
scenarios during validation.
 Sixth Principle: Repeated Validation

 Establish guidelines that clearly determine when or under what

conditions an already released requirements artefact has to be
validated again.
 Resources needed for requirements
validation

 Requirements Document
 Analyst
 Budget

“The main- problem of requirements validation is

that there is no existing document which can be a
basis for the validation”
 Resources needed for requirements
validation

 Plan review: The review team is selected and a time and place for
the review meeting is chosen.
 Distribute documents: The requirements document and any other
relevant documents are distributed to the review team members.
 Prepare for review: The individual reviewers read the
requirements document to identify conflicts, omissions,
inconsistencies, deviations from standards and any other problems.
 Hold review meeting :The individual comments and problems are
discussed and a set of actions to address the problems is agreed.
 Follow-up actions: The chair of the review checks that the agreed
actions have been carried out
 Revise document :The requirements document is revised to reflect
the agreed actions. At this stage, it may be accepted or it may be re-
reviewed
 Techniques for Validating Requirements

 Inspections
 Desk-Checks
 Walkthroughs
 Prototypes
 Inspections

 This technique involves reviewing the requirements

document with a group of experts, looking for errors,
inconsistencies, and missing information.

Involved roles: Critical Success Factors:

 Organizer  Commitment of the
 Moderator organization
 Author  Size and complexity of the
 Inspectors inspected artefacts
 Minute-taker  Number and experience of
the inspectors
Benefit: Effort:
 Detailed checking of the  Medium-High
artefacts
 Desk-Checks

 The author of a requirement artefact distributes the

artefact to a set of stakeholders.
 The stakeholders check the artefact individually.
 The stakeholders report the identified defects to the
author.
 The collected issues are discussed in a group session
(optional). Benefit:
Critical Success Factors:  Obtain feedback from
 Commitment of the individual reviewers
participants
 Coverage of all the aspects Effort:
 Not recommended for critical  Medium
artefacts
 Walkthroughs
 This technique involves a group of experts reviewing the
requirements document and walking through it line by line,
discussing any issues or concerns that arise.
 A walkthrough does not have formally defined procedure and
does not require a differentiated role assignment.
 Checking early whether an idea is feasible or not.

 Obtaining the opinion and suggestions of other people.

 Checking the approval of others and reaching agreement.

Critical Success Factors: Benefit:

 Involving stakeholders from  Validation of ideas and
different contexts sketches
 Comprehensible presentation of Effort:
the artefact  Medium-Low
 Prototypes

 A prototype allows the stakeholders to try out the requirements

for the system and experience them thereby.
 Develop the prototype (tool support).

 Training of the stakeholders.

 Observation of prototype usage.

 Collect issues.
Benefit:
 Highly effective defect detection
 Proof of feasibility
Critical Success Factors:
 Level of detail of the
prototype
Effort:
 Quality of the review
Very- Very High
Any Question?