Engenharia de Requisitos: “uma mão na roda!” | Dênis Leite

automação para competitividade

Engenharia de Requisitos: “uma mão na roda!”

Se você não conhecia o termo, eu também não sabia que existia uma “ciência” pra isso, mas há um ano venho estudando o assunto para o desenvolvimento de sistemas aeroespaciais aqui no ITA e INPE.
Vamos começar nosso bate-papo com um exemplo um tanto exagerado, mas muito interessante:

Digamos que um cliente te solicite a projetar um sistema que automatize a casa dele. Uma das coisas que essa pessoa te pede é a seguinte: “Eu quero um sistema que abra a porta sempre que eu chegar em casa”. Você então desenvolve um sistema que abre as portas da cozinha, do banheiro e do quarto sempre que uma pessoa chega, porém não abre a porta principal da casa. Na hora de testar o cliente percebe isso e diz a velha frase “Mas não era isso que eu queria!”. E você então retruca: ”Mas você não especificou qual porta abrir. Por uma questão de segurança, eu não fiz o mesmo com a porta principal para evitar que um ladrão invada sua casa.”

Hoje concentrado na área de Engenharia de Sistemas (sejam esses sistemas Mecatrônicos, Aeronáuticos, Aeroespaciais, de Software, entre outros), a Engenharia de Requisitos se preocupa com os objetivos, funções e restrições da vida real para sistemas.  Ela também se preocupa com a relação desses fatores para precisar as especificações do comportamento do sistema, e suas evoluções ao longo do tempo. A minha interpretação é que ela está preocupada em fazer com que os requisitos sejam bem documentados para evitar situações de mau entendimento.

Para que os requisitos sejam escritos de maneira satisfatória, é necessário que sempre se esteja praticando sua escrita. Um bom conjunto de requisitos deve ter, em minha opinião, as seguintes características mínimas:

  1. Correto: Um requisito está correto se, e somente se, for uma ação que o software deva cumprir;
  2. Não-ambíguo: Um requisito é não-ambíguo se, e somente se, ele tem apenas uma interpretação;
  3. Completo:  Todas  as  funcionalidades  e  comportamento  do  sistema  devem  estar  descritas  nas especificações;
  4. Consistente: O requisito não pode estar em conflito com outro requisito;
  5. Verificável:  Para  evitar  diferenças  relacionadas  à  concretização  do  requisito  especificado,  ele  deve  ser escrito de uma maneira que seja possível verificar se ele foi concretizado ou não.
  6. Modificável: Um sistema de  requisitos é modificável se, e somente se, sua estrutura e estilo são  tais que quaisquer mudanças nos requisitos sejam feitas facilmente, completamente e, consistentemente, enquanto retém sua estrutura e estilo.
  7. Rastreável: Um  sistema de  requisitos é  rastreável  se  a origem de  cada um dos  seus  requisitos é  clara e facilita a referência a cada requisito num desenvolvimento futuro ou na melhora de sua documentação.

Abaixo eu dou algumas dicas que auxiliarão no desenvolvimento do sistema, esteja ele no início, no meio ou no fim.

  1. Junte-se ao cliente para fazer a lista de Requisitos (ou especificação) do que está sendo pedido por ele, devendo ser escrita em um documento que explicite o funcionamento do sistema sendo assinados por ambos os lados: Cliente e Fornecedor. Isso servirá como um guia do que será desenvolvido e dos objetivos a serem alcançados para a aplicação (ou software ou sistema) em desenvolvimento. Servirá também como uma documentação para o projeto e, possivelmente, evitará possíveis constrangimentos para qualquer um dos lados.
  2. Ao se escrever um requisito, este deve ser uma sentença única.
  3. Evite usar conjunções como E e OU. Isso faz o requisito ser objetivo e evita ambigüidade na interpretação.
  4. Sempre revise as especificações, certificando-se se os requisitos estão sendo entendidos da maneira correta.
  5. Entre sempre em contato com o cliente, para o qual está sendo desenvolvido o sistema, para possíveis esclarecimentos de dúvidas dos requisitos.
  6. Faça reuniões constantes para mostrar o andamento do desenvolvimento da aplicação e, caso seja necessário, fazer as correções de possíveis erros junto ao cliente. Isso com certeza deixará o cliente satisfeito, pois ele terá total noção de como está o seu projeto.
  7. No caso de ter de corrigir o documento original dos requisitos, se certifique de que a nova versão seja também assinada por ambos os lados.

Bom, é isso aí. A prática faz a perfeição. Da mesma forma que antes parecia intuitivo desenvolver um projeto sem escrever requisitos, a partir do momento que você começar a escrevê-los, vai fazer isso intuitivamente também!

Para os que desejam mais informações,  aqui vão algumas referências:

1)  http://www.ifi.uzh.ch/rerg/teaching/past_semesters – Este é um siteum professor da Universidade de Zürich onde são disponibilizadas várias apresentações sobre Engenharia de Requisitos.

2) Norma ECSS-E-10Part1B(18November2004) – Norma Européia para a área aeroespacial

Disponível em : <http://www.itasat.redecasd.ita.br/images/6/6f/ECSS-E-10Part1B(18November2004)_Requirements_and_process.pdf>

3) IEEE-Std-830-1998.pdf e IEEE-Std-1233-1998.pdf – Normas da IEEE.

Para essa última referência, é só por os nomes dos documentos no Google que eles serão disponibilizados.

Quaisquer dúvidas, não hesitem em entrar em contato, via e-mail ou comentários, que eu tentarei esclarecê-las.

E-mail:    rpastl@gmail.com

Gostou do conteúdo? Assine nossa newsletter!

Como sabemos que ninguem tem tempo a perder, condensamos o material e enviamos os headlines uma ou duas vezes ao mês.


3 Comments

  • Realmente é uma mão na roda, nós que chegamos a trabalhar com dois, três ou mais projetos em pouco tempo realmente sofremos com esse tipo de coisa, sempre fica uma coisinha para trás, por mais experiente que o “caboco” seja, já estou criando um procedimento aqui na firma pra implantar no setor de projetos. 🙂

    Parabéns mais uma vez…

    André

  • Obrigado André e parabéns pela iniciativa de criar o procedimento. Isso vai facilitar muito a sua vida nos projetos, te garanto.

    É verdade isso que você falou. Por mais que o “caboco” seja experiente, sempre há algo que se esquece na hora da implementação do sistema.
    Além disso, existe uma documentação precisa E concisa que prova o correto funcionamento do sistema de acordo com o pedido do cliente (ou do chefe), o que evita uma posterior “dor de cabeça”.

    Abs.

    Rodrigo Pastl

  • Ótima postagem para auxiliar na especificação correta de um projeto, para que “pelo menos” diminua a quantidade de desvios que encontramos até a entrega definitiva.

    Parabéns.

Post a Comment

Your email address will not be published. Required fields are marked *

Spam Protection by WP-SpamFree

  • Categorias