top of page
Search

PLC Draft to Software -02

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:


  1. Ensuring the equipment operates as required.

  2. 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:





 
 
 

Recent Posts

See All
PLC do Rascunho ao Software - 34

Depois que entendemos um pouco da norma ISA18.2 "Management of Alarm System for the Process Industries", temos que entender que em um...

 
 
 

1 Comment

Rated 0 out of 5 stars.
No ratings yet

Add a rating
Rated 5 out of 5 stars.

Os grandes problemas se indicam na falta d comunicação clara entre os setores, de deixar claro o funcionamento da máquina

Like

Sobre Nos

SOCIALS 

Participe do nosso Grupo:

Telegram e  WhatsApp.
 

SUBSCRIBE 

PLC com Engenharia de Sofware nasceu de um grupo de WhatsApp, que teve suas origens em 2018 em outro grupo, e criado oficialmente em 2020. Depois de solicitação seus participantes e outras pessoas que gostam do trabalho, vem a criação desse Blog para trazer alguns artigos, apostilas e tamém sempre que possível notícias.

Se inscreva para receber notificações de novas postagens!

Obrigado por sua Inscrição

© 2035 by FEEDs & GRIDs. Powered and secured by Wix

bottom of page