URS - The Alfa & Omega of Control System Validation

I bet that each Control/Computer/Software System #Validation engineer had the issue, with the inappropriate #URS. Where the person or group who created the #User #Requirement #Specification doesn't have appropriate knowledge of the internal regulations, federal regulations, product knowledge, or even basic knowledge of the process or quality.

Do you?

Buying equipment does not give you permission to use it production; validation and qualification are still needed.

I saw multiple User Requirements Specification, which had many as possible requirements, where the document had 40+ pages. Still, requirements relevant to the specific project can be written on 5 pages in total. The User Requirement Specification is a key document, from which are based all other qualifications, and validation activities. A low-level or poorly written URS is a piece of paper, without value.

Today's article will be about the most common points of poorly written URS, and how not to do it.

Specify requirements and not design solutions. The focus should be on what is required, but not how to do it.

1- Know what you want from your system

The person, who is preparing the User Requirement for the supplier, should know, what is he expecting from the system. Starting from the mandatory requirements (i.e., Siemens Software TIA Portal V17 / Allen Bradley Software RSLogix5000 V20.05, an Alarm system with the fault finding guide directly on the HMI + direct sensor identification, and Access Control - User groups with dedicated access rights - administrator, engineer, operator), and finishing with the desired requirements of the system (i.e., Background color, Alarm background color, etc.)

2- Understand your Requirement Specification

The person, who is preparing the User Requirement for the supplier, should understand, what is he writing. In most cases, when additional questions are raised by the supplier regarding the requirement, it's funny to see the URS creator when doesn't know, what he means by this requirement. The URS should not be written until the manufacturer (Client) has a full understanding of the requirements. If requirements are not clear then the Front End Study should be the first action to solve the constraints.

The URS should be understood by both client representatives and suppliers. Do not use, that this is our template and we are using it like this!

3- Making the Requirements Traceable,

URS without unique requirement numbering is low-level URS. Remember, that the URS is a key document for the validation and qualification activities. In that case, the further documentation Software Design Specification, or Software Test Report should refer to the URS requirement under a unique number. The traceability is a key for a fast check when you are performing the tests on the machine and preparing the traceability matrix.

4- Writing Testable Requirements,

Too much general URS is a common thing, where the creator writes too many general and untestable requirements.

I.e., "The audible alarm must be loud enough to alert the operator, but less than the maximum acceptable noise level and not so loud as to cause a nuisance to other operators". How this can be tested?

As "enough to alert the operator", "less than the maximum acceptable noise level", and "not so loud as to cause a nuisance to other operators" cannot be defined, this requirement is untestable.

The requirement should be specific as it is possible, i.e.,

"The audible alarm must be loud more than 75db(A) but lower than 80db(A), 1-meter distance, 1-meter heigh.

5- No duplicated requirements

The URS should be consistent and requirement statements should not be duplicated or contraindicated.

Once the Control System Validator or Validation engineer gets the poorly written URS and he should create validation documentation, or perform the tests, it looks like this :