Writing a URS your supplier can actually test against

"The system shall be user friendly." "The system shall comply with 21 CFR Part 11." "The system shall have adequate security." Every validation engineer has read requirements like these, and every one of them has later tried to write a test against them. It cannot be done. A requirement that cannot be tested cannot be verified, and a requirement that cannot be verified is not doing its job.

The user requirements specification is the foundation of the whole validation. If it is vague, everything built on it, the supplier's design, the risk assessment, the test scripts, the traceability matrix, inherits the vagueness. Here is how to write one that holds up.

One requirement, one thing

Each requirement should state one need. "The system shall record the user ID, date and time of each change and require a reason for change" is three requirements joined together. Split them. When a test later fails on the reason-for-change part, you want to be able to say exactly which requirement is not met.

Number every requirement uniquely, and do not renumber when the document is revised. The number is what the traceability matrix hangs on.

Make it measurable

Replace adjectives with numbers or observable behaviour:

• Not "fast", but "the batch report shall be generated within 30 seconds for a batch of up to 500 records".
• Not "secure", but "the system shall lock a user account after five consecutive failed login attempts".
• Not "compliant with Part 11", but the specific behaviours you need: audit trail content, electronic signature components, record retention.

If you cannot put a number on something, describe what a tester would see if the requirement were met. That description is the start of the test.

Say what matters most

Mark each requirement by priority, for example mandatory and desirable, and flag the ones that have GMP impact: anything affecting product quality, patient safety or data integrity. These flags feed straight into the risk assessment and decide which requirements get the most rigorous testing. It also helps suppliers tell you honestly where their standard product falls short.

Write the data integrity requirements in

Data integrity is easier to build in than to bolt on. Typical requirements cover:

• Unique user accounts and role-based access, with no shared logins.
• An audit trail that records who, what, when and why for every GMP-relevant create, change and delete, and that cannot be switched off by ordinary users.
• Time stamps taken from a controlled, synchronised source.
• Backup and restore of records and their metadata, with a tested restore.
• Retention of records in a human-readable form for the required period.

What to leave out

A URS states what the user needs, not how the supplier should build it. "The database shall be Oracle 19c" is a design decision. Unless there is a real constraint, such as an IT standard you must follow, leave design to the functional and design specifications. Over-specified URS documents close off good solutions and make every supplier response a list of deviations.

Keep it alive

The URS is usually approved early and then forgotten. Requirements change during selection, configuration and testing. Keep it under change control and update it when the agreed scope changes, so that at the end of the project the URS, the tests and the system all describe the same thing.