3 C’s of Specifications
Design Input, FDA, Medical Devices, QSR, Specifications
One area of design and development that is foundational to product success is a well written set of product requirements and specifications.
In my career in Medical Devices, one of the most significant causes of ineffectiveness in product development has been the area of Requirements and Specifications. One of the biggest shortcomings in this area is poorly written specifications. In the FDA QSR, specifications fall under “Design Input”, of which the FDA QSR requires that Design Input procedures “include a mechanism for addressing incomplete, ambiguous, or conflicting requirements”. I like to remember that good specifications meet the “3 C’s”, that is they are:
- Complete
- Clear
- Conflict-free
Specifications that meet the (3) C’s can be designed to and verified. So here’s the tip for writing complete, clear and conflict-free specifications:
- Write them as complete sentences so that each can be understood standalone
- Include a verb, which is often used as a keyword
- Either specify the existence or non-existence of an attribute, or the acceptable range of a variable
- Write them so they can easily be reworded into a verification or validation statement
- Write them clearly (complete and unambiguous) so they can be completely understood without needing additional information, e.g.
- Anticipate the design and/or implementation
Here are a few examples of complete, clear and conflict-free specifications:
Write them as complete sentences so that each can be understood standalone, e.g.
- The <xyz> product size shall be a maximum of 12”W x 3”H x 8”D
- The <xyz> product size shall weight a maximum of 4.5 albs
Include a verb, which is often used as a keyword
Either specify the existence or non-existence of an attribute, or the acceptable range of a variable, e.g.
- Attribute specification: the <xyz> product shall have a 7” color LCD
- Variable specification: the <xyz> product shall weigh less than 5 lbs
Write them so they can easily be reworded into a verification or validation statement, e.g.
- Attribute specification: the <xyz> product shall have a 7” color LCD
- Attribute verification statement: verify that the <xyz> product has a 7” color LCD
- Variable specification: the <xyz> product shall weigh less than 5 lbs
- Variable verification statement: verify that the <xyz> product weighs less than 5 lbs
Write them clearly (complete and unambiguous) so they can be completely understood without needing additional information, e.g.
- Bad: The <xyz> product shall have a high rate alarm.
- Better: The <xyz> product have a high ECG heart rate alarm.
- Even Better: The <xyz> product have a high ECG heart rate alarm that:
- detects the alarm condition when the measured heart rate exceeds a preset value
- provides a continuous visual indication while the alarm condition exists
- provides an audible annunciation while the alarm condition exists
Anticipate the design and/or implementation, e.g. in the previous example of a high ECG heart rate alarm, the “even better” specification anticipates that the design will need:
- A means to detect the alarm condition when the measured heart rate exceeds a preset value
- A means to provide a continuous visual indication while the alarm condition exists
- A means to provide an audible annunciation while the alarm condition exists
If you strive to develop a well written set of product requirements and specifications, you will be laying a solid foundation for design, development and product success.