The User Requirements Specification (URS), can never be described as a planning tool nor is it mainly used with software - but it is the most often screwed up of all the compliance documents. Whether the system is purely mechanical, or a mix of electro-mechanical, or solely a software program, the successful compilation and execution of the Installation Qualification (IQ) (for installation), Operational Qualification
(OQ) (for functionality) and the Performance / Product Qualification (PQ) (for operability), is dependent on an User Requirements Specification (URS) containing clear, concise and testable requirements.
Once the end user requirements specification or URS as it is commonly called; is documented, agreed and approved they form the basic URS Level-1 document. The engineers (or vendor) can then commence the preliminary design to establish exactly what functions are required for each of the items specified in the user requirements specification, the end user has listed. Once this functionality is documented and approved it forms the URS Level-2 document. This is the final level of the URS unless software is used.
If software is to be used, the URS Level-2 document, is passed to the code writers. As the code is written, lines, or groups of lines, of code must be attributed to the individual functions that necessitate their presence. The completion of this task results in the completion of the URS Level-3 document.
Developing the URS to this level is unique in most industries, but is, standard practice in strictly regulated industries, as it is a major building block in the creation of quality software. The URS Level-3 document, contains all the traceability which is deemed mandatory for software assessed to be critical to product quality, in the pharmaceutical regulated industries.
Full life cycle function testing.
Bringing these needs and tasks together in a manner
which will verify design fitness for purpose, has
traditionally been a tedious and laborious labour.
It involved trawling the VP and URS and cross-
referencing to the Functional Specification and the
Design Specification and the associated Test
Specifications, sometimes, with only limited success.
The design of our document is unique, it requires the
URS to be an active document up to completion of the
Design Qualification (DQ). The DQ will be executed
against the three level URS, and verify that the code
(if there is any) specified in URS Level-3, will deliver
the functionality detailed in URS Level-2, which in turn
will deliver the operability that the end user specified
in URS Level-1.
This document consists of a generic template which uses an attached SOP to allow you to quickly auto-populate the template. It then takes you page by page through the template allowing you to develop the template into your own bespoke company URS. Just ask about validation time that is saved using this simple and quick to produce a quality URS.
A PROPERLY STRUCTURED AND REFERENCED USER REQUIREMENTS SPECIFICATION (URS) TEMPLATE WILL ENSURE THAT YOUR USER REQUIREMENTS ARE PROPERLY SPECIFIED, REMAIN TRACEABLE AND ARE DOCUMENTED. THIS IS ABSOLUTELY ESSENTIAL IF YOU ARE TO HAVE SUCCESS IN YOUR VALIDATION TASK.
User Requirements Specification Justification (URS)
They must be comprehensive. Each and every requirement relating to product safety, identity, strength, purity, and quality must be identified. Hence, Quality Assurance (QA) must have a significant role in reviewing and approving the final list of requirements, and must be an approver of changes to any requirement that can affect the above product or process attributes (e.g., cGMP’s).
Given a comprehensive User Requirements Specification that has been approved by QA and is under project change management, the Design Qualification (DQ) process then can be reduced to two key objectives:
Documented verification that the overall design appears to address, by some means, each and every requirement; in the URS, affecting the product and performance of the manufacturing process (or, in the case of unknown product or multi-product manufacturing facility, the required equipment/ system performance capabilities).
Identification (and documentation) of the critical individual physical components, attributes, and operational features that directly support meeting each requirement.
User Requirements Specification (URS) Scope includes but is not limited to;
Level-1, full details of end user operability.
Level-2, full details of functionality.
Level-3, software functionality interface.
A full description of the required system performance.
Performance criteria, critical parameters and operating range.
Cleaning and maintenance requirements.
Appropriate regulatory requirements.
All none industry standard testing that may be required.
To find a specific document enter full details in Search Box Below. The more defined the search is the more precise the search findings will be.
SOP for Spreadsheet Creation.
Why does something as simple as a spreadsheet figure in so many regulatory citations? Good question; and at times a difficult one to answer. When you ask a group of compliance personnel the same question you will be informed that Excel cannot be validated because it does not seal the original copy (of the spreadsheet), allows the original to be modified and has an audit trail that can be disabled. All true, but none of these problems interfere with your ability to validate that the spreadsheet is fit for purpose. They only preclude you from using the spread sheet as a compliant repository for any data that has to be store in compliance with 21 CFR Part 11.
If the spreadsheet is signed off and dated by the user, their supervisor and QA, it becomes regulatory acceptable data stored in hardcopy, and Part 11 does not apply.
After numerous requests for this, we have launched our brand new SOP for Spreadsheet Creation to cover these and other known target points that the regulators consistently hone into as soon as they find that
spreadsheets are being used. Use this Spreadsheet Creation SOP to ensure that you create spreadsheets that are validatable. Then use our spreadsheet validation pack to validate them.
SOP for Spreadsheet Creation. -- $125.00
SOP Equipment Validation.
The SOP for Computer Equipment Validation
continues to be an extremely popular document. This document leads you through
the validation process, from the URS to the final P2Q.
Purchase your copy now at Special Price of $22.00.
Equipment combined IQ/OQ/PQ Protocol.
This combination protocol has been produced in response to several hundred reader suggestions we received in our ‘Suggestions Section’. It has been carefully designed to make it the preferred choice for Process and Laboratory stand alone equipment. It is interactive, easy to use and suitable for all mixes of equipment with and without software.
The IQ section establishes documented verification that key aspects of the equipment adhere to approved design intentions and that the recommendations of the manufacturer have been suitably considered. The OQ section establishes that there is documented verification that the installed system functions as specified and that there is sufficient documentary evidence to demonstrate this. The PQ section gives documented verification that the equipment performance in its normal operating environment is consistently exactly as specified in the URS.
It now appears that the current FDA Guidance rules pertaining to 21 CFR Part 11 may be with us for a longer time than was
originally anticipated. So we have incorporated the guidance suggestions in their latest guidance document, into our current Validation Risk Assessment (now
issue 10), which is now available for immediate download. This VRA document now comes with a downloadable matrix for registering the justification for all your
Part 11 assessments as this is now a mandatory requirement.