Functional Safety: Getting Safety Requirements Right

08 Jul 2026

The Foundation of IEC 61508 and IEC 61511 Compliance

In functional safety, not all failures begin in hardware, software, or even integration – many are systematic issues that are introduced much earlier, during the definition of safety requirements.

IEC 61508 and IEC 61511 are explicit: the safety requirement specification (SRS) is not a supporting document – it is the foundation of the required risk reduction and related safety function design. It translates hazards into engineered controls, defines the expected performance of those controls, and provides the baseline against which the system is ultimately validated.

Put simply:

If the requirements are wrong or incomplete, everything built on top of them is fundamentally flawed.

The SRS: Where Risk Becomes Engineering

Both IEC 61508 and IEC 61511 position the SRS at a critical point in the lifecycle – after hazards have been identified, but before any meaningful design begins. It is the moment where risk is translated into something engineers can actually build.

In IEC 61511, this typically takes the form of defined safety instrumented functions (SIFs), each linked to a specific hazardous scenario and assigned a target safety integrity level (SIL). In IEC 61508, the scope is broader, but the principle is the same: the SRS defines what the system must do, under what conditions, and with what level of integrity.

What is often underestimated is how much of the eventual system behaviour is already locked in at this stage. Architecture decisions, diagnostic strategies, response times, and even maintenance assumptions all trace back to how the requirements were written. If those requirements are vague or incomplete, the design team doesn’t stop – they attempt to fill in the gaps. And when that happens, safety becomes dependent on undocumented assumptions rather than defined intent.

Accuracy is About Clarity

There is a tendency to equate a “good” SRS with a long one, spanning over several pages, full of references and detailed information. In practice, the size of the SRS is irrelevant. What matters is whether the requirements are clear, traceable and can be objectively verified.

In practice, SRS reviews consistently highlight the same issue – ambiguity, and this is the real issue. Phrases such as “the system shall respond quickly” or “the function shall be reliable” appear surprisingly often in early drafts. They feel reasonable, but they provide no engineering value. One engineer may interpret “quickly” as 100 milliseconds, another as one second. Both may believe they are compliant, but without definitive, clear requirements it can be impossible to know.

The standards expect more. Requirements must define behaviour in a way that can be tested and demonstrated. That means response times, safe states, operating modes, and performance targets need to be explicit. It also means recognising that systems do not operate in a single steady state. Start-up, shutdown, maintenance, and fault conditions all influence how a safety function should behave, and those conditions need to be captured up front.

The SRS is not about driving behaviour that leads to over-engineering – it is simply a documented way in which we remove interpretation in our design requirements.

Why Validation Becomes Difficult

When the SRS is weak, validation is typically where issues first become visible. At that point, the design is confirmed and the physical system exists. Hardware has been selected, software has been written, and integration is complete.

During validation the expectation is that the system will be checked and tested against the SRS. But if the SRS is ambiguous, incomplete, or inconsistent, validation becomes subjective. Meaning teams struggle to provide sufficient evidence and end up asking:

• What exactly are we trying to prove?
• What does “acceptable performance” look like?
• Are we testing the system correctly, or inaccurately interpreting the requirements?

This is where costly delays and rework begin. Safety requirements need to be clarified, validation planning needs to be restarted, and in some cases, physical design changes are introduced late in the project. The cost of fixing a requirement issue at this stage is significantly higher than addressing it at the point of definition.

What Good Looks Like in Practice

A strong SRS reflects a clear line of thinking from hazard to mitigation, and it leaves little open to interpretation.

In practice, well-developed requirements tend to have a few common characteristics:

• Each safety function is clearly tied to a specific hazardous scenario, with defined initiating conditions and a clear statement of what the system must do.
• The concept of a safe state is explicit, including how the system behaves not just during a demand, but also during faults, loss of power, and recovery.
• Performance expectations are defined in measurable terms – response times, demand rates, and where applicable, target integrity levels such as SIL with associated PFDavg or PFH considerations.
• Interfaces and dependencies are acknowledged, particularly where the safety function relies on external systems, utilities, or human interaction.
• Assumptions are documented, which is critical for ensuring that the design and validation activities remain aligned with the original intent.

When these elements are in place, the SRS becomes a stable reference point for the entire lifecycle. Design decisions are easier to justify, validation becomes straightforward, and independent assessment is far more efficient.

How Intertek Can Support

Capturing accurate safety requirements is not just about understanding the standards – it requires experience in applying them across real systems, where constraints, interfaces, and operational realities all come into play.

Intertek works with organisations at the point where requirements are defined, ensuring that the SRS is robust enough to support the full lifecycle. This typically includes leading or supporting hazard and risk analysis activities, developing structured and unambiguous safety requirements, and ensuring that those requirements are fully traceable and aligned with the intended safety functions.

Where an SRS already exists, independent review can provide significant value. Identifying gaps, inconsistencies, or hidden assumptions early allows them to be addressed before they impact design and validation. Engaging at the requirements stage provides the greatest opportunity to reduce lifecycle risk, avoid rework and additional unforeseen costs.

Closing Thought

Functional safety is often associated with reliability analysis, diagnostics, and integrity calculations. However, the effectiveness of these activities is fundamentally dependent on the quality of the underlying safety requirements.

The SRS defines the intended behaviour of the safety functions, the required level of risk reduction, and the basis for verification and validation. As such, it provides the reference point for design, implementation, and assessment activities.

Ensuring that safety requirements are accurate, complete, and verifiable is therefore fundamental to demonstrating that the system achieves its intended safety performance.