How to write Design Requirements for Medical Devices

Written by Karl Larsson on 23 September 2024. Posted in Expert's Secret.

There is no way around it.

If you are developing a medical device, writing Design Requirements is something you will have to do.

Writing good Design Requirements, on the other hand, is "optional" and, in my opinion, an acquired skill.

At konplan, many years of medical device development experience for numerous medical device manufacturers have taught us the difference between good and bad requirements. In this article, I will share some of our tried and tested best practices, lessons learnt in our pursuit of the well-written Design Requirement.

A Design Requirement shall describe the product

As opposed to a Stakeholder Requirement, that ideally capture what stakeholders expect of the product, reflecting their needs and desires, the design requirements focus on how the product fulfils these needs.

They are intrinsically more technical in nature, and therefore also more functional in character. In short, Design requirements are best when they describe the product, preferably in atomic statements.

Avoid confusing process requirements ("All requirements shall be verified" or "The product development shall be ISO 13485 compliant") with Design Requirements. Process requirements do not describe the product and are inherently awkward to verify. Low level details, such as UI style guides or architectural decisions are better not placed among the Design Requirements but rather in their dedicated categories (Specification Documents or Architectural Documents respectively).

'Acceptance criteria' is mandatory

Design requirements shall be written as S.M.A.R.T. (specific, measurable, achievable, relevant, time-bound). However, in our experience, much headway can be made by spending extra focus on the 'measurability' as it is so closely related to the testability of the requirement.

A good way to address this is to include an explicit Acceptance Criteria. This helps the Verification team to correct untestable requirements and to perform an early assessment on the efforts needed to verify the requirements downstream.

Another tip: if numbers are used in the requirement, always justify the origin of these numbers. This helps the verification team doing a good job and is also important for posterity.

Only include MUST Requirements

Any 'should', 'would', 'could' or 'nice-to-have' requirements should be lifted out of the Design requirements document into a separate Product Roadmap.

Limit the Design requirements to MUST requirements only. Do you have time to implement anything “nice-to-have”, instead of a “must”?

Any kind of priority issues are inherently resolved by only allowing “MUST” requirement. Even though the intention of such priority levels is to give the design team a possibility not to implement certain requirements if there should be a squeeze in the timeline, the effect is often the opposite: conflict, confusion and time-consuming disputes.

Bonus: Use the EARS syntax to write Requirements

A consistent language when writing Design Requirements can be a challenge. We, at konplan, have found the EARS syntax for describing Design requirements to be simple to use and easy to communicate to the team.

It favours clarity and structure, making them easy to understand while reducing ambiguity. If you have not tried it, you should really take a look at them. It has definitely helped my team to reduce the chance of misinterpretation, making it easier to communicate design requirements clearly.

Conclusion

There are of course other aspects in play when working with your Design Requirements. However, keeping these simple principles in mind should help you to take the next step in your Design Requirement journey.

In my opinion, they are not controversial and should be easy to include in your own Design requirement work without having to rework any existing procedures and development processes.

Remember: There is no absolute right or wrong, only better or worse. If you were on the better or worse side will become obvious during the development!

About the Expert

Dr. Ivo Locher is an electrical engineer with specialization in wearable computing and signal processing.

Currently, he acts as program manager at konplan ag and he is expert in systems engineering. During his career, Ivo has successfully led several medical device development projects, starting from requirements engineering up to market clearance.