N

&

&
O
E
I
N
I
T
N
M
A
S
O
A
C
I
J
I
:
T
IF A B Y
R
D
E
E LID
V A ENT
V RES

IT

5
/1
4
2
5/

14MC009

CONTENTS
General Intro to V & V
Verification activities
Verification of requirements
Verification of HL design
Verification of data design
Verification of architectural design
Verification of UI design
Verification of LL design
Intro to validation activities.

5
/1
4
2
5/

14MC009

WHY IS V & V NECESSARY

The designers and implementers of computer based systems are
human
They will make errors.
These errors will result in undetected faults in delivered systems.
Faults can result in dangerous failures causing loss of life, financial
loss or property damage.
The mission of V&V is therefore to find and correct errors as early as
possible in the development life cycle thus preventing the delivery of a
faulty product to a customer.

5
/1
4
2
5/

14MC009

HOW MUCH V&V IS REQUIRED?

The level of effort applied to V&V is a function of the criticality of the
software or systems product.
That is, the risks involved if the system fails.
At one end of the scale the software controlling the shutdown of a
nuclear reactor will likely be thoroughly verified and validated by an
independent organisation.
At the other end of the scale, a website providing a company brochure
will likely have no formal verification and validation applied

5
/1
4
2
5/

14MC009

WHAT DO V&V PEOPLE DO?

V&V is carried out in parallel with the software/system
development process.
V&V activities include traceability analysis, evaluation, review,
inspection, assessment, and testing.

5
/1
4
2
5/

14MC009

Validation:

Are we building the

right system?

Does our problem

statement accurately
capture the real
problem?
Did we account for the
needs of all the
stakeholders?

5
/1
4
2
5/

Verification:
Are we building the system
right?
Does our design meet the
spec?
Does our implementation
meet the spec?
Does the delivered system do
what we said it would do?
Are our requirements
models consistent with one
another?

14MC009

VERIFICATION & VALIDATION

It is a whole life--cycle process cycle process -- V & V must be
applied at each stage in V & V must be applied at each stage in
the software process. the software process.
Has two principal objectives
The discovery of defects in a system;
The assessment of whether or not the system is useful and
useable in an operational situation.

5
/1
4
2
5/

14MC009

VERIFICATION & VALIDATION

Verification and validation should establish confidence that the
software is software is fit for purpose.
This does NOT mean completely free of defects.
Rather, it must be good enough for its intended use and the
type of use will determine the degree of confidence that is
needed.

5
/1
4
2
5/

14MC009

GOALS OF VERIFICATION
EVERYTHING MUST BE VERIFIES: In principle, all the
products of these processes must be verified
RESULTS OF VERIFICATION MAY NOT BE BINARY
EVEN IMPLICIT QUALITIES MUST BE VERIFIED:
the qualities desired in the software are explicitly stated in the
SRS. but those requirements which are implicit and not
mentioned anywhere must also be verified.

5
/1
4
2
5/

14MC009

V TESTING
Start
Development

Start Testing
verification

Define specifications

Check specifications
Check design

design
coding
validation
Implementation

Unit test
System test

integrate

Testing

Tested
System

5
/1
4
2
5/

14MC009

ABOUT V- DIAGRAM
Testing can be implemented in the same flow as for the SDLC
Testing can be broadly planned in two activities, verification &
validation
Testing must be performed at every step of SDLC
V- diagram supports the concept of early testing
V- diagram supports parallelism in the activities of developer
& testers
Testers should be involved in the development process

5
/1
4
2
5/

14MC009

End user

Requirement
gathering

Requirement
Specification

Functional
design, high
level
design(HLD)
Coding

VERIFICATION & VALIDATION ACTIVITIES

SDLC
PHASES
15
14MC009
4/

2
5/

V & V ACTIVITIES
V & V activities can be understood in the form of a diagram as
shown before
For this, first we need to understand SDLC phases.
After this V & V activities in those SDLC phases will be
described.
1. Requirement Gathering- the need of the user are gathered
and translated into a written set of requirements.
2. Requirement specifications-all the user requirement are
specified in developers terminology and are prepared in the
form of a document- SRS

5
/1
4
2
5/

14MC009

3. Functional design or High level designo Process of translating user requirements into a set of external
interfaces.
o The HL design is prepared with SRS
o In HLD the software system architecture is prepared and
broken into independent modules
o HLD document cannot be given to a programmer for coding
as it provides macro level details.
4. Internal design or low level design
Analyst prepares micro level design document
This doc design each and every module
5. Coding
If a LLD document is prepared for every module than it is easy
to code the module

5
/1
4
2
5/

14MC009

V
E
R
I
F
I
C
A
T
I
O
N

End
user

V & V Diagram

Installation
testing

Requirement
gathering

Build
acceptance
test plan

Acceptance
testing

Requirement
specification

Build system
test plan

System testing

High level
design

Build function
test plan

Function/inte
gration testing

Low level
design

Build unit test

plan

Unit
validation
testing

5
/1
4
2
5/

Coding

14MC009

V
A
L
I
D
A
T
I
O
N

VERIFICATION ACTIVITIES
The following verification activities have been identified :
Verification of requirements & objectives
Verification of high level design
Verification of low level design
Verification of coding (unit verification)

5
/1
4
2
5/

14MC009

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
5
/1
4
2
5/

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 and other
software development
products (design,
implementation, ...)
against the specification
14MC009

HOW TO VERIFY REQUIREMENTS &

OBJECTIVES ?
Requirements & objectives have high potential of detecting
bugs : requirements must be verified
Testers use SRS for verification of objectives
SRS can be verified if and only if. Every requirement stated
herein can be verified
Requirement can be verified if & only if there is some
procedure to check that the software meet its requirement

5
/1
4
2
5/

14MC009

Following are the Points against which every

requirement in SRS should be verified:
1.
2.
3.
4.
5.
6.

5
/1
4
2
5/

CORRECTNESS
UNAMBIUOUS
CONSISTENT
COMPLETENESS
UPDATION
TRACEABILITY
BACKWARD TRACEABILITY
FORWARD TRACEABILITY

14MC009

VERIFICATION OF HIGH LEVEL DESIGN

All the requirements mentioned in the SRS document are addressed in
this phase & work in the direction of designing the solution.
The architecture & design is documented in another document called the
software design document(SDD)
Like the verification of requirements the tester is responsible for two
parallel activities in this phase as well:
The tester verifies the high level design. Since the system has been
decomposed in a number of sub-systems or components, the tester should
verify the functionality of these components. The tester verifies all the
components and their interfaces are in tune with requirements of the user

5
/1
4
2
5/

14MC009

 The tester also prepares a function test plan which is based on the
SRS. This plan will be referenced at the time of function testing.
The tester also prepares an integration test plan which will be
referred at the time of integration testing.

5
/1
4
2
5/

14MC009

HOW TO VERIFY HIGH LEVEL DESIGN

High level design takes the second place in SDLC, wherein
there is a high probability of finding bugs.
HLD must be verified as a next step in early testing. unless the
design is specified in a formal way, design cannot be verified.
If a bug goes undetected in the high level design phase, then
its cost of fixing increases with every phase. Therefore,
verification for high level design must be done very carefully.

5
/1
4
2
5/

14MC009

High level design is divided into three parts:

Data design
It creates a model of data or information that is represented at
high level of abstraction.
The structure of data has always been an important part of
software design
At the program component level the design of data structure
and the associated algorithms required to manipulate them is
essential to create high quality application.

5
/1
4
2
5/

14MC009

Architectural design
The phase of the design of computer architecture and
software architecture can also be referred to as high-level design.
The baseline in selecting the architecture is that it should realize all
which typically consists of the list of modules, brief functionality of
eachmodule,their interface relationships, dependencies, database
tables, architecture diagrams, technology details etc. The
integration testing design is carried out in the particular phase.
It focuses on the representation of the structure of software
components, their properties and interactions .

5
/1
4
2
5/

14MC009

Interface design
It creates an effective communication medium between the
interface of different software modules , interfaces between the
software system and any other external entity and interfaces
between a user and the software system.

5
/1
4
2
5/

14MC009

VERFICATION OF DATA DESIGN

Points considered for this verification are as follows:
Check whether the sizes of data structure have been estimated
appropriately.
Check the provisions of overflow in a data structure.
Check the consistency of data formats with the requirements.
Check whether data usage is consistent with its declaration.
Check the relationship among data objects in data dictionary.
Check the consistency of data warehouses with the
requirements specified in SRS.

5
/1
4
2
5/

14MC009

VERIFICATION OF ARCHOTECTURAL
DESIGN
Points considered for this verification are as follows:
Check that every functional requirement in the SRS has been
take care of in this design.
Check whether all exceptions handling conditions have been
taken care of.
Verify the process of transition mapping and transaction
mapping, used for the transition from requirement model to
architectural design
Check the inter-dependance and interface between the
modules.

5
/1
4
2
5/

14MC009

It takes patience to listen

It takes skill to pretend youre listening

5
/1
4
2
5/

14MC009