User Requirements Specification

The User Requirements Specification describes the business needs for what users require from the system. User Requirements Specifications are written early in the validation process, typically before the system is created. They are written by the system owner and end-users, with input from Quality Assurance. Requirements outlined in the URS are usually tested in the Performance Qualification or User Acceptance Testing. User Requirements Specifications are not intended to be a technical document; readers with only a general knowledge of the system should be able to understand the requirements outlined in the URS.

The URS is generally a planning document, created when a business is planning on acquiring a system and is trying to determine specific needs. When a system has already been created or acquired, or for less complex systems, the user requirement specification can be combined with the functional requirements document.

User Requirements Examples

Good requirements are objective and testable. For example:

• Screen A accepts production information, including Lot, Product Number, and Date.
• System B produces the Lab Summary Report.
• Twenty users can use System C concurrently without noticeable system delays.
• Screen D can print on-screen data to the printer.
• System E will be compliant with 21 CFR 11.

The URS should include:

• Introduction – including the scope of the system, key objectives for the project, and the applicable regulatory concerns
• Program Requirements – the functions and workflow that the system must be able to perform
• Data Requirements – the type of information that a system must be able to process
• Life Cycle Requirements – including how the system will be maintain and users trained

For more examples and templates, see the User Requirements Specification Template.

Requirements are usually provided with a unique identifier, such as an ID#, to aid in traceability throughout the validation process.

User Requirements Specifications should be signed by the system owner, key end-users, and Quality. Once approved, the URS is retained according to your organization’s practices for document retention.

Frequently Asked Questions

Q: Are User Requirements Specifications always required for validation?
A: When a system is being created, User Requirements Specifications are a valuable tool for ensuring the system will do what users need it to do. In Retrospective Validation, where an existing system is being validated, user requirements are equivalent to the Functional Requirements: the two documents can be combined into a single document.

Alternative Document Names and Acronyms

The following terms or abbreviations are sometimes used: User Requirements Specification, User Requirement Specifications, User Requirements, User Specifications, URS, UR, US.

Validation Document Resources

• Validation Master Plans (VMP)
• Validation Plans (VP)
• Risk Assessment (RA)
• User Requirement Specifications (User Specs, URS)
• Functional Requirements (Functional Requirement Specifications, Functional Specs, FRS, FS)
• Design Specification (DS)
• Test Plan / Test Protocol
• Installation Qualification (IQ)
• Operational Qualification (OQ)
• Performance Qualification (PQ)
• Requirements Traceability Matrix (Trace Matrix, RTM, TM)
• Protocol Test Deviations
• Validation Summary Report (Validation Report, Summary Report, VR, SR)
• Change Control for Validated Systems
• Validation Terminology
• Validation FAQ (Frequently Asked Questions about Validation)

• Computer System Validation
• Part 11 Training
• Auditing and Assessments