PLC Draft to Software -03
- Paulo Ricardo Siqueira Soares
- Jun 10
- 3 min read
What Are the Main Techniques for Requirements Gathering?
The three primary techniques used are:
Brainstorming
Interviews
Questionnaires
These techniques should be applied together with the stakeholders involved in the identified requirement—or simply the people involved in the project or the software requesters—and, if possible, include the people who will operate the line/machine/equipment.
Did you notice that when I mentioned asking the 10 questions (back in the first article), that was a reference to a questionnaire, an interview, or even a brainstorming session? Probably you didn’t realize that because you may not have been introduced to each technique yet, so let me briefly explain each one below:
Brainstorming
The famous idea storming method is widely used in areas such as advertising, product development, general problem-solving, and, of course, requirements gathering. It is essentially a group dynamic aimed at exploring the group’s creativity to solve a problem or, in our case, to define a requirement.
There are templates available—even in software like Microsoft PowerPoint—that can help set up the session. However, in practice, it involves discussing a topic you want to clarify, and participants will contribute ideas until a consensus is reached—or not, as it’s common to leave some points open-ended.
Example: Questions about the equipment’s operating modes—will it have manual, automatic, or semi-automatic modes? Often, this topic sparks extensive discussion, and a final decision is not reached in just one meeting.
Interviews
This involves preparing a series of questions, supported by technical materials and prior research, and speaking directly with a person responsible for the project or a specific area of your project or software. You will guide this conversation using your pre-prepared questions and aim to note, absorb, and extract as much information as possible from that individual.
A significant challenge with this method is getting the availability of the right people for the interview. Keep this in mind and seek strategies suited to the profiles of the people from whom you need to gather information.
Questionnaires
This method also involves preparing a series of questions, supported by technical materials and prior research, and sending them by email, print, WhatsApp, or any other convenient method to the people responsible for the project.
Following up on this process is essential, as people may forget to respond. Unfortunately, we often have to be "that annoying person" to get the necessary information.
Keep in mind that these are superficial explanations, just enough so you know what we’re referring to.
Now that we understand what requirements are, let’s start exploring the different types of requirements we encounter.
Where to Find Support Material to Create Questions for These Techniques?
We can list a few documents that are extremely valuable and may already define some requirements, just needing refinement. Here’s a list:
Programming and electrical design standards
Technical standards referenced in the project document, such as NR12, ISA-88, etc.
Project and/or service request
Commercial proposal for the project/service
Electrical project
Example software from the company's standard library
Technical manuals for the equipment to be used, such as HMIs, pumps, motors, VFDs, etc.
CT Chart – Cycle Time Graph
Project description
Project initiation document
Operating description of the equipment/project/line
Any other technical documentation relevant to the project
See you in the next article.
References:
https://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034
https://www.devmedia.com.br/introducao-a-engenharia-de-requisitos/29454
Software Requirements Analysis and Management: Where Systems Are Born – Felipe Nery Rodrigues Machado – ISBN: 978-8536516066 – Érica Publishing
IEEE 610.12-1990 – IEEE Standard Glossary of Software Engineering
Comments