SOP For Preparation of User Requirement Specification (URS)
Objective: To lay down a procedure for preparation, review and approval of user requirement specification.
Scope: This procedure outlines the requirements which shall be followed when creating a User Requirement Specification (URS), which is referred to as system or equipment design documentation.
This procedure applies to all systems or equipment utilized for GMP applications, including Product Processing, Laboratory, Environmental Monitoring and Engineering /Maintenance systems that are directly related to manufacture, control and evaluation of pharmaceutical product intended for commercial or clinical distribution.
Requirements of this procedure do not apply to legacy systems and equipment purchased or installed prior to the procedure effective date.
Responsibility:
User Department : Create and review of URS.
Describe current and proposed business requirements pertinent to the system for which the design documentation is written.
Engineering : Assure systems and equipment for GMP applications are installed according to design specifications (may be delegated to others).
Assist as necessary in creating URS to meet the requirements of this procedure.
Review of URS.
QA – Validation : Assure that URS required for system or equipment description is complete and current.
Assure that appropriate change control procedures are in place and followed in order to capture and describe changes to logic controlled systems or equipment utilized for GMP applications.
Review and approve URS wherever applicable.
Quality Assurance : Responsible for ensuring the policies/procedures and compliance to current Good Manufacturing Practice (cGMP) Federal and other applicable regulations.
Accountability: Plant Head and Head – Quality Assurance shall be accountable for implementation and compliance of SOP.
Materials, Equipment and Definitions: User Department: Department designated as the primary user of a given system/equipment.
Responsible Engineering: Individual primary responsible, from the Engineering perspective, to assure that systems and equipment are designated, purchased, installed and commissioned.
Procedure URS numbering System:
URS numbering system shall consists of 20 alphanumeric characters i.e. COP/URS/XX/ZZZ-NN/YY description is as follows:
COP : Company Name
URS : User Requirement Specification
XX : Department Code
ZZZ : URS Serial No.
NN : Version No.
YY : Current Year.
For Example: First URS for equipment generated by Production Oral Department of COMPANY in year 2025 shall be as follows: COO/URS/PO/001-00/25.
In case if there is any change required in URS the URS No. shall remain same but version no. shall change. e.g. suppose first version of URS is COP/URS/PO/001-00/25 for an equipment in year 2025 and there are some changes in URS for same equipment in the same year then the URS No. shall be COP/URS/PO/001-01/25.
All systems and equipment purchased to be utilized for GMP applications shall have associated design documentation that accurately and comprehensively describes the system/equipment requirements, attributes, functionality, construction and operation.
The first step of the design process begins with the conceptualization of a business need. The business need shall be expressed as a formal Conceptual Design document or plan; however, this is not a requirement and is not addressed in the scope of this procedure.
The next step of the design process is the development of a User Requirement Specification (URS). The URS is the primary design document, and while of sufficient detail to describe the system and equipment, also provides an overview of the required / desired functionality. The URS describes what the system or equipment is supposed to do.
An initial version of the URS shall be included with the request for quotation (RFQ) sent to potential suppliers. This version should include all essential requirements and if possible, a prioritized set of desirable requirement.
The URS is typically a key design document for creation of performance qualification test plans.
Prepare the URS content as per Below Guideline.
URS review/approval requirements is as follows:
Guidelines for Preparation of URS
Some of the supporting information for specific user requirements shall appear in other documents (e.g. Operational/Process descriptions, existing standards). Reference to these other documents should be made where applicable.
Each requirement shall be accurate, clear, consistent, complete and objectively verifiable where possible.
Each requirement shall be uniquely indexed for ease of traceability.
Requirement statements shall neither be duplicated nor contradicted.
All members of the project team and any other stakeholder shall be able to understand the URS. Avoid ambiguity and technical jargon.
Multiple systems sharing the same requirements and same boundaries shall be covered in a single URS document.
Since the URS is used to create criteria for acceptance and define qualification testing of the system, each specification element shall be testable or verifiable in some way.
URS documents shall include the following identification, Organization and approval sections:
- Author(s)
- Effective Date
- Signature/Approval page
- System Name
- Document Name
- Document Identifier and Version
- Table of Contents
The sections to be included in the URS are listed as follows. If there is no requirement specified for a particular section, then the section shall state “Not Applicable” and the reason why the section is not applicable. It is not expected that all of the details listed shall be available for every system.
- Purpose
- Scope
- System Description
- Responsibilities
- Definitions
- Reference Documents
- Functionality
- Data and Reporting
- User Interferences
- System Interfaces
- Constraints/Limitations
- Regulatory and Procedural Compliance
- Environment
- Delivery Requirements
- Safety
- Attachments
- Revision History
USER REQUIREMENT SPECIFICATION FOR EQUIPMENT / SYSTEM / INSTRUMENT NAME:…………………
URS documents shall contain the following sections. If there is no requirement specified for a particular section, then the section shall state “Not Applicable” and the reason why the section is not applicable.
Purpose: Include a concise statement indicating the purpose of the URS document Include Present the required functionality to support the business function
Scope : The scope of the URS shall encompass the following points:
Include identification and general boundaries for the equipment and system for which the URS is written.
Operational boundaries and interface requirements shall be mentioned and diagram shall be employed where they shall facilitate greater understanding.
System Description : Include a high level description of the system and process for which the URS has been written, including the business need of the system and key objectives/benefits.
Where the system replace or augment a previously existing system, consideration shall be outlined here in term of the extent of any interfaces and identifying any changes in the functionality of the previously existing system.
High level process/product workflow diagram including (as applicable) known system phases/state, Process I/O, system boundaries and system interfaces shall be included.
Responsibilities : Include a statement of the departments that have review and approval responsibilities for the URS. The responsible Quality group shall be listed in this section.
Definitions : This section shall include any necessary definitions of terms used within the URS.
Reference Documents : Include internal and external documents that are relevant to the system under development or in operation. (Project documents, corporate and site SOPs, plans, vendor documents, industry standards, regulations and guidance etc.).
Functionality :This section shall provide a description of the functions shall be divided into required and desirable items (if determined).Information on the required system shall be listed here.
Performance and timing requirements, which shall be quantitative where applicable and For example:
- Number of users
- Capacity (e.g. disk space, memory, processor)
- Response Times
- Availability
- Reliability and robustness
- Instrument Controls (e.g device connectivity, number of ports etc.)
- Data migration/Data load from other systems
Requirements of the system in case of failure (Power failure, processor failure, I/O equipment failure)
User requirements for system access/security shall be specified in the URS – Access levels / Passwords
Definition of what information is protected.
Define what constitute an error and state general requirements for handling. More specific error handling requirements shall be stated in appropriate sections (System interface, User interface, Data Reporting, Performance, Controls, and Security).
Specify the report distribution and printing.
Identify the alarm requirements for the system and address any requirements for viewing and printing recorded alarms and the number of alarms to be stored on the system.
Identify the event requirements for the system and address any requirements for viewing and printing recorded events and the number of events to be stored on the system.
Detail the real time and historical trending requirements.
Specify any required functionality related to data retention.
User interfaces
This section shall address and define any system user interfaces and shall include the following:
Applicable specialty hardware interface.
User group interfaces
These shall be defined in terms of roles (e.g. plant operator, warehouse administrator, system manager etc, or function as appropriate)
Client Workstation interface
The equipment required by the operator workstation to use the system (e.g. network requirements)
System Interfaces
Define each system interface and reference applicable diagrams depicting each interface each interface.
Specify requirements for interfaces to equipment with in the system including communication with independent controllers, sensors, output devices, control loops etc.
Specify requirements for interfaces to other systems focusing on the nature of the interaction and the methods/rules governing the interaction. The interaction shall also be described in terms of roles and functions of each system in the process.
Consider specifying data transmitted and received, data type, format, ranges and meaning of values, timing and rates of data transfer, communications protocol (initiation and order of execution) error handling, messages, recovery and reporting, handshake procedure, number of retries, security of interface and if the interface and if the interface is fully automatic or requires user actions to initiate or maintain.
Constraints/Limitations
This section shall identify constrains on the specification of the system. These identify and issue that shall restrict the options available to the developers and describe why they are limitations. It shall cover the following:
Timescales and milestone as appropriate
Compatibilities: Any existing systems or hardware
Maintenance
Including ease of maintenance, expansion capability, likely enhancements, expected lifetime, long term support etc.
Procedural
Include any procedural constraints pertinent to the system (e.g. where a certain aspect of the system shall conflict with company policy and or cGMP requirements in terms of its functionality).
Technology standards (Hardware requirements/software requirements)
Layout: Allocated floor space and/or bench space, vertical clearance etc.
Regulatory and Procedural Compliance
Include a statement of the need for compliance of the system to regulations and guidelines, including cGMP. Specific regulations guidelines pertaining to the system shall also be detailed (e.g. Code of Federal Regulations, part 21, sub-part 11 relating to electronic signatures)
Include other industry codes and company procedure as relevant.
Environment
List any important details known about the environment in which the system shall work (e.g. clean room environment)
Delivery requirements
Requirements for system delivery, including vendor documentation.
Support
In this section, detail the support which is required from the vendor. Areas for consideration include but are not restricted to:
Start-up support /Technical support /User site support /Training support /Service agreements
Safety : In this section, any safety requirements pertinent to the system shall be detailed.
Attachments : List all attachments referenced in the document
Revision History :This section contains document history information, such as a description, the date and the author of all revision.
End of Document