Part 3, It All Starts with Requirements
This is part three of a four-part series on medical device validation practices.
Is writing requirements a validation activity? Of course, it is! What has been verified if verification testing is attempted without written requirements? The GPSV points out: “Success in accurately and completely documenting software requirements is a crucial factor in successful validation of the resulting software.”
There is some room for debate on what constitutes a requirement and what constitutes design detail. While much benefit derives from solid, well reviewed requirements that have nothing to do with testing, the testing effort should be based on verifying the correct implementation of requirements.
Tests should test requirements. Too often, tests are written without detailed requirements or not enough detail in requirements (exploratory testing), and the test developer is forced to refer to the software for details regarding how the software works. The result is that the test ends up documenting the way the software works, not necessarily the way it is supposed to work. The requirements for the software are embedded in the test, not in a requirements document. Many problems are associated with this, but perhaps most alarming is that potential problems can get embedded into tests as expected behavior—thus, making it difficult to identify them as problems, and guaranteeing that the behavior will be accepted forever after.
From: Vogel, David A., Ph.D. “Validating Medical Device Software Includes and Goes Beyond Testing.” Medical Product Outsourcing Mar. 2006: .