Why crafting proper requirements is so important for your software medical device (and how to do so).

Clear, concise, singular requirements for your software medical device will help align stakeholders, guide regulatory efforts, and improve product decisions

To build a successful software product, especially in healthcare, it is crucial to ensure all stakeholders understand its capabilities and limitations precisely. A successful software medical device must also comply with regulations, and make use of state-of-the-art software development practices.

All of this can be achieved through proper requirements.

These specify what a piece of software should do, outline its functionalities, and define the constraints under which it operates.

What are proper requirements?

Proper requirements should be four things: clear, concise, singular, and testable. We’re going to focus on the first three here, and we’ll explore testability in a subsequent post.

• Clear: Requirements should be unambiguous and easily understood by all relevant stakeholders

• Concise: Requirements should be comprehensive yet brief, avoiding unnecessary complexity (a good question to ask yourself is: "Could I communicate the same information more succinctly without compromising on actual meaning?")

• Singular: A single requirement should address (as far as possible) a single aspect of the system

Adherence to these qualities will provide a framework that avoids ambiguity and contradictions, allows for efficient verification that the requirements do not contradict one another, and in general serves as an excellent foundation to ensure the requirements are testable.

Let’s examine how these three qualities can be achieved in your software medical device.

Clear and concise

How do we achieve clarity and concision in our requirements?

One way is to define the terms that indicate obligations. To do so, we can make use of RFC 2119, which provides the guidelines for specifying requirement levels in internet standards.

It outlines the use of "must" or "shall", and defines them both as follows:

"This word [...] mean(s) that the definition is an absolute requirement of the specification."

At Scarlet we believe each manufacturer should have the flexibility to best represent their device. So “must” or “shall” defined as above might not be the best fit for you. Either way, precisely defining the terms you use to craft requirements will help you to have a consistent and comprehensible approach. In short, it will guide you to requirements that are clearer and more concise.

Singular

When it comes to achieving singular requirements, the MECE principle (mutually exclusive, collectively exhaustive) is a powerful tool.

The idea behind it is simple:

• Decompose your requirements until there is no overlap between them (this is the mutually exclusive part)
• Make sure you cover all cases you want to describe (this is the collectively exhaustive part)

As an example, let’s take the following requirement:

“If the user clicks on the big red button, the button shall become green, the device shall display a random number, and the user shall be logged off.”

This can easily be reformulated into three distinct requirements:

1. If the user clicks on the big red button, the button shall become green
2. If the user clicks on the big red button, the device shall display a random number
3. If the user clicks on the big red button, the user shall be logged off

Doing this might feel scary as your number of requirements will likely grow, and in some instances the benefits will not be immediately apparent.

Remember that by making requirements singular you do not end up with a higher level of requirement overall, you are simply reorganising the ones you have in a way that will facilitate their verification and validation, and you will reap the benefits later.

Set up for success

Writing clear, concise, singular requirements for your software medical device is crucial. It will enable alignment of all stakeholders, and provide you with a better framework to comply with the regulation effectively. It will help steer you towards the right product, i.e. one that embodies what stakeholders had originally envisaged and is also compliant.

One bonus of this approach is that such requirements also make it easier for conformity assessment bodies to understand your device, giving them greater ability to assess your data efficiently.

So subjecting your requirements to the filter of these three qualities will set up your software medical device for success in a number of ways, with stakeholders both inside and outside your organisation.