A primeira vez que alguém me pediu um sistema, não pediu um sistema.
Pediu algo que resolvesse um incômodo que ele já estava carregando há um tempo.
Ele falava da tela, das funções, do que “precisava ter”.
Mas, conforme a conversa avançava, ficava claro que o problema não estava ali. Estava no processo, no jeito como as coisas aconteciam antes mesmo de qualquer tecnologia entrar.
Análise de requisitos começa nesse ponto.
Não é sobre escrever documentos, nem sobre desenhar telas.
É sobre entender o que realmente precisa ser resolvido.
Segundo o IREB¹, análise de requisitos é o conjunto de atividades usadas para identificar, documentar, validar e gerenciar requisitos de um sistema.
Na prática, isso significa transformar uma necessidade — muitas vezes confusa — em algo claro o suficiente para ser construído.
Antes de existir um requisito, existe uma situação:
alguém perde tempo, comete erros, repete trabalho, não confia nos dados, ou simplesmente se sente travado.
O trabalho da análise é observar isso com calma, fazer perguntas, ouvir respostas incompletas, conectar informações e registrar o que foi entendido de forma que outras pessoas também consigam entender.
Um requisito não nasce pronto.
Ele vai sendo lapidado conforme o entendimento aumenta.
Por isso, a análise de requisitos não acontece uma única vez.
Ela acompanha o sistema desde a ideia inicial até as mudanças que surgem com o uso real.
No fim, analisar requisitos é garantir que o sistema certo está sendo construído, para o problema certo, pelas razões certas — mesmo que isso só fique totalmente claro depois de algumas conversas.
Fonte: