10 Safety-rated requirement with no hazard or risk link
The requirement carries a safety rating, so it exists to control a hazard or to meet a safety goal, and the paste has a column for that link, but this cell is blank. The link may be kept elsewhere, in the risk file or the hazard analysis; the question is where.
- the test
- only when the paste carries a hazard, risk or safety goal column: a requirement with a safety rating above QM, DAL E or class A whose link cell is blank
- the question
- Which hazard, risk control measure or safety goal does this requirement serve, and where is that link recorded?
- asked of
- the safety or risk lead
- columns it reads
- Hazard or Risk and Safety rating
Only when the paste carries a hazard, risk or safety goal column; without one this finding never appears. ISO 14971 is named, not quoted: we do not hold its text.
The clauses behind it, by standard
each shown when you tick its standard- ISO 26262: Part 3, 7.4.2 and Part 8, 6.4.1
- IEC 62304: 5.2.3, 7.2.2 and 7.3.3
- ISO 13485: 7.3.3
The clause text
Functional safety requirements are obtained from the safety goals together with the preliminary architectural assumptions, stating for each the operating modes, the fault tolerant time interval, the safe states, the emergency operation interval and the functional redundancies where relevant, and assigned to parts of the system architecture, to external measures or to driver actions, with the ASIL inherited from the safety goal or decomposed per part 9. Sub-clause title from the held contents page; the clause's objectives quoted by a certification body; requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Functional safety requirements with ASIL, safe state and FTTI; Allocation of functional safety requirements to architectural elements
where it usually breaks Functional safety requirements left unallocated or allocated to elements with no stated ASIL
Safety requirements are specified through the hierarchy from safety goals to functional, technical, hardware and software safety requirements, with each requirement derived from and traceable to the level above, allocated to an element, and specified in natural language or in an informal, semi-formal or formal notation per the standard's table by ASIL. Requirement text not held.
Held text: ISO 26262:2018, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Safety requirements hierarchy with derivation and allocation
where it usually breaks Requirements written at one level with no traceability to the safety goals
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.
The organization determines and records the design and development inputs that relate to product requirements. These include the functional, performance, usability and safety needs arising from the intended use; applicable regulatory requirements and standards; relevant risk management outputs; information from earlier similar designs where appropriate; and any further requirements essential to designing the product and its processes. The inputs are reviewed for adequacy and approved. Requirements must be complete and unambiguous, must be capable of verification or validation, and must not contradict each other.
Held text: ISO 13485:2016, our statement of the clause, not the instrument verbatim.
what an assessor asks to see Design input specification covering functional, performance, usability, safety, regulatory and standards requirements; Risk management outputs incorporated as inputs; Record of input review for adequacy and approval; Evidence each input is verifiable or validatable and free of conflict
where it usually breaks Usability requirements absent from inputs; Risk controls identified in the risk file never entered as design inputs; Inputs approved without a check for ambiguity or conflict