Safety Requirements Specification (SRS) – Part 2

In Part 1 of this series on Safety Requirements Specification (SRS), we started with an introduction on challenges, and we proposed staged development of SRS as a remedy. In this Part 2, we will further expand on the staged development and discuss classification and traceability of requirements.

---

3. Staged Development and Shared Responsibility in SRS

A staged approach to developing the Safety Requirements Specification (SRS) document can significantly improve project efficiency and clarity. Instead of waiting for all information to be available, the SRS is developed incrementally—each section is completed as soon as prerequisite inputs are ready, and before they’re needed for system design or implementation. This approach aligns with systems engineering best practices, drawing from Agile principles and two-stage requirements engineering methodologies [1,10].

Incremental SRS Development: A Step-by-Step Example

Consider a typical Safety Instrumented System (SIS) project. Figure 1 illustrates a partial timeline where the combined SRS and Application Program SRS (AP SRS) are developed in six logical steps, labeled A to F. These steps align with lifecycle phases and reflect when certain requirements become available or necessary.

Clauses 10.3.2 and 10.3.5 of IEC 61511 define the minimum content for the SRS and AP SRS, respectively. Based on those clauses, the requirements can be grouped as follows:

• Step A – Initial SRS Foundation
  After completing the Hazard and Risk Assessment (H&RA) and Safety Integrity Level (SIL) allocation, the initial SRS is drafted. This includes identifying each Safety Instrumented Function (SIF), their associated safety functions, safe states, demand rates, response times, SIL targets, spurious trip limits, and Common Cause Failure (CCF) considerations.
• Step B – General AP Requirements
  Before software design begins, general AP SRS elements are defined. These include the full list of SIFs and SILs, real-time performance expectations, operator interfaces, plant operation modes, and key reference documents.
• Step C – Hardware-Specific Requirements
  Prior to detailed hardware design, technical details are added, including specifications for I/O devices related to SIFs, process measurement requirements, manual shutdown mechanisms, trip functions, environmental parameters, operational modes, and proof test hardware details.
• Step D – Software-Related Requirements
  Before software development begins, both SRS and AP SRS are expanded to cover input/output logic, reset behavior, failure response logic, mode transitions, and proof test software. The AP SRS further addresses diagnostics, sequencing, bad variable handling, communication interfaces, process validation, and self-monitoring.
• Step E – Repair Time and other HW Requirements
  Once hardware design is finalized, the SRS is updated with requirements for repair time, safe restart procedures, and maintainability considerations.
• Step F – SIL Verification
  After SIL verification, the last stage finalizes proof test intervals, bypass logic, safe state behaviors in fault conditions, and updated CCF strategies.

These six groups of requirements are not developed simultaneously (see Figure 1). Steps A, E, and F are defined at the end of respective lifecycle activities, while Steps B, C, and D are defined earlier, just before the corresponding development tasks begin.

---

SRS Ownership and Collaboration Across Stakeholders

Ownership of the SRS can be shared among different parties, depending on the nature of the requirements. Typically, ownership starts with the Plant Owner (PO) and gradually transitions to the system Integrator (SI). In this example, and based on the requirement groupings outlined above, ownership distribution will be as illustrated in Figure 2.

However, cross-review is essential. The PO should always verify the requirements developed by the SI, and vice versa, to ensure alignment, traceability, and correctness before implementation.

In complex industrial projects, additional stakeholders such as subcontractors or specialist vendors may also contribute. Their roles should be clearly defined through further allocation and refinement of SRS ownership to ensure accountability and integration across disciplines.

---

4. Best Practices for Structuring and Managing SRS Requirements

Developing a comprehensive SRS is crucial for the effective implementation of SIS in accordance with IEC 61511. A well-structured SRS ensures that all safety-related requirements are clearly defined, traceable, and verifiable throughout the SIS lifecycle.

Classifying Requirements for Clarity and Traceability

To enhance the organization and clarity of the SRS, it’s beneficial to categorize requirements based on their primary function. This classification aids in understanding the purpose of each requirement and facilitates easier tracking and management. The following categories are recommended:

1. Functional (FU): Define the intended operations of the SIS and Safety Instrumented Functions (SIFs) across various operational modes.
2. Reliability (RE): Specify target reliability metrics, including Safety Integrity Levels (SILs) for each SIF.
3. Hardware (HW): Detail constraints and conditions related to SIS hardware components, such as Environmental and Electromagnetic Compatibility (EMC) requirements.
4. Software (SW): Outline software-specific requirements, encompassing logic solvers, application programs, and diagnostic functions.
5. Operational (OP): Describe procedures and responsibilities for operations and maintenance personnel during the SIS operational phase. Some of these should be considered during the design phase to ensure future maintainability.
6. Compliance (CM): Include requirements for adherence to relevant safety standards, regulations, and documentation practices.
7. Interface (IN): Address requirements for interactions with third-party systems, including communication protocols and cybersecurity measures.

This classification not only clarifies the nature of each requirement but also assists in aligning them with the appropriate stages of the SIS lifecycle.

Implementing Requirement Traceability

Assigning unique identifiers to each requirement enhances traceability and facilitates verification and validation processes. A recommended format for these identifiers includes:

• ID: A unique alphanumeric code (e.g., R0503) for easy reference.
• Category: The classification code (e.g., RE for Reliability).

Example: [ID: R0503, Cat: RE] Safety Function SIF01 must achieve a minimum SIL rating of 2.

This approach distinguishes between normative (mandatory) and informative (guidance) content within the SRS, ensuring clarity and consistency.

Balancing Document-Based and Tool-Based Requirement Management

While requirement management tools like IBM DOORS [5] are valuable for handling complex projects, maintaining a well-structured SRS document remains essential. Documents provide context and narrative that databases may lack, aiding in the comprehensive understanding of requirements.

Moreover, not all safety requirements lend themselves to the SMART (Specific, Measurable, Achievable, Relevant, Time-bound) criteria. For instance, requirements such as “Common Cause Failures (CCF) must be minimized as far as reasonably practicable” are inherently qualitative and require expert judgment during Functional Safety Assessments (FSA).

Ensuring Clarity in Requirement Expression

Regardless of measurability, all requirements should be articulated clearly and unambiguously. As stipulated in IEC 61511 Clause 10.2, requirements must be:

• Clear: Easily understood without interpretation.
• Precise: Specific and detailed.
• Verifiable: Capable of being confirmed through testing or analysis.
• Maintainable: Structured to accommodate future changes.
• Feasible: Realistically achievable within project constraints.

By adhering to these principles, the SRS becomes a robust foundation for the design, implementation, and maintenance of SIS, ensuring compliance with IEC 61511 [7] and promoting overall process safety.

---

In Part 3 of this series on SRS, we will talk about the untold requirements and inclusive inspection of SIS program.

---

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.