How to Write a URS for Pharmaceutical Equipment: Structure, Examples and Template Outline

A major lacking discipline for pharma professionals working in pharmaceutical industries as the majority don't know how to write a user requirement specification. (URS)

Short answer: A URS is the buyer’s written statement of what the equipment must do. Write what you need and not how the supplier should build it, make every requirement testable, and avoid words that cannot be measured, such as “fast” or “user-friendly”.

Every equipment project starts with a document, and the quality of that document decides how the project ends & how the equipment will be. A user requirement specification (URS) is the buyer’s written statement of what the equipment or system must do. Suppliers quote against it, engineers design from it, and the FAT, SAT and qualification tests are written to prove it. A vague URS leads to a vague machine, change orders and disputes about who promised what. A clear URS saves both money and time.

What a URS is, and what it is not

A URS describes what you need, not how the supplier should build it. It is written from the point of view of the user (who will use it) the product, the process, the capacity, the quality and regulatory expectations, and the working environment. The supplier’s own functional specification and design documents then describe how the machine meets each requirement.

If a URS names a particular motor, a pump brand or a design solution without good reason, it limits the supplier’s choices and can hide a better answer. State the need, and give a specific brand only where it is truly needed, for example to match existing spare parts.

Who should write it

The URS needs input from several people, because each sees a different set of requirements.

  • Production knows the products, the batch sizes, the operating routine and the changeovers.
  • Engineering and maintenance know the utilities, the space, the spares and the support the plant can offer.
  • Quality assurance sets the GMP, documentation, cleaning and data integrity expectations.
  • EHS covers operator safety, dust and solvent hazards, noise and emergency stops.

One person should own the document and keep it consistent, but the content should be reviewed by all of them before it is approved.

How to write a requirement that can be tested

Each requirement should be one clear statement, with its own number, and with a way to confirm it. Compare these two,

  • Weak: “The machine should be easy to clean and run fast.”
  • Strong: “The machine shall run at an output of 200,000 tablets per hour at the maximum tablet weight & hardness and all product-contact surfaces shall be accessible for cleaning without special tools.”

A few simple rules help

  1. Use “shall” for mandatory requirements and “should” for desirable ones, and be consistent.
  2. Give numbers and ranges with units, such as batch size, speed, temperature, pressure and accuracy.
  3. Write one requirement per line, so that each can be traced to one test.
  4. Avoid words that cannot be measured, such as “user-friendly”, “fast” or “robust”.
  5. Say how each requirement will be verified: by a document check, at the FAT, at the SAT, or in qualification.
  6. Clearly define in URS weather the FAT will be performed on manufacturer expense or on buyers.

Example requirements

The numbers below are illustrations only. Replace them with the figures from your own process.

IDRequirementPriorityVerified in
URS-012The coater shall process batches from 60 kg to 180 kg of core tablets without a change of parts.MandatoryFAT, OQ
URS-021All product-contact parts shall be stainless steel 316L or another material approved by QA, with material certificates supplied.MandatoryFAT (documents), IQ
URS-034The spray system shall allow the spray rate to be set and recorded between 50 and 400 g/min.MandatoryFAT, OQ
URS-047The machine should allow wash-in-place cleaning without opening the pan.DesirableFAT, SAT
URS-058The control system shall keep an audit trail of recipe changes, alarms and operator actions, with individual user logins.MandatoryFAT, OQ

A practical URS outline

  1. Purpose and scope. What the equipment is for and which products, areas and processes it covers.
  2. Process description. A short narrative or flow of the operation, with inputs and outputs.
  3. Capacity and performance. Batch size range, output rate, speed, accuracy, and the product ranges to be handled. A batch size calculation helps to check that the stated range fits the real batches.
  4. GMP and design requirements. Materials of construction, surface finish, cleanability, drainage, dead legs, sealing, and the separation of product and non-product areas.
  5. Controls and data. The control system, user levels, recipes, alarms, audit trail, data storage, backup and the computerised system rules that apply to you.
  6. Utilities and installation. Power, compressed air, steam, water, vacuum, extraction and HVAC needs, plus the space, floor loading and layout limits of the room.
  7. Safety and environment. Guarding, interlocks, emergency stops, noise, dust and explosion protection where relevant.
  8. Cleaning and changeover. The cleaning method, the number of parts to be dismantled and the time targets.
  9. Documentation. Drawings, manuals, certificates, calibration records, software documentation and the validation documents the supplier must provide.
  10. Testing and qualification. The expected FAT and SAT scope, and the support the supplier will give for IQ and OQ. The FAT vs SAT guide explains how these tests relate.
  11. Service and support. Spare parts, training, response time, warranty and long-term availability of parts.
  12. Acceptance criteria and approvals. What must be true for the machine to be accepted, and who signs.

From URS to the finished machine

Once approved, the URS becomes the reference for the rest of the project. Suppliers answer it point by point, often marking each requirement as compliant, partly compliant or not compliant, and this makes the bids easy to compare. The FAT and SAT protocols are written from the same numbered requirements, and a traceability matrix shows which test proves which requirement. Any change to the scope later goes through version control, so everyone works from the same document.

The URS is also reviewed against risk. Requirements that protect product quality or patient safety deserve more testing than convenience features, and this should be visible in the priorities and in the tests.

Common mistakes

  • Copying a URS from a previous project, so that it carries requirements that no longer apply.
  • Describing a solution instead of the need, which narrows the supplier’s options.
  • Leaving out the real range of products, so the machine is sized for the average and fails on the largest or smallest batch.
  • Forgetting cleaning and changeover, which turn out to be the daily pain points.
  • Ignoring utilities and space until the machine arrives.
  • Writing requirements that nobody can verify.
  • Skipping the QA and EHS review, then finding gaps during qualification.

Frequently asked questions

How long should a URS be?

As long as it needs to be to cover the requirements clearly. A simple piece of equipment may need a few pages, and a packaging line or a computerised system may need many more. Clarity matters more than length.

Who is responsible for the URS, the user or the supplier?

The user. The supplier can offer a standard specification and advice, but the user is accountable for stating what the equipment must do for its own product and process.

Can I change the URS after the order is placed?

Yes, through a documented change control. Changes affect the price, the schedule and the tests, so it is better to settle the requirements before ordering.

What is the link between the URS and qualification?

The qualification tests should show that each requirement is met. A traceability matrix connects each URS item to the test that verifies it.