---
title: System Requirements for Medical Devices Under MDR
description: How to write, manage and trace system requirements for medical devices under MDR and EN ISO 13485 clause 7.3.3, from GSPR to verifiable specifications.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: system requirements medical devices MDR
canonical_url: https://zechmeister-solutions.com/en/blog/system-requirements-medical-devices
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# System Requirements for Medical Devices Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **System requirements are the contract between intended purpose and the finished device. Under EN ISO 13485:2016+A11:2021 clause 7.3.3 they must capture functional, performance, usability and safety needs — including every applicable General Safety and Performance Requirement from MDR Annex I — in a form that is verifiable, unambiguous and traceable. Without that contract, verification cannot exist, and neither can a technical file.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- System requirements are the top-level technical specification of the device, written in language a developer can build against and a tester can verify against.
- EN ISO 13485:2016+A11:2021 clause 7.3.3 requires design inputs to include functional, performance, usability, safety, statutory, regulatory and risk-management requirements.
- Every applicable General Safety and Performance Requirement (GSPR) from MDR Annex I must be translated into one or more device-level requirements with a direct trace link.
- A good requirement is verifiable, unambiguous, atomic, feasible and traceable. Ambiguous requirements are the single biggest source of downstream audit findings.
- Requirements are baselined and then managed under change control per clause 7.3.9. Uncontrolled requirements are the root cause of most traceability collapses.

## Why system requirements matter more than founders think

Most early-stage teams treat requirements as paperwork. The engineers know what to build. The requirements document is written retroactively so the Notified Body has something to read. This approach collapses the first time a tester asks "what exactly am I verifying?" or an auditor asks "where does this performance claim come from?".

Requirements are the device's contract with itself. The left side of the requirements document says what must be true. The right side — tests, reports, clinical evidence — proves that it is true. Without a clear left side, there is nothing to verify against, and the entire design and development file rests on implicit knowledge in the founder's head. That knowledge does not survive a single staff turnover, let alone a Notified Body audit.

Tibor has reviewed technical files where the device worked perfectly, the clinical evaluation was sound, and the team was competent — and the audit still failed because the requirements were not verifiable. "The device shall detect atrial fibrillation accurately" is not a requirement. "The device shall detect atrial fibrillation with sensitivity ≥ 95% and specificity ≥ 95% against a reference 12-lead ECG interpreted by a board-certified cardiologist, in a population of adults aged 18–85 with suspected paroxysmal AF" is a requirement.

## What MDR and EN ISO 13485 actually say

EN ISO 13485:2016+A11:2021 clause 7.3.3 requires design and development inputs relating to product requirements to be determined and records maintained. The inputs must include:

- Functional, performance, usability and safety requirements according to intended use
- Applicable statutory and regulatory requirements
- Applicable output(s) of risk management
- Where appropriate, information derived from previous similar designs
- Other requirements essential for design and development

Inputs must be "reviewed for adequacy and approved", must be "complete, unambiguous, able to be verified or validated, and not in conflict with each other". That last clause is the audit hook. "Unambiguous" and "able to be verified" are not suggestions.

MDR Annex I contains the General Safety and Performance Requirements — Chapter I (General Requirements, §1–9), Chapter II (Requirements regarding design and manufacture, §10–22), and Chapter III (Requirements regarding information supplied with the device, §23). Every GSPR that applies to the device must be addressed. MDR Annex II §4 requires the technical documentation to demonstrate conformity with each applicable GSPR, typically via a GSPR checklist that maps each GSPR to one or more system requirements and then to evidence.

EN ISO 14971:2019+A11:2021 feeds requirements from the risk management side: every risk control measure is an input to the design, which means it must appear as a system requirement and be verified.

## A worked example: translating a GSPR into a requirement

Take GSPR 14.2(d) from MDR Annex I Chapter II. The GSPR reads (paraphrased): devices intended to be used in combination with other devices or equipment shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe.

That is the regulation. It is not a requirement a developer can build against. To translate it into a system requirement for a wearable ECG patch with a companion mobile app, you might write:

> **SR-0142**: The patch shall transmit ECG data to the companion mobile app over Bluetooth Low Energy 5.0 with AES-128 encryption. Data loss during a 24-hour continuous monitoring session shall not exceed 0.1% of samples. The patch shall gracefully resume transmission within 10 seconds of link loss without loss of data buffered in the preceding 60 seconds.
>
> Source GSPR: MDR Annex I §14.2(d)
> Verification: Integration test IT-0142 and system test ST-0142
> Risk control from: RCM-0087 (data integrity loss)

This single requirement has everything a good requirement needs. It is functional (what the device does), performance-quantified (0.1%, 10 seconds, 60 seconds), unambiguous (BLE 5.0, AES-128), verifiable (you can write a test), and traceable (up to the GSPR and the risk file, down to the test).

Now multiply this by every applicable GSPR and every identified risk control. A typical Class IIa device with a hardware and software component lands somewhere between 80 and 200 system requirements. A Class III implantable can exceed 1,000.

## The Subtract to Ship playbook for requirements

**Step 1 — Start from intended purpose, not from features.** Intended purpose is defined in MDR Article 2(12) as *"the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation"*. Every system requirement must serve that intended purpose. If a requirement does not, it is either risk-driven or it is scope creep. If it is scope creep, cut it.

**Step 2 — Build the GSPR matrix first.** Before writing a single system requirement, walk through MDR Annex I and mark each GSPR as "applies", "does not apply with justification", or "partially applies". For each "applies", the system requirements list will need at least one entry. This is the most boring day of your project. It is also the day that saves three weeks in the audit.

**Step 3 — Write requirements using the "shall" test.** Every requirement uses the word "shall". Every requirement has a single testable assertion. "The device shall A and B" is two requirements, not one. Split them.

**Step 4 — Attach acceptance criteria at writing time.** Alongside each requirement, write the acceptance criterion — the exact measurable condition that determines pass or fail. If you cannot write an acceptance criterion, the requirement is not verifiable and must be rewritten.

**Step 5 — Assign a stable ID.** Requirements need IDs that do not change when the document is reordered. SR-0142 stays SR-0142 forever, even if it moves from page 12 to page 47. Tools like Jama, Polarion, or Matrix Requirements handle this natively; if you use a spreadsheet, freeze the ID column and never reuse a number.

**Step 6 — Trace upward and downward at writing time, not at audit time.** Upward: every requirement points at its GSPR source or risk control source. Downward: every requirement will eventually point at its verification test. The upward link is written the moment the requirement is written. The downward link is written the moment the test is written. Never both at the end.

**Step 7 — Baseline and freeze before verification begins.** Per clause 7.3.9, changes after baseline go through change control with impact analysis. Without this rule, the requirements drift during verification, test results become invalid, and traceability rots.

**Step 8 — Review for conflicts.** Clause 7.3.3 explicitly requires requirements to be "not in conflict with each other". A five-minute scan for conflicts at the end of the requirements phase catches issues that would otherwise surface as field bugs.

**Step 9 — Keep the requirements document small and layered.** One top-level system requirements specification. Subsystem requirements specifications for hardware and software below it. Unit-level design details below that. Do not mix layers. A system requirement that says "the firmware module xyz shall use interrupt priority 3" is in the wrong layer and will cause confusion.

**Step 10 — Use tools, but do not worship them.** A disciplined spreadsheet with a frozen ID column, change log and review signatures satisfies clause 7.3.3 for a small Class IIa device. A sprawling Polarion installation that nobody understands does not. Pick the simplest tool that gives you stable IDs, change history, and trace links. Then protect the discipline around it.

## Reality Check

1. Does every system requirement trace up to either an applicable GSPR, a risk control, or a statutory/regulatory requirement?
2. Can you point at the GSPR matrix for your device, and is it current?
3. Pick a random requirement. Does it have a measurable acceptance criterion, a stable ID, and a planned verification activity?
4. Are any of your requirements compound ("shall A and B")? If yes, they are ambiguous.
5. Are your requirements under change control, or is the spreadsheet still being edited by anyone at will?
6. Has someone other than the author reviewed each requirement for unambiguity and conflict?
7. If a new engineer joined tomorrow, could they understand what the device is supposed to do from the requirements document alone?
8. Are risk controls from your EN ISO 14971 file represented as numbered requirements, or only as entries in a risk table?

## Frequently Asked Questions

**How detailed should system requirements be?**
Detailed enough that two independent engineers, reading the same requirement, would write the same test. If two testers would disagree, the requirement is ambiguous.

**Do I need a separate requirements document for each subsystem?**
For a small device, a single system requirements specification plus an internal structure (hardware section, software section) is sufficient. For complex devices with multiple subsystems developed by different teams, separate subsystem requirements specifications derived from the system level work better.

**Can I use user stories instead of "shall" requirements?**
User stories are useful for Agile planning but insufficient for clause 7.3.3. You need formal "shall" requirements that a tester can verify against. You can generate shall requirements from user stories as you mature the backlog.

**How do I handle performance requirements I do not yet know?**
Write them as TBD with an owner and a deadline. TBDs are acceptable early in design but must be resolved before baseline. A TBD in a requirement at audit time is a finding.

**What happens when a requirement changes after baseline?**
Per EN ISO 13485:2016+A11:2021 clause 7.3.9, the change goes through a controlled change process with impact analysis on design outputs, verification, validation, and the risk file. The change is documented; affected tests are re-run.

**How do I know if a GSPR applies?**
Read the GSPR and ask: could this requirement be relevant to my device given its intended purpose? If yes, it applies. If no, document the reasoning. Many founders mark GSPRs as "not applicable" without justification — this is a common finding.

## Related reading
- [Systems Engineering V-Model for Startups](/blog/systems-engineering-v-model-startups) — how requirements fit into the overall V structure.
- [Design Input Requirements for Medtech](/blog/design-input-requirements-medtech) — a deeper dive into clause 7.3.3.
- [MDR Annex I GSPR Explained](/blog/mdr-annex-i-gspr) — the source of regulatory requirements.
- [Documenting the GSPR Checklist](/blog/document-gspr-annex-i-checklist) — how to run the GSPR matrix.
- [MDR Design Changes and Iterations](/blog/mdr-design-changes-iterations) — how to manage requirements after baseline.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, Annex II.
2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 7.3.3 and 7.3.9.
3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

---

*This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*