Erros em Levantamento de Requisitos: 8 Falhas e Suas Consequências

66% dos projetos de software falham, e mais de 31% dos que estão em andamento serão cancelados antes de terminar, segundo levantamento do UDS Blog. Na prática, boa parte desse fracasso nasce muito antes da primeira linha de código: nasce nos erros em levantamento de requisitos, quando ninguém percebeu que o cliente descreveu o problema errado ou que o usuário final nunca foi ouvido. Este guia lista os erros mais frequentes dessa etapa, mostra o que cada um costuma custar ao projeto e explica como evitá-los mesmo sem experiência técnica prévia.

Resumo em 30 segundos

Levantamento de requisitos é a etapa em que a equipe descobre o que o sistema precisa fazer, antes de qualquer código ser escrito.
Entrevistar apenas o cliente contratante e ignorar o usuário final é apontado como uma das maiores dificuldades da fase, segundo o blog da Cedrotech.
78% dos projetos de software sofrem 'scope creep' — aumento de escopo não planejado — de acordo com dado citado pelo movti.com.br.
A norma internacional ISO/IEC/IEEE 29148 (2018) é a referência técnica para escrever requisitos claros e verificáveis.
52,7% dos projetos ultrapassam em 189% o orçamento estimado, conforme dado do UDS Blog, e requisitos mal levantados são apontados como causa raiz recorrente.

O que é levantamento de requisitos e por que erros aí custam tão caro?

Levantamento de requisitos é a etapa em que a equipe de projeto descobre, junto com quem vai usar e pagar pelo sistema, o que ele precisa fazer antes de qualquer linha de código ser escrita. É diferente de análise de requisitos (organizar e priorizar o que foi levantado) e de especificação (documentar tudo de forma formal, geralmente em um documento SRS). Na prática, é a fase de perguntas: o que o usuário faz hoje, o que falta, o que não pode faltar, quem decide o quê. Se essa etapa é malfeita, tudo que vem depois — desenho técnico, desenvolvimento, teste — herda o erro e ele só cresce.

Os números mostram o tamanho do problema. Segundo levantamento do UDS Blog, 66% dos projetos de software falham, mais de 31% dos projetos em andamento são cancelados antes de terminar, e 52,7% deles custam 189% a mais do que a estimativa original previa. Para um gestor, isso significa que a chance de o projeto sair do papel exatamente como planejado é baixa — e que o estouro de orçamento, quando acontece, não é um detalhe: é quase o dobro do valor combinado no contrato ou no orçamento interno. Não é um problema de programação ruim na maioria dos casos; é um problema de ponto de partida errado.

A razão para esse efeito cascata é simples de entender: cada decisão de projeto se apoia na anterior. Se o levantamento não captura que o sistema precisa emitir nota fiscal em três estados com regras tributárias diferentes, essa lacuna só aparece quando alguém for testar a emissão — e nesse ponto o código já está escrito, o cronograma já foi cumprido em outras frentes e a correção compete com prazos que já estão em andamento. Corrigir um requisito mal levantado na fase de testes custa, na prática, retrabalho de desenvolvimento, retrabalho de teste e atraso de entrega — tudo ao mesmo tempo. É por isso que a engenharia de requisitos trata o levantamento como a fase de maior retorno por hora investida: um erro identificado ali custa uma pergunta a mais; o mesmo erro identificado na entrega custa um projeto renegociado.

Quais são os erros mais comuns no levantamento de requisitos e o que eles causam?

Os erros em levantamento de requisitos se repetem de projeto para projeto porque nascem de atalhos na hora de ouvir quem vai usar o sistema, não de falta de ferramenta. Cada erro abaixo tem uma consequência concreta e mensurável, não apenas um "pode dar problema":

Entrevistar só o cliente, não o usuário final. O cliente que assina o contrato raramente é quem opera o sistema no dia a dia. O blog da Cedrotech descreve exatamente esse descompasso: o analista valida requisitos com o gestor, entrega o sistema, e a equipe operacional aponta que faltam telas ou fluxos essenciais — a consequência é retrabalho completo de módulos já entregues.
Confundir requisito funcional com regra de negócio. Tratar uma política da empresa (ex.: limite de desconto por vendedor) como se fosse uma função do sistema (ex.: gerar boleto) faz a equipe técnica implementar a lógica no lugar errado, exigindo retrabalho quando a regra muda e o time descobre que ela estava hardcoded no código em vez de configurável.
Não escrever requisito não funcional de carga ou segurança. Quando ninguém formaliza quantos usuários simultâneos o sistema precisa suportar, a equipe só descobre o problema quando o sistema cai em produção sob uso real — orçamento e cronograma que não previam essa correção estouram justamente aí.
Aceitar linguagem ambígua no documento de requisitos. Frases como "o sistema deve ser rápido" ou "a tela deve ser intuitiva" abrem espaço para interpretações diferentes entre quem escreveu e quem construiu, gerando retestes e funcionalidades entregues fora do que o negócio esperava.
Não validar o escopo formalmente com o cliente. Sem um documento assinado descrevendo o que entra e o que fica de fora, cada parte lembra de uma versão diferente da conversa — e a negociação sobre o que foi "prometido" trava o cronograma.
Ignorar o scope creep. Esse é o erro mais caro em volume: segundo o movti.com.br, a inflação de escopo ocorre em 78% dos projetos de software, e mais de 80% dos gerentes de projeto admitem lançar produtos sabendo que havia falhas. Cada pedido extra aceito sem repactuar prazo e orçamento empurra o projeto para os números do UDS Blog: 52,7% dos projetos custam 189% a mais do que a estimativa original.

Registrar cada mudança de escopo numa matriz de rastreabilidade é o que transforma um pedido informal em decisão documentada — e evita que o sexto erro da lista vire regra no seu projeto.

Requisito funcional, não funcional e regra de negócio: por que confundir os três gera erro?

Muita confusão em erros em levantamento de requisitos começa antes mesmo de o projeto sair do papel: o time não sabe separar o que é requisito funcional, requisito não funcional e regra de negócio. Requisito funcional descreve o que o sistema faz — uma ação, uma tela, um cálculo. Requisito não funcional descreve como o sistema deve se comportar enquanto faz isso — velocidade, segurança, disponibilidade. Regra de negócio é uma política da empresa que existe independente do software e que o sistema só precisa respeitar, como um limite de desconto ou uma condição fiscal. Como resume a apuração do setor, regras de negócio "tratam de políticas e normas que o sistema deve obedecer", e por isso não podem ser tratadas como sinônimo de requisito não funcional, embora frequentemente sejam confundidas com ele.

Para tornar isso concreto, imagine a Vitrine Fácil, uma loja virtual fictícia de médio porte. "Permitir que o cliente aplique um cupom de desconto no carrinho" é requisito funcional: descreve uma função visível, testável, que o usuário aciona. "A página do carrinho deve carregar em até 2 segundos com até 500 usuários simultâneos" é requisito não funcional: não é uma função nova, é uma exigência de desempenho sobre funções que já existem. Já "cupons de primeira compra não podem ser combinados com frete grátis" é regra de negócio: é uma política comercial da Vitrine Fácil que existiria mesmo sem sistema nenhum — ela só precisa ser respeitada pelo código.

A confusão entre as três categorias é uma das lacunas mais caras do levantamento, porque requisito não funcional é sistematicamente esquecido quando a equipe só pensa em "o que o botão faz". É o cenário clássico de um e-commerce que nunca levantou requisito de carga e, na Black Friday, derruba o site porque ninguém formalizou quantos acessos simultâneos o sistema precisava suportar — a funcionalidade existia e funcionava perfeitamente em teste, só não resistiu ao volume real. O time testou a regra de negócio e a função, mas não testou o comportamento sob estresse, porque esse requisito nunca foi escrito.

Para não repetir esse erro, vale registrar as três categorias em documentos separados e com donos diferentes: regra de negócio validada com quem entende do processo comercial, requisito funcional descrito como comportamento observável, e requisito não funcional quantificado com número e unidade de medida, não como adjetivo ("rápido", "seguro"). O guia Requisitos Funcionais e Não Funcionais: Guia com Exemplos detalha como classificar e escrever cada tipo sem essa mistura.

Como a ISO/IEC/IEEE 29148 ajuda a evitar erros ao escrever requisitos?

A ISO/IEC/IEEE 29148 é a norma internacional que define como um requisito bem escrito deve se comportar — ela existe desde 2018 e é hoje a principal referência de mercado em engenharia de requisitos, conforme descreve a ficha técnica do SEBoK, mantida pelo consórcio ISO/IEC/IEEE. Para o gestor sem bagagem técnica, a boa notícia é que ela não exige conhecimento de programação: trata-se de um conjunto de regras de escrita, parecido com um manual de estilo, aplicado a frases que descrevem o que o sistema deve fazer. Quando essas regras não são seguidas, o requisito vira ambíguo — e ambiguidade é justamente o tipo de erro mais difícil de detectar antes que o retrabalho apareça, porque duas pessoas leem a mesma frase e entendem coisas diferentes.

Na prática, a norma recomenda algo simples de aplicar mesmo sem formação em TI: cada requisito deve conter uma única exigência por sentença, evitar palavras vagas como "rápido", "amigável" ou "adequado" sem um número que as defina, e ser redigido de forma verificável — ou seja, alguém precisa conseguir testar e dizer "sim, isso foi atendido" ou "não, não foi". Um exemplo real do problema: a frase "o sistema deve responder rapidamente às consultas do usuário" parece inofensiva, mas não diz o que é "rapidamente" — 1 segundo? 5 segundos? Sem esse número, o time de desenvolvimento entrega algo, o cliente considera lento, e a discussão sobre quem tem razão consome semanas que poderiam ter sido evitadas com uma frase como "o sistema deve responder em até 2 segundos para 95% das consultas". É exatamente esse tipo de lacuna — o requisito escrito de forma abstrata, sem conectar a um cenário concreto de teste — que a norma foi desenhada para eliminar.

Adotar a 29148 como referência interna também ajuda a padronizar como diferentes squads e fornecedores escrevem requisitos, o que reduz a dependência de

Como evitar os erros no levantamento de requisitos na prática?

Evitar erros em levantamento de requisitos não é escolher uma técnica "certa" e aplicá-la sempre — é casar cada técnica de elicitação ao tipo de erro que ela neutraliza. O erro de escolher a ferramenta errada para o contexto errado é, ele mesmo, uma causa recorrente de retrabalho: uma entrevista mal conduzida com o stakeholder errado produz o mesmo problema que um workshop tentaria resolver com outra dinâmica. A tabela abaixo cruza os erros mais citados na apuração com a prática que ataca a causa, não o sintoma.

Erro no levantamento	O que causa	Prática recomendada
Falar só com o cliente, não com o usuário final	Sistema que não atende a rotina real de quem opera	Entrevista estruturada com roteiro específico para o operador, separada da conversa comercial com o cliente
Requisito ambíguo, escrito em linguagem vaga	Retrabalho e interpretação divergente entre times	Questionário fechado + revisão do texto final contra critérios objetivos (ver ISO/IEC/IEEE 29148, citada na seção anterior)
Escopo levantado só com uma pessoa ou área	Requisito que ignora regra de negócio de outro setor, gerando scope creep depois	Workshop (JAD — Joint Application Design) reunindo as áreas impactadas na mesma sessão
Requisito não funcional esquecido (performance, segurança)	Sistema aprovado em teste funcional, mas instável em produção	Checklist de não funcionais aplicado em toda entrevista, não só ao final do projeto
Documentação de requisitos feita de memória, sem registro estruturado	Perda de rastreabilidade entre o que foi pedido e o que foi entregue	Registro imediato em documento formal, com matriz de rastreabilidade vinculando requisito à origem

A entrevista técnica e a entrevista funcional, mencionadas nas fontes do setor, servem a propósitos diferentes: a primeira valida viabilidade com quem vai construir, a segunda valida necessidade com quem vai usar. Confundir as duas — ou aplicar apenas uma delas — é onde nasce boa parte do erro de

Perguntas frequentes

Quais são os erros mais comuns no levantamento de requisitos?

Os mais citados são entrevistar apenas o cliente contratante sem ouvir o usuário final, confundir requisito funcional com regra de negócio, deixar de lado requisitos não funcionais como performance e segurança, aceitar descrições ambíguas e não controlar o crescimento do escopo depois do início do projeto. Cada um desses erros tende a gerar retrabalho, atraso ou estouro de orçamento mais adiante no projeto.

Qual a diferença entre requisito funcional e não funcional?

Requisito funcional descreve o que o sistema faz, como 'permitir login com e-mail e senha'. Requisito não funcional descreve como o sistema deve se comportar, como tempo de resposta, capacidade de usuários simultâneos ou nível de segurança exigido.

O que é scope creep e como evitar no projeto?

Scope creep é o crescimento não planejado do escopo do projeto depois que ele já começou, geralmente por pedidos informais de mudança que não passam por análise de impacto. Segundo dado citado pelo movti.com.br, isso ocorre em 78% dos projetos de software, e a forma de conter é documentar o escopo inicial por escrito e formalizar todo pedido de alteração antes de executá-lo.

Reduzir os erros em levantamento de requisitos começa por tratar essa etapa como parte central do projeto, não como formalidade antes do desenvolvimento — documentar quem foi ouvido, que técnica de elicitação foi usada e como cada requisito foi validado com o usuário final. Para quem quer apoio nesse processo, o espacoia.com.br usa agentes de IA para transformar entrevistas e conversas de negócio em documentação técnica estruturada, reduzindo a chance de um requisito mal levantado virar retrabalho lá na frente.