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.
Good requirements are objective and testable. For example:
The URS should include:
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.
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.
The following terms or abbreviations are sometimes used: User Requirements Specification, User Requirement Specifications, User Requirements, User Specifications, URS, UR, US.