do’s and don’ts

A checklist for better product requirements

Design Input – agreeing on what to design

Development projects are complex and often the team is not even in the same location. Writing unambiguous and specific design input requirements are of the utmost importance. According to a study that included large, medium, and small companies (incl. healthcare), opinions about why projects are impaired and ultimately canceled ranked ’incomplete requirements’ at the top of the list [the Standish Group].

It is therefore of significant importance that the team agrees on what to design.

How to avoid half-peeled potatoes

To avoid half-peeled potatoes, we have collected a checklist that you can use to ensure that 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.
Do
  • -
  • Weight of the system ≤ 0.8 kg.
Don't

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.
Do
  • Req 02:
  • The product shall be smaller than the previous version.
Don't

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.
Do
  • Req 03:
  • The parts shall be glued together.
Don't

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.
Do
  • Req 04:
  • The device display shall show the glucose values.
Don't

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.
Do
  • Req 05:
  • The device shall be waterproof.
Don't

Consistent:

Requirements shall not contradict other requirements

  • Req 04:
  • Requirements shall not contradict other requirements
Do
  • Req 06:
  • The device display shall show the glucose value in mg/dl for 8 seconds when the device has read the test strip.
Don't

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.
Do
  • Req 07:
  • The displayed glucose values shall be easy to read.
Don't

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.
Do
  • 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.
Don't

Feasible:

The requirement is technically achievable within existing constraints

  • Req 09:
  • The device shall be operated with a battery.
Do
  • Req 09:
  • The device shall be operated without a power source.
Don't
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.

Want to know more?

Insights you might also be interested in:

Tagged