How to make software medical device requirements testable

Testable requirements will ensure a better framework for your SaMD to comply with MDR.

In a recent post, we discussed the importance of crafting proper requirements for software medical devices, and how ensuring they are clear, concise, and singular can set your product up for success. We also briefly mentioned another critical aspect of proper requirements: testability.

In this post we’ll explore why testable requirements are vital, and how to achieve them.

Supporting evidence

For any software medical device, robust verification and validation activities are a huge part of ensuring that the right product has been built correctly i.e. it is both safe and high performing.

Both verification and validation rely on producing objective evidence that requirements have been fulfilled. Since most of this evidence comes through testing, it’s crucial to write requirements that easily support the creation of test cases. This is not just best practice; state-of-the-art SaMD standards require it.

So how do you make requirements testable? As well as clear, concise, and singular, a requirement must also be both:

• measurable, and
• feasible.

Measurability: quantitative or state based

A requirement becomes measurable by including quantitative statements, and/or by specifying state changes.

For instance, consider this requirement:

• “The detection module shall be compatible with iOS 17 running with a limited amount of RAM.”

It is vague and hard to test.

Instead, we can specify a specific quantity to make the requirement measurable:

• “The detection module shall be compatible with iOS 17 running with at least 4GB of RAM.”

Similarly, subjective terms can obscure measurability. For example, a requirement such as the following is not measurable:

• “A healthcare practitioner shall be able to input the patient diagnostic into the system easily.”

What does "easily" mean exactly? How do we know if it has been done easily? One way to improve this is to make it quantifiable:

• “A healthcare practitioner shall be able to input the patient diagnostic in under five minutes, with an error rate of less than 1%, after reading the instructions for use.”

This makes the requirement measurable, and testable.

To focus on a state-based example, instead of:

• "The system shall allow the user to switch between diagnostic modes seamlessly.”

A state-based (and quantitive) version would be:

• “The system shall allow the user to switch from diagnostic mode A to mode B within 2 seconds, maintaining all previous input data.”

This uses state changes (switching between modes) and provides clearly quantified criteria (within 2 seconds, keeping input data intact), making it testable.

Feasibility: avoid negative and unrealistic requirements

A testable requirement must also be feasible—it should be grounded in reality and account for available resources. One way to achieve this is by avoiding negative statements, which can lead to completely unrealistic promises for a device.

For example, consider this requirement:

• “The communication module shall not allow any downtime.”

This is not grounded in reality, as no system can guarantee zero downtime.

A more feasible requirement would be:

• “The system shall maintain an uptime of 95% or higher during intended use.”

By framing requirements positively, you also make it easier to translate them into test cases. For instance, instead of saying:

• “The system shall not allow users to bypass login.”

You can specify:

• “The system shall enforce user authentication by requiring valid login credentials before granting access to any functionality.”
  Drag

Positive formulations are clearer, easier to test, and contribute to a smoother verification process.

Passing the testability

Testable requirements are grounded in measurability and feasibility. Just as proper requirements set the framework for success, making them testable ensures that your product can be developed and assessed in the right way.

Crafting your requirements using the guidelines we’ve discussed in these two blog posts will establish a strong foundation for your software medical device. That should allow you to create a product that meets its intended goals and can be verified, validated, and brought to market with confidence.

Ultimately, this approach is designed to ensure your device will be safe, compliant, and high-performing, benefiting both your stakeholders and the patients who need it.