SOP for User Requirement Specification (URS)

 

1. Purpose

• The purpose of this SOP is to establish procedure to define the User Requirement Specification (URS) for a computerized system.

• User Requirement Specification (URS) is a document that informs the software vendor / software on the users expectations from the software.

• URS is also first and most important step of developing a computerized system. Without clear user specifications, it is not possible to proceed with the development of a computer software that is consistent with the users’ requirements and expectations.

2. Scope

• This SOP applies to the creation of User Requirement Specifications (URS) for any computerized software system to he used in area where Quality of Product is affected or a system affecting to quality of the product.

• This SOP is applicable for proposing a new software system / application / module or developing a new functionality within an existing software system.

• It is not applicable for equipment with or without PLCs and without computers.

3. Responsibilities

3.1. User shall be responsible for:

• Request and get User Requirement Specifications (URS) Number from QA.

• Prepare the User Requirement Specification (URS) document and forward to QA for review.

• Update the URS document based on review comments (if any).

3.2. Quality Assurance shall be responsible for:

• Review the URS document and give comments (if any) to user.

• Forward the reviewed URS to IT for review and approval.

• Maintain the User Requirement Specifications (URS) register (Annexure- 1).

• Allot unique URS No to the User for new requirement request.

• Receive the URS forwarded by the User.

• Provide regulatory and/or cGxP inputs and review comments (if any) with the URS.

• Approve the URS after Change Control approval.

• To forward the final approved User Requirement Specifications (URS) to respective Technical Owner for its execution and implementation.

• Provide clarity to the Technical owner (if required/asked).

• Follow up with Technical owner for respective URS implementation.

• Update the current status of User Requirement Specification (URS) register (preparation I review/ approval / development / implementation)

3.3. Information Technology (IT) shall be responsible for:

• Evaluate the URS from a technical perspective.

• Retain the approved URS.

• Prepare the SRS using the User Requirement Specifications (URS), (if any)

4. Definitions

• URS: A URS defines precisely and clearly what the user expects the system to do.

5. Procedure

5.1. Content of URS :

5.1.1. A URS register shall be prepared and maintained by QA to record each requirement with unique identification number upon getting the requirement request from user.

5.1.2. The Register shall be updated using details mentioned below:

5.1.3. Application: Name of the Computer Software System (ex: LIMS, ERP, QMS etc.)

5.1.4. URS No : Incremental URS sequence number (as XXXX _YYY)

5.1.5. URS Date: Date when the user sent request for URS No

5.1.6. Requirement details : Brief text for the requirement (Title of the URS)

5.1.7. Raised By : Specify Name of the user who requested for new requirement

5.1.8. URS Sent date : The Date when QA sends URS to the Technical Owner for development

5.1.9. Target Completion Date : Date (if) communicated by Technical Owner to complete the development and implement at user department

5.1.10. Implementation date: Date of application release when the respective URS gets implemented.

5.1.11. Implementing Version: Version of the application through which the respective URS gets implemented.

5.1.12. Status: Status of the URS (ex: Under Preparation / Under Review / under development /Implemented / Withdrawn etc.).

5.2. Modification Details :

5.2.1. Below Modification details shall be updated in the case, any modified URS is created and circulated.

5.2.2. Flow of Modified URS will be same as per URS.

5.2.3. The Modified User Requirement Specification (URS) shall be prepared only when, development of the URS is not started or competed.

5.2.4. Modification Detail: Brief detail for the URS modification (if created).

5.2.5. Modification Date: Date; when the URS modification sent to technical owner.

5.2.6. User Requirement Specifications (URS) document shall be prepared in standard format

5.2.7. User must specify the functions to be carried out, the data on which the system will operate.

5.2.8. Technical environment concerns shall be addressed within the URS lo the best possible extent.

5.2.9. Emphasis of the URS should be on the required functionality, and not on the methodology of how the functionality will be implemented.

5.2.10. The URS should refer to and interpret the relevant cGxP regulations to assist the project learn and supplier/developer in delivering a compliant system that meets with the users’ requirements.

5.2.11. If the User Requirement Specification (URS) does not refer to any cGxP regulations, then it should explicitly state so.

5.2.12. Duplication and contradiction of the requirements must be avoided at the time of drafting the URS.

5.2.13. Each requirement described should be testable and/or verifiable.

5.2.14. The URS should define the environment in which the system must operate. Like required functions, mode of operation, and behavior of the system.

5.2.15. It should consider following:

5.2.16. Functions and process required, with information on existing manual system.

5.2.17. Calculations, including input data, processing conventions and output at respective screens or reports where required. User Requirement Specification (URS)

5.2.18. Action required in case of failure

5.2.19. Security and Access control

5.2.20. Validation / Checks required, wherever possible

5.2.21. The User Requirement Specifications (URS) must comprise all the possible scenarios for meeting the user’s requirement.

5.2.22. The URS must explicitly specify the impact on the other functional areas.

5.3. URS header Content :

5.3.1. Raised By : Name of the person who initiated the change for new requirement

5.3.2. Request Date : Date when the requirement identified

5.3.3. Request sent on: Handwritten date; when the approved User Requirement Specification (URS) sent for development to Technical Owner.

5.3.4. Title: In this brief description of requirement in minimum generalized text shall be mentioned.

5.3.5. User Requirement Specification (URS) document’s Requirement Details section should consist below details:

5.3.6. Requirement Sr No : In this part user shall define sequential number for each requirement

5.3.7. Existing System: In this part user shall specify the existing functionality along with area (in current application) where it is impacting

5.3.8. Proposed System: In this part user shall explain the new / updated requirements from application along with area (in application) how it is required to behave.

5.3.9. If there are more than one requirements then for each new requirement Sr No shall be incremented and further requirements shall be mentioned in same fashion (i.e. with Existing and Proposed System details)

5.3.10. User Requirement Specification (URS) documents Justification section:

5.3.11. In this section, enter the appropriate justification text.

5.3.12. User Requirement Specification (URS) document’s Approval section:

5.3.13. This section shall be at the end of the URS where user from specified department shall sign with date after review.

6. The following point must be included in URS:

• Name of the user department

• Location

• Machine/equipment/software name

• Purpose of the machine/ equipment/ software

• Other areas of impact (AHU, movement, and space)

• Parameters to be considered for the URS.

• Model making Name with specification, and quantity with the remark.

• Capacity: give the detailed specification and quantity likes requirement in Kilogram or liters.

• The material of construction: give details about the material of construction like Stainless steel and its grades.

• Give details about Instruments on machine likes Metal detector, Camera inspection system, and pinhole detector, etc.

• Required calibration details with the specification with remarks

• Details specification: baffles, Die, punches, Guide track, cutter, and channel.

• Specified details about required tools

• Documentation like FAT / SAT/ Qualification/ manuals

• Environmental: (Include the temperature and humidity of the area ) / health safety requirements (like MCB and safety Guard) and Control (Specify needs of equipment, interfaces, output forms (e.g., USB)

• Critical control points

• Others:

Utilities: Define the kind of power supply to use for the equipment, the requirement of UPS, or other utility requirements. Include water system, quality, or compressed gas, if required.

Availability: Limitation of operation time for the equipment

Supporting Documents: Operating manuals, warranty, parts, spare parts, circuit diagrams.

User requirement specification document shall be signed by an authorized person in the column prepared by, reviewed by, and approved by. In the end, review, revise, and approve the URS. The next step is the design qualification.

Are User Requirements Specifications always required for validation?

When a system is being created, User Requirements Specifications are a valuable tool for ensuring the system will do what users need it to try to do. In Retrospective Validation, where an existing system is being validated, user requirements are equal to Functional requirements.

Read also: User Requirement Specification in Pharmaceutical Industry

Resource Person: Dr. Hassan Elsanhouty