Safety Requirements Specification (SRS)
We author a safety requirements specification compliant with IEC 61511 clause 10 that sets the functional and integrity requirements for each safety instrumented function
What this element is and why it matters
Phase 3 produces the safety requirements specification, the design grade document that translates the Phase 2 safety integrity level allocations into the functional and integrity requirements that your functional safety engineering team can actually build. To IEC 61511 clause 10 the specification covers process safety time, demand mode, the safe state, response time, the environmental conditions and the proof test interval.
Individual significance for organisations
A complete safety requirements specification catches design ambiguities before they turn into commissioning rework. Facilities that practise rigorous specification see around half the commissioning issues with their safety instrumented systems and substantially fewer findings at the Stage 2 functional safety assessment, and our team builds that rigour in from the start.
Contribution to Functional Safety Lifecycle Implementation
Phase 3 is the formal hand off from process safety in Phases 1 and 2 to functional safety engineering from Phase 4 onward. The safety requirements specification is the contract between the hazard study and the design.
What compliant execution looks like
How we implement this element
A focused six step methodology calibrated to deliver safety requirements specification (srs) as a working capability rather than a documented compliance artefact.
We receive the safety integrity level allocation register and baseline the safety instrumented function inventory with the SIL targets, the demand mode and traceability back to the process hazard analysis.
To clause 10.3 we author the measurement parameter, the trip setpoint, the voting arrangement, the time to action, the final element action and the reset philosophy.
To clause 10.3.14 through 10.3.18 we specify the probability of failure allocation, the hardware fault tolerance, the safe failure fraction, the diagnostic coverage and the common cause factor.
We calculate the process safety time from process upset to dangerous consequence and budget the response time for each function across the sensor, logic and final element shares.
To clause 10.3 we hold a review with process, instrumentation, operations and HSE, and we capture the deviations and their resolution.
We issue the baselined specification, hand it to Phase 4 safety instrumented system design and connect it to management of change for any subsequent change.
Element implementation flow chart
A decision gated workflow that shows the actual sequence of activities from initiation through steady state operation, with key decision points highlighted.
What we produce
- A baselined specification for each function with both functional and integrity requirements
- A process safety time calculation pack
- A multi discipline review record
- A safe state and trip setpoint schedule for each function
- A table of probability of failure and proof test interval requirements
- A traceability matrix from the process hazard analysis through to the specification
Where execution fails
- A safe state definition that is incomplete or contradictory
- A process safety time budget with no allocation across sensor, logic and valve
- Operations and HSE left out of the specification review
- A proof test interval omitted, which forces Phase 4 to assume one
Codes this element is built on
Explore related elements in this framework
Functional Safety Lifecycle Implementation full element index
Talk to us about implementing Safety Requirements Specification (SRS)
We can scope this element implementation against your facility, regulatory context, and existing management system maturity, then integrate it with the other Functional Safety Lifecycle Implementation elements you already operate.