Dando prosseguimento ao artigo anterior, - em que mostrei dados estatísticos, reconhecidos mundialmente, para ilustrar o panorama atual da indústria de desenvolvimento de software, que vem passando por uma fase de transição em que procura pontos frágeis dos atuais processos estabelecidos, bem como estabelece modelos de maturidade da capacitação do desenvolvimento software como forma de orientar os esforços realizados pelas organizações nos seus processos produtivos de desenvolvimento -, cabe lembrar que essa orientação é mais aplicável quanto mais organizados estão os nossos processos básicos como: planejamento, documentação, teste,...

Lembrando que, segundo pesquisa do Standish Group, as razões principais que levam a problemas de projeto são identificadas na tabela abaixo [4]:

Juntando com os dados de projetos da Força Aérea Americana sobre o levantamento da fonte de erro por fase do ciclo de vida do software, relatados no gráfico abaixo:

Avaliando os dados da tabela das razões principais de problemas de projeto com o gráfico de fonte de erro por fase do ciclo de vida, sob o foco do quadro abaixo de custo relativo de reparo por fase do ciclo de vida, originado por estudos independentes das empresas GTE, TRW e IBM em meados da década de 1970 [1];

Podemos concluir que identificar um erro na fase de manutenção tem um custo relativo 200 vezes maior em relação à descoberta do mesmo erro na fase de análise de requisitos, a etapa inicial do ciclo de vida. Devemos, então, orientar nossos esforços na definição e melhoramento contínuo de processos formais a serem executados durante esta fase, como forma de aumentarmos a qualidade do software desenvolvido, bem como, minimizar o custo deste desenvolvimento.

No final da década de 80, com a incumbência de definir processos formais para orientar o estudo da descoberta do problema e do levantamento dos requisitos do software a ser construído, surgiu a engenharia de requisitos.

Muitos autores descrevem diferentes atividades para o cumprimento da fase inicial do ciclo de vida, conhecida como análise de requisitos. Segundo Kotonya [2], as atividades a serem desenvolvidas são as seguintes:

• Extração de requisitos – etapa onde os requisitos são descobertos através de consultas aos envolvidos, documentos, domínio do conhecimento e estudos de mercado;
• Análise e negociação – os requisitos são analisados em detalhe e recusados ou aceitos;
• Documentação – onde os requisitos aceitos são documentados em um nível apropriado de detalhe;
• Validação – os requisitos são checados cuidadosamente para verificação de consistência e completeza.
• Gerenciamento – onde os requisitos são controlados em função da dinâmica das mudanças ambientais.

Como o mundo dos negócios está a cada dia mais ágil, mudanças nos requisitos são uma constante. Isto significa que o processo de tratamento de requisitos é iterativo durante todo o ciclo de vida do software.

Após a etapa de validação dos requisitos, temos como resultado o documento formal dos requisitos, que passa a ser o acordo entre os envolvidos no projeto e deve refletir as necessidades que o software deve atender. Este documento norteará todos os esforços das fases seguintes do ciclo de vida. É por este motivo que requisitos bem definidos antes do início do projeto lógico podem evitar retrabalho, minimizando custo e esforço de implementação.

A dificuldade de comunicação é o fator crucial dos problemas com requisitos. Uma citação que reflete este problema pode ser encontrada no livro de Engenharia de Software de Roger Pressman [3], a seguir:

No próximo volume, parece-me interessante mostrar o esforço que a CELEPAR vem aplicando em pesquisa nesta área de requisitos e o que já está saindo da teoria para integrar nossos processos da fase de análise de requisitos, etapa inicial do ciclo de vida de desenvolvimento de software.

Até lá !!!

[1] DAVIS, Alan M. Software requirements – objects, functions and states. Englewood Cliffs : Prentice Hall, 1993.

[2] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements engineering – processes and techniques. Chichester : J. Wiley, 1998.

[3] PRESSMAN, Roger S. Software engineering: a pratictioner’s approach. 3. ed. New York : McGraw-Hill, 1995.

[4] STANDISH GROUP. Chaos: pesquisa sobre o desenvolvimento de software e o panorama caótico da indústria de software dos dias de hoje. Disponível na Internet. www.standishgroup.com/chaos.html