The FDA 510(k) guidelines for medical device software leave something to be desired in the poor differentiation of two important and distinct software development practices: verification and validation. In particular, the FDA often uses the word ‘validation’ to describe both types of activities. (See, for example, the General Principles of Software Validation; Final Guidance for Industry and FDA Staff.)
Put simply, software validation is a set of activities that together demonstrate that you “made the correct product” (or, as others have put it, “built the right thing”) for the customer’s needs. Validation tests that the product’s behavior is consistent with the requirements, safe, and efficacious.
By contrast, software verification is a set of activities that together demonstrate that the implementation matches the design. That is, verification tests that you “made the product correctly” (“built it right”).
In the larger context, verification should come before validation. It doesn’t make sense to check that the product does what it is supposed to unless you first confirm that it does what you programmed it to. If it were only the case that the many engineers and organizations that talk about software verification and validation (a.k.a., V&V) could get this simple concept. It wouldn’t hurt, of course, if the FDA rewrote the above document.
