Aqui mostro um pouco da teoria da
Engenharia de Requisitos para que o leitor possa compreender a importância desta fase em um projeto.
A importância da Engenharia de Requisitos
O processo de Engenharia de Requisitos tem como principal objetivo a aquisição de conhecimentos das regras de negócios e verificação das necessidades do cliente, de forma a obter uma especificação não ambígua e completa dos requisitos de software, com o intuito de minimizar os erros, inadequações e falhas no produto final a ser entregue ao cliente. Uma análise e especificação de requisitos com baixa qualidade podem levar a danos e prejuízos, que inviabilizam o projeto e que podem até mesmo colocar em risco vidas humanas, como por exemplo, em sistemas hospitalares, de tráfego aéreo, de controle de trânsito etc.
O
Gerenciamento de Requisitos é o processo de compreender e controlar as mudanças que ocorrem nos requisitos, por força da evolução dos mesmos, refletindo as alterações que ocorrem ao longo do tempo, no ambiente do sistema e nos objetivos da organização. Além da Análise e Especificação, o Gerenciamento de Requisitos é de fundamental importância no processo da Engenharia de Requisitos, pois organiza o controle das mudanças, permitindo subsídios para a análise de impacto e custos em tempo e dinheiro, que estas mudanças trarão para a organização.
Definição de requisito
Um requisito pode ser definido como uma restrição ou uma funcionalidade que um sistema deve prover.
Classificação de um requisito
Um requisito pode ser classificado em:
- Requisito funcional: quando o requisito declara explicitamente O QUÊ o sistema deve fazer, que funções (ou mesmo restrições) o sistema deve ter. São exemplos (Sistema de gestão de colaboradores): o sistema deve ser capaz de, através das notas armazenadas, gerar o resultado da avaliação; O sistema deve receber notas de 1 à 10, sendo o intervalo entre as notas de 0,5;
- Requisito não-funcional: Definem qualidades globais de um software como desempenho, segurança, confiabilidade etc. Por exemplo: O usuário deve ser capaz de acessar a página de cadastro de colaboradores em no máximo 3 cliques;
- O usuário deverá acessar o sistema através de um login e senha próprios;
- Requisito de Designer: Requisito que identifica restrições tecnológicas. Por exemplo: o sistema deve ser construído utilizando o SGBD MySQL. O sistema deve ser construído utilizando a linguagem PHP.
Processos de Engenharia de Requisitos
Não existe um único processo de engenharia de requisitos que atenda perfeitamente à todas as organizações. Entretanto a figura abaixo dá uma visão ampla dos principais processos existentes.
Fases da Engenharia de Requisitos
Basicamente a engenharia de requisitos pode ser dividida em:
- Elicitação dos requisitos: nesta fase é determinado o que o sistema deve fazer, definido o escopo do sistema. É o "descobrimento" do requisito. Envolve 4 aspectos: domínio da aplicação, problema a ser solucionado, contexto de negócios e necessidades e restrições dos stakeholders;
- Análise dos requisitos: nesta fase os requisitos são "traduzidos" para os da engenharia de requisitos. Eles são entendidos e começam a ser transformados em especificações técnicas. É aqui que realmente começam a surgir as dúvidas ;)
- Especificação dos requisitos: nesta fase os requisitos são detalhados ainda mais e as eventuais dúvidas são sanadas (ou deveriam ser ao menos... ^^'');
- Validação dos requisitos: nesta fase os requisitos são finalmente aprovados pelos clientes e eventuais "recusas" fazem com que o requisito retorne ao estágio de elicitação/análise do requisitos.
Gerenciamento de requisitos
Os requisitos são mutáveis durante todo o projeto. Portanto é necessário gerenciá-lo para que os desenvolvedores realmente entreguem um sistema que foi pedido pelo cliente.
Gerenciamento de Mudanças:
O gerenciamento de mudanças, segundo Kotonya e Sommerville, está relacionado à política de uso de procedimentos, processos e padrões que serão utilizados para gerenciar as mudanças nos requisitos do sistema.
Rastreabilidade:
Rastreabilidade de requisitos é a habilidade de descrever e acompanhar a vida de um requisito em ambas as direções do processo de software (do planejamento do negócio à especificação do projeto), idealmente durante todo o seu ciclo de vida.