Quando alguém pede um sistema, quase sempre já chega com uma ideia pronta.
Uma tela, um botão, um fluxo que “resolveria tudo”.
Nos últimos tempos, essa ideia tem vindo com outro nome: IA.
Não é raro ouvir que o sistema precisa “ter IA”, mesmo quando ninguém consegue explicar exatamente o que ela vai fazer ali. A tecnologia aparece antes da necessidade, como se o simples fato de estar presente já fosse uma solução.
Segundo o IREB¹, antes de definir requisitos é preciso entender o contexto e os objetivos.
Isso vale para qualquer tecnologia, inclusive para a mais recente.
Em muitas conversas, a IA entra como resposta para um problema que ainda não foi formulado.
Querem automação, mas não sabem onde o processo falha.
Querem inteligência, mas não conseguem dizer quais decisões hoje são difíceis.
Querem algo moderno, mas não apontam o que está travando o trabalho.
Às vezes a justificativa é externa.
O concorrente usa.
O mercado comenta.
Pode chamar atenção de novos clientes.
Nada disso, por si só, descreve um problema.
Quando o problema não está claro, a IA vira promessa.
Ela tenta organizar o que ainda não foi entendido, acelerar o que ainda não foi mapeado, decidir o que ainda não foi definido.
A análise de requisitos começa quando a conversa muda de ritmo.
Quando a pergunta deixa de ser “onde a IA entra” e passa a ser “o que acontece hoje”.
É nesse ponto que aparecem os detalhes simples:
tarefas repetitivas, decisões manuais, dados espalhados, pessoas que conferem a mesma informação várias vezes.
Esses são problemas.
A IA pode ser uma forma de tratá-los — ou não.
Porque a IA não é o objetivo.
Ela é uma ferramenta.
Uma entre várias possíveis.
Quando o problema está organizado, fica mais fácil perceber se a IA faz sentido naquele contexto, ou se outra solução resolve melhor, com menos custo e menos complexidade.
O sistema vem depois.
A tecnologia vem depois.
O entendimento sempre vem antes.