Synopsis:
Before purchasing an equipment, software or instrument, regulatory requirement mandates that one documents what is expected of the proposed acquisition. While it may be tempting to rely on vendors for this, as they understand their product, they do not understand the business requirements. That is why the User Requirement Specification (URS) must be authored by the team responsible for this new acquisition. This article explains why a user-driven URS ensures the acquired entity genuinely matches user needs, moving it from basic functionality to real-world fit
It All Starts with a Need
Picture this. You have been asked to put together a URS for a new equipment/software/instrument. If this requirement was identical or similar to one that you have purchased in the past, that makes your task easier. But what if this is a brand-new requirement. Where do you start?
Appendix D5 from the ISPE GAMP 5 guidance document says it the best when it states that each user requirement should be specific, measurable, achievable, realistic, and testable. It is also a good practice to prioritize the requirements, typically in two or three levels: (mandatory (high), beneficial (medium), and nice-to-have (low)) Or (mandatory (high) and nice-to-have (low)).
The Easy Way
As a vendor, we very often get asked to provide a draft URS that the regulated company then uses as a basis to draft the requirement. Is this the right approach? It sounds logical, right? After all, vendors are experts in the products they sell. But here’s the catch — they are experts in their product, not your business process.
Sometimes we receive a URS that lists a specific brand or model, even including specifications unique to that brand. This is not the intended purpose of a user requirement, which should describe what is the needed functionally, not prescribe a particular vendor or solution. When this happens, it limits the scope of solutions, undermines competitive assessment, and can introduce bias or compliance risks. Such requirements do not reflect true user needs but rather pre-select a solution, making it harder to compare alternatives and potentially exclude options that better meet functional requirements. GAMP 5 guidelines recommend describing functional needs in clear, objective terms, avoiding references to specific suppliers unless it is absolutely necessary to do so for business reasons
Understanding the Roles the RACI way
How do we decide the roles of various stakeholders. A RACI Matrix, a simple chart that outlines who does what, breaks down the roles:
Responsible: Team/end users responsible for the business process. The end users or process owners are usually responsible for drafting the URS since they know the operational needs best.
Accountable: Manager(s) responsible for the business process. Oversees URS creation and ensures it meets desired goals
Consulted:
- Other departments to provide their input/expertise as the acquired product may influence their workflows
- IT team for software/IT hardware requirements to provide input on technical feasibility and rollout implications
- CSV team for software to include regulatory requirements
- Vendor – provide input and give technical advice.
- Informed-Vendors so as to put together a function requirement specification.
What do the Regulators Say?
The FDA, the EMA and others, have made their stance clear: every system must be “fit for its intended use.” That phrase — fit for intended use — is powerful. It means the system should perform exactly as needed for your specific products and processes.
And who defines that intended use? Not the vendor — you do.
According to the FDA’s General Principles of Software Validation and EMA’s Annex 11 on Computerised Systems, the responsibility for defining and confirming suitability lies with the regulated user organisation for computerised systems. But that principle doesn’t stop there. Under broader GMP guidance, such as Annex 15 on Qualification and Validation, the manufacturers are responsible for ensuring equipment is suitable for its intended purpose and for defining its requirements in a User Requirements Specification (URS) or functional specification.
In short, the user determines what’s needed; the vendor shows how their product meets those needs.
Why Ownership Matters?
When the customer owns the URS, everything aligns. The equipment fits its real operational needs, and the system passes regulatory scrutiny because it was built for its true purpose. And most importantly, it saves time, money, and frustration down the road.
When vendors take over the URS, it might seem faster, but it’s like letting someone else write your recipe — you’ll never get the exact flavour you wanted.