O levantamento de requisitos é uma fase crítica de um projeto de software
O levantamento de requisitos é uma fase crítica de um projeto de software

A correta execução da análise de requisitos, depende integralmente da assertividade no entendimento dos problemas de negócio do cliente e dos resultados esperados de do sistema para atender às necessidades.

É consenso entre todos os profissionais engenharia de software que a de análise de requisitos é uma atividade que certamente pode comprometer a entrega de um projeto de software.

Entenda melhor como a análise de requisitos e o gerenciamento de requisitos pode ajudar equipes de desenvolvimento a garantir o sucesso de um sistema.

Pequena história sobre análise de requisitos

Você é um redator de uma pequena equipe de publicidade? Ou então é um arquiteto e urbanista? Talvez um artesão ou artista plástico? Não importa, se você tem um cliente (seja sua mãe ou uma multinacional) você uma hora ou outra vai ter que tratar com os conflitos de expectativa.

Quando se trabalha com engenharia de software, principalmente nas disciplinas que norteiam o desenvolvimento, evolução e manutenção de um produto, uma das barreiras mais difíceis de serem superadas é justamente essa, a divergência entre as expectativas que cada um dos atores de todo o ciclo.

O usuário nem sempre sabe o que precisa

O usuário final espera que você lhe entregue um carro potente, bonito e confortável. O patrocinador deixa claro que este automóvel não deve ultrapassar o budget combinado. Já o marketing da empresa quer que além de potente, bonito, confortável e barato.

O carro tem que ter um apelo familiar para que seja possível abocanhar o mercado. Acredito, isso não é nem a metade dos problemas com as expectativas.

Forest Gump - O contador de histórias
Para uma boa análise de requisitos, o analista deve ser um ótimo contador de histórias, assim como Forest Gump. Entendimento do Escopo e dos Requisitos de Software é um processo fundamental da Engenharia de Software, e pode definir o sucesso ou fracasso de um projeto.

As exigências, requisitos, restrições e premissas dadas pela primeira ponta do tripé são já esperadas e de certa forma sempre aceitáveis, mas nem sempre justificáveis (essas informações são os insúmos principais da primeira parte de qualquer projeto de projeto, e são documentadas no termo de abertura de projeto, ou simplesmente TAP)

As coisas começam a ficar tormentosas quando o analista apresenta ao PM o primeiro artefato contendo o design de negócio proposto, surgem então os primeiros desvios.

O analista quase louco, completamente entupido de café negocia feature a feature com o usuário, patrocinador, marketing e a dona Jandira, a senhora que faz o café na empresa.

Dias de suor frio, ansiedade e insônia. Protótipos de interface elaborados são criados sob medida aos requisitos coletados. Diagramas de caso de uso alterados, deletados ou perdido no meio do desktop são incontáveis.

Aleluia: o PM aprovou o esboço, agora é só correr e especificar, depois disso o arquiteto faz o design da aplicação, o carinha do banco faz o modelo do schema, e os coders fazem a mágica final acontecer. Pára, pára, pára tudo!

O arquiteto não gostou da solução e inviabilizou tecnicamente um a cada três dos requisitos. Começa tudo de novo!

Novamente o ciclo de reuniões, visitas, discussões, especificações e choro livre toma conta da vida do analista. O projeto deveria ser concluído em seis meses, nove se passaram e criança nenhuma ainda veio ao mundo!

Depois de uma maratona de tentativas o nosso querido amigo arquiteto aprova com louvor o que foi proposto.

A arquitetura é feita, o banco de dados desenhado, os desenvolvedores fazem milagre pra codificar oitenta linhas por minuto. Finalmente o projeto está pronto.

Ninguém alinha as expectativas da entrega.

Chega o dia da entrega, o tão esperado momento de glória que toda a equipe espera, é o momento onde o famoso churrasco prometido pelo PM vai ser finalmente consagrado!

O cliente abre a porta, olha um pouco em torno a si, olha para os presentes e diz:

“ – Espetacular! Olhe as curvas, os detalhes, e essa cor então é a cereja do bolo.”. Nesse momento ninguém mais consegue segurar o sorriso que tenta escapar pelo canto da boca. Estão todos orgulhosos do trabalho feito e das madrugadas não dormidas, então o cliente conclui:

“ – Mas, é uma bicicleta!”.

Entendeu a moral da história, não? Então você não serve para ser um bom analista de requisitos.

Dilbert explica os requisitos de software

Dilbert é um personagem de tiras diárias criado por Scott Adams, publicado pela primeira vez em 16 de abril de 1989. Teve também um desenho animado que durou duas temporadas, que no Brasil era exibido pela extinta Fox Kids.

A tirinha de Dilbert se encaixa perfeitamente para definir a importância da análise de requisitos.
Tirinha de Dilbert. A definição e o entendimento do escopo de negócio e dos requisitos de software nem sempre são entendidos ou respeitados.

Conheça e aprenda mais sobre o processo de gerenciamento de projetos e análise de requisitos de software. Recomendamos a leitura dos seguintes artigos:

Paranaense com alma paulistana e coração italiano. Bacharel em Engenharia de da Computação (Laurea magistrale in Ingegneria e Scienze Informatiche) pela Università degli Studi di Verona, Técnologo em Sistemas para Internet. Iniciou também uma licenciatura em História Italiana e Letras Clássicas pela Università di Bologna, aventura que infelizmente não foi concluída. Atualmente é acadêmico do curso de Engenharia Civil na Faculdade Mater Dei. Trabalha com desenvolvimento de software desde 2010, especializou-sem em Engenharia de Requisitos, Análise de Negócios e Gerenciamento de Projetos. Ao longo de sua carreira autou em projetos para a administração pública, sistemas de ERP, processamento distruibuído e inteligência artificial.

2 COMENTÁRIOS