Explorer

Content

Verification and Validation Requirements Matrix (VVRM)

A Verification and Validation Requirements Matrix (VVRM) provides traceability from requirements to the relevant testing and trials results. It forms the basis for decisions on acceptance and ensuring the stakeholder need is met.

The VVRM should include reference to:

User and System Requirements
Evidence and information (Test type, results)
Acceptance criteria and recommendation
Responsibilities
Progress and key milestones.

A principal feature of a VVRM is to provide a tool to manage incremental verification with a definition of each of the incremental test stages and stage criteria invoked against specific requirements.

The following table illustrates an example, giving the Progressive Verification and Validation Stages:

ID	Requirement Statement	Requirement	Architecture	Design	Manufacture	Installation	Integration
n1	The system shall protect the operator from external noise. Maximum dB	Link to URD	Inspection of functional allocation	Computer simulation at Interim and Critical Design Review	Physical test of prototype and first production crew cabin in anechoic chamber (microphone)	Physical test of un-loaded vehicle in field trial (microphone and human-in-loop)	Physical test of loaded vehicle in military exercise (human-in-loop)

This illustrates an extreme example of incremental verification.

Critically select stages according to need and benefit, not opportunity.
A hierarchical VVRM may be constructed to address component and sub-system testing in advance of end-product verification.
The VVRM is an appropriate place to use Technology Readiness Levels (TRLs) and System Readiness Levels (SRLs) and map progressive certification of design.
Use a spreadsheet or database to sort the VVRM and subdivide by test source.

Where progressive testing is to be adopted, identify the dependency of each test on the other LoDs, for example, testing a prototype aircraft will require a trained test pilot, interim sustainability arrangements and possibly test mission plans.

Due to the complexity of managing links between related documentation and information, it is strongly recommended that a Requirements Management Tool such as DOORS is used to maintain an overall audit trail.

A suggested approach is described below.

User Requirement

System Requirement

Result

UR1

The [user] shall…

SR1

The [system] will

Test – Demonstration

Planned – May 07

Responsibility –

Progress -

Test Result – Passed 7 Jun 07

Acceptance Recommendation

References

Determination of V&V criteria in consultation with stakeholders is a matter of deciding what confidence in satisfaction of the requirement is required, and thereby what class of test method is appropriate to deliver that level of confidence.

Risk analysis and cost benefit analysis techniques should be used to inform the decision making.

Factors that influence the selection include:

Where the capability will be deployed.
Safety and security
The need and feasibility to test in a realistic operating environment
The use of simulated environments
The development maturity of the article under test
The use of destructive or non destructive testing
System interfaces
Availability of a suitable test capability, and the MOD's confidence in supplier's test capability
Legal and regulatory requirements
Test duration, and relationship to the acquisition critical path
Test cost
Whether 'probability' is an issue.

The risk that the selected method is not representative and may fail to expose a need for remedial action should be assessed. The potential impact if that risk materialises.

Reliance on testing at the completion of manufacture or integration add risk that remedial action may be too late in the programme for the impact to be within tolerable cost and schedule limits.

Change History