Introdução ao problema
A diferença entre "pedir uma funcionalidade" e "resolver um problema de negócio" começa na engenharia de requisitos. Quantas vezes você rodou um prompt na sua ferramenta de IA preferida e o resultado não era o esperado? No dia a dia, o mesmo padrão aparece quando um pedido vago entra na esteira: o time executa, surgem dúvidas, o ciclo se repete e a entrega chega tarde — ou diferente do que o negócio precisava.
O título deste artigo usa 90% como hipérbole editorial, não como estatística exata do seu próximo projeto. Estudos clássicos de falhas em software — como os relatórios CHAOS do Standish Group — mostram repetidamente que requisitos mal definidos, incompletos ou instáveis aparecem entre as causas mais citadas de fracasso ou estouro de prazo. Em plataformas reguladas, o custo não é só atraso: é retrabalho, auditoria e risco reputacional.
Vou usar uma analogia exagerada para fixar a ideia. Você é chefe de cozinha e a cozinha está um caos. O garçom entra correndo: “o cliente pediu um prato de macarrão!”. Você, que estudou culinária na Itália, prepara uma carbonara impecável. O garçom volta: “ele queria salada de bifum”. Esse restaurante é boa parte da indústria que se declara ágil, mas opera no extremo Go Horse quando o pedido não descreve o problema.
Engenharia de Requisitos
Algumas definições da literatura:
"O processo de estabelecer os serviços que o cliente requer de um sistema e as restrições sob as quais ele opera e é desenvolvido." — Ian Sommerville
Por essa definição, o garçom teria registrado pelo menos que o “macarrão” era de arroz, não de trigo.
"A engenharia de requisitos fornece o mecanismo apropriado para entender o que o cliente quer, analisando a necessidade, avaliando a viabilidade, negociando uma solução razoável, especificando a solução sem ambiguidades, validando a especificação e gerindo os requisitos à medida que eles são transformados em um sistema operacional." — Roger Pressman
Klaus Pohl resume como transformação de informação:
- Desejos vagos em requisitos explícitos;
- Linguagem informal em modelos formais;
- Visões individuais em acordo comum entre stakeholders.
Há padrão internacional: ISO/IEC/IEEE 29148. Para aprofundar, use o padrão ou as obras citadas — não repito aqui o conteúdo acadêmico completo.
O paralelo com o seu prompt
Para quem usa IA no ciclo de desenvolvimento, o prompt é uma materialização parcial de engenharia de requisitos. Processo fraco gera prompt fraco; processo sólido reduz — sem eliminar — o risco de surpresa na entrega.
Arquivos como AGENTS.md e SKILLS.md são formas de embutir parte dessa disciplina no repositório: contexto, restrições e critérios de aceite antes da geração de código.
No GitHub Copilot (modo Ask, Plan, Agent no VS Code), o paralelo é direto:
- Ask — entender contexto e problema no código;
- Plan — estruturar a mudança com critérios claros;
- Agent — executar e validar contra o que foi acordado.
Quem lidera times em fintech ou domínios regulados já faz versão disso em RFCs, ADRs e revisão de backlog. A IA só tornou o gap visível para quem pulava a etapa.
Reflexão
Se você atua em software há alguns anos, provavelmente já ouviu falar de requisitos — mas pouco tempo é reservado para praticá-los com rigor. A IA torna o tema inevitável: modelos antigos já existiam para fraude e scoring; LLMs generalizaram a geração de texto e código para fora de engenharia.
Mesmo sem IA no fluxo diário, vale perguntar se seus incidentes de escopo, retrabalho e “não era isso” não são, na raiz, falta de engenharia de requisitos — a disciplina que separa pedido vago de decisão que o negócio consegue defender.