Verification and Validation
Verification and Validation tests the distinction between conformance and fitness for use, and the planning discipline that makes both credible. Questions cover verification methods, validation in the operational environment, V&V planning, traceability, integration, regression, and problem reporting. The exam expects precise use of terms: verification answers whether we built the system right against specified requirements; validation answers whether we built the right system against stakeholder needs and intended use.
Verification
Verification confirms that a work product conforms to its specified requirements. Methods are inspection, analysis, demonstration, and test. Each requirement should have a planned method, verification criterion, and level (component, subsystem, system). Verification can apply to requirements, design, and the delivered system. Independence of the verifier strengthens confidence; a developer test is still verification if it is rigorous and evidence-based.
Validation
Validation confirms that the system, when used, satisfies stakeholder needs in the intended environment. It uses operational scenarios, user involvement, and acceptance criteria derived from stakeholder requirements, not just system requirements. Validation often occurs at the end of integration but should be planned from the start through prototypes, models, and early user evaluation.
Worked example
A delivery drone has a parachute recovery system. Verification: 'The parachute shall deploy within 1.5 seconds of a commanded cutoff at 120 m altitude.' A controlled-range test with instrumentation proves the requirement. Validation: 'The recovery system shall protect people and property during delivery operations in the approved urban corridor.' That requires representative wind, failure modes, operator response, and regulatory acceptance, not just deployment time. Reasoning: a system can pass every requirement and still fail validation if the requirements missed a need or an operational condition.
Traps that cost marks
Using test as a synonym for both verification and validation; validating only at the end; writing requirements without a verification method; treating a successful demonstration as proof of all performance thresholds; ignoring regression after design changes; accepting traceability as a document rather than evidence linking needs, requirements, and results.