Design Input – agreeing on what to design
Development projects are complex and often involve distributed teams. Writing unambiguous and specific design input requirements is of the utmost importance.
According to a study covering large, medium, and small companies (including healthcare), the Standish Group found that “incomplete requirements” ranked at the top of reasons why projects are impaired or ultimately canceled.
It is therefore critical that the team aligns on what to design.
How to avoid half-peeled potatoes
To avoid half-peeled potatoes, we have created a checklist to help ensure your system requirements are not misinterpreted.
These are the do’s and don’ts:
Traceable:
The requirement is uniquely identified and traceable to specifications and verification
Req 01:
Weight of the system ≤ 0.8 kg.
–
Weight of the system ≤ 0.8 kg.
Unambiguous:
Requirements shall be subject to one and only one interpretation
Req 02:
L x W x H ≤ 0.3m x 0.2m x 0.2m.
Req 02:
The product shall be smaller than the previous version.
Implementation Free:
Requirements shall state what is required and not how the requirement should be met
Req 03:
The device shall comply with IEC 60529 IP64.
Req 03:
he parts shall be glued together.
Completeness:
Requirements shall be stated in one place with no missing information
Req 04:
The device display shall show the glucose value in mmol/l for 10 seconds when the device has read the test strip.
Req 04:
The device display shall show the glucose values.
Correctness:
Each requirement shall accurately describe what to be built
Req 05:
The device shall remain clearly legible during the expected service life of the device.
Req 05:
The device shall be waterproof.
Consistent:
Requirements shall not contradict other requirements
Req 04:
Requirements shall not contradict other requirements.
Req 06:
The device display shall show the glucose value in mg/dl for 8 seconds when the device has read the test strip.
Verifiable:
Requirements shall be verifiable in a verification that either pass or fail
Req 07:
The device display shall display the glucose value with a minimum character height of 2.3 mm.
Req 07:
The displayed glucose values shall be easy to read.
Atomic:
The requirement shall contain one single traceable element
Req 07:
The device display shall display the glucose value with a minimum character height of 2.3 mm.
Req 08:
The device display shall be backlit.
Req 07:
The device display shall display the glucose value with a minimum character height of 2.3 mm and the display shall be backlit.
Feasible:
The requirement is technically achievable within existing constraints
Req 09:
The device shall be operated with a battery.
Req 09:
The device shall be operated without a power source.
The key benefits
A key benefit of ensuring that your design input is not misunderstood is to avoid late-stage design changes. The earlier in the project the team agrees on the user need they are solving with the medical device, the fewer late-stage design changes will occur. The cost of any change is relatively low in the early phases of the project and implementing – and following – a healthy design control process increases your chances of avoiding late-stage design changes.
Insights you might also be interested in:
Design Control Documentation That Brings Value to the Project and the Product
MGS Design & Development's design control specialists can quickly gain an overview of the product and the project to ensure a red thread during the design control documentation process.
The Highlights of the Updated Risk Management Standard
What you need to know about the updates to the 2019 version of ISO 14971.
