Skip to content
SILProof
My SIFs Join free

IEC 61511 · Safety Requirements Specification

A SIS is only as good as its SRS

If the Safety Requirements Specification is weak, the best SIS hardware still fails to protect the plant. SILProof keeps Clause 10 requirements on the same SIF record as risk and verification.

Open SRS Builder Download SRS template
IEC 61511-1 safety lifecycle
Management of functional safety and assessment · Cl. 5
One SIF record
  1. 1Hazard and risk assessment (outside SILProof scope)Cl. 8
  2. 2Allocation to protection layersSIL determination · Risk AnalysisCl. 9
  3. 3SIS safety requirements specificationSRS BuilderCl. 10You are here
    1. Safe state
    2. Timing
    3. Proof test
    4. Interfaces
    SRS for the SIFClause 10 structure · Word, JSON, Excel
  4. 4SIS design and engineeringSIL Verification · issued reportCl. 11
  1. 5Installation, commissioning and validation (outside SILProof scope)Cl. 14–15
  2. 6Operation and maintenance (outside SILProof scope)Cl. 16
  3. 7Modification (outside SILProof scope)Cl. 17
  4. 8Decommissioning (outside SILProof scope)Cl. 18
Verification · Cl. 7

IEC 61511-1 Clause 10 structure · Word, JSON and Excel exports

Why a strong SRS matters

Without an SRS, the SIS is a collection of intentions

The Safety Requirements Specification is the contract between hazard analysis and hardware. It tells everyone what “successful” means for this SIF.

  • Defines successSafe state, process safety time and required SIL — not vague trip language.
  • Prevents silent redesignBypasses, resets and BPCS interfaces are written before they are wired.
  • Owns the proof testCoverage and interval become requirements, not afterthoughts in a spreadsheet.

IEC 61511 Clause 10

What the specification has to say

The SRS is where a required SIL becomes a function someone can design, test and operate. Each Safety Instrumented Function needs both its functional requirements and its integrity requirements written down.

  • Functional requirementsWhat the SIF protects against, its safe state and how it gets there, trip points and ranges, and behaviour on detected faults, loss of power and manual shutdown.
  • Integrity requirementsRequired SIL and demand mode, required risk reduction, response time against the process safety time, and proof-test interval and coverage.
  • Operation and interfacesReset and restart, bypass and override with authorisation and indication, operator interfaces and the links to the BPCS and other layers.

How the builder works

Eight sections, in the order you write them

  1. SIF & Document — Tag, title, purpose, project and document control, demand mode.
  2. Hazard & SIL Basis — Hazardous event and causes, consequence, the method used, required SIL and required risk reduction.
  3. Functional Requirements — Specific, measurable requirements: trip conditions and set points, safe state and the action that achieves it.
  4. SIS Components — Sensors, logic solver and final elements with tags, measurement, voting and type.
  5. Response Time — Process safety time and the response time allocated to sensors, logic and final elements.
  6. Proof Test & Maintenance — Proof-test interval and coverage, acceptance criteria, partial stroke testing and calibration.
  7. Reset / Bypass / Interfaces — Reset and restart conditions, bypass authorisation, indication and alarms, interfaces to the BPCS and operators.
  8. Review & Generate — Completeness warnings, review comments and the issued document.

One SIF record

What it inherits and what you add

Taken from the SIF

  • Tag, title and description from the SIF register
  • Required SIL and required risk reduction from Risk Analysis, with the method as the assessment reference
  • Sensors, logic solver and final elements with their voting from SIL Verification

You add

  • Trip set points, safe state and the action that achieves it
  • Process safety time and allocated response times
  • Proof-test procedure, acceptance criteria and any partial stroke testing
  • Reset, bypass and interface requirements

Review and export

From draft to an issued document

  • Review & Generate flags missing or inconsistent requirements before you issue, for example a bypass that is permitted without an authorisation rule.
  • Issue the SRS as a Word document (.docx) for your document control and revision history.
  • Keep a JSON copy of the structured SRS, or start offline from the Excel SRS template.
  • The SRS stays linked to the SIF, so verification and the specification describe the same function.

Basis and limits

A structured draft, reviewed by people

  • The section structure follows the requirements of IEC 61511-1 Clause 10 for the Safety Requirements Specification.
  • Imported values come from the SIF record as it stands; re-import after the risk basis or the design changes.
  • Requirements, set points and timings are your engineering inputs. The tool does not supply them.
  • SILProof is engineering support. The issued SRS needs review and approval by competent people under your project procedures.

Read the engineering basis and review guide for the full scope.

Questions

Frequently asked questions

What must a Safety Requirements Specification contain?

IEC 61511-1 Clause 10 asks for the safety functional requirements and the safety integrity requirements of each SIF: what it protects against, the safe state and how it is reached, trip points, response time against the process safety time, required SIL and demand mode, proof-test requirements, behaviour on detected faults, reset, bypass and manual shutdown, and the interfaces it depends on. The builder walks through these in order.

What does the builder take from the SIF record?

Opened from a registered SIF, it imports the tag, title, description, required SIL and required risk reduction from the risk basis, and the sensors, logic solver and final elements with their voting from SIL verification. You then add the requirements that only the specification can state.

What do I get at the end?

Review & Generate lists missing or inconsistent items, for example a bypass that is permitted without an authorisation rule. Issuing produces the SRS as a Word document for your document control; a JSON copy keeps the structured data, and an Excel template is available for offline drafting.

Can I start without a SIF in the register?

Yes. The builder opens on its own, but linking it to a SIF is what lets it import the risk basis and architecture and keep the SRS on the same record as verification.

Does the SRS replace verification?

No. The SRS states the requirements; SIL verification shows whether the designed SIF meets the integrity requirement. Both stay on the same SIF so one can be checked against the other.

Is the issued SRS an approved document?

No. It is a structured draft for project-specific completion. Requirements must be reviewed and approved under your procedures by competent people, against the applicable edition of IEC 61511 and your hazard analysis.

Related

Read more and related tools

Learn

Tools

Next step

Build the SRS on the SIF record

Open the builder to specify requirements against the same tag used for risk and verification.

Open SRS Builder