Software Requirement

Engineering

Verification & Validation

Ameer Hamza

1
Requirements Verification and
Validation

 Requirements Validation
 Check that the right product is being built
 Ensures that the software being
developed (or changed) will satisfy its
stakeholders
 Checks the software requirements specification
against stakeholders goals and requirements
 Requirements Verification
 Check that product is being built right
 Ensures that each step followed in the process of
building the software yields the right products
 Checks consistency of the software requirements
specification artefacts and other software
development products (design, implementation, ...)
against the specification
Difference:
Requirements Verification and
Validation

 Requirements Verification and Validation

Techniques
 Simple checks
 Prototyping
 User manual development
 Reviews and inspections
 Model-based (formal) Verification and Validation
Requirements Verification and
Validation (2)

 Help ensure delivery of what the client wants

 Need to be performed at every stage during the
(requirements) process
 Elicitation
 Checking back with the elicitation sources
 “So, are you saying that . . . . . ?”
 Analysis
 Checking that the domain description and requirements are
correct
 Specification
 Checking that the defined system requirement will meet the
user requirements under the assumptions of the
domain/environment
 Checking conformity to well-formedness rules, standards…
Requirements V&V
Techniques
Various Requirements V&V Techniques
• Simple checks
• Traceability, well-written requirements
• Prototyping
• User manual development
• Reviews and inspections
• Walkthroughs
• Formal inspections
• Checklists

10
 Simple Checks
• Various checks can be done using traceability
techniques
• Given the requirements document, verify that all elicitation
notes are covered
• Tracing between different levels of requirements
• Checking goals against tasks, features, requirements…
• Involves developing a traceability matrix
• Ensures that requirements have been taken into
consideration (if not there should be a reason)
• Ensures that everything in the specification is justified

• Verify that the requirements are well written

(according to the criteria already discussed)

11
Requirement Traceability Matrix
(RTM)

 A Requirement Traceability Matrix (RTM)

is a table or matrix that maps the
requirements of a project to the corresponding
design, implementation (code), and testing
artifacts. It ensures that all requirements are
accounted for and properly addressed during
the software development lifecycle.
Prototyping (1)
• Excellent for validation by users and customers
• More accessible than specification
• Demonstrate the requirements and help stakeholders
discover problems
• Come in all different shapes and sizes
• From paper prototype of a computerized system to formal
executable models/specifications
• Horizontal, vertical
Horizontal Prototype:
Clarify scope and requirements
Demonstrates outer layer of human interface only, such as
windows, menus, and screens
Vertical Prototype
Refine database design, test key components early
Demonstrates a working, though incomplete, system for
key functions

14
Evolutive, throwaway

 Throwaway or Rapid Prototyping refers to the

creation of a model that will eventually be
discarded rather than becoming part of the
final delivered software. After preliminary
requirements gathering is accomplished, a
simple working model of the system is
constructed to visually show the users what
their requirements may look like when they
are implemented into a finished system.
 The main goal when using Evolutionary
Prototyping is to build a very robust prototype
in a structured manner and constantly refine
it.
User Manual Development

 What is a User Manual?

A user manual is a comprehensive document that
provides detailed instructions on how to use,
install, and resolve issues with a system.
 User Guidance:
It helps users understand the basic and advanced
features of the system, enabling them to use it
effectively.
 Verification and Validation:
During the development of the user manual, errors
or ambiguities in the requirements specification often
surface, allowing for their early correction.
16
Reviews and Inspections (1)

 A group of people read and analyze requirements,

look for potential problems, meet to discuss the
problems, and agree on a list of action items needed
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
 Need appropriate checklists (must be developed if necessary
and maintained)

17
Reviews and Inspections (2)
 Different types of reviews with varying degrees of formality exist
(similar to JAD vs. brainstorming sessions)
 Reading the document

 Simple reading by someone other than the author to understand the

content without providing feedback.
 Example: A project manager reads a requirement document for
understanding.
 Reading and approval (sign-off)

 After reading, the reviewer formally approves the document or work,

indicating it meets necessary standards.
 Example: A QA lead signs off on code after reviewing it.
 Walkthroughs
 Informal, high-level review led by the author or expert to explain the
work and ensure others understand it.
 Example: A senior developer presents the system design to the team
for clarification and understanding.
 Formal inspections
 A detailed, structured review with specific roles and preparation,
focusing on finding errors and ensuring quality.
18
 Example: A Fagan Inspection is conducted on a software design
Typical Review / Inspection Steps (1)
 Plan review
 The review team is selected and a time and
place for the review meeting is chosen
 Distribute documents
 The requirements document is distributed to

the review team members

19
Typical Review / Inspection Steps (2)
 Prepare for review
 Individual reviewers read the requirements to
find conflicts, omissions, inconsistencies,
deviations from standards, and other problems
 Hold review meeting
 Individual comments and problems are

discussed and a set of action items to address

the problems is established

20
Typical Review / Inspection Steps (3)
 Follow-up actions
 The chair of the review checks that the agreed
action items have been carried out
 Revise document
 Requirements document is revised to reflect

the agreed action items

 At this stage, it may be accepted or it may be

re-reviewed

21
Review Team

 Reviews should involve a number of

stakeholders drawn from different
backgrounds
 People from different backgrounds bring different
skills and knowledge to the review
 Stakeholders feel involved in the RE process and
develop an understanding of the needs of other
stakeholders
 Review team should always involve at least a domain
expert and a user

22
Review – Problem Categorization

 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
 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 constraints on the system
 Stakeholders must be consulted to decide how to make the
requirement more realistic

23
Pre-Review Checking

 Reviews can be expensive because they involve many people

over several hours reading and checking the requirements
document
 We can reduce this cost by asking someone to make a first
pass called the pre-review
 Check the document and look for straightforward problems

such as missing requirements (sections), lack of

conformance to standards, typographical errors, etc.

24
Fagan Inspection (1)

 Formal and structured inspection process

Note: the boss is not

involved in the process!
25
Fagan Inspection (2)

 Characterized by rules on who should participate, how

many reviewers should participate, and what roles
they should play
 Not more than 2 hours at a time, to keep participants focused
 3 to 5 reviewers
 Author serves as the presenter of the document
 Metrics are collected
 Important: the author’s supervisor does not participate in the
inspection and does not have access to data
 This is not an employee evaluation
 Moderator is responsible for initiating the inspection, leading
the meeting, and ensuring issues found are fixed
 All reviewers need to prepare themselves using checklists
 Issues are recorded in special forms

26
Fagan Inspection (3)

 The inspection meeting is like a brainstorming

session to identify (potential) problems
 Re-inspection if > 5% of the document change
 Some variants are less tolerant... too easy to
introduce new errors when correcting the previous
ones!

27
Requirements Review Checklists (1)

 Both verification and validation depend heavily

on thorough requirements reviews.
 Verification Checklist:
 Ensures requirements are complete,
unambiguous, and feasible within the given
constraints.
 Validation Checklist:
 Ensures the requirements meet the needs of
stakeholders and are aligned with the project's
objectives.

28
Key Components of a
Requirements Review Checklist

• For Verification:
• Comprehensibility: Are the requirements clearly
defined and understandable?
• Feasibility: Can the requirements be implemented
with available resources and technology?
• Consistency: Do the requirements conflict with
each other or other documents?
• Testability: Can the requirements be verified
through testing or other means?
• For Validation:
• Stakeholder Alignment: Do the requirements
reflect the true needs of stakeholders?
• Traceability: Can the requirements be traced to a
specific stakeholder or business need?
• Relevance: Are the requirements still relevant to the
project's goals?