User Requirement Specification is a specific document where end user generally defines needs, target, goal and their expectation for a system, service and product. This is actually blueprint for the development personnel and it help to ensure that the product meet the target for the specific group.
A standard User Requirement Specification includes information about the user group, targeted use of the product, functional requirements, Operational requirements, and performance requirements. It also contains constraints or limitations.
A standard User Requirement establishes a better understanding between the stakeholders regarding a defined outcome; also sets a specific goal for the end-user and helps to save the project, and product delivery time the best thing is its budget-friendly; the user can previously estimate the cost of the specific project.
URS is generally developed by the buyer defining all listed requirements. After the development of a URS, the user sent it to the equipment manufacturer to prepare it as per predefined criteria.
A poorly developed URS is always creating confusion for the manufacturer, you can see the poorly written URS at the manufacturer’s end and If you don’t know how to write URS then you can ask standard URS template from the manufacturer, they are happy to help you. If supplied Template is found near your requirements then you can go with a modified version.
User Requirement Specification when disregarded?
A confusing URS is always disregarded. If the manufacturer can’t read you then the faulty or wrong machine can be developed which can destroy your project and A meaningful and well-written user requirement specification saves time and money; also reduce misunderstanding among the manufacturer.
A series of emails may generate to explain your requirement to the manufacturer which may express your poor level of understanding of the specific requirement also create of the high chance of wrong specification delivery and You have to express the requirement what exactly you are looking for in your User Requirement Specification (URS).
Keep it simple, Specific, and Better user requirement specification creates better outcomes.
Requirements of user and support design, qualification activities, operations, commissioning, and maintenance are mainly present on the URS. It’s good to set your mind at the start of your dream project.
According to Mark R. Smith, MD, Realtech,
“A standard URS shall be clear, jargon-free, easily readable, not hard to understand which helps to software engineer and Designer clearly readable and understandable of the user requirement with minimum cost and maximum output”.
Types of Requirements
There are several types of requirements that are depicted here.
[] Business Requirements
[] Functional Requirements
[] Stakeholder Requirements
[] Non-Functional Requirements
[] Transition Requirements
What thing to consider for user requirement specification (URS)?
Two main things shall be considered during the writing of URS, number one: What shall be included and number two what shall not be included.
What to include:
During the writing of the URS, the actual information shall be included in the URS. More information may require for big projects and less for a small project the basic of all URS shall be specific. Unknowingly including a feature that is not available in the market is the same as knowingly ruining your project.
Knowing then any feature should be included in the URS. The most important thing is to include only those specifications that are necessary. Features that will never be used need not be included but the facility to use updated features can be retained.
What not to include:
Ambiguous words or terms, Features that are not easy to understand, and that no one has yet used, features that are not user-friendly and will never be used, and features that are overpriced but less important shall be avoided.
How to proceed with your User Requirement Specification?
Before proceeding with your URS, define the responsibility of the stakeholders in your URS then collect all stakeholders’ signatures with designation and date. An approved URS shall be procced to the manufacturer to avoid any wanted circumstances. To sign a document means that you are responsible for it.
What should be included in the Introduction section?
In this section, you should describe more briefly about yourself and why this URS has been raised. Give a short description of your organization. Like “We are Startech is a startup organization in west Virginia. We want to install a high tech tablet compression machine to produce almost 6000K tablets per hour. This user requirement specification (URS) documents the user requirements for producing tablet dosage forms in a tablet compression machine.
The objective of the User Requirement Specification
They clearly describe the goal of the project so that anyone understands it. A brief overview of the project shall be included. Mention the actual purpose of the URS.
Who will write the User Requirement Specification?
Anyone can write URS, who has a thorough knowledge of the system, service, product, or machine in question. But you don’t let someone write something they don’t know about, for example, production personnel can’t write the URS of quality control equipment and vice versa.
How to document a User Requirement Specification?
The user will prepare the URS and another SEM will check the URS and Engineering personnel and the head of the user department will Review the document, finally Head of Quality will approve the URS. Always documented hierarchy shall be maintained.
To write user requirement specifications for a pharmaceutical company equipment following points should be included
1. Front Page: URS no., Revision no., Addendum no., Using Facility shall be mentioned.
2. List of revisions: Revision number shall be mentioned (if required).
3. List of addendums: Addendum to be mentioned (if required).
4. Table of Contents: Write the list content of the URS.
5. List of abbreviations: All abbreviations shall be mentioned.
6. Signature page: Signatory page contains all signatures including Approval authority.
7. Scope: The scope of the URS is to define the specific Equipment/Instrument.
8.0 Procedural Document Requirements:
This part gives information about the Equipment / Instrument including the Purpose of the Equipment, Specification, Qualification, etc.
8.1 Name of the Equipment: Name of the equipment to be mentioned here, if possible, and Model No. to be defined here.
8.2 Purpose of the Equipment: Purpose of the Equipment shall be clearly defined here.
8.3 Number of Equipment Required: Require quantity of the Equipment/Instrument shall be defined here.
8.4 Qualification: A list of qualification documents shall be mentioned here.
8.5 Specification of Equipment: All major specifications of the Equipment/Instrument shall be mentioned here.
9.0 Operational Requirements:
9.1 Vendor Scope: The Vendors scope shall include the Supply, Installation, and Documentation including calibration certificates, User training, and Details of service/maintenance contracts available.
9.2 Operation: Basic operative characteristics including Data logging (21 CFR part 11), controlling system, capacity, safety, and protection, the capacity of basic function, etc.
9.3 Options and Ancillaries: The vendor should identify, where applicable, their standard equipment that fits this specification. The vendor shall (where possible) also provide costs including, A range of additional maintenance support and services., Any additional accessories to fulfill the requirements indicated in section 9.2.
9.4 Interfaces: A user-friendly control system is required, that can allow system operation with a minimal amount of training.
9.5 Data and Security: If required, data and security articles are to be clearly defined here.
9.6 Environment: Instruments/Equipment’s operating environment should be clearly defined here. The operating area must fit with the specific Instruments/Equipment in such a way that it can be operated without any difficulty.
10.0 Constraints
10.1 Milestones and Timelines: A projected timeline and milestone may be set here.
10.2 Compatibility and Support: The internal components of the system must be compatible with, and resistant to, the materials used during operation. Operating power to be mentioned here.
10.3 Maintenance Requirements: The manufacturer should supply details of any maintenance/breakdown packages available.
10.4 Procedural Constraints
11.0 Life Cycle
11.1 Development Procedures: Future development procedures are to be mentioned here.
11.2 Testing Requirements: See Section 11 for a detailed matrix of the validation testing requirements.
11.3 Delivery Requirements: On supply, the following documentation should be supplied: Operation and maintenance manual (including manufacturer’s recommendations for maintenance schedules). Calibration certificates. Parts list and spare requirements. System specifications.
11.4 Support: The vendor must supply details of all service and maintenance requirements of the equipment. The vendor must also supply details of any service and maintenance support that they can supply.
12.0 GMP Requirement: A list of cGMP requirements shall be mentioned here.
13.0 Utilities Available at The Site of Installation: Utilities shall be described here including the power supply for the machine/equipment.
14.0 Documentation Requirement: A list of documents shall be described here such as Operation, cleaning, and maintenance manuals for equipment as well as the operation, Installation instructions/ guideline, other drawings (such as Mechanical, electrical, instrumentation, etc.), IQ/OQ documents & operating manual., Instrument calibration / Qualification certificates traceable to the national reference standards, Guaranty/ warranty certificates for the equipment, Shipping checklist, and Hardware design specification.
15.0 Terms and Conditions to Be Included in The Quotation: All the terms and conditions shall be described here.
16.0 All the discussion shall be noted here and contact personnel details shall be mentioned at the end of the discussion details.
17.0 Annexures: Mention annexures if there are any.
18.0 Validation Requirements:
The following details the test requirements for documentation, testing, and the stage of the project at which they must be provided/performed. These requirements are a minimum tariff, and the vendor is required to include any documentation, not already requested here, which is considered necessary to support the successful validation of the system.
Which things to follow to write a Modern User Requirement Specification?
From the discussion till now we know what to add to our URS and what not to add. Ambiguity to be avoided as much as possible should be written clearly so that anyone who reads it can understand it. Ambiguity is the enemy of any project’s success and expressing yourself as accurately as possible is possible. Communication must be done in an unambiguous manner to achieve good results; Your project will be successful when you are able to convey your message to others.
To write a best User Requirement Specification you need to keep the following points in mind:
1. Focus on Single Requirement:
Check each requirement to be developed and how it is tested. Project success depends on each effective requirement which is really a demand to the project. Avoid unnecessary requirements which really not essential to the project.
2. Avoid Haziness
Your URS must be clearly written. Use a Simple Sentence. No confusing word. Just say what you want and what not.
A user requirement specification should be clearly written, using simple sentences, and without ambiguity. Examples of ambiguous words are:
[] Easy
[] Strong
[] Improve
[] Fast
[] Slow
[] Enough
[] User friendly
What exactly are you meaning “Fast”? this term is theoretical; you can’t actually express your requirement using the word “Fast”. It is hard to measure. Avoid any abbreviations, acronyms, and jargon words (words and phrases, that are not generally understood).
3. Go with the SMART Approach
[] S for Specific
[] M for Measurable
[] A for Achievable
[] R for Realistic
[] T for Time-bound
SMART [Specific, Measurable, Achievable, Realistic, Time-bound) targets offer a decent way to confirm your URS is well-defined and supportable.
Specific: All requirements mentioned in the URS must be specific, clear, and jargon-word-free. Don’t add any unnecessary requirements like easy and fast. Mention the actual specification.
Measurable: Reequipment must be measurable, don’t state anything which can’t confirm by testing or examination. Always avoid theoretical statements like rapid and swift. It can’t measure, you can’t prove that your requirements just met the specification until it is measurable.
Achievable: Never set a requirement which is can’t achieve with help of current technology. A feasibility study shall be done before setting any requirements. You can’t set any requirement which is technically impossible to achieve. It is wise to study well before adding features that you have no idea about. If even then you cannot be confirmed, then seek an expert for help. It is not right to add any feature without knowing it.
Realistic: It’s important to be realistic when determining the list of requirements. Sometimes technically achievable requirements may not be realistic due to regulatory requirements, time restrictions, Budget constraints, or other limitations.
Time-bound: A specific time frame shall be fixed to obtain your project. Even after finishing everything and if the specified time is not fixed, then any project may fail.
4. Organize
Organize your word choice and think carefully about it. Generally, the word “Shall” and “will” define the actual requirement which must be met. Word like “May” and “Could” use to define goals than are expected but not necessarily requirements. So, when you want the requirement must be met then use shall/will and use may/could for not mandatory cases.
5. Control Changes to the Requirements
Any type of changes may require during creating your list of requirements. Changes to the specification of the specific requirement shall be controlled. If any type of change directly affects the requirement, then the requirement shall be updated and a new version shall be created.
6. Requirements Must be Testable
Requirements shall be written in a such way that they can be tested and Specific requirements shall be traceable through the life cycle of the system/service/equipment/instruments.
7. Structural Products
Two types of products may be used as structural products & custom applications; for custom applications, the manufacturer must describe every process step to the user. For structural products, the process steps must be aligned with their predefined specification.
8. Vendor Audit
Most of the cases Regulated companies are most aware of their vendor for periodic assessment. All types of assessment/re-assessment perform in accordance with the Quality Management System (QMS).
9. Specifications
It is essential for the supplier to thoroughly document both the functionality and design of the system which is a prerequisite to ensure successful product development. Documentation must cover all aspects of the system, including software, hardware, and configuration, to meet all requirements to be established.
10. Training & Documentation
The supplier must agree to provide comprehensive system management documentation and provide instructions for both maintenance and use by the supplier and related issues must be agreed upon prior to system purchase.
11. Eliminate Requirement Redundancy
Avoid overcomplicating the system requirements and there is no need to bulk it up by duplicating it. Avoid duplication. Duplicating your documents may require more testing, documentation, and review time, making the project and time progressively longer Don’t include anything which is related to money or finance.
What is the difference between data and information
12. Embrace the Opportunity to Evaluate Vendors
Conducting audits on suppliers may include asking the following questions:
[] Security
[] Product support
[] End User training
[] Company Overview
[] Use of sub-contractors
[] Service delivery process
[] QMS application at the company
[] Development product life cycle
[] Key products development plans
[] Organization, roles, responsibilities, & training
13. Don’t be intimidated by your vendor comparisons
Utilize your URS to evaluate different vendors & note their advantages and disadvantages. If new information is found during the initial stage, feel free to revise your approved URS accordingly through the change control process. It is acceptable to make modifications or adjustments to the requirements to fit your needs until the final approval of the URS and it shall be revised the approved User Requirement Specification accordingly maintaining proper documentation.
14. What ought to be included in the URS?
The contents of a URS naturally include the following (but are not limited):
[] Functional requirements
[] Operational requirements
[] Technical requirements
[] Interface requirements
[] Data requirements
[] Security requirements
[] Regulatory requirements
[] Maintenance requirements
[] Availability requirements
[] Migration of any electronic data
[] Environmental requirements
[] Constraints to be observed
[] Life cycle requirements
15. Categorize Your Requirements
Categorize Your Requirements as-
[] Mandatory (High)
[] Beneficial (Medium)
[] Good to have it (Low)
16. Subjective Knowledge and Processing Step
To ensure that requirements, your professional knowledge is essential but not mandatory; if require you can seek help from an SME [Subject Matter Expert]. To identify key requirements of the system Process knowledge is required which are related to the manufacturing/servicing process. Look for the following key points-
[] Experience
[] Knowledge
[] Documentation
17. The requirements may be incomplete or not fully specified
Sometimes the requirements are not fully understood at the beginning of the project; Requirements evolve over time. URS shall be developed as per requirements when information is available. Don’t share incomplete User Requirement Specifications to the manufacturer to avoid any unwanted requirements.
Frequently Asked Questions
Are URS always required for validation?
At the initial stage of system/service/equipment/instruments, then URS is a valuable tool for ensuring the asking requirements. When an existing system is being validated then URS consider as a functional requirement. These two documents can’t be considered as single documents.
What is the benefit of good User Requirement Specification?
Requirements gathering is an important part of a good software/hardware/service/product development project. Good estimation, improved customer satisfaction, reduced cost, and project duration can all fail if good requirements are not selected and sufficient knowledge is not introduced in the selection If you are unclear about what you are delivering, no one can expect anything better from you.
There are Five main questions that shall be asked to develop any project:
[] Why we are doing it?
[] What do we need to do it?
[] What is the benefit?
[] How do we do it?
[] What is the timeframe?
If we fail to estimate project requirements or are unable to assume what is the requirement, can lead to a poor outcome of the project, and also lead to extra manpower, longer duration, and project costing.
Download Your
User Requirement Specification (URS) Template