top of page
Search

PLC do Rascunho ao Software - 04

O que são e como aplicar os requisitos de usuário com PLC?


Os requisitos do usuário descrevem requisitos funcionais e não-funcionais de forma compreensível pelos usuários do sistema, ou seja, descreve de forma não formal, incluindo com desenhos feitos a mão, com redações curtas, etc. uma vez que não possuem conhecimento técnico.

Em resumo descrevem o comportamento externo do sistema, descrevendo características do projeto do sistema.

Dentro dos documentos, teremos um exemplo:

- Quando eu apertar o botão de start, a luz para o operador muda de verde para vermelho, os grampos fecham e a mesa vira.

Vejam que esse tipo, de declaração pode ser confusa, se você tem mais de uma torre de iluminação? Qual delas muda de estado? As duas? Será que tem ordem o carregamento de peças? Tem ordem de fechamento de grampos? A mesa só tem 2 posições?

Os requisitos de usuário vão criar perguntas e é normal, mas vão conter as expectativas dos usuários. Em um mundo perfeito o responsável pelo projeto iria refinar os requisitos, tornar essas pequenas histórias do usuário em requisitos para o software, em uma linguagem mais formal, incluindo prototipação de telas, etc. em TI temos a figura do analista de requisitos para fazer esse tipo de descrição, infelizmente a área de automação ainda está engatinhando nisso nesse caso cabe ao programador, isso mesmo meu amigo!!! O programador além de desenvolver o software tem que correr atrás dos requisitos em grande parte das vezes.

Mas veremos que algumas ferramentas que projetos de automação possuem ou podem possuir, irão ajudar a refinar requisitos.

Legal, já sabemos o que são requisitos de usuário, agora como eu vou aplicar para o meu software? Como vou transformar esse meu requisito de usuário em parte funcional do software.

Primeiro passo, o ideal é separar os requisitos.

Como assim???

Dentro da frase do usuário podemos encontrar mais de um requisito!

- Quando eu apertar o botão de start, a luz para o operador muda de verde para vermelho, os grampos fecham e a mesa vira.


Podemos identificar alguns requisitos:

Repare, que na divisão dos requisitos, ainda não ouve refinamento dos mesmos, uma vez que todos os requisitos são identificados, é possível começar os seus refinamentos, e assim gerar os famosos casos de uso, casos de teste, etc., ou seja, é possível criar uma documentação que efetivamente será usada no desenvolvimento.

E como seria esse refinamento?

Bom algumas documentações do próprio projeto podem ajudar, por exemplo, para o Requisito 001 – Luz de Orientação do Operador.

Quantas luzes de orientação para o operador teremos?

O projeto elétrico pode responder essa pergunta, seguido de uma documentação de operação e segurança padrão da empresa (se existir), documentação de padrão de software da empresa (se existir), ou normas como a NR12, que falam da sinalização.

Qual o tipo de sinalização? Torre sinalizadora ou Dome Light LED que altera sua cor?

O projeto elétrico vai responder essa pergunta. (se ficou na dúvida o que é um dome light – manda um Google e vai ver várias imagens 😉)

A lâmpada só muda de estado ou terá que aguardar alguma outra ação?

O diagrama de processo ou o ciclograma de processo pode responder essa pergunta, e podem ser complementadas com a documentação de operação, ou documentação de padrão de programação da empresa (ambas se existir).

Adicionalmente, pode-se fazer reuniões de brainstorm, conversar com as pessoas que escreveram o requisito de usuário, para esclarecer dúvidas a respeito dos requisitos. (usando as técnicas que foram comentadas no artigo anterior dessa série


Acima é um pequeno exemplo de como um refinamento rápido poderia ser feito antes da formalização do mesmo.

Uma vez que os requisitos podem ser separados como funcionais e não-funcionais, que veremos mais a frente é possível criar o documento formal, onde por exemplo os requisitos funcionais podem organizados da seguinte forma:


[RF 01] – Nome do Requisito

Modulo: {Módulo a qual pertence}

Data:08/04/2019

Alteração:08/04/2019 Autor: {Alteração}

Autor: {Criador da Primeira Versão}

Prioridade: {Prioridade que auxilia na ordem das tarefas}

Descrição: {Descrição detalhada do Requisito}

Outra forma de descrever um requisito de usuário, é através de histórias de usuário, forma muito utilizada quando estamos usando métodos ágeis, mas podem ser usadas em qualquer metodologia.


A seguir um modelo de ficha para história de usuário:


Algumas documentações podem auxiliar a identificar e elucidar requisitos:

  • Simulações;

  • Exemplo de telas de projetos anteriores;

  • Prototipação;

  • Vídeos e fotos de projetos anteriores;

  • Documentação de lições aprendidas;

  • Documentação de padrões de programação do próprio cliente e/ou da empresa desenvolvedora da solução;

Vejam tudo o que falei aqui é uma introdução rápida, com o básico, levantamento e análise de requisitos é algo complexo e profundo, que vale muito o estudo.

Lembre-se, quem vai operar é o operador e não você!

Um grande erro ao escrever os requisitos é não se colocar no lugar do operador que vai estar lidando com a máquina, e pior ainda não verificar com a operação do cliente as dificuldades encontradas atualmente. Apesar de muitas vezes isso não ser possível, é o ideal, é algo que a gestão do projeto deveria ter em mente.

O que para você é simples e intuitivo, as vezes não é para o operador, e o mesmo eu posso dizer sobre o código, quem irá dar manutenção provavelmente não será você!!! Será outra pessoa!, lembre-se das responsabilidades do operador:

Desenvolver um software COERENTE, onde é possível a manutenção por outras pessoas e não somente você.

Isso significa utilizar boas práticas de programação e software limpo, criar a documentação coerente do software.

Lembrar que quem irá operar é o operador e não você, significa consultar a operação no momento de desenvolver o software, levar em consideração os problemas encontrados atualmente e criar um manual de operação coerente e de fácil compreensão.


Até o próximo Artigo!



Bibliografia:





Análise e gestão de requisitos de software: Onde nascem os sistemas - Felipe Nery Rodrigues Machado(Autor) - ISBN:978-8536516066 - Editora Érica


IEEE - 610.12-1990 - IEEE Standard Glossary of Software Engineering




 
 
 

Comentarios

Obtuvo 0 de 5 estrellas.
Aún no hay calificaciones

Agrega una calificación

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