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.
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.
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:
