Part 2 of a series. Part 1 — Writing Good User Needs for Medical Devices — covered the layer above this one. If you have not settled who your users are and what they must accomplish, stop and go do that first. Requirements written on top of undefined needs cannot be traced or validated.
Part 1 closed on two points: user needs are negotiated rather than gathered, and the most common failure is writing them after the design already exists.
Requirements have the mirror-image problem. They are almost always written — nobody forgets to write requirements — but they are written in the wrong layer, in the wrong number, or in a form that quietly cannot be verified. Nobody notices until verification, when a test engineer has to invent an acceptance criterion because the requirement did not supply one. At that point the acceptance criterion is being authored during verification rather than during design input definition, outside the design input review and approval that governs it.
This article addresses that defect.
1. What a requirement actually is
A requirement is a statement that identifies a characteristic or constraint of a system, product, or process, and that arises from an expressed need — meaning it traces to a user need or a stakeholder need. If it traces to neither, it is not a requirement and should not be carried in the design input set.
Recall the stack from Part 1:
- User need — what the user must accomplish, in their language, in their environment.
- Design input (requirement) — the engineering statement derived from that need, verifiable against the design.
- Design output — the thing you built, plus its acceptance criteria.
And the two questions:
- Validation — did we build the right thing? Tests against user needs.
- Verification — did we build the thing right? Tests against requirements.
Requirements are the entire load-bearing surface of verification. Every weakness you leave in a requirement becomes a weakness in the verification evidence, and verification evidence is what a reviewer actually reads.
What the standards require of design inputs
- ISO 13485:2016, clause 7.3.3 requires that inputs relating to product requirements include “functional, performance, usability and safety requirements, according to the intended use,” along with applicable regulatory requirements and standards, applicable outputs of risk management, information from previous similar designs where appropriate, and other essential requirements. The clause also requires inputs to be reviewed for adequacy and to be “complete, unambiguous, able to be verified or validated, and not in conflict with each other.”
- ISO 13485:2016, clause 7.3.4 requires design outputs to be “in a form suitable for verification against the design and development input” and to contain or reference product acceptance criteria. A requirement you cannot verify an output against is a requirement that broke clause 7.3.4 upstream.
- ISO 13485:2016, clause 7.3.6 requires verification against the input requirements, with documented verification plans that include “methods, acceptance criteria and, as appropriate, statistical techniques with rationale for sample size.”
- IEC 62304:2006, clause 5.2.2 enumerates what software requirements must cover, as appropriate to the device: 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; and usability engineering requirements that are sensitive to human errors and training.
That IEC 62304 list is a practical completeness checklist for a software requirement set. In our review experience, three categories are the most commonly incomplete: interfaces, software-driven alarms and operator messages, and security. Alarms and operator messages are frequently specified only in user interface design material and never entered into the requirement set, which means they are not verified against a requirement, not traced, and not reviewed as risk control measures. Action: check the requirement set explicitly against each of the six 5.2.2 categories during design input review.
A note on 21 CFR 820.30. Older training material, including the source deck for this article, quotes 21 CFR 820.30(c) for the design input requirement and 820.30(g) for design validation. That section was removed from the CFR effective 2026-02-04 under the QMSR transition. Cite ISO 13485:2016 clauses 7.3.3 and 7.3.7 instead. The substance of the old 820.30(c) language — inputs must be appropriate, address intended use including the needs of the user and patient, and include a mechanism for resolving incomplete, ambiguous, or conflicting requirements — survives in 7.3.3, so the practice does not change. Only the citation does.
2. The three types, and why collapsing them hurts
Part 1 made one rule non-negotiable: never merge a functional statement and a performance statement into one requirement. Here is the full taxonomy behind that rule.
| Type | What it specifies | Typical character | Example |
|---|---|---|---|
| Functional | The behavior of the system — what it shall do | Usually qualitative | The system shall extract the MEASURE from the image file. |
| Performance | A measure, constraint, or characteristic of a function | Qualitative or quantitative | The MEASURE shall be accurate to within +/-5%. |
| Non-functional | An attribute or characteristic of the system or its components; maps to architecture | Qualitative or quantitative | The system shall be deployable in a cloud environment. |
Three reasons the separation earns its keep:
- They verify differently. A functional requirement is often satisfied by demonstration or inspection. Its performance sibling usually demands a test with a numeric criterion and a sample-size rationale under ISO 13485 clause 7.3.6. Fused into one statement, you get one test that half-covers both, and a partial pass that nobody can interpret.
- They change on different clocks. Tolerances move with clinical evidence and with what the hardware can actually do. Behavior moves with scope. Fuse them and every tolerance negotiation reopens a behavioral requirement, with all the review and re-verification that implies.
- Non-functional requirements map to architecture, not features. “Cloud deployable” is not something a user does. It constrains the design, it belongs to the architects, and burying it inside a functional statement hides it from the people who need to act on it.
Performance requirements may be qualitative
A performance requirement may be qualitative. It specifies a measure or constraint on a function; it does not have to carry a number to do that. This is the requirement-layer echo of Part 1’s rule that verifiable does not mean quantified.
What it does not license is a vague adjective. “The measure shall be accurate” is not a qualitative performance requirement — it is an unverifiable one. The distinction is whether a defined evaluation method can produce an unambiguous pass or fail. A constraint stated as a defined condition, verified by analysis against a documented rationale, is legitimate. A constraint stated as an adjective is not.
3. The eight characteristics of a good requirement
These are the criteria the training material teaches, restated with the failure mode each one prevents.
Necessary
If you can delete the requirement and still satisfy the stakeholder and user needs, it was not necessary. If its intent is already met by other requirements, it was not necessary. Necessity is only assured by reviewing each requirement against the needs, objectives, constraints, and scenarios defined for the system — which means you cannot assess necessity requirement-by-requirement in isolation. It is a property of the set.
Failure mode it prevents: a specification inflated with restatements, each of which then requires its own verification evidence, review approval, and change record for the life of the product.
Implementation independent
Requirements should minimize constraints on implementation and ideally be independent of it. Expressing a requirement in implementation terms forecloses potentially better designs and forces a requirements change every time the implementation changes.
Failure mode it prevents: the same one Part 1 flags at the need layer — a solution locked in at the wrong altitude. The system shall store session data in a PostgreSQL table states a design decision rather than a requirement. The system shall retain session data across an unplanned power loss states the requirement; the database choice belongs to the design output.
Implementation independence is an objective, not an absolute. Some constraints are genuinely real — a mandated protocol, a platform an accessory must run on, a regulatory format. Document those as constraints with their source, rather than smuggling them into functional statements where they look like free design choices.
Unambiguous
The intent should be understood the same way by every responsible party and applicable stakeholder. Four practices support this:
- Use correct grammar.
- Use defined terms and acronyms drawn from a central glossary.
- Use precise quantifiers and qualifiers.
- Use definite articles.
Precise quantifiers and qualifiers address the most common source of ambiguity. “The system shall alert the user” does not identify which user role from the user profile; “Data shall be retained” does not identify which data. The central glossary matters for the same reason: if the risk management file and the requirement specification define a term such as ALARM differently, the risk control measures and the requirements are not describing the same behavior, and the discrepancy typically surfaces only at verification.
Complete
A requirement is complete only if it supports downstream implementation, verification, and traceability analysis. Each one must be understandable in its own right, as a complete sentence, without informal reference to other statements or documents.
Note the word informal. A formal reference — to a named standard, a defined term, a controlled interface specification — is fine and often required. What breaks is the implied reference: “as described above,” “per the previous requirement,” “consistent with the workflow.” Those references break when the document is reordered or a referenced statement is revised.
Singular
One function, one characteristic, or one constraint per statement. A requirement that can be decomposed into multiple requirements should be. Treat “and” joining two thoughts as a split signal, the same way Part 1 treats it at the need layer.
Failure mode it prevents: the partial pass. A compound requirement produces a test result that is neither pass nor fail, and the resolution of that ambiguity happens in a meeting rather than in the record.
Feasible
Requirements should be achievable within the agreed project scope. An unachievable requirement often indicates an important concern that has not been properly developed. Do not simply delete it. Something real drove it. Find out what, and write the requirement that actually expresses it.
Verifiable
Requirements should be verifiable by analysis, demonstration, inspection, or test — the same four methods Part 1 applies to validation. Only test demands a numeric acceptance criterion. To keep requirements verifiable:
- Specify correct functional behavior, conditions, and states clearly.
- Be precise in the ranges of quantitative constraints.
- Use objective criteria; avoid subjective criteria.
- Avoid ambiguous terms.
The practical discipline: name the verification method when you write the requirement, not when you write the protocol. If you cannot name one of the four, you have not finished the requirement. Deferring that decision to protocol authoring moves acceptance criteria definition outside design input review.
Consistent and unique
Two properties that only exist at the set level. No requirement may conflict with another — ISO 13485 clause 7.3.3 makes non-conflict an explicit adequacy criterion for design inputs — and no requirement should duplicate another under a different identifier. Duplicates tend to drift. One gets updated, the other does not, and now the specification contradicts itself with full traceability in both directions.
4. Completeness of the requirements set
Individually good requirements do not make a good requirement set. Completeness is judged against five things.
1. Every user need is addressed. The goal is the minimum set that is necessary and sufficient, and no more. “No more” is a real constraint, not a stylistic preference: every extra requirement is verification evidence you must produce and maintain for the life of the product.
2. There are no orphan tests. A test with no parent requirement means either an undocumented requirement, or effort spent verifying something nobody asked for. Both are findings. The inverse — a requirement with no test — is the one everyone already looks for; orphan tests are the direction people forget to check.
3. Risk management has been folded in, in both directions. This is the highest-value item on the list and the most frequently done halfway. The risk process contributes to requirement completeness two ways:
- Risk control measures are implemented as requirements. A control that lives only in the risk file is not implemented, not verified, and not traced.
- Risks introduced by system functions are analyzed, and so are new risks arising from the risk control measures themselves. The second half is where teams stop. A control measure is a design change; design changes create hazards; those hazards need the same treatment. When that loop is not closed, you get a risk file describing a device that no longer exists.
4. Every external interface is identified and defined, with interface requirements for each interaction within each interface. This is where Part 1’s allocation rule pays out. Needs that allocate outside your system of interest do not disappear — they become interfaces, and interfaces become requirements. IEC 62304 clause 5.2.2(c) makes interfaces between the software system and other systems explicit software-requirement content for exactly this reason.
5. Tracing is thorough and systematic from lower-level statements to higher-level ones. The chain is: user needs → requirements → test cases. Thorough tracing provides confidence in completeness; it does not by itself prove it. Trace coverage tells you every row has a partner. It cannot tell you the partner is any good, and it cannot tell you what is missing from both columns.
And carry Part 1’s identifier rule down into this layer unchanged: do not encode the trace in the identifier. REQ-UN-011-03 embeds a relationship inside a name, and every restructuring then becomes a rename cascade across the specification, the protocols, the test records, and the risk file. Opaque stable identifiers plus an explicit trace matrix. Relationships are data, not names.
5. Requirements across the lifecycle
Requirements are not a phase-gate artifact you finish and file. The maturity expected of the design input set changes by phase.
| Phase | Expected design input status |
|---|---|
| Definition and planning | High-level requirements analysis: user needs related to intended use defined; corresponding system functions defined; critical performance requirements identified or defined; feasibility understood. |
| Development, verification, validation | User needs and requirements defined; risk control measures integrated into requirements; traceability analysis complete. |
| Transfer to production | Minimize changes. Some changes may be driven by regulatory submissions. |
| Operations and maintenance | New requirements identified through the risk management and problem resolution processes; new user needs and requirements defined from the product roadmap. |
Two things worth drawing out.
“Critical performance requirements identified or defined” during planning. Not all of them — the critical ones. This provides the answer to the position that development cannot begin until the requirement set is complete: enough requirement definition is needed to establish feasibility. Feasibility of the critical performance requirements is the gate, not completeness of the whole set.
Changes do not stop at transfer. ISO 13485 clause 7.3.9 requires documented procedures to control design and development changes, and requires determining the significance of each change to function, performance, usability, safety, and applicable regulatory requirements before implementation. Post-transfer requirement changes are normal — they arrive from CAPA, from complaints, from problem resolution, from postmarket data. What is not normal is changing a requirement without running it back through that evaluation.
6. Rewrites: before and after
| Weak statement | Why it fails | Rewritten |
|---|---|---|
| The system shall be easy to use. | Subjective; no verification method exists. | Split into a usability requirement with a defined evaluation, traced to a usability objective and the use specification. |
| The system shall be compatible with image formats. | Written for the system with no defined outcome; ambiguous — which formats? | The system shall process images in the DICOM format defined in the interface specification. |
| The system shall store results in a PostgreSQL database and export them as CSV. | Implementation-locked and compound. | Split: (1) The system shall retain analysis results for the retention period defined in the data-retention specification. (2) The system shall export analysis results in a documented interchange format. Implementation choices move to the design output. |
| The measurement shall be accurate. | Performance requirement with no measure. | The measurement shall be accurate to within +/-5% of the reference standard across the specified input range. |
| The system shall not permit unauthorized access. | Negative phrasing; no bounded passing condition. | The system shall require successful authentication before granting access to protected health information. |
| The device shall alert the user on fault. | Ambiguous user; alarm content unspecified; not traceable to a risk control. | The system shall present an occlusion alarm to the clinician user when an occlusion condition is detected, per the alarm specification. Trace to the risk control measure it implements. |
Note the fifth row. Part 1 rejects “shall not” phrasing at the need layer, and the rule holds unchanged here: a negative statement has no bounded passing condition, and INCOSE practice is to state what must be achievable. Security requirements are frequently drafted in negative form (“shall not permit,” “shall not disclose,” “shall not allow”), and these are requirements where an unbounded passing condition is least acceptable. IEC 62304 clause 5.2.2(e) calls for security requirements; it does not call for them to be written as prohibitions.
7. A working review checklist
| Check | Pass condition |
|---|---|
| Traces upward | Links to a specific user need or stakeholder need, or to a documented risk control measure |
| Necessary | Cannot be deleted without losing need coverage; not restated elsewhere |
| Implementation independent | No mechanism, component, or technology unless it is a documented constraint with a stated source |
| Unambiguous | Defined terms from the central glossary; specific actor; precise quantifiers; definite articles |
| Complete | Stands alone as a sentence; no informal references to other statements |
| Singular | One function, characteristic, or constraint; no “and” tying two thoughts |
| Correct type | Functional, performance, and non-functional kept as separate statements |
| Feasible | Achievable in the agreed scope; if not, the underlying concern is developed instead of deleted |
| Verifiable | One of inspection, demonstration, test, or analysis is named now, not at protocol time |
| Consistent | No conflict with any other requirement in the set |
| Risk-linked | If it implements a risk control measure, the trace says so explicitly |
| Set-level | 62304 5.2.2 categories covered: function/capability, inputs/outputs, interfaces, alarms and operator messages, security, usability |
| Downward trace | At least one verification test case exists; no orphan tests in the other direction |
Closing point
Part 1 stated that user needs are negotiated rather than gathered. The equivalent point at the requirement layer is this.
The requirement set is the product, as far as the record is concerned. Not the code, not the hardware — those are outputs. When something goes wrong in the field years from now, the investigation does not start with what the device does. It starts with what the device was specified to do, and whether the evidence shows it did that.
Which means the most expensive requirement defect is never the badly worded one. Badly worded requirements get caught — by a reviewer, by a test engineer who cannot write a protocol, by someone asking what “efficient” means. The expensive defect is the requirement that is missing, because nothing downstream ever asks for it. No test fails. No trace breaks. The matrix is green in both directions. The only artifact that would have caught it is a risk analysis that actually ran the loop back through the risk control measures, and that loop is commonly truncated under schedule pressure.
When assessing whether a requirement set is complete, “is everything traced?” is not sufficient. The additional question is: what was decided not to require, where is that decision recorded, and who approved it? Record deliberate exclusions and their rationale in the design input review record.
Sources
- ISO 13485:2016, clause 7.3.3 (design and development inputs: functional, performance, usability, and safety requirements per intended use; adequacy review for completeness, unambiguity, verifiability, and non-conflict), clause 7.3.4 (outputs in a form suitable for verification against inputs; acceptance criteria), clause 7.3.6 (verification plans with methods, acceptance criteria, and sample-size rationale), and clause 7.3.9 (control of design and development changes; significance to function, performance, usability, safety, and regulatory requirements).
- IEC 62304:2006, clause 5.2.2 (software requirements content: functional and capability; inputs and outputs; interfaces to other systems; software-driven alarms, warnings, and operator messages; security; usability engineering requirements sensitive to human error and training).
- INCOSE requirement-phrasing practice: positive phrasing; singular statements; functional and performance requirements kept distinct; implementation independence.
- Highland Biomedical, General User Needs and Requirements Training (internal), for the characteristics-of-good-requirements framework, requirement typology, set-completeness criteria, and lifecycle design-input maturity table.
A note on 21 CFR 820.30. As in Part 1: 820.30 was removed from the CFR effective 2026-02-04 under the QMSR transition. Training material quoting 820.30(c) or 820.30(g) as current predates that change. Cite ISO 13485:2016 clause 7.3.3 for design inputs and clause 7.3.7 for design validation.
Part 1: Writing Good User Needs for Medical Devices
Highland Biomedical helps medical device companies build design controls, software lifecycle, human factors, and cybersecurity evidence that holds up under review.