Medical Device Development Insights: Converting Inputs into Engineering Requirements in Medical Devices

Inputs, Inputs, Inputs

This article is part of ATL’s Medical Device Development Insights series, which explores the engineering processes used to bring safe, effective medical devices from concept to market.

Overview

In the previous articles in this series, we explored how Design Thinking helps teams define the right problems, and how Human Factors and Usability Engineering ensure those solutions work in real-world use.

The next step is where many projects either gain clarity—or begin to drift:

How do those insights actually become engineering requirements?

At ATL, this stage is often summed up in a simple phrase:

Inputs, Inputs, Inputs…

That phrasing comes from years of reviewing requirements across full medical device development projects, and repeatedly coming back to one question:

Which “need” does this requirement actually satisfy?

• a User need
• a Regulatory need
• or a Business need

It sounds like a simple distinction—but in practice, it’s one of the most important (and most difficult) parts of the entire development process.

The Challenge: Turning Needs into Engineering Inputs

One of the core challenges in medical device development is translating what we learn—from users, from clinical environments, and from regulatory frameworks—into something engineering teams can actually build against.

User insights are often qualitative, context-driven, and sometimes incomplete or even conflicting. Engineering requirements, however, must be structured, measurable, and traceable.

Bridging that gap without prematurely locking in a solution is where many projects succeed—or struggle.

Storyline 1: The User’s Input

Let’s start with a simple example:

“As a surgeon, I want this system to provide radio frequency energy so I can remove damaged tissue.”

At first glance, this appears to be a User Need.

In reality, it already assumes the solution.

That makes it closer to a Customer Requirement or even a System-Level Design Specification.

This is one of the most common—and challenging—points in the requirements process.

At this stage, teams often know roughly what the system will do and have a good idea of how it might be achieved. However, that information cannot (and should not) be locked into the User Need.

It can feel counterintuitive not to document that level of detail early, but doing so constrains the entire design space before it has even been explored.

A more appropriate User Need would be:

“As a surgeon, I need a reliable way to remove damaged tissue accurately and safely.”

Now the intent is clear, but the solution remains open. This creates space downstream for engineering to explore the most appropriate approach.

User Needs → Customer Requirements → Design Specifications

At ATL, this relationship is treated as a connected system:

1. User Needs define intent
2. Customer Requirements translate that intent
3. Design Specifications define implementation

While this may be a one-to-many relationship in practice, maintaining traceability between these layers ensures that design decisions can be challenged, assumptions can be revisited, and intent is not lost as complexity increases.

Seeing Requirements from the User’s Perspective

Capturing User Needs versus Customer Requirements is often a contentious part of development.

User Needs tend to be clinical and functional, focusing on what the user is trying to achieve rather than how it is achieved. Examples include removing tissue, recording data, or transporting a device between locations.

This is also one of the more interesting phases of a project, as it is when teams begin to understand the people who will actually use the device.

In recent projects, demonstration labs have been set up to recreate realistic clinical environments to help onboard engineers. Not all engineers have the opportunity to observe procedures firsthand, so bringing that context into the development environment helps teams better understand real-world use.

From User Needs to Customer Requirements

Once User Needs are clearly defined, the next step is translating them into Customer Requirements.

At this stage, it is worth remembering that these requirements will be validated during Design Validation.

The key question becomes:

“Have we designed the right thing?”

Example: Storage Requirement

Consider the following:

“The device must be able to fit on shelf X, Y and Z.”

This is a Customer Requirement, not a User Need.

The corresponding User Need would be:

“I need the device to be stored away from the operating room.”

At this stage, the requirement remains solution-neutral while still guiding engineering decisions.

The next step is understanding what those shelves actually look like.

The Role of the Clinical Model

At ATL, this is where the Clinical Model is introduced.

This document acts as an intermediate layer between clinical understanding and engineering requirements. It defines the operating environment, the clinical procedure, and physical or spatial constraints.

This allows Design Specifications to remain grounded in a real-world context rather than abstract assumptions.

In some cases, these details could be included directly within design specifications. However, as product complexity increases—whether in the device itself, the clinical procedure, or the broader portfolio—the Clinical Model provides a structured way to anchor engineering decisions.

Storyline 2: The Regulatory Input

Regulatory inputs are often the most dominant force in medical device development.

For example, achieving 510(k) clearance requires extensive documentation, testing, and objective evidence.

Sources of Regulatory Inputs

• International standards (ISO, IEC, EN)
• FDA guidance documents
• EU MDR / UKCA legislation

These inputs define what must be achieved for a device to be considered safe and effective.

The Challenge with Regulatory Inputs

External test houses and certification bodies can support compliance, but without a strong internal regulatory understanding, these inputs can become disconnected from design decisions.

Good practice ensures that regulatory requirements are translated into clear design inputs, integrated into the same systems engineers use daily, and understood in terms of their rationale—not simply documented.

ATL Approach: Compliance Matrix

At ATL, one of the primary tools for managing this complexity is the Compliance Matrix.

This document maps regulatory requirements line by line, generates traceable outputs, and ensures completeness.

In some cases, requirements can be applied directly. In others, interpretation is required, and teams must define appropriate tests or specifications.

This is a significant task—and one that should not be left until late in development. Delaying this work can lead to redesign, delays, and dependencies on external testing schedules.

Storyline 3: The Business Input

The third set of inputs is often less explicitly discussed—but equally important: business needs.

A device can be safe, effective, and fully compliant, yet still fail if it is not commercially viable.

Typical Business Inputs

• cost targets and margins
• time-to-market pressures
• manufacturing scalability
• supply chain constraints
• product portfolio alignment
• servicing and lifecycle costs

Where Problems Appear

When business needs are not addressed early, they tend to reappear later as redesigns, specification changes, cost-reduction efforts, or, in some cases, project cancellations.

A Balanced Approach

A well-balanced medical device design does not prioritize business over safety or compliance. Instead, it acknowledges that all three input types must coexist.

When captured early and transparently, business needs become another constraint for engineering to work within, allowing teams to plan appropriately and manage cost without disrupting development.

Conclusion: What “Inputs” Really Means

When we talk about “Inputs,” we are not simply referring to a list of requirements.

We are referring to three distinct perspectives:

• User Needs — what problem is being solved
• Regulatory Needs — what must be achieved for safety and compliance
• Business Needs — what makes the product viable

If these inputs are incomplete or misaligned, everything downstream becomes more difficult.

When they are aligned early, engineering teams have the clarity—and freedom—to design effective solutions.

Next in the Series

In the next article in the Medical Device Development Insights series, we will explore how these inputs are managed within development frameworks, including agile approaches in regulated environments.