Muito se discute sobre projeto de software, mas ainda temos muitos problemas, principalmente quando tratamos sobre os requisitos. O Relatório do Standish Group denominado Chaos, indica que 42% dos projetos foram entregues fora do prazo previsto, ainda indica que 21% dos projetos foram um fracasso total, e somente 37% dos projetos foram bem sucedidos. Segundo o relatório, parte das falhas é devida a problemas de requisitos, desta forma, é de suma importância para a equipe saber levantar e gerenciar requisitos.
Temos de tomar cuidado para não entendermos algo que não é a realidade do que o cliente necessita.
Figura 1: Imagem clássica sobre diferentes visões de um requisito
A NBR/ISO possui normas que tratam sobre o ciclo de vida e o processo de engenharia de requisitos, entre as normas temos: NBR/ISO/IEC 25001 – Requisitos e avaliação da qualidade de produto de software, NBR/ISO/IEC 25020 – Requisitos e avaliação da qualidade do produto de software e NBR/ISO/IEC 12207 – Processos de ciclo de vida de software. Mas além das normas, outras organizações também trabalham no processo de engenharia de requisitos, mas uma que será destacada aqui neste artigo é a IREB ou International Requerements Engineering Board. Fundada por especialistas independentes com extensa experiência na Engenharia de Requisitos de Software, a IREB criou então uma certificação, a Certified Professional for Requirements Engineering (CPRE), esta certificação se baseia em um currículo, possuindo metas e parâmetros padronizados de qualidade para a engenharia de requisitos. A IREB então dividiu a certificação em níveis, o Foundation é o nível de entrada, depois é possível fazer o Advanced Level em Modelagem ou em Elicitação.
Mas como isso ajuda no requisito de software?
Bem, o IREB disponibiliza um manual para a certificação, e este manual é gratuito e pode ser utilizado não só para a certificação, mas também para o aperfeiçoamento do profissional de engenharia de requisitos. O manual possui uma divisão de conhecimento e de domínio e utilização, facilitando o estudo do profissional.
Desta forma, o objetivo é melhorar o nível da engenharia de requisitos, reduzindo o numero de problemas dos projetos, devido a problemas de requisitos, lembrando a premissa de Pressman de que quanto antes achar o erro, menor é o custo do erro, ou seja, se encontrarmos o erro na fase de levantamento de requisitos, o custo é menor do que encontrar o erro na fase de entrega do produto. A engenharia de requisitos é composta por cinco fases, sendo a elicitação, análise e negociação de requisitos, documentação, verificação e validação.
Figura 2: Fases da engenharia de requisitos
A engenharia de requisitos depende de processos, entre os processos temos:
Elicitação de requisito: é o processo de descoberta do requisito. Como muitas vezes o usuário não tem ao certo o que quer do produto, é a etapa mais complicada, que pode utilizar técnicas como entrevistas, brainstorming, entre outros para atingir o objetivo, ou seja, descobrir os requisitos que o sistema deve possuir. Esta descoberta pode passar por problemas, logo, é indicado que após a elicitação, seja feita a modelagem dos requisitos e apresentada para validação junto ao cliente, mas se estiver utilizando um processo ágil, há uma grande vantagem, pois é feito apenas o requisito dos produtos que serão desenvolvidos no incremento, sendo mais rápido para efetuar o levantamento e também para validar, já que o usuário pode validar diretamente o produto pronto.
Outra vantagem na utilização de metodologias ágeis, é que o foco aqui é comunicação, o que normalmente gera problemas em outras metodologias, pois o contato com o cliente é constante.
Além de requisitos funcionais, que devem indicar funcionalidades do produto, temos os requisitos não funcionais, que indicam fatores como desempenho, confiabilidade, usabilidade, manutenbilidade, entre outros. Estes fatores são de grande importância para o projeto, pois de que adianta ter um produto web maravilhoso, mas que ao abrir leva mais de 10 minutos para exibir a tela? Então não podemos deixar de atender os requisitos não funcionais do projeto.
Outro ponto importante de qualquer projeto, e isto se aplica aos requisitos, é o limite do requisito/aplicação, para evitar que o cliente queira mais do que realmente será desenvolvido. Se o cliente solicita um requisito que não é possível desenvolver, temos a fase de negociação de requisitos.
Para a elicitação de requisitos é importante identificar as fontes de informação do requisito. Normalmente as fontes são o stakeholders (que é o público estratégico, ou a parte interessada no requisito), os documentos, formulários disponíveis sobre a tarefa e também sistemas legados. A Engenharia de Requisitos deve “coletar e compilar as metas e requisitos das diversas fontes de requisitos”.
Mas não adianta apenas um bom levantamento de requisitos, é necessário ainda acompanhar, validar e gerenciar os requisitos. Em processos ágeis os requisitos também são ágeis, sendo validados rapidamente e gerenciados em tempo de desenvolvimento, mas dependendo do processo, é importante gerenciar os requisitos para saber o que foi mudado e quando, pois toda mudança impacta em tempo, recursos e custo.
Na metodologia OpenUP por exemplo, a especificação do software (etapa de engenharia de requisitos) define a funcionalidade do software e as restrições sobre sua operação.
Vale ressaltar aqui que a engenharia de requisitos é um processo documental e de comunicação, desta forma é necessário, através de sistemas ou documentos impressos, possuir os requisitos com aprovação e acompanhamento constante sobre as mudanças e a comunicação para apresentar mudanças nos requisitos para todos os envolvidos: desenvolvedores, clientes etc.
O ponto principal aqui é que os documentos de requisitos impressos ou em sistemas devem possibilitar então um acompanhamento, uma rastreabilidade para mostrar históricos de alteração e de sugestões, lembrando que ao remover ou incluir requisitos em um sistema durante o desenvolvimento, devemos analisar o risco do impacto desta ação ao sistema como um todo.
O IREB indica modelos para os documentos de requisitos, para que os engenheiros possam utilizar, mas há premissas que não fazem parte do modelo e sim das necessidades do documento de requisitos, entre as premissas, temos:
- O requisito deve ser acordado entre as partes envolvidas;
- Deve possuir priorização, ou seja, devemos ao levantar os requisitos, analisar a prioridade para o desenvolvimento, quanto maior a prioridade, mais rápido deve ser desenvolvido. Esta prioridade pode ser realizada com uma análise do impacto do requisito no negócio;
- Não ambíguo;
- Validado e atualizado: indicando que depois de feito o documento de requisitos, os envolvidos devem validar o documento, e este documento, caso sofra alteração no requisito, deve ser atualizado;
- Correto;
- Consistente: não deve ferir a consistência de outros requisitos, nem dele próprio;
- Verificável: indica que outro engenheiro pode verificar o requisito;
- Realizável: indica que é algo que possa ser feito;
- Rastreável: indica que se pode rastrear quem fez, os envolvidos e as modificações;
- Completo: o requisito só pode ser desenvolvido quando estiver completo, caso contrário, impossibilita seu desenvolvimento;
- Compreensível: a redação e as indicações devem possibilitar ao desenvolvedor o entendimento, para isso, deve ser o mais compreensível possível. A expressão “aqui eu quis dizer” não serve, se quer dizer, o engenheiro deve escrever e não apenas “pensar em dizer”.
Outras indicações são de que os parágrafos devem ser curtos e que cada item deve ter apenas um requisito e não um conjunto de requisitos, facilitando a validação e manutenção.
Se você atua em projetos, análise ou quer se especializar, é uma boa ler os livros de Pressman e de Sommerville sobre engenharia de software. Além disso, segue o link do manual do IREB em português, que está disponível em: http://www.abramti.org.br/sites/default/files/arquivos/IREB_CPRE-FL_Syllabus_pt_v2.1.pdf.
Para ler mais sobre OpenUP, vide: http://epf.eclipse.org/wikis/openuppt/index.htm.
