FUNCTIONAL SAFETY SERVICES
SRS: SAFETY REQUIREMENT
SPECIFICATION
Translate your SIL targets into precise, auditable engineering requirements. Give your design team the specification they need to build and verify a safety system that performs.
A Safety Requirement Specification is the document that converts the outputs of risk analysis and SIL determination into engineering requirements. Without a complete and accurate SRS, the design of a Safety Instrumented System has no defined target to achieve and no standard against which it can be verified.
The SRS defines what each Safety Instrumented Function must do, how reliably it must perform, what process conditions constitute a demand, what the safe state is, and what constraints the design must satisfy in operation and maintenance. Every hardware selection, architecture decision, software requirement, and proof test procedure that follows in the safety lifecycle derives its legitimacy from the SRS.
When an SRS is incomplete, ambiguous, or disconnected from the HAZOP and SIL determination outputs that preceded it, the consequences appear later and are expensive to resolve. Design decisions made against unclear requirements produce systems that fail verification, generate non-conformances during functional safety assessments, and require rework at the worst possible point in the project schedule.
A well-developed SRS eliminates that risk. It gives procurement, engineering, software development, commissioning, and operations a single, traceable reference for what the safety system must deliver and how its performance will be confirmed.
An SRS (Safety Requirement Specification) is a formal document produced during the design phase of the functional safety lifecycle, required by IEC 61511 Clause 10 and IEC 61508 Part 3. It is developed for each Safety Instrumented System and contains both functional requirements and integrity requirements for every Safety Instrumented Function (SIF) the system implements.
The SRS sits at the boundary between risk analysis and engineering design. It takes SIL targets, safe state definitions, and process demand information from SIL determination, and translates them into requirements that the engineering team can design to, the commissioning team can test against, and the FSA team can audit for compliance.
Functional Requirements
Functional requirements define what each SIF must do. A complete SRS addresses the following for every function:
- The process variable or condition that constitutes a demand on the SIF, including setpoints and measurement ranges
- The defined safe state for the process, including the required position or condition of each final element upon SIF activation
- The required response time from process demand to the achievement of a safe state
- The process operating modes in which the SIF is active, including start-up, shutdown, maintenance, and normal operation
- Reset requirements, including whether a manual reset is required after a SIF activation, and who is authorized to reset
- Bypass and inhibit requirements, including conditions under which the SIF may be bypassed, the duration permitted, and the compensating measures required
- Operator interface and alarm requirements relevant to the SIF
Integrity Requirements
Integrity requirements define how reliably each SIF must perform. These derive directly from the SIL determination study and address:
- The required SIL target for each SIF, with reference to the LOPA or risk graph record from which it was derived
- The required probability of failure on demand (PFD) or probability of failure per hour (PFH) associated with the SIL target
- The proof test interval and the required proof test coverage for each subsystem
- Hardware fault tolerance requirements for the sensor, logic solver, and final element subsystems
- Systematic capability requirements for hardware and software
- Common cause failure requirements and constraints on the independence of protection layers
- Environmental and operational conditions that must be accommodated by the SIF design
Our SRS development follows the requirements and guidance of:
- IEC 61511-1 Clause 10: Safety requirements specification for the SIS, covering functional and integrity requirements for each SIF
- IEC 61508 Parts 2 and 3: Requirements for hardware and software safety requirements specifications
- ISA 84 (ANSI/ISA-84.00.01): Equivalent requirements for process industry SIS design in North American regulatory contexts
- ISA/IEC 62443: Where safety system architecture intersects with OT cybersecurity requirements, particularly for systems with network-connected logic solvers or remote access capability
All SRS documents are structured for direct use in design verification, third-party functional safety assessment, and regulatory audit without requiring reformatting or supplementary documentation.
The SRS occupies a specific and critical position in the IEC 61511 safety lifecycle. Understanding where it sits clarifies why its quality has such a large downstream effect.
- HAZOP and HAZID: Identify hazardous scenarios and establish that a SIF is required as a safeguard. Define the cause, consequence, and safe state for each scenario.
- SIL Determination (LOPA): Establishes the SIL target for each SIF based on the required risk reduction. Produces the quantitative performance requirement that the SRS must capture.
- SRS: Translates HAZOP scenario information and SIL targets into a complete engineering specification. This is where risk analysis outputs become design requirements.
- SIS Design: Uses the SRS as the design input. Every architecture decision, hardware selection, and software requirement derives from the SRS.
- Safety Validation and Verification: Confirms that the designed system meets the SRS. The SRS is the baseline against which all validation activities are measured.
- Functional Safety Assessment (FSA): Audits the SRS for completeness, correctness, and traceability to upstream risk analysis. An incomplete SRS is one of the most common FSA non-conformances.
We maintain this traceability explicitly throughout our SRS development work, so that every requirement in the document has a clear origin in the HAZOP or SIL determination record and a clear path forward to design and verification.
Developing a compliant and usable SRS requires a clear understanding of the process, the risk analysis outputs, the engineering constraints, and the lifecycle activities that will follow. We bring that understanding to every engagement.
Input Review and Alignment
We review the HAZOP register, SIL determination report, process and instrumentation diagrams, cause and effect matrices, and any existing design documentation. We identify gaps or inconsistencies in the upstream documentation that would create problems in the SRS and resolve them before requirements are drafted.
Functional Requirement Development
We work with process engineering, operations, and instrumentation teams to develop functional requirements for each SIF. This includes confirming safe states, process demand conditions, response time expectations, reset logic, bypass requirements, and operating mode coverage. We document requirements in language that is precise, testable, and unambiguous.
Integrity Requirement Development
We transfer SIL targets, PFD requirements, proof test interval assumptions, and hardware fault tolerance requirements from the SIL determination record into the SRS. We confirm that all integrity requirements are expressed in a form that design and verification teams can work with directly.
Review, Traceability, and Lifecycle Handoff
We conduct a structured review of the completed SRS against the HAZOP and SIL determination records to confirm traceability and completeness. The final document is formatted for direct use in design verification and FSA activities, with a requirement register that supports efficient review and audit.
- A single, traceable engineering baseline that connects risk analysis outputs to every downstream design, verification, and operational decision
- Clear design input for the SIS engineering team, eliminating ambiguity about what the system must do and how its performance will be measured
- Reduced risk of non-conformances during functional safety assessments, where SRS completeness and traceability are among the most frequently audited items
- Efficient design verification, because test acceptance criteria can be derived directly from precise SRS requirements rather than reconstructed from design assumptions
- A documented basis for managing future modifications, where changes to process conditions or risk criteria can be evaluated against the existing SRS requirements
- IEC 61511 and IEC 61508 compliance at the documentation level, supporting regulatory submissions, internal governance, and operator confidence
- Safety Requirement Specification document for each SIS in scope, covering all functional and integrity requirements per IEC 61511 Clause 10
- SIF registers with individual requirement records for each safety instrumented function
- Traceability matrix linking each SRS requirement to its source in the HAZOP register and SIL determination report
- Bypass and inhibit register with conditions, duration limits, and compensating measure requirements.
- Action list for gaps identified during input review, with owner, priority, and closure guidance
- Review record confirming SRS completeness and readiness for design handoff.
An SRS produced by a team that understands only the process safety requirements will miss the increasingly important intersection with control system architecture and OT cybersecurity. Modern safety instrumented systems run on programmable logic, communicate over industrial networks, and in many cases share infrastructure with operational technology that carries its own security risk profile.
- Full lifecycle context: we develop SRS documents with a clear understanding of the HAZOP and SIL determination work that preceded them and the verification and FSA activities that will follow
- Precise, testable requirement language that gives engineering teams a usable design input, not a document that requires further interpretation before it can be acted on
- Integrated functional safety and OT/ICS security perspective, ensuring that requirements for networked or programmable safety systems capture both IEC 61511 compliance needs and relevant security constraints
- Structured traceability that holds up under FSA and regulatory audit, because gaps in SRS traceability are a recurring source of project delays and compliance findings
- Deep operational experience across high-consequence sectors, including oil and gas, energy, pharmaceuticals, and process manufacturing
- We do more than produce a compliant document. We help teams build a safety case that is coherent from hazard identification through to commissioning and operation.
Ready to Develop Your Safety Requirement Specification?
Reach out to our functional safety team. We will confirm the scope of your SIS, review the upstream documentation available, and define the SRS development approach your project needs.