Artificial intelligence is making its way into nearly every stage of medical device development, including one of the most foundational activities: defining product requirements. With a well-structured prompt, AI-generated requirements, spanning user needs, software specifications, and even preliminary verification criteria, can be produced in a fraction of the time traditionally required.
For medical device manufacturers, this presents an appealing opportunity to accelerate development. However, generating requirements quickly is not the same as ensuring they are complete.
The challenge is that AI-generated requirements can look technically sound when reviewed individually, while still overlooking critical relationships between system functions, clinical workflows, and safety considerations. These omissions may be difficult to recognize until much later in development, when they become considerably more expensive to address.
The Problem With Requirements That Look Complete
Consider a hypothetical remote cardiac monitoring system that collects electrocardiogram (ECG) data from a wearable sensor, analyzes the recordings for potential cardiac abnormalities, and presents relevant findings to clinicians for review.
An AI tool tasked with generating requirements for this system might produce a reasonable list covering sensor connectivity, data acquisition, signal processing, arrhythmia detection, clinician notifications, and visualization of ECG recordings.
Each requirement could be clear, testable, and technically feasible. But what happens when the wearable sensor temporarily loses connectivity? How should the system respond when poor signal quality affects the reliability of an algorithm’s output? If an abnormality is detected in a recording that later fails quality checks, should the clinician still receive the same alert?
These are not necessarily missing features. They are dependencies and conditions that emerge when individual functions are considered together as part of a clinical workflow.
A requirements document could contain hundreds of well-written statements and still fail to describe how the product should behave in these situations.
This is not a limitation unique to AI. Human engineers can overlook similar dependencies. However, the speed and apparent completeness of AI-generated documentation can create a false sense of confidence, particularly when reviewers are faced with large volumes of technically plausible content.
Reviewing Capabilities Instead of Documents
One way to address this challenge is to change how AI-generated requirements are reviewed.
Rather than evaluating requirements only as individual statements organized by subsystem, development teams can examine them through the lens of complete, end-to-end product capabilities.
A useful approach is vertical slicing, which decomposes a complex product into smaller increments that deliver meaningful functionality across the system [1].
At the product level, a slice might represent the complete capability to acquire ECG data, assess signal quality, identify a potential arrhythmia, communicate the finding, and support clinician review.
At the feature level, that capability can be decomposed into the supporting user interface, data processing, algorithms, application logic, integrations, risk controls, and verification activities.
This decomposition creates an opportunity to review requirements in context. Instead of asking only whether the arrhythmia detection requirements are complete, engineers can examine whether the entire clinical workflow is supported, including its dependencies and potential failure conditions.
For example, reviewing the complete monitoring capability may reveal that signal quality must influence how detected events are classified and communicated to clinicians. That dependency might be overlooked when signal processing, detection algorithms, and notification functions are reviewed independently.
The objective is not simply to organize AI-generated requirements differently. It is to expose interactions that would otherwise remain hidden between engineering disciplines.
Making AI-Assisted Engineering More Reliable
AI can still play a valuable role in this process. Beyond generating initial requirements, it can help identify potential dependencies, propose alternative workflow scenarios, and suggest verification conditions for engineers to evaluate.
However, the review process must remain grounded in clinical intent and system behavior.
For each end-to-end capability, engineers should consider whether the complete user workflow is represented, whether abnormal and failure conditions have been addressed, and whether the resulting requirements can be traced to appropriate risk controls and verification evidence.
Importantly, generating a traceability relationship does not demonstrate that the underlying requirement is correct or that the proposed verification is sufficient. Those judgments still require engineering and clinical expertise.
Speed Is Valuable, but Completeness Matters More
As AI tools become increasingly capable of producing engineering documentation, the bottleneck in medical device development may shift from creating artifacts to reviewing their quality and completeness.
This makes the structure of the review process particularly important. Teams need methods that help them identify missing dependencies, challenge assumptions, and evaluate whether the requirements collectively describe a safe and usable product.
For medical device manufacturers, the opportunity is not merely to write requirements faster. It is to combine AI-assisted generation with disciplined, end-to-end systems thinking.
Ultimately, the most consequential requirement may not be the one AI writes incorrectly. It may be the one nobody realizes is missing.
Author Bio
