Why Acceptance Criteria Are the Hard Part
Most engineers can list what a system needs to do. The URS challenge is expressing those needs in a form that is simultaneously user-perspective (not implementation detail), measurable (contains a specific verifiable value), testable (an OQ test case can be written directly from it), and unambiguous (two different engineers reading it produce the same test case).
When a URS fails QA review, it is almost always because requirements are vague ("the system shall respond quickly"), solution-prescriptive ("the system shall use a Siemens S7-1500"), or untestable ("the system shall be GMP compliant"). These are not minor stylistic issues — a vague requirement produces a vague test case, and a vague test case cannot produce a defensible PASS result. The whole evidence chain unravels.
The QLean URS template (URS-SYS-001) is built around five requirement types and four testability rules. This article explains both in practical terms — with real before/after examples drawn directly from the template.
Before finalising any URS requirement, ask: "Can I write a specific test step with a binary pass/fail criterion directly from this requirement, without making any assumptions?" If the answer is no, the requirement needs rewriting before the URS is approved. The OQ cannot rescue a vague URS.
The Five Requirement Types
Every requirement in a PLC/SCADA URS falls into one of five types. Each type has a different focus and a different primary verification phase. Knowing which type you're writing shapes how you phrase it.
Specific behaviours the system must perform. Uses clear action verbs, measurable outcomes, and defined conditions. The largest section of any PLC/SCADA URS.
How well the system performs its functions. Quantitative measures, time constraints, capacity limits. Every performance requirement must contain a number.
Legal and regulatory obligations. Must cite the specific regulation and clause — not just "GMP compliant." The specific clause is the acceptance criterion.
How the system interacts with other systems or users. Must specify data format, protocol, direction, and GMP criticality of the data being exchanged.
How data is managed, stored, and protected. Covers retention periods, backup frequency, access restrictions, and all ALCOA+ principles. Highest inspector scrutiny.
The Four Testability Rules
A requirement passes all four of these checks before it belongs in an approved URS. In QA reviews and FDA 483 inspections, failures trace back to requirements that violated at least one of them.
No vague qualifiers: "adequate", "sufficient", "fast", "appropriate", "user-friendly". Every requirement must contain a specific, verifiable quantity — a number, a unit, a count, a time period, a percentage.
The URS is the user perspective. Implementation belongs in the FDS, HDS, and SDS. A requirement specifying a product, platform, or architecture is a design constraint — not a user requirement. It freezes the design before engineering has started.
A requirement with "and" often contains two requirements. Each becomes one test case. Compound requirements ("the system shall do X and also Y and notify Z") produce ambiguous pass/fail determinations.
For any regulatory or compliance requirement, cite the exact clause — not just "Part 11 compliant" or "Annex 11 compliant." The specific clause is the acceptance criterion an inspector will check against. A general compliance statement cannot be verified.
Anatomy of a Well-Written Requirement
Every well-written URS requirement contains four elements. Here is URS-GEN-014 from the QLean template dissected:
This requirement generates a single, unambiguous OQ test case: configure NTP, verify sync is within ±30 seconds, then disconnect NTP and verify that an alarm is generated and an audit trail entry is created. The test writer needs to make zero assumptions.
Before and After: 6 Real Rewrites
These are the most common weak requirement patterns in PLC/SCADA URS documents. Each one is taken from real QA review findings and rewritten to be testable.
The system shall respond adequately to operator commands during production.
System shall respond to operator commands within 2 seconds, measured from command submission to visual confirmation on HMI, for 99% of commands during scheduled production hours (06:00–22:00).
The system shall use a Siemens S7-1500 PLC for all control functions.
Critical control functions (closed-loop temperature and conductivity control, safety interlocks, alarm generation) shall continue to operate correctly during loss of SCADA server communication.
The system must be 21 CFR Part 11 compliant.
Audit trail shall record user ID, date/time (UTC), parameter name, old value, new value, and reason for change for all GMP-critical parameter modifications. The audit trail shall be computer-generated and not modifiable by any user including Administrator, per 21 CFR 11.10(e).
The system shall implement user access control with role-based permissions and shall generate an audit trail entry for all login attempts and shall lock accounts after 3 failed attempts.
URS-GEN-005: System shall implement RBAC with minimum four roles: Read-Only, Operator, Supervisor, Administrator.
URS-GEN-009: Audit trail shall record all login attempts (successful and failed) with user ID, timestamp, and outcome.
URS-GEN-010: Accounts shall lock automatically after 3 consecutive failed login attempts. Administrator alert generated on lockout.
The system shall record conductivity data frequently and retain it for a long time.
System shall record all GMP-critical process parameters (conductivity, TOC, temperature, flow) at 1-minute intervals. Historical data shall be retained for a minimum of 7 years in a read-only, tamper-evident format.
The system shall never lose GMP data under any circumstances.
System shall prevent data gaps during scheduled backup operations, network outages lasting up to 4 hours, and system restarts. Any detected data gap exceeding 2 consecutive missed scan intervals shall generate a High alarm within 3 minutes.
The ID Format and Traceability
Every requirement must have a unique, stable identifier that flows through the Traceability Matrix, the FDS, and the OQ protocol. The QLean URS uses the format URS-[SECTION]-[NNN]:
| Prefix | Section | Examples |
|---|---|---|
| URS-GEN- | General — availability, access control, data integrity, audit trail | URS-GEN-001 through URS-GEN-020 |
| URS-FUN- | Functional — process control, sequences, alarms, interlocks | URS-FUN-001 through URS-FUN-030 |
| URS-HMI- | HMI — screen layout, navigation, colour standards, interaction | URS-HMI-001 through URS-HMI-010 |
| URS-DAT- | Data — historian configuration, retention, reporting, export | URS-DAT-001 through URS-DAT-010 |
| URS-NET- | Network / Infrastructure — connectivity, redundancy, cybersecurity | URS-NET-001 through URS-NET-010 |
| URS-INT- | Interface — LIMS, ERP, DCS, third-party system connections | URS-INT-001 through URS-INT-005 |
The ID must remain stable after URS approval. If a requirement is added, it gets the next available number in the section — existing IDs are never renumbered. If a requirement is deleted, its ID is marked as "DELETED — not to be reused" in the URS. This preserves the integrity of any TM or OQ protocols that may have already referenced it.
Every requirement must be assigned a priority: High (must be implemented and verified — no risk acceptance), Medium (implemented and verified, or risk-accepted by QA), Low (best practice — implementation desirable but risk-acceptable). A URS with no priority assignments forces the risk assessment to classify everything from scratch. Set priority in the URS — it flows directly into the risk assessment and testing strategy.
URS-SYS-001 contains over 60 pre-written, testable requirements across all six sections — General, Functional, HMI, Data, Network, and Interface — with unique IDs, priorities, verification phases, and regulatory references already populated. The requirement authoring guidance boxes (which are deleted before approval) explain exactly what testable language looks like for each section. You adapt the pre-written requirements to your specific system rather than writing from blank.