"The device shall be easy to use" and "the parser shall reject malformed HL7 messages" don't belong in the same list. Levelling your requirements — user needs, system, software, hardware — is what makes validation, verification and risk control provable. Here's how to structure it without drowning in bureaucracy.
The FDA's design-control model — which ISO 13485's design and development clauses mirror — draws one line that explains the whole structure: verification confirms the design outputs meet the design inputs; validation confirms the device meets user needs and its intended use. Two different questions, answered against two different kinds of statements.
That's why a flat, single-level requirements list always breaks down. If everything from "intuitive for night-shift nurses" to "TLS 1.3 for all connections" lives in one list, you can't say what gets validated with users and what gets verified on the bench — and your traceability can't show that high-level intent actually decomposed into things that were built and tested.
Written in the user's language, free of solutions. Sources: intended purpose, clinical workflows, usability engineering, regulatory demands. These are what your validation — usability studies, clinical evaluation — is judged against.
The engineering restatement — what FDA calls design inputs. Each is testable, with acceptance criteria, and traces up to one or more user needs. Risk control measures from ISO 14971 enter the structure here (or below) as requirements like any other.
System requirements decompose to the discipline that implements them. For software this is the IEC 62304 software requirements level (clause 5.2) — the baseline your software architecture and software testing answer to. Hardware gets its own parallel set where it exists.
A software-only device (SaMD) often collapses levels 2 and 3 into a single software requirements level — legitimate, as long as user needs stay separate and the trace to risk controls and tests is kept. The rule of thumb: use the fewest levels that keep validation targets and verification targets apart. Levels you can't maintain are worse than levels you don't have.
| Source | What it asks of your requirements |
|---|---|
| ISO 13485 §7.3.2–7.3.3 | Design inputs must include functional, performance, usability and safety requirements, applicable regulatory requirements and risk management outputs — and must be reviewable, unambiguous and verifiable. Outputs must be traceable to inputs. |
| IEC 62304 §5.2 | A software requirements level distinct from system level: software requirements must be documented, analysed for completeness and consistency, and traceable to system requirements and to the risk controls implemented in software. |
| FDA design controls (QMSR) | The user-needs / design-inputs split is what makes design validation and design verification two different activities. Under the QMSR this now runs through ISO 13485's clauses, but the model is unchanged. |
| EU MDR | The intended purpose anchors the technical file; the GSPR matrix expects device requirements you can point at as the method of conformity, and Annex II §3 asks for the design information that connects them. |
The levels only pay off if the links between them are real: every system requirement traces up to at least one user need, every software requirement up to a system requirement, every row down to the verification that proves it — and risk controls thread through the same structure. Reviewers read this as a graph: pick a user need, walk down to the tests; pick a test failure, walk up to what's affected.
Two orphan checks tell you whether the structure is healthy. Orphan requirements — rows with no parent — mean someone is building things nobody asked for. Childless requirements — rows with no verification — mean promises nobody is checking. Both checks should run continuously, not the week before an audit, because both accumulate silently every time the requirements change.
FDA: Design Control Guidance for Medical Device Manufacturers — the origin of the user-needs / design-inputs / outputs model and the V&V split.
ISO 13485:2016 §7.3 (design and development) and IEC 62304:2006/AMD1:2015 §5.2 (software requirements analysis) — the clauses this structure answers to.
Threeqa keeps user needs, system and software requirements, risk controls and tests in one traced structure — so orphans surface the moment they appear, not the week before an audit. Book a 30-minute walkthrough.