How to Write a URS
for a PLC/SCADA System:
A Step-by-Step Guide

What the URS Actually Is — and What It Isn't

The User Requirements Specification is the founding document of your validation project. Everything downstream — the FDS, the risk assessment, the traceability matrix, and ultimately the test protocols — derives from it. Get the URS right and the rest of the project has a clear foundation. Get it wrong and you're retrofitting requirements into approved designs for the rest of the project.

What the URS is: a statement of what the system must do, written from the perspective of the people who will use and operate it. It is written before design begins and should be readable by both engineers and QA reviewers without an engineering degree.

What the URS is not: a functional specification. It describes requirements (what the system must achieve), not solutions (how it will achieve them). The FDS handles solutions. Engineers regularly mix these up on their first pharma project — writing sentences like "The PLC shall use a PID algorithm with a 100ms scan rate" in the URS. That's FDS content. The URS should say "The system shall maintain reactor temperature within ±2°C of setpoint."

The Structure of a GAMP 5-Compliant URS

A URS for a Category 4 PLC/SCADA system in a pharmaceutical environment should follow a consistent structure that allows QA reviewers to navigate it and traceability tools to reference it. Here is the standard structure used in the GAMP 5 framework:

Requirement Numbering — Non-Negotiable

Every requirement in your URS must have a unique identifier. Without unique IDs, you cannot build a traceability matrix. Without a traceability matrix, you cannot prove the system is validated. The format used in the QLean framework is:

Good vs Bad Requirements — Real Examples

The single most common URS failure mode is requirements that are too vague to test. Here are examples of weak requirements rewritten to be testable:

The Regulatory Requirements Section — What Experienced Engineers Add

Most junior engineers write functional requirements well but forget to explicitly state the regulatory requirements. A senior engineer adds a dedicated regulatory section to the URS — not because the regulation demands it, but because it forces the FDS author to design compliance in from the start rather than bolt it on at the end.

The regulatory section of a URS for a SCADA system should explicitly state requirements derived from 21 CFR Part 11 and EU GMP Annex 11:

• Unique named accounts — no shared logins (§11.10(d) / Annex 11 §12)
• Role-based access with documented role matrix (§11.10(d) / Annex 11 §12)
• Write-once audit trail with 6 required fields (§11.10(e) / Annex 11 §9)
• NTP-synchronised system clock (Annex 11 §4)
• Electronic signature capability where batch sign-off is required (§11.50)
• Automated backup with restore testing (Annex 11 §16)

The URS Review and Approval Process

The URS must be formally reviewed and approved before design begins. The three stakeholders who must sign are:

• System Owner (typically Production or Engineering) — confirms the functional requirements reflect what the business actually needs
• QA — confirms regulatory requirements are included and the document meets GMP documentation standards
• Validation Lead — confirms requirements are testable and the scope is consistent with the Validation Plan

A URS approved without QA sign-off is a significant finding. More importantly, it means regulatory requirements almost certainly got missed — and you'll discover them when the OQ test cases reveal gaps in the FDS.