Blog

Standard Operating Procedure (SOP) for Handling of User Requirement Specification (URS) for a computerized system or Instrument / Equipment. User Requirement Specification (URS) is a document that informs the software vendor / software on the users expectations from the software

User Requirement Specification (URS)

1.0   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.0   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 equipments with or without PLCs and without computers.

3.0   RESPONSIBILITIES:

• • For Centralized Computer Software Systems:

• • 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)

• • 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)

• • 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.0   ABBREVIATION USED – USER REQUIREMENT SPECIFICATION (URS):

• • URS : User Requirement Specifications

• • PLC : Programmable Logic Control

• • SRS : System Requirement Specification

• • MIS : Management Information System

• • cGxP: Current Good “x” Practice (x = Clinical, Engineering, Laboratory, Manufacturing, Documentation, Pharmaceutical, etc.)

• • LIMS : Laboratories Information Management System

• • ERP : Enterprise Resource Planning

• • QMS : Quality Management System

• • DEFINITION :

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

• • The document contains information about the operating environment, the required data for processing, the functionality that the system should carry out and can have references to the existing process flows, documents, forms and reports.

• • In a regulated environment, the URS should have a reference on the GxP regulation and must interpret it in clear and unambiguous terms.

5.0   PROCEDURE – USER REQUIREMENT SPECIFICATION (URS):

• • Content of URS :

• • A URS register shall be prepared and maintained by QA (as per Annexure – I) to record each requirement with unique identifier upon getting the requirement request from user.

• • The Register shall be updated using details mentioned below:

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

• • URS No : Incremental URS sequence number (as XXXX _YYY)

• • URS Date: Date when the user sent request for URS No

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

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

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

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

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

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

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

• • Remarks : Any further details if needed to be recorded for the respective URS.

• • Amendment details :

• • Below Amendment details shall be updated in the case, any amended URS is created and circulated.

• • Flow of Amended URS will be same as per URS.

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

• • Amendment Detail : Brief detail for the URS amendment (if created).

• • Amendment Date : Date; when the URS amendment sent to technical owner.

• • User Requirement Specifications (URS) document shall be prepared in standard format (as per Annexure – 2).

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

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

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

• • 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.

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

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

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

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

• • It should consider following:

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

• • • Calculations, including input data, processing conventions and output at respective screens or reports where required.

• • • Action required in case of failure

• • • Security and Access control

• • • Validation / Checks required, wherever possible

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

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

• • URS documents header should consist below things:

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

• • Request Date : Date when the requirement identified

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

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

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

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

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

• • 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.

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

• • User Requirement Specification (URS) documents Justification section:

• • In this section, Enter the appropriate justification text.

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

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

• Procedural flow of URS with Centralized Computer Software Systems:

  • User from any department shall send request to QA for getting URS No.

• • Upon getting request from user, QA shall issue an incremental unique URS No to the requesting user and simultaneously shall update the User Requirement Specification (URS) register.

• • Upon getting URS No from QA, user shall draft the User Requirement Specification (URS) document (Annexure – 2).

• • User shall consider sections and related details with the URS document.

• • After completion of drafting the User Requirement Specification (URS) document, user shall sign Prepared By column in URS approval section and forward the URS document to QA for review.

• • QA shall review, give comment (if any) and get it corrected from user. QA shall sign the User Requirement Specification (URS) and forward to technical owner.

• • Technical owner shall evaluate the User Requirement Specifications (URS) from a technical perspective and get any clarification from the QA (if required) and proceed for preparation of the SRS.

Note : If addendum is received, necessary Updation shall be made to the SRS.

• • Technical owner shall prepare action plan with target implementation date and shall inform target completion date for implementation of the User Requirement Specification (URS) to QA.

• • Before implementation of the User Requirement Specifications (URS), technical owner shall inform QA about URS No, Application Name, Application version and Release Date

• • Upon getting information from technical owner, QA shall inform about implementation of the User Requirement Specification (URS) to user(s) and shall update the “CLOSE” status in URS register for respective URS.

• Procedural flow of URS with Decentralized Computer Software Systems:

(User – Department Head – Quality Head – Factory Head)

• • User from any department shall request to QA for getting URS No.

• • Upon getting request from user, QA shall issue an incremental unique URS No to the requesting user and simultaneously shall update the User Requirement Specification (URS) register.

• • Upon getting User Requirement Specification (URS)No from QA, user shall draft the URS document (Annexure –  2).

• • User shall consider sections and related details with the User Requirement Specification (URS) document.

• • After completion of drafting the URS document, user shall sign under Prepared By column in URS approval section and forward the User Requirement Specification (URS) document to his/her Department Head for review.

• • Department Head shall review, give comment (if any) and get it corrected from user.

• • Department Head shall sign the URS and forward to Quality Head.

• • QA Head shall review, give comment (if any) and get it corrected from user (with due signatures of user and Department Head), sign it under first approval and forward the URS document to Factory Head.

• • Factory Head shall review, give comment (if any) and get it corrected from user (with due signatures of user, Department Head and Quality Head), sign it as Final approver and forward to QA.

• • QA shall perform below activities:

• • Write down the URS approval date at URS Sent On (at URS Header)

• • Keep the duplicate / scan copy with QA

• • Forward the original approved URS document to technical owner

• • Update the User Requirement Specification (URS) register with status = Pending

• • Technical owner shall evaluate the User Requirement Specification (URS) from a technical perspective and get any clarification from the QA (if required) and proceed for preparation of the SRS.

• • Note : If addendum is received, necessary updations shall be made to the SRS.

• • Technical owner shall prepare action plan with target implementation date and shall inform target completion date for implementation of the User Requirement Specification (URS) to  QA.

• • Before implementation of the User Requirement Specification (URS), technical owner shall inform QA about URS No, Application Name, Application version and Release Date

• • Upon getting information from technical owner, QA shall inform about implementation of the URS to user(s) and shall update the “CLOSE” status in URS register for respective URS.

6.0   ANNEXURES:

Annexure – 1 : URS Register

Application	URS No.	URS Date	Requirement Detail	Raised By	URS Sent Date	Target Completion Date

Implementing Version of Execution	Status	Remarks	Amendment Detail	Amendment Date

Annexure – 2 : URS Format

Computer System Title:
URS No.:				Raised By:
Request Sent on:				Request Date:
Title:
Sl. No.:	Requirement Details:
1	Existing System:
	Proposed Changes:
	Justification:
	Relevant cGxP Regulations (if any):

Prepared By: (Sign &  Date)	Reviewed By (Sign & Date)	Approved By (Sign & Date)

Note:

• • If required, Calculations, Data, report formats etc. can be provided in same URS document or as separate Annexure with appropriate references.

• • In case of space constraints attach Annexure to URS.

• • Justification can be single for whole requirement or separate for each requirement point in the URS

• • Relevant cGxP regulations (if any), stated where needed otherwise to state “Not Applicable”.

• • For each separate impact area / requirement, use the incremental Sl. No.