The complexity of medical device technology seems to be growing almost exponentially. Today, medical instruments may make use of Nano technology; they may incorporate complex electromechanical and robotic apparatus; or they may include electronic subsystems as sophisticated as any modern-day computer. At the heart of this complexity, however, lies a fundamental question: what are the real requirements for such a system? After all, if the intended behavior of a system is not fully understood, how can its labeling claims of efficacy and safety be assured? How can the system be designed? How can the system’s purpose be determined, or its quality measured? And how can a company predict what level of effort will be required to develop and produce the system?
Design and development are exacting endeavors. Mechanical tolerances are specified to within a few thousandths of an inch, electrical timing is specified in nanoseconds, and software is specific to every bit in applications containing thousands of lines of code. Despite this precision, many projects suffer a nagging uncertainty: what exactly is this thing supposed to do?
Take a look at following DILBERT cartoons by Scott Adams, SOUND FAMILIAR?
Some managers consider requirements management to be an unnecessary exercise. They would prefer to proceed directly to implementation. However, our experience suggests requirements management is the most important exercise of the medical device design development.
Defining “complete”, “correct”, “feasible” and “prioritized” requirements as early as possible in the process is the key to successful execution and allows for:
- Better definition and management of labeling claims. An up-front investment in requirements management can provide a stronger basis for the claims of efficacy and safety that the manufacturer will ultimately make for the device.
- Better control of the development project. Requirements creep and inadequate knowledge of the intended behavior of the system are commonplace in out-of-control projects. Requirements management can provide the development team with a clearer understanding of what is to be delivered, as well as when and why.
- Improved quality and end-user satisfaction. What is the fundamental measure of quality? It is, does the device do what it is supposed to do? Higher quality is only achieved when end-users, developers, and test personnel have a common understanding of what must be built and tested.
- Reduced project costs and delays. Research shows that requirements errors are the most pervasive and most expensive errors to fix. Reducing the number of these errors early in the development cycle lowers the total number of errors and cuts project costs and the time to market.
- Improved team communications. Requirements management encourages the involvement of customers, so that the device meets their needs. It minimizes guesswork, interpretation and disconnects and brings team to the same level of understanding.
- Easier compliance with regulations. Objective evidence can be demonstrated in documented Design Verification and Validation activities and Traceability matrix shows the relationship to the initial requirements. Ultimately, this helps ensure that all needs have been addressed.
There is strong evidence that effective requirements management leads to overall project cost savings. Requirements errors that remain undetected until test or deployment, for example, typically cost well over 10 times more to repair than other errors. Reductions in the number of such errors can save money by avoiding rework and scheduling delays.
But as high as they are, these estimates of the hard costs of requirements errors tell only part of the story. Intangible costs include features that could have been delivered had the project’s resources not been devoted to rework, the increased potential for adverse incidents, and lost market share, along with the associated loss of revenues and profits. The sum of these costs demonstrates that companies cannot afford to ignore the benefits of improved requirements management.
The cost associated with repairing the requirement error increases drastically as the project moves further along in the process.
However, it is not enough to just define requirements. So what are the characteristics of Good Requirements? & How to check for Goodness of the Requirements? Good requirements specifications have the following attributes in common:
- Necessary – The stated requirement should be an essential capability, physical characteristic, or quality factor of the product or process. If it is removed or deleted, a deficiency will exist, which cannot be fulfilled by other capabilities of the product or process.
- Clear (minimal, understandable) – The requirement statement includes only one requirement stating what must be done and only what must be done, stated simply and clearly. It should be easy to read and understand.
- Complete – It may be impossible to know all of a system’s future requirements, but all of the known ones should be specified. The stated requirement should be complete to the point where it does not need further amplification.
- Consistent – A system that satisfies all requirements cannot be built if two requirements conflict. The stated requirement should not contradict other requirements, and should not be a duplicate of another requirement. The same term should be used for the same item in all requirements.
- Unambiguous – If a requirement has multiple interpretations, the resulting product will probably not satisfy the needs of users. Each requirement must have one and only one interpretation. Language used in the statement must not leave a doubt in the reader’s mind as to the intended descriptive or numeric value.
- Verifiable – The stated requirement should not be vague or general but should be quantifiable in a manner that can be verified by one of these 4 alternative methods: inspection, analysis, demonstration or test.
- Traceable – The source of each requirement should be identified. The requirement may represent a refinement of another, more abstract requirement, or it may result from input from a meeting with a target user.
- Attainable (achievable or feasible) – The stated requirement can be achieved by one or more developed system concepts at a definable cost. This implies that at least a high level conceptual design has been completed and cost tradeoff studies have been conducted.
In summary, when writing effective requirements, we have to remember some basic concepts. It is really important to make sure each requirement is necessary, verifiable, unique, achievable and traceable also is written clearly, simply, concisely and unambiguously. Some specify “how to do it” instead of “what is required”, which is not a good idea. Specifying an unnecessary design constraint can be a burden on design and can cause an increase in costs, lengthy timelines, reduced quality and reliability.