Hello all, I have some doubt about the URS.
My query is,
Who is the person that have to write the URS?
Thanks for your help.
Carlos
Hi Carlos,
The person who has the requirement for the equipment/software/system etc.
Regards
Hi Carlos
I generally agree with Graham that it’s whoever needs it.
However, sometimes we have found in our company that the person needing it isn’t the best person to actually write down what is needed overall. The reason I say this is that they may not appreciate that certain things are required either by law, or by another person who will interact with whatever is being bought.
(As an example, it would be our production manager who would need the new equipment and could write all the needs for capacity, speed, materials to be handled etc. They wouldn’t be very concerned about whether the lubricating points were easily accessible without undue reaching, bending etc as the maintenance would be done by someone else and is therefore outside of their expertise).
Typically in our company we put an engineer in charge of writing the URS, and they do this with the end users (plural). So the engineer will ask lots of questions about what’s needed on the ground between the production people, the maintenance crew, the quality group and anyone else who will use or interact with the equipment. They then actually write the URS, and all the end users approve it - including the validation group and quality department as independent overseers, and to ensure that it’s written appropriately.
We find this works quite well. Usually, it’s engineers who have to install and test the thing anyway, so they get quite good at writing things in a way that leads moderately easily into testing. They also like nice short words, clarity, and no additional “fluff” in documents (I speak as an engineer myself). These points are helpful in most URS documents!
Hope that gives you a bit more information.
Cat
Oh yes I agree with you, in my previous company
I wrote all the URS, and the end user only approved it.
My question is based in a document published by GAMP, “…the URS is normally written by users”.
Thanks very much!!
In my opinion, URS by user as given by GAMP can be interpreted as having the URS in user’s business language and not like a technical language. but like Cat said, engineering dept. guys are in a better position to write the URS and then get it approved by users, validation and QA who can add relevant points if necessary.
The same can be said of small It projects developed by the inhouse IT team.
regards,
…JP
[quote=Carlos]Hello all, I have some doubt about the URS.
My query is,
Who is the person that have to write the URS?
Thanks for your help.
Carlos[/quote]
the person who use the equipment
Hi Carlos
The FDA states that the URS must concisely define the user requirements, to ensure that each requirement is testable. We found it required a different format of document to guarantee that this traceability can and is consistently delivered.
The starting point for all validation is the URS. The URS is an extremely important document and it is essential that it has been correctly put together. The document must contain the high level requirements of the end user and must be clearly laid out by a Qualified End User. This produces URS-Level-1. These high level requirements must be broken down into functions that are required to work together to deliver each end user requirement. This is an engineering responsibility, and produces URS-Level-2. If the system uses software, the tasks detailed in URS-Level-2, must be translated into lines of code by the software writer, these lines of code constitute URS-Level-3.
These URS Level 2 and 3 documents were once part of the Functional Specification, however with the advent of the Full Life Cycle Requirement in software validation, the traceability between the URS and the DS was not specified in sufficient detail to allow conclusive testing, and generally it was found impossible to trace from the URS down to individual lines of code. The use of levels of URS gives the required traceability and engenders good testing between code and functionality. During these activities the URS must be maintained as an active document with each (of the 2 or 3) stages being reviewed and approved on completion.
At this stage a Design Qualification (DQ) review must be carried out to verify that this proposed coded (URS-Level-3) or uncoded (URS-Level-2) functionality, will deliver the performance stipulated in URS-Level-1, in a manner safe to product and operator, while conforming to all relevant cGMP rules and guidelines.
Satisfactory completion of the DQ signifies that everyone is agreement that the URS requirements as detailed will be deliver by the proposed design.
This traceability is essential when it comes to incorporating software changes into critical software driven systems.
Alex Kennedy
We have found that a URS should clearly address items that relate to quality versus those that are engineering only in separate areas. This allows you to carry two signature pages. Why? Because the quality section has a slightly different audience. We find with due respect to the QA folk, they should not waste their valuable time on engineering data.
We also find that QA stuff does not change much but engineering specifications do (the URS, for example might need to be adjusted a fair bit if you move from a DCS to a
PAC/SCADA solution - but none of that is strictly cGMP or QA related). The URS has to be a living document.
We took what we had done in the past plus GAMP5 and ASTM E2500-07 to produce this new template. If you ask around there is a draft JETT template (not on the ISPE JETT site - I wish someone would make them more up-to-date) that has this dual approach.
We in turn offer this template to our customers (it as lost of prompts in it) as a starting point. After all as a purveyor of bespoke automation solutions, an incomplete URS is the worst place to start.
Some of our customers consider this too radical; that is fine.
The client prepares the URS with a prompt from us.