Design Verification & Validation Process

Design Verification

Design Verification is a method to confirm, by examination and by providing evidence, that the output of a designed software product meets its input specifications. The goal of the design verification process during software development is to ensure that the designed software product is the same as what was specified.

Design input is any physical and performance requirement that is used as the basis for the design. Design output is the result of each design phase and of the total design effort. In regulated industries such as medical devices, the final design output becomes the basis for the device master record, which is why design-control vocabulary appears so often in verification documentation.

In practice, verification compares two sets of documents: the specifications, standards and constraints that went in, against the drawings, code and test instructions that came out. Every mismatch between them is a verification finding.

Design Validation

Verification proves internal consistency. Validation asks the harder question of whether the specification described the right product in the first place.

Design Validation is a process of evaluating the software product against the exact requirements of end-users or stakeholders. The purpose of design validation is to test the software product after development to confirm that it meets those requirements when it is used in the user’s own environment.

Validation is concerned with demonstrating the consistency and completeness of a design with respect to user needs. This is the stage where you actually build a version of the product and validate it against the user requirements.

The banner below labels the two halves of the activity as they are usually presented in design records.

The diagram that follows shows the design validation process itself, from user needs through to the validated product.

The purpose is to prove with objective evidence that the product satisfies the documented user needs. Objective evidence is simply physical proof of the output — an image, a text file, an audio file or a signed report — that shows the procedure was actually carried out.

Through that objective evidence, the process consistently examines whether the product meets the predefined requirements. It involves testing activity, inspection, analysis and similar techniques, which is why validation usually draws on system testing and user acceptance testing rather than on unit-level checks.

Difference between Design Verification and Validation

There are always misconceptions between verification and validation. They are different activities, and both are performed at every stage of the development process rather than at a single milestone.

A useful shortcut: verification is mostly static work against documents, while validation is mostly dynamic testing against a running build.

Design Verification Process

The verification process runs in five stages, and each one produces an artefact that the next stage depends on.

Identification and preparation:

• While a specification is being developed, verification activity is identified in parallel. This lets the designer make sure the specification is actually verifiable, so a test engineer can start on detailed test plans and procedures. Any change to the specification must be communicated.
• Identify the best approach for conducting verification and define the measurement methods, required resources, tools and facilities.
• The completed verification plan is reviewed with the design team to surface issues before the plan is finalised.

Planning:

• Planning for verification is a concurrent activity with the core and development teams. It occurs throughout the project life cycle and is updated whenever design inputs change.
• During this phase, the software or system under test is documented in scope.
• A preliminary test plan is written and then refined. The plan captures the critical milestones that reduce project risk.
• Tools, test environment and development strategy are selected, and the requirements to be confirmed through inspection or analysis are identified.

Developing:

• Test case development coincides with the SDLC methodology the project team has implemented. A variety of test methods are identified at this stage.
• The design inputs must be developed so that even the simplest verification activities are unambiguous and verifiable.
• Verification time is reduced when similar concepts are verified in sequence, because the output of one test can be reused as the input for a subsequent test.
• Traceability links are created between test cases and their corresponding design inputs, to ensure that every requirement is tested and that the design output meets the design inputs.

Execution:

• The test procedures created during the development phase are executed in accordance with the test plan and followed strictly during the verification activity.
• If invalid results occur, or if any procedure needs modification, the changes must be documented and formally approved.
• Any issue found is logged as a defect through the usual defect management process.
• A traceability matrix is created to verify that every design input identified in the verification test plan has been tested, and to determine the pass ratio.

Reports:

• This activity is performed at the end of each phase of verification execution.
• The design verification report gives a detailed summary of the verification results, including configuration management, the results for each type of testing and the issues found during the verification activity.
• A design verification traceability report is created between requirements and the corresponding test results, to confirm that all requirements were tested and that appropriate results were recorded.
• Any non-conformance is documented and appropriately addressed.
• Reviews are carried out on completion of the design verification activity and the outputs are formally approved.

Design Validation Process

Validation has no equally rigid sequence. Instead it draws on a small set of accepted methods, and a project normally uses more than one of them.

• Comparison with equivalent designs. Some designs may be validated by comparing them with similar equipment serving a similar purpose. This is particularly relevant when validating configuration changes to existing infrastructure, or standard designs that are being incorporated into a new system or application.
• Demonstration and inspection. Either or both may be used to validate requirements and other functionality of the product.
• Analysis. The design can be analysed through mathematical modelling or a simulation that recreates the required functionality.
• Testing. Tests are performed on the final design to validate the ability of the system to operate as specified, which is where functional testing and non-functional testing meet the user requirements.
• Documentation. The test plan, execution and results should be documented and maintained as part of the design records. Validation is, in the end, the collected results of all validation activities.
• Equivalence justification. When equivalent products are used in the final design validation, the manufacturer must document the similarity and any difference from initial production.

Example

A short worked example makes the distinction concrete.

• Take a simple product: a waterproof watch.
• The product requirement document might state that “the watch must be waterproof during swimming”. That is the user need, and it is what validation is measured against.
• The design specification might state that “the watch should function even if the user swims for a prolonged time”. That is the design input, and it is what verification is measured against.
• The test results should confirm that the watch meets these requirements. If they do not, redesign iterations continue until it does.

Note how a watch could pass verification and still fail validation. If the specification defines a prolonged swim as fifteen minutes and real swimmers stay in the water for an hour, the design output matches its input perfectly and still fails the user.

Advantages of Design Validation and Verification

Running both activities continuously, rather than as a gate at the end, is what produces the benefits below.

• Designs can be monitored continuously, which makes it possible to meet the user-defined requirements at every stage.
• Validating the design points out the difference between how the functionality works and how it is expected to work.
• Documenting the validation procedures makes the functionality easy to understand later, whenever a change or enhancement is made.
• Development time is consistently reduced and productivity improves, which helps deliver the product as expected.
• The process defines the range and scope of each validation method that has to be employed.
• Validation can be carried out using detailed design data that represents the final user requirements.
• Any difference between the outcome and the user need documents is captured rather than lost.
• Changes to a validated design trigger a revalidation activity, so the record never drifts away from the product.
• Documenting every activity that occurs during validation is what adequately proves the design meets the user requirements.

Design verification and validation are therefore best planned inside the wider software testing life cycle and mapped against the other types of software testing, rather than treated as a separate compliance exercise.

FAQs