7 Questionnaire Blocks for PLC User Requirements

Perhaps, when you read these questions, you will wonder for a moment whether they are really all the same. And some experts are suddenly no longer sure either. We won't keep you in suspense any longer ...

In short: All expressions describe the requirements of a product, for example software, from the user's point of view. They are usually created when a new system is purchased or an existing system is modified with the following contents:

• What must this software be able to do?
• What do I expect from her?
• Which interfaces have to be considered?
• Who writes a URS?

In this article we restrict ourselves to programmable logic controllers, so-called PLCs.

The four guiding questions mentioned above should be asked and answered by everyone when creating a user requirement or even a specification.

URS A URS is written by the group of people who will use the software or computer system. The requirements are described and not the finished solution. The different requirements must not contradict each other. The user requirements can be described in tabular form or in continuous text. The advantage of the tabular form is the clarity and the assignment of a number to a user requirement. The traceability of user requirements is thus given. The disadvantage of the tabular form is the short description of the user requirements.

Example: I would like a handwriting instrument with document-proof ink. The ink must be blue and the handwriting implement must not weigh more than 100g, have a total length of max. 20cm and be approx. 15mm thick in diameter.

Not: I want a biro of the brand XYZ1 that writes blue. That would already be the solution.

The German knowledge and learning portal for equipment qualification, GMP:KnowHow Anlagenqualifizierung, uses an example to show what a user requirement for a PLC might look like. Based on guiding questions, the development of a PLC URS is explained. In this article, we give you an insight into the structure and excerpts from the more than 50 guiding questions.

The following areas and topics form the structure of a URS:

Project Description

First you start with a short project description. The URS is normally sent to one or more potential suppliers. This way they know what it is about and can propose a suitable solution.

Possible guiding questions for a project description could be:

• What do I want to tell my potential supplier?
• What is the project actually about?
• Where is the place where the software is used?

[...]

Regulatory Requirements

Possible guiding questions are:

• Which guidelines, laws and regulations must be observed?
• Which version is binding?
• Which national, supranational and international documents should be included?

[...]

Human Machine Interface Requirements

Human Machine Interface (HMI) requirements are the ease of use of a computer system/software.

Possible guiding questions are:

• How is the operation of the software/computer system regulated?
• Is the operation intuitive, or does the supplier have to be trained over several days?
• Are process-relevant and quality-relevant data immediately perceptible, i.e. clearly presented?

[...]

Performance Requirements/Functions

Possible guiding questions are:

• Is an audit trail in place?
• Are the different user roles defined and available? What processors are installed in the system and what performance do they have?
• What processor power is required for at least 5 years of system use?
• How is the system installed? (Via CD or Internet download?)
• How often is the system used? (24h/7d?)

[...]

Requirements for the Validation Documentation

Possible guiding questions and documents to be produced are:

• Which documents are required according to the validation master plan?
• Which documents do I create myself as a user, and which do I buy from the supplier?
• What tests are required and what tests does the supplier perform? (For example: White Box Test = Developer tests the software; Black Box Text = Operator tests the software with the user interface).
• Risk analysis software requirements
• Traceability Matrix
• Functional Specification (FS)
• Hardware Design Specification (HDS)
• Software Design Specification (SDS)
• HMI Design Specification
• Software Validation Master Plan/Computer System Validation Plan
• Design Qualification (DQ) Plan-Test-Report
• Installation Qualification (IQ) Plan-Test-Report

[...]

Training

Possible guiding questions are:

• Who should be trained?
• When should the trainings take place?
• Who conducts the trainings?

[...]

Occupational Safety

Possible guiding questions are:

• Does the new acquisition or conversion pose a risk to people, machines or the environment?
• Is the process becoming safer or less safe?
• Is the process realised in an ATEX environment?

[...]

Conclusion

Based on such guiding questions, detailed user requirements can be created, which significantly facilitates the creation of follow-up documents such as the software quality plan, functional specification, test plan and report for the PLC.

The article is an excerpt from the German kowledge portal for equipment and systems qualification GMP:KnowHow Anlagenqualifizierung.