Safety Hazard Management: The Role of Requirements in Safety-Critical Systems

1. What Are Safety Requirements?

Safety requirements are a specific category of system requirements whose purpose is to mitigate or eliminate identified hazards. They do not exist in isolation — every safety requirement traces back to a hazard that has been identified through structured analysis.

There are two distinct types of safety requirements:

• Safety functional requirements define what the system must do to achieve or maintain a safe state. For example: "The braking system shall bring the vehicle to a complete stop within 50 metres from 100 km/h on a dry surface."
• Safety integrity requirements define how reliably the safety function must perform. This is expressed as a Safety Integrity Level (SIL) in IEC 61508, an Automotive Safety Integrity Level (ASIL) in ISO 26262, or a Design Assurance Level (DAL) in DO-178C. The integrity level determines the rigour of the development and verification process.

The hierarchy of safety requirements typically follows this structure:

1. Stakeholder needs and legislation — regulatory obligations, operational safety targets, and duty-of-care requirements.
2. System safety requirements — derived from hazard analysis, specifying what the system must do (or must not do) to be acceptably safe.
3. Allocated safety requirements — system safety requirements allocated to specific subsystems: hardware, software, or operational procedures.
4. Detailed design requirements — implementation-level specifications that satisfy the allocated safety requirements.

2. How Safety Requirements Fit Within Systems Engineering

Safety requirements sit within the broader systems engineering framework. They are not a separate activity — they are integrated into the requirements engineering process at every stage of the V-model.

The relationship follows a clear sequence:

1. Concept of operations — defines how the system will be used, including the operating environment, user interactions, and foreseeable misuse scenarios.
2. Hazard identification — structured analysis (HAZOP, FMEA, FTA, etc.) identifies what can go wrong and the potential consequences.
3. Safety requirements specification — hazards are addressed through safety requirements that are added to the system requirements specification. The safety requirements specification (SRS) is a subset of the overall system requirements.
4. Allocation — safety requirements are allocated to hardware, software, or operational procedures, depending on the system architecture.
5. Design and implementation — the design team implements solutions that satisfy the allocated safety requirements.
6. Verification — each safety requirement is verified through test, analysis, demonstration, or inspection.
7. Safety case — the evidence is assembled into a structured argument demonstrating that the system is acceptably safe.

At every stage, traceability is mandatory. The thread from hazard through to verification evidence must be unbroken. This is what safety authorities and independent assessors examine during review.

3. Safety Hazard Identification Methods

Hazard identification is the process of systematically discovering what can go wrong with a system and what the consequences would be. Each method produces outputs — hazard scenarios, failure modes, fault paths — that must be translated into traceable safety requirements.

No single method captures all hazards. Most safety-critical programmes use a combination of techniques at different stages of the lifecycle.

4. The Safety Lifecycle

IEC 61508 established the concept of the safety lifecycle — a structured sequence of phases that governs the development, operation, and decommissioning of safety-related systems. The fundamental principle is that safety must be managed throughout the entire lifecycle, not added as an afterthought.

The safety lifecycle includes three interrelated sub-lifecycles:

• Overall safety lifecycle — from concept through hazard analysis, requirements, design, installation, validation, operation, modification, and decommissioning.
• E/E/PE system safety lifecycle — covers the development of electrical, electronic, and programmable electronic systems that implement safety functions.
• Software safety lifecycle — covers the development of software within safety-related systems, with rigour determined by the Safety Integrity Level.

Safety Integrity Levels (SIL)

IEC 61508 defines four Safety Integrity Levels (SIL 1 through SIL 4), where SIL 4 represents the highest integrity and the most stringent development and verification requirements. The SIL determines:

• The rigour of the requirements specification process
• The verification methods required (e.g., formal methods may be mandatory at SIL 3-4)
• The level of independence required for verification and validation
• The degree of documentation and traceability evidence

IEC 61508 mandates bidirectional traceability throughout the safety lifecycle — backward traceability (every implementation decision justified by a requirement) and forward traceability (every requirement has corresponding verification evidence).

5. Building a Safety Case

A safety case is a structured argument, supported by evidence, that a system is acceptably safe for its intended use in its intended environment. It is the document that brings together hazard analysis, safety requirements, verification evidence, and risk acceptance decisions into a single coherent argument.

There are two broad approaches to constructing a safety case:

Prescriptive approach

Safety is demonstrated by showing compliance with a prescribed standard. The standard defines what must be done — the developer follows the rules and provides evidence of compliance. This approach is common in:

• Aviation — DO-178C defines objectives that must be met at each Design Assurance Level. Compliance with the objectives constitutes the safety argument.
• Automotive — ISO 26262 prescribes a safety lifecycle with specific work products and methods required at each ASIL.

Goal-based approach

The developer constructs their own argument for why the system is safe, rather than following a checklist. The argument is structured using techniques such as Goal Structuring Notation (GSN), which breaks the top-level safety claim into sub-goals, strategies, and evidence. This approach is common in:

• UK rail — EN 50129 requires a safety case built around a structured argument, assessed by an Independent Safety Assessor (ISA).
• UK nuclear — operators must present a safety case demonstrating acceptable risk, based on the ALARP (As Low As Reasonably Practicable) principle.
• UK offshore oil and gas — the Safety Case Regulations (post-Piper Alpha disaster) require operators to construct a safety case for each installation.

6. Safety Requirements Verification and Acceptance

Every safety requirement must be verified — that is, proven through objective evidence to have been met. The four recognised verification methods (IADT) apply to safety requirements just as they do to all system requirements:

• Inspection — visual examination of a work product. Used for physical characteristics, labelling, wiring, and documentation completeness.
• Analysis — mathematical models, simulations, or analytical calculations. Used when physical testing is impractical (e.g., structural integrity under extreme loads, MTBF predictions).
• Demonstration — operating the system to show it works as required, without detailed measurement. Used for functional capabilities visible to the observer.
• Test — exercising the system under controlled conditions with measured results compared to acceptance criteria. The most rigorous method, used when quantitative evidence is required.

Independent verification

Safety-critical systems typically require independent verification — the verification must be performed or reviewed by a person or organisation independent of the development team. The level of independence depends on the Safety Integrity Level:

• SIL 1-2: Verification may be performed by a different person within the same team.
• SIL 3-4: Verification should be performed by an independent department or an external organisation.

Key roles in safety verification include the Independent Safety Assessor (ISA) in rail, the Designated Engineering Representative (DER) in aviation, and the Notified Body in medical devices under the EU MDR.

Acceptance criteria

Every safety requirement must have measurable, unambiguous acceptance criteria defined during requirements analysis — not left until the test phase. A requirement like "the system shall be safe" is not verifiable. A requirement like "the emergency stop shall halt all moving parts within 0.5 seconds of activation" has clear acceptance criteria that can be tested.

7. Managing Safety Risk: Assumptions, Constraints, and Dependencies

Safety risk does not sit only in identified hazards. A significant portion of residual risk lives in the assumptions, constraints, and dependencies (ACDs) that underpin the safety argument. Open ACDs represent unresolved safety risk — and must be actively managed throughout the project lifecycle.

Assumptions

An assumption is a factor believed to be true but not yet confirmed. In a safety context, assumptions are particularly dangerous because safety requirements derived under a false assumption may be invalid.

Example: "The operating environment temperature will not exceed 50°C." If this assumption is later found to be false, every safety requirement derived under it must be reassessed. Material properties, cooling system capacity, and sensor accuracy may all be affected.

Constraints

A constraint is an imposed limitation on the design or implementation. In safety, constraints may prevent the use of preferred hazard controls, forcing reliance on lower-tier controls in the hierarchy.

Example: "Existing track geometry cannot be modified." This constraint may prevent elimination of a hazard through redesign, requiring engineering controls or operational procedures instead — a less effective mitigation that must be justified in the safety case.

Dependencies

A dependency is a reliance on another party, system, or condition. In safety, an unmet dependency means a safety function may not work as intended.

Example: "The signalling system depends on the telecommunications provider's network availability of 99.99%." If the dependency is not met, the safety function fails. Each dependency should generate a safety requirement on the interface — and should be tracked to closure.

8. Safety Standards Across Industries

Different industries have developed their own safety standards, but most are derived from or aligned with IEC 61508 as the foundational standard for functional safety. Each standard defines how safety requirements must be identified, specified, and verified — with varying levels of rigour depending on the safety classification.

9. The Hierarchy of Controls

The hierarchy of controls is a framework for selecting hazard mitigation measures in order of effectiveness. The most effective controls eliminate the hazard entirely; the least effective rely on human behaviour. MIL-STD-882E's "system safety design order of precedence" mirrors this hierarchy.

The key insight for requirements engineers: each control measure must be expressed as a verifiable safety requirement. The hierarchy tells you what kind of control to prefer; requirements engineering tells you how to specify and verify that control.

• 1. Elimination — Remove the hazard entirely Example requirement: "The system shall not use mercury-based components in any assembly."
• 2. Substitution — Replace with something less hazardous Example requirement: "The system shall use water-based coolant in place of glycol-based coolant in all operator-accessible circuits."
• 3. Engineering Controls — Isolate people from the hazard Example requirement: "The system shall include a physical guard preventing operator access to moving parts during operation. The guard shall be interlocked such that the machine cannot operate when the guard is open."
• 4. Administrative Controls — Change the way people work Example requirement: "The operating procedure shall require lockout/tagout before any maintenance activity on the drive system."
• 5. PPE — Protect the individual (least effective) Example requirement: "The operator shall wear heat-resistant gloves rated to 250°C when performing manual valve operations on the steam circuit."

10. Why Requirements Management Is Foundational to Safety

Every concept covered in this guide — hazard identification, the safety lifecycle, safety cases, verification, ACDs, and the hierarchy of controls — depends on the same thing: traceable, verifiable, managed requirements.

• Every hazard identification method produces outputs that must become traceable safety requirements.
• The safety lifecycle mandates bidirectional traceability from hazard through to verification evidence.
• The safety case is an argument built on evidence — and that evidence is structured around requirements and their verification.
• Assumptions, constraints, and dependencies are risk items that attach to requirements and must be tracked to closure.
• Regulatory audits and independent safety assessments depend on being able to follow the unbroken thread from hazard to requirement to evidence.

Reqi provides the requirements management infrastructure that supports this. It is not a safety tool — it is the foundational layer that makes safety requirements traceable, compliance visible, and risk items auditable across your supply chain. Learn how Reqi works across regulated industries.

See It in Action

Watch how safety hazards are identified and managed within a requirements management workflow.