What is the difference between verification and validation?
Verification confirms the software was built correctly — that the implementation meets its specified requirements. Validation confirms the right software was built — that it meets user needs and intended use in the actual use environment. Verification asks "did we build it right?"; validation asks "did we build the right thing?"
For medical device software both are required, and both must be documented. Verification typically spans unit, integration, and system testing against requirements; validation confirms the device performs as intended for its users and clinical purpose, often under simulated or actual use conditions.
What does an FDA submission expect from software V&V?
An FDA premarket submission expects software documentation scaled to the device risk: a software description, requirements, architecture, a verification and validation summary with test results, a traceability matrix, and a record of known anomalies. The depth scales with the documentation level the FDA assigns based on risk.
- Software requirements specification, traced to design and tests
- Verification and validation protocols and the executed results
- Requirements-to-test traceability matrix with full coverage
- Risk management file (ISO 14971) and the software safety classification
- Revision history and a list of unresolved anomalies with risk assessment
Why does traceability matter so much?
Traceability is the documented thread linking every requirement to its design, its verification test, and the risk control it implements. Reviewers use it to confirm nothing was specified-but-untested or tested-but-unspecified — gaps that stall clearances.
A complete traceability matrix is also the single most useful artifact for change impact analysis: when a requirement or risk control changes, the matrix shows exactly which design elements and tests must be re-verified, which keeps maintenance under control over a product’s life.
How do test protocols and the Design History File fit together?
Test protocols define what will be tested and the acceptance criteria before execution; the executed protocols, their results, and the supporting requirements/design/risk records are compiled into the Design History File (DHF) that demonstrates the device was developed under design controls.
Under 21 CFR Part 820 (Quality System Regulation, transitioning to the harmonized QMSR aligned with ISO 13485), the DHF is the evidence trail. Building V&V records as living artifacts — rather than reconstructing them at submission time — is what keeps a program audit-ready.
Frequently asked questions
What is the difference between V&V and QA testing?
QA testing is the broad activity of finding defects across devices, OS versions, and protocols. V&V is the regulated, documented subset that proves requirements are met (verification) and user needs are satisfied (validation) with the traceability and records an FDA submission requires.
Does software validation require testing on the real device?
Validation must demonstrate the software meets its intended use in the actual or a representative use environment. For device software that usually means testing against real or hardware-in-the-loop simulated devices, not just mocked interfaces.
What is 21 CFR Part 11 and when does it apply?
21 CFR Part 11 governs electronic records and electronic signatures — audit trails, access controls, and signature integrity. It applies when your software creates, modifies, or stores records the FDA requires, such as clinical or quality records.