Article
Card image cap for article

Requirements engineering, medical device, software

Medical Devices

2/14/2026

Motivation

Requirements are the backbone of every medical device software project. They help manufacturers stay compliant, pass audits, meet release goals, and build quality into the product from the start. IEC 62304 sets requirements for software requirements, but the guidance is quite limited. This article shares practical recommendations to close that gap.

What IEC 62304 Actually Requires (and What It Doesn't)

IEC 62304 gives only limited guidance on how to create good requirements. It assumes there are already system requirements, and that software requirements are derived from them. That fits embedded software in a larger device, but for standalone SaMD the manufacturer often has to create the system requirements first.

IEC 62304 dedicates only six sub-clauses (5.2.1–5.2.6) to software requirements analysis, and most of them apply to all safety classes (A, B, and C), with one exception.

The normative “musts” are:

  • 5.2.1 – Define and document software requirements derived from system-level requirements.
  • 5.2.2 – Include content across twelve categories: functional/capability requirements, inputs/outputs, interfaces, alarms/warnings, security requirements, user interface requirements, data/database requirements, installation/acceptance, operation/maintenance, IT-network aspects, user maintenance, and regulatory requirements.
  • 5.2.3 – Include risk control measures implemented in software as requirements (Class B, C).
  • 5.2.4 – Re-evaluate the medical device risk analysis when software requirements are established.
  • 5.2.5 – Update existing requirements (including system requirements) as a result of the software requirements analysis.
  • 5.2.6 – Verify that each requirement implements system requirements (including risk controls), is free from contradiction, unambiguous, testable, uniquely identifiable, and traceable to its source.

IEC 62304 tells us what to address but gives almost no guidance on how deeply or how to structure requirements. Note 8 under 5.2.2 even hints at this gap: “Among others, ISO/IEC 25010 provides information on quality characteristics that may be useful in defining software requirements.”

Functional vs. Non-Functional Requirements

A clear distinction between functional and non-functional requirements is essential for complete coverage.

Functional requirements

Definition

Functional requirements describe what the software does – its features, behaviors, computations, and data transformations.

Examples

Examples: “The system shall calculate the infusion rate based on the prescribed dose and patient weight,” or “The app shall display a warning notification when a risk encounter is detected.”

Non-functional requirements

Definition

Non-functional requirements (also called quality requirements) describe how well the software performs those functions, its speed, reliability, security posture, usability, and maintainability.

Examples

Examples: “The system shall respond to user input within 200 ms,” or “The system shall encrypt all data at rest using AES-256.”

IEC 62304 clause 5.2.2 covers both: items (a) through (g) are mostly functional, while performance targets in (a), security in (e), IT-network aspects in (j), and regulatory constraints in (l) drive non-functional requirements.

Typical gaps

The challenge is that teams often focus on functional requirements and neglect the non-functional ones – leading to gaps that auditors and, more importantly, real-world usage will expose.

ISO/IEC 25010: The Catalogue That Fills the Gap

ISO/IEC 25010:2023 provides a structured product quality model with nine characteristics, each broken into sub-characteristics. It can be used as a checklist [1, 2] to prompt requirement discussions across the team.

Article content

The 2023 edition added Safety as a ninth characteristic, directly relevant to medical devices and covering operational constraints, hazard warning, safe integration, and fail-safe behavior.

ISO/IEC 25010 can be considered as the implementation guidance that IEC 62304 clause 5.2.2 deliberately leaves open. Every 25010 characteristic can generate requirements that map to one or more of the twelve IEC 62304 content categories.

Security Requirements: Where IEC/TR 80001-2-2 Comes In

IEC 62304 clause 5.2.2(e) explicitly requires security requirements, covering compromise of sensitive information, authentication, authorization, audit trails, and communication integrity/malware protection. But how do we systematically derive those requirements?

IEC/TR 80001-2-2 defines 19 security capabilities that serve as a structured catalogue for medical device security controls. These include, among others:

  • PAUT / AUTH – Person authentication and authorization
  • AUDT – Audit controls and logging
  • TXCF / TXIG – Trusted communication channels and transmission integrity
  • MLDP – Malware detection/protection
  • SAHD – System and application hardening
  • CSUP – Cybersecurity product upgrades (patching)
  • DTBK – Data backup and disaster recovery
  • EMRG – Emergency access
  • DIDT – Health data de-identification
  • CNFS – Configuration of security features

Each capability comes with guiding questions. For example, under AUDT: “Does the device generate tamper-resistant, time-stamped audit logs of security-relevant events? Can audit data be exported to the organization's SIEM?”

AAMI TIR57:2016 is another helpful source to identify the security characteristics a device should have, through a questionnaire provided in Annex D.

The MDS2 (Manufacturer Disclosure Statement for Medical Device Security) aligns with these frameworks, containing 216 questions across 23 security capabilities. FDA's 2023 premarket cybersecurity guidance and AAMI TIR57 also map directly to the 80001-2-2 capability set.

The risk-based argument: Requirements and documentation depth should be proportionate to risk (ISO 14971). IEC/TR 80001-2-2 helps us identify which security controls are relevant to the device's risk profile, connectivity, and intended use environment. It is not necessary to implement all 19 capabilities at maximum depth for every device. The catalogue can be used to systematically determine which ones matter, derive requirements from those, and document the rationale.

Note: IEC/TR 80001-2-2:2012 is currently being revised and will be replaced by IEC/TS 81001-2-2, which consolidates and updates the security capabilities framework.

Testing Requirements: Verification, Traceability, and Coverage

IEC 62304 is explicit that every requirement must be stated in terms that permit establishment of test criteria and performance of tests (5.2.6). Here is the verification chain the standard expects:

  • Software unit verification (5.5.2–5.5.5) – Establish strategies and acceptance criteria, execute, document results (Class B, C).
  • Integration testing (5.6.3–5.6.7) – Test integrated software items including risk control measures, interfaces, and abnormal conditions; conduct regression tests; document pass/fail and anomalies.
  • Software system testing (5.7) – Demonstrate that the software system meets its requirements, including execution in the intended environment.

Traceability is non-negotiable. Clause 5.2.6(f) requires each requirement to be traceable to system requirements or another source. IEC 62304 also requires to verify and document that the software architecture implements the system and software requirements (including risk controls). This can be shown with traceability links.

Important: IEC 62304 expects traceability to be planned early (in the software development plan), not added at the end.

The informative Annex B recommends that traceability be maintained as data items in a common database – supported by tools ranging from simple hypertext documents to full CASE/requirements management tools.

Coverage means demonstrating that every requirement has at least one test, and every risk control measure implemented in software is verified. IEC 62304 clause 5.7.4 requires to evaluate the adequacy of the verification strategies and test procedures, which in practice means demonstrating sufficient coverage of requirements.

In practice, a requirements traceability matrix (RTM) linking system requirement → software requirement → test case → test result is the standard audit artefact.

Interestingly, traceability from software requirements to software architecture is not demanded in the IEC 62304, but a traceability analysis can cover this completeness check [3].

A Real-World Example: The Corona-Warn-App Scoping Document

One of the best publicly available examples of how to write structured, testable requirements for a health-related app is the Corona-Warn-App (CWA) scoping document on GitHub [4].

The CWA team used a person-centric methodology: the process flow was designed from the user's perspective, mapped as a user journey, organized into epics (high-level requirement groups), and broken down into user stories with explicit acceptance criteria.

For example:

“E06.03 – As an app user, if I receive a positive test result, I want to be able to grant my consent to sending the pseudonymized IDs under which I was visible to other people in recent days to the Warn server, so that the people I have been in contact with can be warned by their apps.”

Acceptance criteria

  • IDs can be sent pseudonymized.
  • Data transmission only possible if verified beforehand.
  • Data transmission only after user consent.

This is an excellent model because each user story is uniquely identifiable, testable via its acceptance criteria, and traceable to a specific epic and user journey step, satisfying IEC 62304 clause 5.2.6 criteria almost by design.

The document also covers non-functional aspects like accessibility (E09.01–E09.03), content management (E10.01), and parameter configurability (E07.01).

Note: CWA was not developed as a medical device.

Key Points and Practical Guidance

Key recommendations include:

  • Categorize each software requirement according to the 62304 categories (functional, non-functional, I/O, interfaces, security, UI, data, regulatory, etc.).
  • Determine the risks associated with each requirement; link requirements that implement risk control measures to the risk management file, so traceability can be shown.
  • Ensure traceability from system requirements to software requirements and finally to verification tests.

It is helpful to use UI mockups or wireframes as part of user interface requirements, which also helps satisfy IEC 62366-1 usability engineering requirements.

Bringing It All Together

Requirements engineering for medical device software isn't just a documentation exercise, it's a risk management activity. The standards ecosystem works as layers:

  • IEC 62304 sets the normative baseline: define, categorize, include risk controls, verify, trace.
  • ISO/IEC 25010 provides the quality characteristic catalogue to ensure we don't miss non-functional dimensions.
  • IEC/TR 80001-2-2 (and its siblings TIR57/MDS2) provides structured security capabilities with guiding questions to derive security requirements proportionate to the device's risk profile.
  • ISO 14971 governs the risk-based rationale: documentation depth and control rigor should be proportionate to the risk, not uniform across all features.

The practical takeaway: write requirements that are uniquely identifiable, testable, traceable, categorized, and risk-linked.

The CWA scoping document [4] serves as inspiration for structure. ISO/IEC 25010 can be used as a non-functional requirements prompt sheet. IEC/TR 80001-2-2 acts as a security requirements generator. A living traceability matrix should be maintained that connects every requirement to its source, its tests, and its risk context.

Good requirements don't just satisfy auditors, they prevent defects and contribute to quality- and security-by-design.

References

Go back