Software Requirements: Risk Management (ISO 14971 Hazards & Controls)¶
Prepared toward requirements baseline v1.7 (ADR-0078/0079; ISO 14971 risk management as the domain shape). Risk and risk-control ITEMS and a risk-score RECORDING live in the tool; the scoring scale and how a level is calculated are CONTENT (the scope's Risk Management Plan) — the tool records tokens, it never computes or endorses a level.
| ID | Requirement | Trace |
|---|---|---|
| REQ-RISK-001 | A risk shall be a keyed trace item (node risk, fence :::risk) inside a risk-analysis-capable controlled document, mirroring one row of an ISO 14971 risk table with the FIXED attribute set: hazard, hazardous situation, harm; an INITIAL and a RESIDUAL score triple, each as free tokens supplied from the scheme — severity, P1 (probability of the hazardous situation arising), P2 (probability it then leads to harm), and the risk level; and an acceptability outcome (acceptable | not-acceptable) that is the CURRENT-evaluation outcome, not a residual-only field. The tool shall RECORD these tokens and shall NEVER compute a level from S and P nor validate them against a matrix — the scale and the level calculus are CONTENT (the scope's Risk Management Plan, tied via a document relation); a score shall render as recorded tokens (S3 · P1 · P2 — High), never as a formula. The descriptive narrative (sequence of events, rationale, benefit-risk justification) is the block body. |
STR-001, STR-009, STR-027; ADR-0079, ADR-0078, ADR-0082 |
| REQ-RISK-002 | A risk control shall be a keyed trace item (node riskControl, fence :::risk-control) carrying the fixed attribute controlKind from the normative ISO 14971 §7.1 priority order (inherent-safety-by-design | protective-measure | information-for-safety); the control description is the body. A control's relationships to risks and to its realization and verification shall be EDGES, not attributes (REQ-REL-007): mitigates (control → risk, many-to-many), implemented-by (control → a requirement item OR an SOP/WI document — an information-for-safety or organizational control is realized by a procedure, not a product requirement), and verifies (document → control). Whether a document type may define risk / risk-control items shall be governed by the per-(scope, type) may-define flag (REQ-DOC-034), and their keys shall share the one scope-wide keyspace. |
STR-001, STR-009, STR-027; ADR-0079, ADR-0078 |
| REQ-RISK-003 | The system shall derive, per scope, a live risk-traceability read model (rows = risks: initial score → mitigating controls → each control's implementation and verification → residual score + acceptability) with completeness gap flags — risk with no mitigating control, control not implemented, control not verified, residual not acceptable. A risk with ZERO mitigating controls AND no residual score recorded AND acceptability acceptable shall be treated as COMPLETE — "accepted without reduction" (ISO 14971 permits no reduction when the initial risk is already acceptable) — and shall NOT raise the "risk without control" flag; a residual score recorded without a control shall still raise its own flag. The "control not implemented" gap shall clear when the control carries ANY implemented-by target of either form (requirement item or document). Derivations shall be live (no stored state); a link target invisible to the caller or disposed shall degrade to inert text, never a leak. |
STR-009, STR-011, STR-027; ADR-0079 |