Requisitos de software

Entendendo o que precisa ser desenvolvido porque os projetos de software ainda estão falhando. Infelizmente!

A figura “clássica” abaixo ilustra perfeitamente a principal motivação por trás deste artigo-entender o que é necessário para ser desenvolvido é um fator essencial para o sucesso de qualquer projeto de software. Embora eu realmente aprecio o valor incorporado na mensagem desta figura, gostaria que esta imagem seria um tema do passado, e poderíamos referir-se a ele como arte Museu, mas, infelizmente, não é!


O clássico-eu gostaria de poder dar créditos para o criador original desta figura.

Mesmo hoje em dia, existem projetos de software lá fora, em que as necessidades do cliente estão claramente disponíveis, possível expressar-se e projetos são iniciados e (de alguma forma) fechados sem levar este assunto suficientemente grave. Procurando por “estudos de caso de falha de software” não é impossível relacionar grandes falhas de um projeto a falhas que poderiam ter sido resolvidas durante a fase de Elicitação de requisitos.

Este artigo é apenas mais um disponível on-line para destacar a importância das atividades de Elicitação de requisitos. Além disso, as informações disponíveis neste artigo são usadas como referências a outros posts disponíveis neste blog.

De acordo com Boehm, s[1]e[2] um defeito é encontrado no início do processo de desenvolvimento de software que iria custar muito menos do que um defeito encontrado em fases posteriores do ciclo de desenvolvimento. Por exemplo, durante a fase de especificação de requisito, um defeito pode custar $1 para fixar, enquanto que durante as atividades de teste, o mesmo defeito custaria $1000 para fixar.

Diferentes estratégias podem ser empregadas para elicitar e definir a especificação do requisito do projeto, por exemplo: casos de uso, protótipos, histórias de usuários e etc. O fato é que não importa como será feito, as necessidades do projeto devem ser claramente compreendidas o mais cedo possível no ciclo de vida do projeto[3]. O mesmo contexto também se aplica a “projetos ágeis”, onde a especificação completa dos requisitos dos projetos não pode ser definida em estágios iniciais, mas, no entanto, a necessidade de compreender as necessidades do projeto permanece[3] (ver “verdade 8“).

A definição de requisitos “bons” para o projeto ajuda a captar as necessidades reais de clientes e negócios, a compreender a complexidade do projeto e seus desafios técnicos, e a identificar ou até mesmo eliminar defeitos em estágios muito precoces do projeto.

Referências:

  • [1] M., Barry W. E Philip N. Papaccio. ‘ Entendendo e controlando os custos de software, ‘ transações IEEE em engenharia de software, v. 14, no. 10, 1988 de outubro, pp. 1462-1477
  • [2] Beohm, Barry e Victor R. Basili. ‘ Redução de defeitos de software lista Top 10, ‘ computador, v. 34, no. 1, Janeiro 2001, PP 135-137.
  • [3] Robertson & Robertson, “dominar o processo de requisitos”-2006

Armando Perico

Share

Leave a Reply

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

Post comment