Shall – indicates a requirement
Should – indicates a recommendation
May – indicates a permission
Can – indicates a possibility or capability
Some useful questions to ask yourself when creating user requirements:
● Is the requirement essential to the success of the product? ● Is the requirement clear? ○ If i gave the requirement to a designer or engineer, would he/she know what I meant by it? ● Is the requirement selfcontained (i.e., can it stand alone and be understood without additional information)? ● Is each requirement actually a single requirement and not actually multiple requirements? ● Is the requirement solution neutral (i.e., does it not imply the use of one solution over another)? ● Is the requirement precise? ○ Does the requirement have only one interpretation? Is this interpretation obvious? ● Does the requirement avoid using potentially ambiguous words such as: ○ Vague subjects: “it” or “they” ● Does the requirement specify a “what” rather than a “how”? ● Is each requirement consistent with the other requirements? Are there direct conflicts?
13
● Does each requirement describe a unique aspect or are there requirements that describe the same thing?
The URS is originated by the end user extrapolating requirements directly from the production processes. These high end user requirements are then passed to engineering who are tasked with turning them into a complete procurement package. A package that will include all aspects of purchasing, installing and operating the specified system. Further to these direct requirements there are also a multitude of indirect requirements, such as; documentation, manpower, training and test equipment that must be fully researched, investigated and specified. The URS must be written in a format that allows each of these requirement to be verified as being “fully satisfied” or not.
https://www.slideshare.net/DrAmsavelvel/validation-master-plan-115143205
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.
- Documentation requirements.
- Training requirements.
- All none industry standard testing that may be required.
[https://www.validation-online.net/design-qualification.html]
Design requirements:
Capacity: Blower, Motor, Condenser, Exhaust, Refrigerator, etc
Physical Space requirements
safety
Cleanability
Loading/unloading - Door movement / auto loading and unloading / manual handling
Proper illumination
Control System requirements:
Access level verification
Process automation / semi automatic
Human machine interface
Data backup - electronic - hardcopy
online monitor/record
printed data
https://www.youtube.com/watch?v=3UQL-J2YedE
http://www.labquality.be/Documents/171013_ITM_Equipement%20Management_ENG.pdf
How to write User Requirements and Engineering Specifications - Core Content
Requirement Specification Template
Example 1 - Wide Range Filler User Requirements Specification
Example 2 - Planetory Mixer
Example 3 - Development and implementation of the furnace monitoring and control system
Example 4 - RFP
Example 5 - Wireless Blood Refrigerator Monitoring
Example 6 - Central Registration Agent
Example 7 -
