Part 4, Inadequate requirements usually result in inadequate testing.
This is part four of a four-part series on medical device validation practices.
Here are some telltale signs of inadequate requirements:
- Software developers need constant access to market and clinical specialists to understand how they want the software to work.
- Code writing begins before requirements are written or approved.
- Test authors need frequent access to the software developers to understand how the software should work.
- Formalized testing finds few if any defects, while “experts” (e.g. developers) with the system find many defects in ad hoc (It could be inadequate testing too, but usually it is a combination of poor requirements and poor testing.)
- Review of test results is time-consuming and requires “experts” with the software to determine whether tests passed or failed. Note that this does not meet the standard of objective evidence of test results if the results have to be interpreted.
- A preponderance of tests fail by the testers but are subsequently passed because the “testers didn’t understand how the software works.”
If these red flags fly, you need to go back and rewrite the requirements, making them specific enough so that they can be tested properly. Adequate requirements are the foundation of testing and should be the foundation of software implementation too. A little extra up-front effort can prevent the whole structure from collapsing later. While testing alone doesn’t amount to validation, proper validation demands testing, and testing depends on testable requirements.
From: Vogel, David A., Ph.D. “Validating Medical Device Software Includes and Goes Beyond Testing.” Medical Product Outsourcing Mar. 2006: n.