URS - The Alfa & Omega of Control System Validation III

In previous articles, I wrote about the URS, the most common mistakes, and which departments are crucial to cooperate with. As you understand these key points, you are ready to create your first professional User Requirement Specification.

Let's recapitulate, what is the purpose of the #URS.

• Provide input information for the Functional Design Specification (#FDS)
• Provide unambiguously and commonly understood Operational and Interface listings of #Functional and #System #Requirements, which can be tested during the #Qualifications,
• Include or reference all #Manufacturing #Data, including critical data for system design and testing.

A suggested structure of the User Requirement Specification document should be used but is not limited to, as each machine and requirements are different. There is no common template, which can be applied directly to all types of machines.

1. Introduction,

A briefly described purpose of the newly created User Requirement Specification.

2. Overview,

This point can be divided into multiple points, where the Background (A brief description of the purchaser company should be written), Scope of the URS ( A brief description of the product with the process description, which will be automatized), and Out-of-Scope ( A brief description, which points will be excluded from the URS, such as deadlines, costs, quotations, etc. )

3. Responsibilities,

All required responsibilities of the supper and regulated company should be listed, such example below:

4. Operational Requirements,

All requirements should be verifiable. Of course, some of the requirements may be difficult to define and verify, because they are subjective and therefore may be subject to different interpretations. Below are listed common operational requirements, which serve as cores for professional URS of Control System automation machines.

4.1 Functional Requirements,

The functional requirements should include all requirements that would help the system to perform the business process to be automated. These requirements can include but are not limited to #Calculations, #safety, #security #access #control, #audit #trails, #electronic #signatures, #outputs ( files, reports), and #error and #alarm #messages requirements.

Example: In case of failure, an alarm message should be highlighted on the HMI panel with red background color

4.2 Data Requirements,

Consideration should be given to an understandable impact on patient safety and product quality. There should be defined #ERES, #Critical #parameters, #valid #data #ranges, #limits, #accuracy, #required #fields, which should be filled in before the process can be confirmed, #backup and #recovery of data, #archiving of the data, and its #security and #integrity.

Example: The filling process should have valid data ranging from 0 to 50 ml.

4.3 Technical Requirements,

System technical requirements should be defined, such as Changes in system operation (#System #start-up, #shutdown, #test, #failover), Disaster #Recovery requirements, #Performance and timing requirements, #capacity, access speed, #hardware, and #configurability requirements.

Example: Siemens Hardware should be used for the Control System (Programmable Logic Controller, and HMI )

4.4 Interface Requirements,

Buyer should document interface requirements, such as interface with other users and their roles ( #Operator, #Technician, #Administrator), log-in through the Human Machine Interface, or other #applications ( Desktop, remote desktop), interfaces with other #systems, or equipment, such as printers, #vision #systems, #actuators or #sensors.

Example: Vision System should be connected through the Ethernet.

4.5 Environmental Requirements,

Predefined required #length, #height, #physical #condition, #physical #security, and #power or #pressure requirements.

Example: The machine should be capable to use 6 bar filtered air pressure to perform its tasks

4.6 Performance Requirements,

Required minimum product rate per hour, maximum rate per hour, the minimum #quality rate on output, #performance efficiency, #OEE, #changeovers, #Cpk measured value, or downtimes should be defined.

Example: The minimum product rate per hour should be 720 pieces when the machine is fully supplied with the input material.

4.7 Availability Requirements,

The availability of the machine per production, such as 365 days should be available to produce on the machine, minus the monthly, or yearly #maintenance.

4. 8 Security Requirements,

Purchaser should describe the user groups, which will be available on the machine, password requirements ( #password aging, minimum password length, #login requirements, data #retention, #user adding and deletion ( User Adding and deleting is typically covered in local or global IT/QA #SOP )

Example: Password should have a minimum of 8 characters, where the combination of letters, numbers, and special characters should be used.

4.9 Maintenance Requirements,

Requirements for daily, monthly, or yearly maintenance should be defined. It follows the template, that the daily maintenance should not be more than 2 hours, and monthly maintenance should not be longer than 2 days. No special tooling should be used to perform the maintenance on the machine, and in case special tooling is required, it should be delivered by the supplier. Support on the machine #breakdown should be defined with timeframes, which are required from the supplier.

Example: No special tooling should be used when maintenance will be performed. In case, that special tooling will be needed, it should be delivered with the machine.

4.10 Regulatory Requirements,

Requirements should address applicable #GxP regulations, EU, and #FDA regulations and should highlight those aspects that are critical to patient safety, product quality, and data integrity. It should not include wording like "#Part11 compliant" or "#GMP compliant".

Example: Passwords, which are entered during the login process should be obscured.