Written by: Senior QA Engineer
Mykhailo RalduhinPosted: 09.04.2026
14 min read
A meditation app can fail and no one gets hurt. Medical device software doesn’t get that luxury.
When code controls insulin delivery, heart monitoring, or life-supporting functions, every requirement matters. And every requirement must be proven to work – not assumed, not implied.
That’s what requirements-based testing is about.
It creates a direct, uncompromising link between what the software is supposed to do and how it’s verified. No gaps. No “we’ll test it later.” No undocumented behavior hiding in production.
In medical device development, this isn’t a methodology you choose. It’s a discipline you commit to, because regulators expect it, auditors demand it, and patient safety depends on it.
Requirements-based testing turns intent into evidence. And in medical software, evidence is everything.
Review your RBT gaps with our QA experts
Why requirements-based testing matters more in medical quality assurance
If you have a look at the FDA recall data, software issues are a recurring theme – there were 320 FDA recalls within the first 8 months of 2025 because of software issues. In many cases, the root cause isn’t a coding error but a vague or missing requirement. A device failed not because engineers didn’t test, but because what needed to be tested was never articulated precisely.
Requirements-based testing, with its precise attention to project requirements, is the way to go, as it is good not only at catching bugs early in the development process but also at meeting regulatory requirements and preventing patient harm.
For instance, in 2021, Philips voluntarily recalled millions of its sleep apnea devices and ventilators due to risks from deteriorating sound-abatement foam. Philips initially claimed that, based on the research program run with five independent laboratories, the devices were unlikely to harm patients’ health.
Yet, the FDA announced that the evaluation wasn’t adequate and called for additional testing. Since then, the company has repaired or replaced over 99% of sleep therapy devices, while ventilator remediation continues, and it has settled personal injury and class action claims under a consent decree with the DOJ and FDA. This highlights that incomplete testing or unclear requirements can lead to serious financial, regulatory, and patient-safety consequences.
Unlike traditional QA approaches or exploratory testing, which can miss scenarios rooted in risk, RBT forces every clinical need, every risk control, and every system behavior into a clearly written requirement with a corresponding test.
It can be compared with the black box recorder of medical software: every critical function leaves a traceable trail from requirement to test result. Without that level of evidence, regulators cannot trust that a device is safe. They want to see a straight line from a clinical need or a risk control all the way to a test result.
What the rulebook actually says
Requirements-based testing isn’t just the best practice in medical device QA – it’s actually a demand written into regulations and standards:
FDA design controls (21 CFR 820, evolving into QMSR 2026) require that every design input be verified and validated. That means requirements must be verified by tests with objective evidence.
IEC 62304 (software lifecycle standard) makes traceability a formal obligation and scales test depth depending on safety classification.
ISO 14971 (risk management) insists that every identified hazard must be controlled by a requirement and verified by evidence.
IEC 62366-1 (usability) demands that use-related risks translate into measurable UI requirements and be validated in studies.
FDA cybersecurity guidance (2023) suggests that secure updates, identity management, logging, and SBOMs must all be treated as requirements with corresponding tests.
To boil this down, all regulators ask the same thing: show us what the software is supposed to do, prove it does it, and prove that nothing unsafe slips through the cracks.
What does this mean for you as a medical device producer? If you can’t map a requirement to a test and show results, you’re unlikely to meet compliance. Quality assurance in healthcare must consider this.
Why this isn’t just red tape
Understandably, requirements-based testing might be viewed as bureaucracy that takes additional time and effort. Yet, in reality, this practice brings practical benefits.
1. Hassle-free regulatory submissions and audits
Requirements-based testing generates much of your Design History File (DHF) and audit documentation as a natural by-product of development. You have every requirement, test, and verification result well documented and traceable. This reduces the frantic effort often required before FDA premarket submissions or Notified Body audits and minimizes the risk of missing evidence or inconsistencies.
Teams can demonstrate, at a glance, that every clinical need and safety control has been addressed and verified. This results in fewer review questions, faster approvals, and less time spent defending your design decisions.
2. Prevention of undocumented functionality
An undocumented functionality is a serious risk. If a feature isn’t captured as a requirement, it doesn’t appear in a traceability matrix, it doesn’t have a test case, and it doesn’t have evidence of verification. In the eyes of the FDA or a Notified Body, this is a critical compliance gap.
Regulatory agencies like the FDA and EU authorities issue warning letters to manufacturers when software updates introduce features that weren’t part of the original submission package. However, they can go further and impose recalls, consent decrees, and costly remediation obligations.
Requirements-based testing prevents these failures by acting like a first-class gatekeeper: if a function isn’t tied back to a requirement, it does not make it into production. This approach ensures every shipped feature is documented and validated.
4. Optimized processes and peace of mind
Requirements-based testing not only facilitates medical device software verification, validation, and compliance but also boosts efficiency. Teams that adopt RBT spend less time arguing about what ‘done’ means and more time delivering value. That clarity provided by RBT also makes adding new features less risky, since regression isn’t left to guesswork but managed through traceable requirements and test results. The payoff is faster development and a smoother path to market.
Turn requirements into evidence
Key components of a requirements-based testing strategy
Requirements-based testing differs from other medical device testing methods. This approach is more than writing and running test cases. In essence, it’s a set of practices and artifacts that ensure every requirement is verifiable, every risk is covered, and every change is managed. The components outlined below make up the foundation of a decent RBT strategy.
Testable requirements
The quality of testing depends on the quality of the requirements it traces back to. If a requirement is vague or bundles several behaviors together, it cannot be tested efficiently.
What makes a requirement testable:
It describes a single, observable behavior.
It defines measurable conditions for pass/fail.
It states the context in which the behavior applies.
Example of the precision for medical device performance testing:
A traceability matrix
This artifact is a core component of requirements-based testing. A traceability matrix links requirement, test case, execution status, and defect (if found). This makes the gaps well visible. If a requirement has no mapped test, it isn’t verified, and if a test fails, you see which requirement is at risk.
Usually, a matrix structure looks like this:
A traceability matrix is of great help. It allows teams to prove to regulators that every documented feature has been checked and nothing has slipped through.
Risk classification and coverage depth
Not all requirements are equally important. For example, both ISO 14971 and IEC 62304 emphasize that the level of testing rigor must correspond with the level of risk.
When it comes to ISO 14971 risk management, it looks like this:
Class A (low risk - no injury possible): Basic confirmation tests are enough.
Class B (moderate risk - non-serious injury possible): More extensive positive/negative test coverage is required.
Class C (high risk – serious harm or death possible): Exhaustive testing, edge cases, stress conditions, and independent review are demanded.
The risk classification defines how much testing effort is needed. This way, teams do not over-test minor features and ensure safety-critical functionality is airtight. For example, a requirement outlining background color on a dashboard might only need one functional test. Yet, safety functions like alarms, dosage calculations, or fault detection need broad test coverage. This is a part of medical device safety testing.
Change management
No software is static. Features evolve, bugs are fixed, platforms change, and new APIs are integrated. When testing healthcare applications, it’s important to ensure that every change is outlined in requirements and properly verified. Otherwise, undocumented functionality can sneak in, leading to FDA warning letters and recalls.
Good change management in RBT includes:
Recording requirements impacted by a change.
Performing a regression impact analysis to identify affected tests.
Re-running the relevant subset of tests and documenting results.
Updating a traceability matrix with new links, results, and defect IDs if applicable.
Proper change control keeps projects from drifting and maintains alignment with the submission package.
RBT implementation in healthcare projects
When working on medical devices that have to meet FDA regulations or IEC 62304 Class C safety requirements, implementing requirements-based testing is a common practice. While it may seem intimidating at first, the RBT introduction actually comes down to introducing the right habits into everyday work. Here’s the approach teams can follow.
Agree on the meaning of a ‘testable requirement’
In medical device software testing, clear requirements are an indispensable prerequisite. QA engineers should challenge every requirement with a simple question of how it can be proven in a test. If there isn’t an objective answer with numbers, thresholds, or tolerances, the requirement is vague. So, start by agreeing with all team members on what a testable requirement must look like. This reduces misunderstandings and prevents features from slipping through untested.
Build traceability gradually
Trying to map all requirements at once can frustrate even the most diligent and disciplined teams. The better way is to begin with the highest-risk or most critical functionality.
We’d recommend you focus first on:
Class C functionality, which includes safety-critical features that could directly impact patient health.
Localization logic, where mistranslations or display issues can affect clinical understanding.
Data integrity, especially storage, transmission, and audit trails, that fall under HIPAA or GDPR.
By ensuring traceability around these core aspects first, teams mitigate the biggest risks early while building confidence in their process. Once these are mapped, traceability can be expanded to less critical features in the following iterations.
Make test mapping part of your workflow
Integrate requirement-to-test linking into your sprint activities, treating each requirement as something that must have a test associated with it.
In backlog grooming, flag requirements as testable only if they have clear acceptance criteria.
In design reviews, check that each requirement has at least a draft test strategy linked.
In the definition of ready, require traceability links before development starts.
In the definition of done, ensure tests have been run and results logged against the requirement.
By following this approach, traceability is introduced into daily work, software testing is executed on time, and a team becomes responsible for verification from day one.
Use automation where it makes sense
Automated software testing in healthcare is a powerful tool, but not every requirement can or even should be automated immediately. Yet, when workflows stabilize, automation keeps traceability lean and repeatable.
Modular and keyword-driven frameworks are a perfect fit for regression testing, allowing tests to be updated in small pieces without rewriting entire suites. For example, a change in the login workflow doesn’t necessitate reworking every downstream test, but just the shared login module. This reduces maintenance efforts and helps keep test evidence aligned with requirements as they change.
Working on Abbott glucose monitoring system, we used a Robot Framework. The keyword-driven approach lets all team members understand tests and their logic, enabling them to choose and run tests according to their needs.
Leverage tools that support requirement–test mapping
Spreadsheets can work in the earliest phases, but as projects evolve, it’s better to switch to purpose-built tools to ensure sustainability.
Jira can store user stories and requirements, with plugins like Xray or Zephyr, enabling direct traceability to test cases.
TestRail offers requirement fields and reporting dashboards that show coverage status.
Zephyr supports linking requirements, tests, and execution results with comprehensive reports for regulators.
With such tools in place, you have all links visible and well-organized, which helps everyone understand the state of testing, supports regulatory review, and reduces the chance of missing critical verification steps.
Audit your medical QA process
Common challenges in RBT and how to solve them
Software testing in the healthcare domain isn’t an easy task, especially when it’s requirements-based testing for medical devices. Medical device software is complex, deadlines are tight, and compliance demands are strict. Teams often encounter recurring pain points that can derail an RBT process if not managed carefully.
Incomplete or shifting requirements
In healthcare projects, requirements are rarely set in stone at project kickoff. Clinical stakeholders may redefine workflows once they see early prototypes, or regulations may change midstream. The result is a backlog full of items that are hard to test because they aren’t fully specified.
Solution:
The way forward is to introduce requirement refinement as a continuous activity, not a one-time task, and make it a shared responsibility between product and QA. Establish checkpoints where QA, development, and product owners agree on atomic, testable requirements before automation or validation proceeds.
Gaps in traceability
Traceability often erodes when documentation is updated inconsistently and when requirements, test cases, and results live in different places – Jira, Confluence, spreadsheets, and file shares. Without integration, it becomes nearly impossible to prove that a requirement has been fully tested. This is a red flag in audits and a frequent source of delays in regulatory submissions.
Solution:
Professional providers of healthcare software testing services maintain a traceability matrix or use tools that support live linking between requirements and tests. Even a well-maintained spreadsheet is better than a fragmented record. What matters is that every requirement can be followed through to its test cases, execution results, and defects if they exist.
High complexity of medical device software
For safety-critical devices, regulators expect comprehensive verification at multiple levels. Teams often see this as overwhelming, with thousands of test cases to manage. But the intent of regulations is not to test everything equally - that’s why the above-mentioned risk classification was introduced.
Solution:
The best thing to do is to ensure risk-based coverage. By classifying requirements according to patient risk (from A to C), teams can apply depth where it matters most. Safety functions like dose limit enforcement need exhaustive testing, while non-critical requirements like user interface color schemes can be verified with proportionate effort. This approach maintains compliance while keeping the validation workload manageable.
Final thoughts
Risk-based testing is not bureaucracy that aims to add complexity. In fact, it’s a framework that makes quality measurable, defendable, and trusted. In medical device development, that trust is everything – regulators demand it, clinicians rely on it, and patients’ safety depends on it.
Ask yourself:
Does our current QA process make it clear which risks are truly controlled?
Can we show, without hesitation, how every critical requirement is verified and traced?
If the answer isn’t a confident ‘yes,’ it may be time to rethink your approach. Risk-based testing provides the structure to fill those gaps. And with the right partner, it’s far easier to embed that trust into your product.
Let’s talk about how we can help you make RBT a driver of efficiency and compliance, not a struggle.
Review your testing strategy
About the author
Senior QA engineer
Mykhailo Ralduhin is a Senior QA Engineer at DeviQA, specializing in building stable, well-structured testing processes for complex software products.