Safety Requirements Specification (SRS) – Part 1

In the process industry, the configuration of Safety Instrumented Systems (SIS) must comply with a defined set of safety requirements, typically documented in the Safety Requirements Specification (SRS). The functional safety standard IEC 61511 outlines the necessary content and quality criteria for the SRS. However, developing an effective SRS can be challenging.

This three-part series examines common challenges in preparing an SRS and proposes good practices for SRS development. It discusses SRS ownership, staged development of safety requirements, and the classification and traceability of requirements. Additionally, it explores the issue of untold negative requirements and suggests exploratory inspection of SIS application programs (APs) as a potential remedy.

Some of the ideas presented here are inspired by general systems engineering concepts, though the practices recommended are not strictly tied to systems engineering methodologies.

While the article primarily focuses on functional safety in the process industry, the core principles and practices are relevant to other industrial sectors as well.

Note: This article is intended for engineers with experience in functional safety and does not provide introductory background. Readers seeking foundational knowledge may refer to the references listed at the end.

---

1. Requirements Specification

According to systems engineering standards [1,2], a requirement is a “statement which translates or expresses a need and its associated constraints and conditions.”

Functional safety standards, including IEC 61511 [7,6], use slightly different terminology to convey the same concept. IEC 61511 defines the SRS as a “specification containing the functional requirements for the SIFs [Safety Instrumented Functions] and their associated Safety Integrity Levels (SILs).”

The purpose of specifying safety requirements is to establish the necessary constraints and conditions for ensuring safe plant operation during its lifecycle. However, most safety requirements are addressed during the design and development stages. Clause 10.3.2 of IEC 61511 states:

“These requirements shall be sufficient to design the SIS and shall include a description of the intent and approach applied during the development of the SIS safety requirements, as applicable.”

While some requirements overlap with operation and maintenance (e.g., bypassing and proof testing), the SRS predominantly focuses on the design and development phase. Requirements purely related to operation and maintenance (e.g., operator training) are addressed elsewhere in the standard, such as Section 16.

2. Two Challenges with One Remedy

Both systems engineering and functional safety standards adopt a life cycle approach, defining processes for various stages, including requirements specification.

In basic systems engineering, requirements are defined through a two-stage process [1,2,4,10]:

• Stakeholder needs
• System requirements

The first stage outlines high-level needs and constraints, while the second translates these into technical, measurable system requirements.

By contrast, IEC 61511 does not explicitly mandate a staged approach. Instead, it requires that the SRS be derived from the SIL allocation and be completed before the design phase (see Clause 10.2 and Figure 7 in [7]).

In practice, final design and implementation details cannot always be known early in the project. The design phase is typically long and iterative. Expecting a fully complete SRS from the outset can be unrealistic.

A more practical approach is to adopt “staged” SRS development:

• Start with the minimum set of safety requirements for conceptual SIS design (aligned with stakeholder needs).
• Add detailed requirements progressively as design advances.

This incremental approach ensures that each element of the SRS is defined before it is needed, supporting SRS-driven design without demanding completeness too early. This not only satisfies IEC 61511’s requirements but also results in a more relevant and adaptive SRS.

The key question that follows is: How should the SRS be structured to align with project stages? This will be addressed in the next article in this series.

Another key challenge is SRS ownership and responsibility. Unlike EN 50126 [3], which assigns roles and responsibilities clearly, IEC 61511 is performance-based and does not prescribe who is responsible for developing the SRS.

In reality, effective SRS development requires input from both:

• The plant owner, who understands operational constraints and high-level safety needs.
• The system supplier, who contributes detailed, technology-specific safety requirements.

Drawing from systems engineering, this can be addressed by dividing responsibility:

• Early stages: Plant owner specifies needs and high-level functional requirements.
• Later stages: System supplier defines technical implementation requirements.

This division facilitates shared ownership and accountability throughout the SRS development life cycle.

---

In Part 2 of this series on SRS, we will further talk about the staged development, and we will discuss classification and traceability of requirements.

---

References

1. AS/NZS ISO/IEC/IEEE 15288: System and software engineering – System life cycle processes. ISO (2015).
2. ISO/IEC/IEEE 12207: System and software engineering – Software life cycle processes. ISO (2017).
3. CENELEC: CENELEC – EN 50126: Railway Applications – The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) (2017).
4. Hirshorn, S.R., Voss, L.D., Bromley, L.K.: NASA Systems Engineering Handbook. NASA/Langley Research Center, Hampton (2017).
5. IBM: Engineering Requirements Management DOORS – Overview of DOORS. https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/    doors/9.7.0?topic=overview-doors, Accessed Mar-2025.
6. IEC: IEC 61508-4: Functional safety of electrical/electronic/programmable electronic safety related systems – Part 4: Definitions and abbreviations (2010).
7. IEC: IEC 61511-1: Functional safety-Safety instrumented systems for the process industry sector – Part 1: Framework, definitions, system, hardware and application programming requirements (2016).
8. IEC: IEC 60812: Failure Mode and Effects Analysis (FMEA and FMECA). IEC (2018).
9. INCOSE: Guide to Writing Requirements. INCOSE (2023).
10. INCOSE, Wiley: INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. John Wiley & Sons, Incorporated, New York (2015).
11. Jahanian, H.: Failure mode reasoning in safety-critical programs. Ph.D. thesis, Macquarie University.
12. Jahanian, H., Parker, D., Zeller, M., McIver, A., Papadopoulos, Y.: Failure Mode Reasoning in Model Based Safety Analysis. In: 7th International Symposium on Model-Based Safety and Assessment (2020).

---

Note: The article is an adapted version of parts of an original paper shared in ArXiv (2503.13958), and it is also listed on our Resources page: Resources – Slima.