Why Engineers Confuse URS and FDS
The User Requirements Specification and the Functional Design Specification are the two most important documents in a GAMP 5 validation project — and the two most commonly confused. Engineers new to pharmaceutical projects regularly write FDS-level content in the URS, or produce a URS so thin it provides no validation foundation at all.
The confusion is understandable. Both documents describe "what the system does." The difference is whose perspective they're written from and at what level of detail. Getting this right is not just a formality — it directly determines whether your traceability matrix closes cleanly and whether a QA reviewer can follow the logic from requirement to test.
The URS says what the system must achieve — written from the user's perspective, technology-neutral. The FDS says how the system will achieve it — written from the engineer's perspective, technology-specific. If a sentence mentions Siemens, TIA Portal, Modbus, or any specific technology, it belongs in the FDS, not the URS.
URS vs FDS — Side by Side
The URS in Depth
The URS is authored by — or in close collaboration with — the end user: the production team, the site engineer, or the process owner. It should be reviewable by a non-engineer and approved by QA before any design work begins. See our complete URS writing guide for structure, numbering, and examples.
Key characteristics of a well-written URS:
- Written in plain language — no PLC or SCADA terminology
- Every requirement has a unique ID traceable through the project
- Requirements are testable — each one maps to at least one OQ test case
- Includes a regulatory requirements section (Part 11, Annex 11, site SOPs)
- Approved before design begins — changes after approval require a formal deviation
The FDS in Depth
The FDS is authored by the system integrator or automation engineer. It is the design document — it describes how every URS requirement will be implemented in the specific technology chosen. It forms the basis for the FAT protocol, which tests that the design was correctly implemented.
Key characteristics of a well-written FDS:
- References every URS requirement it addresses — explicit traceability
- Names specific hardware, software versions, tag names, network addresses
- Includes PLC program structure, function block descriptions, alarm setpoints
- Includes SCADA screen descriptions, navigation flow, user role matrix
- Reviewed and approved by both the client's engineering lead and QA
Where the HDS Fits In
Many projects also have a Hardware Design Specification (HDS) sitting alongside the FDS. The FDS covers the software and functional design. The HDS covers the physical hardware — panel layouts, cable schedules, instrument datasheets, network diagrams, and P&IDs. Together they form the complete design package that the IQ verifies was correctly installed.
For smaller systems a combined FDS/HDS is acceptable. For larger systems with complex hardware, keeping them separate makes review and approval more manageable.
The Approval Sequence — Why It Matters
The GAMP 5 V-model requires documents to be approved in sequence. The URS must be approved before the FDS is written. The FDS must be approved before the FAT protocol is written. This sequencing isn't bureaucracy — it's the control that prevents design scope creep from undermining the validation.
In practice, the engineer often wants to start designing before the URS is approved. The correct response is to document any design assumptions in the FDS explicitly and flag them for URS confirmation — not to bypass the approval sequence.
The URS and FDS templates are pre-linked — the FDS includes a traceability column that references URS requirement IDs, and the format is consistent with the Traceability Matrix template. This means the trace from URS → FDS → FAT → OQ flows automatically without manual cross-referencing.