Como usar IA na descoberta de requisitos

Entrevistas, tickets, atas e conversas dispersas raramente chegam como requisitos prontos. A inteligência artificial ajuda quando transforma esse material em hipóteses verificáveis. O ganho está em organizar evidências, revelar lacunas, comparar interpretações e preparar ciclos curtos de validação, não em deixar a IA decidir o que o usuário precisa.

Um requisito só deveria avançar para especificação quando tiver origem clara, usuário afetado, critério de aceite inicial e uma pergunta de confirmação ainda possível de testar.

Quando a IA ajuda na descoberta de requisitos

A descoberta de requisitos costuma começar com material imperfeito. Uma reunião gera anotações soltas. Um canal interno acumula reclamações. O suporte registra tickets com linguagens diferentes para o mesmo problema. Uma área de negócio pede uma funcionalidade, mas não deixa claro qual fricção operacional quer remover.

É nesse ponto que a IA na descoberta de requisitos pode ser útil: não para substituir a conversa com usuários, mas para dar forma ao material bruto. A equipe pode pedir que um modelo agrupe relatos semelhantes, separe pedidos de funcionalidade de dores operacionais, identifique termos ambíguos e sugira perguntas de aprofundamento.

A diferença parece pequena, mas muda o processo. Uma coisa é usar IA para escrever um requisito bonito. Outra é usar IA para deixar evidente o que ainda não foi compreendido.

A segunda opção preserva a validação antes da especificação.

A qualidade dessa análise depende do contexto entregue ao modelo. A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência, incluindo instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada Anthropic. Em descoberta de requisitos, isso significa que a IA só consegue organizar bem aquilo que recebeu: transcrições, notas, tickets, objetivos do produto, restrições conhecidas, glossário do domínio e decisões já tomadas.

Se a entrada mistura fato, opinião e desejo sem separação, a saída tende a parecer mais resolvida do que realmente é. Fluência não é validação.

O recorte aqui é específico: requisitos de software.

Separe evidência, interpretação e decisão

Um erro comum na descoberta assistida por IA é aceitar uma síntese como se ela fosse uma conclusão. Para evitar isso, a equipe precisa classificar cada item levantado em três camadas.

• Evidência: algo observado, dito ou registrado. Pode vir de entrevista, ticket, métrica interna, conversa com suporte, observação de uso ou regra de negócio identificada.
• Interpretação: a leitura que a equipe faz a partir da evidência. Pode estar correta, incompleta ou enviesada.
• Decisão: o compromisso assumido no produto, no sistema ou no processo.

A IA pode ajudar a sugerir essa classificação, mas a equipe precisa revisar a origem. Um exemplo simples: três usuários dizem que “o pedido fica parado”. Isso é evidência, desde que a fonte esteja rastreada. A interpretação pode ser “a fila de triagem não dá visibilidade de prioridade”. A decisão poderia ser “criar ordenação automática por prioridade”.

Perceba o salto. A decisão pode estar errada mesmo quando a evidência é real.

Por isso, a pergunta operacional não é “a IA resumiu bem?”. A pergunta é: “o que neste resumo sabemos, o que estamos inferindo e o que já estamos decidindo?”.

Essa separação também evita que a equipe transforme vocabulário interno em necessidade do usuário. Quando alguém pede “um dashboard”, talvez esteja pedindo visibilidade. Quando pede “automação”, talvez esteja pedindo menos retrabalho. Quando pede “integração”, talvez esteja pedindo eliminação de dupla digitação. A IA pode listar essas alternativas, mas não deve escolher sozinha qual delas corresponde ao problema.

Use IA para encontrar lacunas antes de escrever requisitos

A melhor pergunta para fazer à IA na descoberta de requisitos muitas vezes não é “escreva uma especificação”. É “o que ainda falta saber para escrever uma especificação responsável?”.

A partir de notas e relatos, a equipe pode pedir que o modelo procure lacunas como:

• Quem é o usuário ou papel afetado?
• Em que situação o problema aparece?
• Com que frequência a situação ocorre, se essa informação estiver disponível?
• Quais exceções foram mencionadas?
• Que regra de negócio limita a solução?
• Que decisão depende de uma área responsável pelo processo?
• Que comportamento observável indicaria que a mudança funcionou?
• Que alternativa mais simples deveria ser considerada antes de uma nova funcionalidade?

Esse uso muda a função da IA. Em vez de acelerar a passagem para desenvolvimento, ela desacelera o ponto certo: a conversão prematura de ambiguidade em escopo.

Na prática, uma saída útil pode ser uma lista de perguntas para nova conversa com usuários ou representantes do processo. Por exemplo: “quando você diz que o pedido fica parado, o problema é não saber quem deve agir, não ter informação suficiente para agir ou não receber aviso quando a etapa muda?”.

Essa pergunta preserva a investigação antes de fechar escopo.

Também vale usar a IA para comparar versões de entendimento. A equipe pode fornecer duas sínteses feitas por pessoas diferentes e pedir diferenças, pressupostos conflitantes e pontos que exigem validação. Isso ajuda a explicitar divergências antes que elas apareçam como retrabalho no desenvolvimento.

No recorte de requisitos, a lógica é parecida: IA sem critério produz artefatos antes da validação. IA com critério explicita lacunas, hipóteses e decisões pendentes.

Transforme sínteses em hipóteses testáveis

Uma síntese gerada por IA deve entrar no fluxo como hipótese, não como requisito fechado.

Uma formulação útil de hipótese contém quatro elementos:

• Usuário ou papel afetado.
• Situação em que o problema aparece.
• Mudança esperada no comportamento, no fluxo ou na decisão.
• Forma de verificação.

Em vez de escrever “o sistema deve ter uma fila única de pendências”, a equipe pode formular: “se o analista de operações conseguir revisar pedidos pendentes em uma fila única, talvez reduza idas e voltas na conferência, porque hoje ele alterna entre diferentes telas para entender o que falta em cada pedido”.

Essa frase ainda não é requisito. Ela é um ponto de investigação.

A próxima ação pode ser observar o fluxo real, revisar tickets relacionados, entrevistar analistas que executam a tarefa ou testar um protótipo de baixa fidelidade. Só depois a equipe decide se a fila única é o caminho, se o problema é informação incompleta, se falta definição de responsabilidade ou se há uma regra de negócio mal compreendida.

O DORA recomenda trabalhar com unidades pequenas, independentes e testáveis para obter retorno sobre mudanças e revisar hipóteses mais cedo. A mesma orientação alerta para a dificuldade de revisar e integrar grandes mudanças geradas com IA DORA. Embora essa referência trate de fluxo de desenvolvimento, o princípio ajuda na descoberta: hipóteses menores são mais fáceis de verificar do que pacotes grandes de escopo.

Isso não significa fragmentar tudo artificialmente. Significa não deixar que uma síntese ampla esconda decisões diferentes dentro de uma única história.

Valide com usuários antes de converter em especificação

A IA pode preparar perguntas, roteiros, alternativas de formulação e critérios de aceite iniciais. Mas a confirmação precisa passar por usuários, representantes do processo ou evidências observáveis.

Em descoberta de requisitos, “validar” não significa perguntar “você gostou desta solução?”. Significa testar se a equipe entendeu corretamente o problema, o contexto e as restrições.

Algumas perguntas ajudam:

• “Esta descrição representa uma situação que acontece no seu trabalho?”
• “O que está faltando ou exagerado?”
• “Em quais casos essa regra não vale?”
• “Como você resolve isso hoje?”
• “Que informação faria você tomar a decisão com segurança?”
• “Se esta mudança existisse, o que você esperaria conseguir fazer de modo diferente?”

A revisão humana também importa quando ferramentas mais autônomas entram no fluxo. A documentação do GitHub sobre agentes do Copilot descreve recursos com ambientes e permissões distintos e ressalta supervisão humana e revisão das saídas GitHub. Na descoberta, o mesmo cuidado vale antes do código: a equipe deve revisar a saída da IA antes que ela se transforme em compromisso de produto.

O requisito só deve avançar quando a equipe souber responder duas coisas: o que foi validado e o que continua assumido.

Essa distinção evita uma armadilha frequente. Se tudo vira “validado”, ninguém sabe onde está o risco. Se tudo fica “em aberto”, nada anda. O bom fluxo explicita a diferença.

Exemplo fictício: triagem de chamados internos

Imagine uma equipe responsável por melhorar a triagem de chamados internos de uma empresa. O exemplo é fictício.

A equipe reúne tickets antigos, comentários de usuários e anotações de uma conversa com pessoas da operação. O material aponta atrasos na triagem, retrabalho e dificuldade para saber o que fazer com determinados pedidos.

Ao analisar esse conjunto, a IA agrupa relatos e sugere uma interpretação: “o principal problema é falta de priorização automática dos chamados”. A sugestão parece plausível. Vários comentários mencionam urgência, atraso e fila acumulada.

Se a equipe converter essa síntese diretamente em requisito, pode escrever algo como: “o sistema deve priorizar chamados automaticamente”. É uma frase clara, mas ainda perigosa.

Ao voltar aos usuários, a equipe descobre outra possibilidade: muitos chamados atrasam porque chegam sem uma informação obrigatória. O analista precisa perguntar de volta, esperar resposta e só então classificar o pedido. A prioridade não é o primeiro gargalo. O problema anterior é a qualidade da entrada.

Nesse cenário fictício, a IA não “errou” sozinha. Ela fez uma leitura possível do material recebido. A equipe é que teria errado se tratasse a leitura como verdade confirmada.

A partir da validação, surgem hipóteses menores:

• Se o formulário exigir a informação mínima antes do envio, talvez diminua a quantidade de chamados que voltam para complementação.
• Se o usuário enxergar exemplos de preenchimento por tipo de solicitação, talvez descreva melhor o pedido.
• Se o analista puder marcar rapidamente “informação insuficiente”, talvez a equipe consiga identificar quais campos mais geram dúvida.

Nenhuma dessas hipóteses deve ser apresentada como resultado ocorrido. Elas são propostas a medir. A decisão seguinte é escolher qual delas tem menor risco, maior clareza de validação e melhor relação com a dor observada.

Critérios mínimos para uma saída da IA virar requisito

Este checklist é um critério prático para impedir que uma resposta bem escrita substitua validação real.

Origem rastreável

A afirmação veio de entrevista, ticket, métrica, observação de uso ou regra de negócio identificável?

Se a origem não estiver clara, trate como hipótese, não como requisito.

Usuário ou papel afetado

Está claro quem sofre o problema ou executa a tarefa?

Se o usuário for genérico, volte para a descoberta. “Usuário final” raramente é suficiente para decidir comportamento de software.

Problema antes da solução

A frase descreve uma dor ou já pula para uma funcionalidade?

Se a saída da IA já vier como solução, peça alternativas de formulação do problema e valide com usuários.

Condição de validação

Existe uma pergunta, teste, observação ou conversa que possa confirmar ou negar a hipótese?

Se não houver como validar, não converta em especificação.

Critério de aceite inicial

A equipe consegue dizer qual comportamento observável indicaria que o requisito foi atendido?

Se o aceite depender apenas de interpretação subjetiva, refine antes de desenvolver.

Tamanho revisável

A mudança pode ser dividida em unidade pequena, independente e testável?

Se a mudança for grande demais para revisar cedo, divida a descoberta em hipóteses menores. Esse critério conversa com a recomendação do DORA sobre lotes pequenos, independentes e testáveis DORA.

Bloqueios antes da especificação

A descoberta assistida por IA precisa de um freio explícito. Sem isso, a equipe pode confundir velocidade de redação com avanço de entendimento.

Não avance para especificação quando:

• O requisito não tem usuário, papel ou responsável pelo processo identificado.
• A origem da afirmação não está rastreável.
• A saída da IA mistura evidência, interpretação e decisão sem separação.
• A equipe não consegue formular uma pergunta de validação.
• As exceções do fluxo não foram investigadas.
• O critério de aceite inicial ainda é subjetivo demais.
• A solução proposta tem impacto alto demais para nascer apenas de análise assistida.
• A mudança reúne decisões diferentes em um bloco grande, difícil de revisar.

Esse freio não existe para tornar o processo lento. Existe para proteger a equipe de uma forma nova de precipitação: requisitos bem escritos, mas mal compreendidos.

A questão não é usar IA em todos os pontos possíveis. É escolher onde ela melhora a qualidade da decisão sem apagar responsabilidade humana.

O limite operacional é este: use IA para estruturar evidências e hipóteses de requisitos, mas bloqueie a passagem para especificação quando não houver origem clara, critério de validação e pergunta de confirmação com usuários ou responsáveis pelo processo. Essa é a diferença entre acelerar a escrita do requisito e melhorar a decisão que justifica desenvolvê-lo.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Desenvolvimento amplificado por IA: como organizar o processo
• Como dividir tarefas para agentes de programação
• Como registrar decisões de arquitetura para uso com IA

Fontes

• DORA: lotes pequenos. https://dora.dev/capabilities/working-in-small-batches/
• Anthropic: engenharia de contexto. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• GitHub: uso responsável de agentes do Copilot. https://docs.github.com/en/copilot/responsible-use/agents