REQUIREMENT ENGINEERING

JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS

CHAPTER FIVE

REQUIREMENTS VALIDATION
Topics we will cover
2

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 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)
4

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
5

During the requirements validation process, different types

of checks should be carried out on the requirements in the
requirements document. These checks include:
• Clarity checks
• Consistency checks
• Completeness checks
• Accuracy checks
• Relevance checks
• Traceability Checks
 Requirements checking
6

Clarity checks: Requirements should be written clearly and

unambiguously, ensuring precise language and terminology. All
terms must be uniquely defined, with no vague or subjective
descriptions that could lead to multiple interpretations.

Consistency checks: Requirements should use uniform

terminology throughout the document, avoiding conflicting or
inconsistent terms. The document formatting should also be
consistent, with no deviations in style or structure.

Completeness checks :Requirements should include all

necessary details to avoid missing critical aspects. They must
comprehensively cover all relevant scenarios and fields, ensuring
no gaps in the document.
 Requirements checking
7

Accuracy checks: Requirements should be factually correct and accurately

represented. They must align with technical specifications, ensuring no
discrepancies or mismatches that could impact implementation.

Relevance checks: Requirements should align with business objectives,

stakeholder needs, and project goals, ensuring they remain relevant to both
current and future contexts. They must reflect market trends and provide
clear value to users, supporting industry standards and best practices.

Traceability checks: Each requirement should have a unique identifier to

ensure easy tracking and referencing throughout the project lifecycle,
avoiding duplication or loss of requirements.
 Requirements checking
8

Discussion

R1: Employees who earn less than 2000 ETB should not be taxed

R2: For all Employees tax should be deducted from their salaries

How would you assess the overall quality of these requirements in

terms of clarity, consistency, completeness, accuracy, relevance,
and traceability?
 Check Results for Requirements R1 and R2
9

Clarity Checks:

• R1: Clear and unambiguous. Specifies a threshold (less

than 2000 ETB) for tax exemption.
• R2: Ambiguous when considered with R1. It states that
tax applies to "all employees" but does not account for the
exception in R1.
• Result: Potential ambiguity between R1 and R2 due to
conflicting interpretations.
 Check Results for Requirements R1 and R2
10

Consistency Checks:

• Uniformity in Terminology:
• "Employees" is used consistently in both requirements.
• Potential conflict between "should not be taxed" (R1)
and "tax should be deducted" (R2).
• Formatting: Both requirements follow consistent
structure and style.
• Result: Logical inconsistency between R1 and R2 needs
resolution.
 Check Results for Requirements R1 and R2
11

Completeness Checks:

• All Necessary Details:

• R1 specifies a threshold but does not clarify what
happens at exactly 2000 ETB.
• R2 does not explicitly address exceptions or scenarios
where employees are exempt.
• Coverage of Scenarios: Missing clarity on scenarios
such as employees earning exactly 2000 ETB or
additional exemptions.
• Result: Incomplete. Key scenarios and details are
missing.
 Check Results for Requirements R1 and R2
12

Accuracy Checks:

• Correctness of Information: Both requirements lack

information on applicable tax laws or regulations to
validate their accuracy.
• Alignment with Technical Specifications: No
reference to underlying systems or policies for deducting
taxes.
• Result: Accuracy cannot be confirmed due to insufficient
context.
 Check Results for Requirements R1 and R2
13

Relevance Checks:
• Alignment with Business Goals: Aligns with a goal of
managing employee taxation but conflicts may impede
implementation.
• Stakeholder Needs: Likely addresses tax rules for
employees but gaps may leave stakeholder expectations
unmet.
• Current and Future Context: Lack of flexibility for
future tax rule changes.
• Market and Industry Trends: Does not reflect best
practices for clarity in taxation policies.
• User Value: Potential confusion reduces value for HR
and payroll teams.
• Result: Relevance is reduced due to conflicts and gaps
 Check Results for Requirements R1 and R2
14

Traceability Checks:

• Unique Identifiers: Both R1 and R2 have unique IDs.

• Result: Passes traceability check.
 Revised Requirements
15

R1: Employees earning less than 2000 ETB per month are
exempt from income tax deductions.

R2: Employees earning 2000 ETB or more per month will

have tax deducted from their salaries based on applicable tax
regulations.
 Validation Inputs and Outputs
16

Requirements
document List of problems

Organisational Requ irements

knowledge validation Agreed actions

Organisational
standards
 Validation inputs
17

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
18

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
19

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
20

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
21

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
22

➢ 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
23

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
24

Inspections

Desk-Checks

Walkthroughs

Prototypes
 Inspections
25

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
26

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).

Critical Success Factors: Benefit:

➢ Commitment of the ➢ Obtain feedback from
participants individual reviewers
➢ Coverage of all the aspects Effort:
➢ Not recommended for critical ➢ Medium
artefacts
 Walkthroughs
27

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 Effort:
of the artefact ➢ Medium-Low
 Prototypes
28

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?

29