PLC Draft to Software -02
- Paulo Ricardo Siqueira Soares
- May 7
- 3 min read
Understanding the Process: Is It Possible Without Gathering Requirements?
Many people think that gathering requirements wastes time; it's just something for academics. Or, as one professional once said in a social media group, “We’re programmers, our job is to make the machine run wild, pump out parts!” — Unfortunately, with that mindset, he had been unemployed for over a year. Meanwhile, other professionals note that professionals, well-established as programmers, who deliver projects not only in Brazil but around the world, know that gathering requirements is essential and are never out of work. By analogy, the friend who wants to “make the machine run wild” should reconsider his concepts.
Even many who say they don’t gather requirements are doing it unconsciously. They claim they don’t do it because they don’t know what it means. After all, they always ask someone, “But how does this work?” or “What do you want it to do?” — there you go, they’re already gathering requirements and not documenting it. They can and will be held accountable for something that wasn’t written.
And do you know why you gathered requirements? Easy — let’s search on Google: “requirements meaning” — look what shows up:

Requirement — When I ask how this works, I want to know what is requested from the software to operate a given piece of equipment! So:
Without understanding the process, you cannot fulfill your responsibilities as a programmer, because you won’t be able to meet two of your primary responsibilities:
Ensuring the equipment operates as required.
Ensuring the safety of people and equipment.
Think carefully: imagine a process where a centrifugal pump X, in a low-viscosity fluid flow control circuit, will be damaged if there’s air in the line. The project engineering department, anticipating this, defines that when the level in a particular tank is at or below 50%, it is necessary (required) to shut off the pump.
An industrial programmer who had worked on a similar line before—in that system, the pump was shut off only when the tank reached 10%—assumes the same logic applies.
However, the physical dynamics here are different, and the engineering department, knowing the tank’s design, understands that the risk of air entering is already high at 50% due to the pump’s high flow rate. What did the programmer do? He didn’t gather requirements. He assumed that he knew the process. And just like that, the pump was burned out!
They failed to meet two basic responsibilities:
Ensuring the equipment operates as required.
Ensuring the safety of people and equipment.
And it could have been worse — it could have been a safety condition that caused an explosion, putting lives at risk.
Remember: we program machines that can injure or kill people!
If you’re still not convinced of the importance of requirements, here’s the IEEE — Institute of Electrical and Electronics Engineers (www.ieee.org) — definition, from their Software Engineering Glossary :
According to 610.12-1990 - IEEE Standard Glossary of Software Engineering:
📖 Requirement (definition)
Requirement:
1️⃣ A condition or capability needed by a user to solve a problem or achieve an objective.
2️⃣ A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
3️⃣ A documented representation of a condition or capability as in (1) or (2).
In the next article, I’ll talk about techniques for gathering requirements.
Bibliography:
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
Análise e gestão de requisitos de software: Onde nascem os sistemas — Felipe Nery Rodrigues Machado (Author) — ISBN: 978-8536516066 — Editora Érica
IEEE - 610.12-1990 - IEEE Standard Glossary of Software Engineering
Os grandes problemas se indicam na falta d comunicação clara entre os setores, de deixar claro o funcionamento da máquina