A software requirements specification for MDR conformity is the controlled document that translates device-level needs into verifiable software statements. EN 62304:2006+A1:2015 clause 5.2 defines the six categories of requirements every SRS must cover, and the quality rules that determine whether the document will survive a notified body audit.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The SRS is the foundational software document under EN 62304:2006+A1:2015 clause 5.2 and the anchor for the entire verification and validation effort.
  • Clause 5.2.1 through 5.2.6 defines six mandatory content areas: functional and capability, software system inputs and outputs, interfaces, environment, data definition, and regulatory requirements.
  • Every requirement must be uniquely identified, verifiable, consistent, and traceable to system requirements and risk controls.
  • MDR Annex I §17 requires software to be developed and manufactured according to the state of the art, and Annex II expects the SRS to be retrievable from the technical documentation.
  • Bad SRS content is the single largest driver of downstream rework in notified body audits — a clean SRS is the cheapest insurance in the software package.

Why this matters

Almost every software non-conformity I see at a notified body audit eventually traces back to a weak SRS. Requirements that cannot be tested. Requirements that restate marketing claims. Requirements that contradict each other. Requirements with no link to the risk management file. Requirements that exist in Jira but not in any controlled document.

When the SRS is wrong, everything downstream is wrong. The architecture cannot be justified, because there is nothing stable to derive it from. The tests cannot be complete, because there is no baseline to test against. The risk controls cannot be verified, because the control statements never became requirements. The release cannot be justified, because the acceptance criteria are verbal.

A good SRS is not long. It is sharp. It is the tool that lets a small team ship safe software on a startup budget — because it prevents the most expensive failure mode: building the wrong thing and discovering it in the audit.

What EN 62304 actually requires

EN 62304:2006+A1:2015 clause 5.2 is titled "Software requirements analysis." It contains six sub-clauses that define what the SRS must include.

5.2.1 Define and document software requirements from system requirements. The SRS is derived from — and traceable to — the device-level system requirements. It is not invented in isolation by the software team.

5.2.2 Software requirements content. This is the substantive clause. It lists what the SRS shall include, as applicable: - functional and capability requirements - software system inputs and outputs - interfaces between the software system and other systems - software-driven alarms, warnings and operator messages - security requirements - usability engineering requirements affecting safety - data definition and database requirements - installation and acceptance requirements at the operation site - requirements related to methods of operation and maintenance - requirements related to IT-network aspects - user maintenance requirements - regulatory requirements

5.2.3 Include risk control measures. Risk control measures implemented in software (from the risk management file under EN ISO 14971:2019+A11:2021) shall be included in the software requirements.

5.2.4 Re-evaluate medical device risk analysis. When new risks or changes emerge from requirements analysis, the risk management file shall be updated.

5.2.5 Update system requirements. If software requirements analysis reveals issues with the system-level requirements, those shall be updated too.

5.2.6 Verify software requirements. The documented software requirements shall be verified against criteria that include: implementing system requirements, not contradicting each other, being expressed in unambiguous terms, being verifiable, being uniquely identified, and not contradicting the risk control measures.

Clause 5.2.6 is the quality gate. If the SRS fails 5.2.6, the auditor does not need to look further.

MDR Annex I §17.2 provides the legal backing: software must be developed according to the state of the art, taking into account the principles of development lifecycle, risk management, verification and validation. EN 62304 is the presumption-of-conformity route for §17.2, and clause 5.2 is how the SRS contributes.

MDR Annex II, the technical documentation annex, expects the notified body to be able to locate and review the SRS as part of the design and manufacturing information and the verification and validation results. In practice the SRS is referenced from the software documentation index and cross-referenced from the risk management file.

The six content categories, translated

Clause 5.2.2 can feel like a wall of bullets. Here is a practical reading for a startup SRS.

Functional and capability requirements. What the software does and how well it does it. "The system shall calculate the estimated glomerular filtration rate using the CKD-EPI 2021 formula within 200 milliseconds of receiving a complete input set." Specific action, specific performance, specific condition.

Interfaces. Inputs, outputs, and anything the software exchanges with the outside world: hardware, other software, users, networks. API contracts, data formats, protocols, error handling. "The software shall consume HL7 FHIR R4 Observation resources and reject resources that fail schema validation with error code INVALID_RESOURCE."

Environment and operational. Where the software runs. Operating systems, browsers, minimum hardware, network requirements, installation conditions. "The software shall operate on iOS 16.0 and later on devices supporting A12 Bionic or newer." Explicit environment boundaries prevent scope creep and support release criteria.

Data definition. The data the software handles. Structures, ranges, precision, validation, retention, integrity. Often neglected by startups until a vigilance event forces it. Includes personal data and clinical data handled under the device's intended purpose.

Safety, security and regulatory. Risk control measures from the risk management file. Cybersecurity requirements derived from EN IEC 81001-5-1:2022 where applicable. Regulatory requirements (MDR GSPRs, UDI display, eIFU access, logging and audit trails where mandated). Alarm and warning behaviour required for safety.

Usability requirements affecting safety. The bridge to EN 62366-1:2015+A1:2020. Requirements that prevent use errors that could lead to harm. "The system shall require explicit confirmation before deleting patient records." Not cosmetic UX preferences — safety-relevant interaction rules.

Requirement quality rules

Clause 5.2.6 expands into practical quality rules. A requirement is fit for purpose if it is:

Unambiguous. One interpretation only. No "fast," no "user-friendly," no "modern." Instead: "within 2 seconds," "following the Apple Human Interface Guidelines for dialog confirmation," "using TLS 1.3 or higher."

Verifiable. You can design a test that produces a yes/no answer. If you cannot describe the test in one sentence, the requirement is not verifiable.

Uniquely identified. One stable ID, one owner, one version. SRS-0142. Not "section 4.3 third bullet." IDs survive edits; positions do not.

Consistent. No requirement contradicts another. No requirement contradicts a risk control. No requirement contradicts the device-level claims or the intended purpose.

Traceable. Every requirement links upward to a system requirement or risk control and downward to at least one architecture element and at least one test case. If a requirement has no upward link, it is scope creep. If it has no downward link, it is untested.

Atomic. One requirement per statement. "The system shall log all access events and encrypt the log at rest and retain it for seven years" is three requirements pretending to be one. Split them.

A worked example

A startup building Class IIa cardiac monitoring software, safety Class B. The team inherited a 90-page SRS from an earlier contractor that failed a pre-audit review.

The root problems, identified in two days: 60 percent of requirements contained the word "appropriate." None of them were testable. Risk control measures from the risk management file appeared only as free text in a separate document — none were in the SRS, violating clause 5.2.3. There was no ID scheme, just section numbers, which broke every time someone reordered a chapter. The interface requirements referenced an API version that had been deprecated.

The fix took three weeks. The team rewrote 187 requirements to remove ambiguous language. They imported every risk control from the risk management file into the SRS as SRS-RC-xxx identifiers. They introduced SRS-FN-xxx, SRS-IF-xxx, SRS-EN-xxx, SRS-DT-xxx, SRS-SC-xxx and SRS-US-xxx prefixes matching the six categories. They linked each requirement to a system requirement ID and at least one test case.

The final SRS was 68 pages and 214 requirements — shorter than the original, with twice the content actually covered. The next notified body audit closed the software section with zero findings.

The Subtract to Ship playbook

Write the SRS in markdown under version control. Not Word. Not a wiki. Plain markdown in the same repository as the code. Review it in pull requests. This alone solves 80 percent of document control problems.

Pick the ID scheme on day one. Prefix by category. Sequential numbers. Never reuse. Never delete — mark as obsolete.

Import risk controls mechanically. Every risk control with software implementation becomes a requirement with a stable link to the risk ID. Automated where possible. Do this every time the risk management file changes.

Review for verifiability in pairs. For every new requirement, one engineer writes it and a second writes the test that would verify it. If the test cannot be written, the requirement is rewritten. This practice alone will eliminate most clause 5.2.6 findings.

Generate the traceability matrix from the source. Tags in markdown, scripts that parse them, matrix regenerated on every commit. Do not maintain a separate Excel file.

Version the SRS with the release. Every CE-marked release has a specific SRS version baselined in the release documentation. Nothing about this is optional.

For the broader lifecycle context, see our posts on software requirements under IEC 62304 and the full software documentation package. For traceability specifically, read software traceability across design, tests and risks. For the downstream document that the SRS feeds, see software architecture documentation under IEC 62304.

Reality Check

  1. Can every requirement in your SRS be verified by a test described in a single sentence?
  2. Does every requirement have a unique, stable identifier that survives document edits?
  3. Is every risk control from the risk management file represented as a requirement in the SRS?
  4. When a system-level requirement changes, does someone update the SRS the same week?
  5. Does your SRS include the six content categories from clause 5.2.2 explicitly?
  6. Can you regenerate your traceability matrix from source in under a minute?
  7. Is the SRS version for your current release archived in the release documentation?
  8. Has anyone deleted the word "appropriate" from your SRS this quarter?

Frequently Asked Questions

How long should an SRS be? For Class B software at startup scale, 40 to 120 pages is typical. Under 30 pages suggests gaps. Over 200 pages suggests the document is mixing design into requirements.

Can user stories replace formal requirements? User stories can be the input to requirements but cannot replace them. Clause 5.2.6 rules on unambiguity, verifiability and unique identification must still be met. Many teams keep both: user stories for planning, formal requirements for conformity.

Do I have to separate functional and non-functional requirements? EN 62304 does not mandate the split. It mandates that the six content categories are covered. Many teams find the split useful, others organise by feature. Either works if the content is complete.

Where do cybersecurity requirements go? In the SRS, in the security category. Derived from your threat model and from EN IEC 81001-5-1:2022 where applicable. They are requirements like any other — written, identified, verified, traced.

Can I use a requirements management tool? Yes. Polarion, Jama, Codebeamer, DOORS, and several lighter tools all meet EN ISO 13485:2016+A11:2021 document control if configured properly. The tool choice matters less than the discipline.

Does the SRS need sign-off? Your QMS defines the approval workflow. Most notified bodies expect at least one review and one approval, documented, before the SRS is used as the basis for architecture work.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17, Annex II.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clause 5.2.
  3. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.