Requirements traceability in IEC 62304
IEC 62304 asks that software requirements are uniquely identified, traceable to the system requirements or another source, stated so that tests can be defined, covered by tests at the system level, and re-tested after change; which activities apply turns on the software safety class.
- standard
- IEC 62304: medical device software life cycle processes
- edition held
- IEC 62304:2015, as the export names it
- clauses cited here
- 11 of the 99 held; shown when you tick IEC 62304
- every clause we hold
- IEC 62304, clause by clause
Where each finding cites it
- 1Requirement with no parent: 5.2.6
- 2No verification method or no linked verification: 5.1.6 and 5.7.1
- 3Verification failed, blocked or not run: 5.5.5 (software unit or detailed designs and low-level requirements), 5.6.7 and 5.8.1
- 4Changed after its last passing verification: 5.6.6 and 5.7.3
- 7Parent outside this export, or an ID used twice: 5.2.6
- 8Wording that may not be verifiable: 5.2.6
- 10Safety-rated requirement with no hazard or risk link: 5.2.3, 7.2.2 and 7.3.3
The columns that show it
Parent, Level, Derived, Verification Method, Verified By, Justification, the results: Result and Date, Last Changed, the result dates, Revision and the results: Requirement Revision, ID, Requirement Text, Hazard or Risk and Safety rating. The requirements traceability matrix template carries every one.
What it asks, clause by clause
11 clausesThe manufacturer verifies and documents that the software requirements implement the system requirements including those for risk control, do not contradict one another, avoid ambiguity, are stated so that test criteria can be established and tests performed, can be uniquely identified, and are traceable to system requirements or another source; no formal specification language is required. Applies to classes A, B and C.
Applies to software safety class A, B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements review record against the six criteria; traceability matrix.
where it usually breaks Requirements that cannot be tested as written.; Unnumbered requirements.
The plan contains, or points to, the verification information: which deliverables need verifying, what verification is done for every life cycle activity, at which milestones deliverables are verified, and the criteria for accepting that verification. Applies to classes A, B and C.
Applies to software safety class A, B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Verification plan with deliverables, tasks, milestones and acceptance criteria.
where it usually breaks Verification planned as 'review' with no acceptance criteria.
For software system testing, a set of tests covering every software requirement is defined and run, each stated in terms of inputs, expected results, pass or fail criteria and procedure, and the suitability of the verification strategies and test procedures is evaluated. Requirements may also be tested at earlier stages or in combination. Applies to classes A, B and C.
Applies to software safety class A, B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see System test specification covering every requirement; procedure adequacy evaluation.
where it usually breaks Requirements with no test.; Tests with no expected outcome stated.
Software unit verification is performed and the results documented. Applies to classes B and C.
Applies to software safety class B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Unit verification results.
where it usually breaks Unit test results discarded after a passing run.
The integration test record documents the result (pass or fail with a list of anomalies), retains enough to repeat the test (test case specifications with actions and expected results, equipment, test environment including tools), and identifies the tester. Applies to classes B and C.
Applies to software safety class B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Integration test records with the three contents.
where it usually breaks Test records that cannot say which environment produced them.
All software verification activities are completed and their results evaluated before the software is released. Applies to classes A, B and C.
Applies to software safety class A, B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Verification completion evidence at release.
where it usually breaks Release with open verification tasks deferred to 'post-release'.
Whenever software items are integrated, suitable regression tests are run to show that the software already integrated has not acquired new defects. Applies to classes B and C.
Applies to software safety class B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Regression test records.
where it usually breaks No regression testing after late integrations.
If changes are made during system testing, tests are rerun, adjusted or added to confirm that the change fixes the problem and that it has caused no unintended side effects, and the risk management activities in 7.4 are carried out. Applies to classes A, B and C.
Applies to software safety class A, B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Retest and regression records tied to each change; 7.4 analysis.
where it usually breaks Fix verified only by rerunning the failing test.
Where appropriate, the software requirements include the risk control measures that software provides against hardware failures and possible software defects, accepting that these may appear and change as design and risk control progress. Applies to classes B and C.
Applies to software safety class B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements traceable to risk control measures in the risk management file.
where it usually breaks Risk controls implemented in code with no requirement to test them against.
If a software item's functions carry out a risk control measure, that measure is written into the software requirements, the item contributing to it receives a safety class reflecting the risk the measure controls, and the item is developed following clause 5. Applies to classes B and C.
Applies to software safety class B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Requirements and class assignment for risk-control software items.
where it usually breaks Risk control implemented in a class A item developed without clause 5 rigour.
Where appropriate, the traceability of software hazards is recorded along the chain: hazardous situation to software item, software item to the specific cause in software, cause to its risk control measure, and measure to the verification of that measure. Applies to classes B and C.
Applies to software safety class B and C: a line of another class does not carry it.
Held text: IEC 62304:2015, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Four-link traceability in the risk management report.
where it usually breaks Traceability that stops at the risk control measure.
Named, not quoted
- ISO 14971 (application of risk management to medical devices): the risk management standard IEC 62304 and ISO 13485 point to for the hazard analysis a medical device requirement traces to; not in the held clause set, so named and never quoted. Named, not quoted: we do not hold its text.