Elicitação de Requisitos: 10 Técnicas e Quando Usar Cada Uma

Elicitação de requisitos é o conjunto de atividades usadas para descobrir o que um sistema precisa fazer, ouvindo quem vai usá-lo ou pagar por ele. A confusão começa na escolha da técnica: entrevista, questionário, prototipação e workshop resolvem problemas diferentes, e usar a errada é uma das razões mais citadas para requisitos incompletos chegarem ao desenvolvimento.

Resumo em 30 segundos

Elicitação de requisitos é a etapa de descoberta das necessidades do sistema, anterior à análise e à documentação formal em um SRS.
Existem ao menos 10 técnicas consolidadas: entrevista, questionário, observação, prototipação, workshop/JAD, cenários de uso, casos de uso, etnografia, análise de documentos e técnicas cognitivas (como análise de protocolo).
A norma ISO/IEC/IEEE 29148 recomenda o uso de técnicas sistemáticas, como prototipagem e pesquisas estruturadas, para identificar proativamente as necessidades de clientes e usuários finais.
Requisitos incompletos ou omissos têm relação direta com baixa qualificação da equipe e uso limitado de técnicas de elicitação, segundo Fernández et al. (2017).
Não existe técnica universal: a escolha correta depende do contexto do projeto — time distribuído, cliente indisponível ou domínio regulado exigem combinações diferentes.

O que é elicitação de requisitos e em que ela difere do levantamento de requisitos

Elicitação de requisitos é o conjunto de atividades realizadas para descobrir o que um sistema precisa fazer — não apenas perguntar ao cliente o que ele quer, mas investigar, observar e interpretar necessidades que muitas vezes nem o próprio stakeholder sabe articular com clareza. A definição é direta: segundo a Unisinos, elicitação é "o nome dado para o conjunto de atividades realizadas para a descoberta dos requisitos de um sistema". Isso significa que ela vai além de coletar informações: envolve entrevistar, observar processos de trabalho, analisar documentos existentes e, em muitos casos, ajudar o próprio cliente a enxergar problemas que ele ainda não tinha formulado como requisito.

Na prática do mercado brasileiro, "levantamento de requisitos" e "elicitação de requisitos" são usados como sinônimos na maior parte das conversas entre gestores e equipes de tecnologia. Se você pesquisou por um termo ou pelo outro, está no lugar certo — o conteúdo é o mesmo. A diferença aparece quando se olha para a literatura internacional de engenharia de software: lá, elicitação é tratada como uma etapa específica dentro de um processo mais amplo, que também inclui análise, especificação, validação e gestão de requisitos. Ou seja, elicitar é descobrir; especificar é documentar essa descoberta de forma estruturada, por exemplo em um SRS Documento.

Essa distinção importa na prática porque muitos projetos falham não na elicitação em si, mas na transição entre descobrir e formalizar. Um exemplo comum: a equipe conduz boas entrevistas, mapeia bem o processo do cliente, mas não documenta o requisito de forma rastreável — e a informação se perde na próxima reunião. Para entender onde a elicitação se encaixa dentro do fluxo completo, do primeiro contato com o stakeholder até a homologação, vale conferir o guia de Engenharia de Requisitos, que detalha cada etapa desse processo maior. Entender esse encaixe evita um erro frequente entre gestores: tratar a elicitação como um evento único ("a reunião de requisitos") em vez de um processo contínuo que se repete ao longo do projeto, especialmente quando o escopo muda ou novos stakeholders entram na conversa.

Quais são as 10 técnicas de elicitação de requisitos (e quando usar cada uma)

Não existe uma técnica única que resolva a elicitação de requisitos de qualquer projeto. O que funciona para mapear o fluxo de aprovação de crédito de um banco não funciona para desenhar a tela de checkout de um app de delivery. Por isso, a engenharia de requisitos consolidou um repertório de dez técnicas — cada uma respondendo a um tipo de incerteza diferente. Conhecer só o nome não ajuda: o que importa é saber quando aplicar e, principalmente, quando trocar de abordagem.

A lista abaixo organiza as técnicas na ordem em que normalmente aparecem num projeto real, da mais genérica (entrevista) às mais especializadas (técnicas cognitivas). Para times que já têm um processo estruturado de Engenharia de Requisitos, essas técnicas alimentam diretamente os requisitos que depois vão para o SRS.

Entrevista — a técnica-mãe, presente na maioria dos processos de elicitação, segundo o material acadêmico da Unisinos. Use quando você precisa entender o processo de trabalho atual do cliente e ainda não sabe quais perguntas fazer — é dela que nasce a necessidade de outras técnicas. Não use como único método quando há dezenas de usuários com rotinas diferentes: o viés de quem você entrevistou primeiro contamina o resto.
Questionário — indicado quando existe grande volume de usuários e é inviável entrevistar todos, com a vantagem de padronizar perguntas e permitir tratamento estatístico das respostas. Evite quando o problema é mal compreendido: questionário fechado não capta o que você ainda não sabe perguntar.
Observação — útil para entender comportamento real, não o relatado. O risco conhecido é que as pessoas alteram a conduta ao saber que estão sendo observadas, distorcendo o resultado. Não use isoladamente em decisões críticas de negócio.
Prototipação — recomendada quando há alto grau de incerteza e a equipe precisa de feedback rápido do usuário antes de codificar. Evite em requisitos regulatórios fixos, onde protótipo visual não substitui análise documental.
Workshop/JAD — reúne múltiplos stakeholders numa sessão só, útil para acelerar consenso. Não funciona bem quando os interesses dos participantes são muito conflitantes sem mediação prévia.
Cenários de uso — usuários finais simulam interações, do esboço inicial à descrição completa. Bom para UX; fraco para requisitos não funcionais como performance.
Casos de uso — formaliza o cenário em estrutura de ator-sistema-fluxo, útil para gerar critérios de aceite. Excessivo para funcionalidades muito simples.
Etnografia — observação imersiva do contexto de trabalho, citada nos materiais da UFMG. Cara e lenta; não se aplica a prazos curtos.
Análise de documentos existentes — reaproveita manuais, planilhas e sistemas legados. Barata, mas insuficiente quando o documento está desatualizado.
Técnicas cognitivas (análise de protocolo) — especialmente úteis em sistemas baseados em conhecimento, como diagnóstico médico. Dispensáveis em sistemas transacionais simples.

Para aprofundar a diferença entre requisito funcional e não funcional levantado em cada técnica, veja o guia de Requisitos Funcionais e Não Funcionais.

Entrevista ou questionário: qual escolher para levantar requisitos

A resposta curta é: depende do tamanho do grupo que você precisa ouvir e da profundidade que a decisão exige. Entrevista é a técnica indicada quando o número de stakeholders é pequeno e as respostas exigem nuance — ela permite ao entrevistador aprofundar um ponto, pedir exemplos e perceber contradições em tempo real. Questionário é a escolha certa quando o universo de usuários é grande e entrevistar cada um seria inviável — ele troca profundidade por escala, padronização e a possibilidade de tratar as respostas estatisticamente. Não são técnicas concorrentes: na prática, uma frequentemente prepara o terreno para a outra.

A entrevista é descrita na apuração como a técnica-mãe da elicitação de requisitos: reuniões formais ou informais com os stakeholders, guiadas por perguntas formuladas pela equipe de engenharia de requisitos sobre o processo de trabalho atual e sobre o sistema a ser construído. Ela está presente na maioria dos processos de elaboração de requisitos porque é a partir dela que surge a necessidade de usar outras técnicas — um gestor entrevista o time financeiro, percebe que o volume de exceções é grande demais para mapear em conversa e só então decide aplicar um questionário para quantificar o problema. É por isso que a entrevista funciona bem no início do projeto, quando ainda não se sabe exatamente o que perguntar, e enfraquece quando o objetivo é confirmar um padrão em centenas de respostas — aí o custo de tempo por entrevista deixa de compensar.

O questionário resolve exatamente esse ponto fraco: a Unisinos recomenda a técnica quando existe um grande número de usuários e dificuldade para entrevistá-los todos, justamente pela vantagem de padronizar as perguntas e permitir tratamento estatístico das respostas. O trade-off é que ele não captura o

Qual técnica usar por contexto: time distribuído, cliente indisponível e domínio regulado

A técnica certa muda dependendo de três variáveis práticas: onde as pessoas estão, se o stakeholder tem agenda disponível e se o setor exige rastreabilidade formal. Escolher entrevista presencial para um time espalhado em três fusos horários, ou observação in loco para um cliente que não abre a agenda, é receita para atraso e requisito mal capturado. A tabela abaixo cruza os três cenários mais comuns com a adaptação que funciona na prática, sem depender de condição ideal de projeto.

| Contexto | Técnica recomendada | Adaptação prática | Risco de ignorar o contexto | |---|---|---| | Time distribuído / remoto | Entrevista + questionário assíncrono | Gravação de sessão com transcrição, quadro colaborativo (Miro) para cenários de uso, formulário assíncrono para fuso incompatível | Retrabalho por mal-entendido não capturado em tempo real | | Cliente indisponível | Análise de artefatos existentes + proxy de negócio | Documentos, planilhas e sistemas legados como fonte primária; indicar um proxy de negócio (gestor de área) para validar hipóteses | Requisito baseado em suposição da equipe técnica, não do negócio | | Domínio regulado (saúde, financeiro) | Prototipação + pesquisa estruturada | Checklist de requisitos funcionais, não funcionais, de interface, dados e regulatórios, com rastreabilidade documentada | Não conformidade identificada só na auditoria, tarde para corrigir |

Para times distribuídos, a saída não é replicar a entrevista presencial por videochamada e torcer para funcionar. É trocar a dependência de sincronismo por artefatos assíncronos: gravar a sessão com transcrição automática substitui a ata manual, e um quadro como Miro documenta cenários de uso sem exigir que todos estejam online ao mesmo tempo. Questionário estruturado resolve a lacuna de fuso horário quando a entrevista simplesmente não cabe na agenda de ninguém.

Quando o stakeholder não tem tempo — situação recorrente em projetos com sponsor executivo ocupado —, a alternativa validada é reduzir a dependência da entrevista e elevar a análise de artefatos existentes: contratos, planilhas, tickets de suporte e sistemas legados carregam requisito implícito que não precisa de reunião para ser extraído. Um proxy de negócio, indicado formalmente pelo sponsor, absorve as decisões do dia a dia sem sequestrar a agenda de quem manda.

Em domínio regulado, a ISO/IEC/IEEE 29148 recomenda o uso de técnicas sistemáticas — prototipagem e pesquisas estruturadas — justamente para documentar proativamente a necessidade do usuário com rastreabilidade, não para engessar o processo. Setores como saúde e financeiro exigem que cada requisito capturado aponte para uma exigência regulatória específica, o que aproxima a elicitação da estrutura descrita no Modelo de Documento de Requisitos e reforça a separação clara entre requisitos funcionais e não funcionais desde a primeira sessão de elicitação.

Como a IA está mudando a elicitação de requisitos

A IA generativa não substitui nenhuma das dez técnicas apresentadas acima — ela acelera a execução delas. Na prática, isso aparece em três frentes: transcrição e resumo automático de entrevistas, geração de perguntas de acompanhamento e estruturação de respostas de questionário. Uma entrevista de uma hora com um gestor financeiro, por exemplo, pode ser gravada e transcrita automaticamente, com a IA extraindo decisões, pendências e contradições no discurso — algo que, feito manualmente, consome horas de um analista e ainda corre risco de perder nuance por fadiga de atenção.

O ganho mais imediato está no pós-entrevista. Depois que a transcrição existe, é possível pedir à IA que gere uma lista de perguntas de acompanhamento com base em lacunas detectadas na fala do stakeholder — pontos em que ele mencionou uma regra de negócio sem detalhar a exceção, ou citou um sistema legado sem explicar a integração. Isso reduz o número de rodadas de entrevista necessárias, o que é especialmente valioso no contexto de cliente indisponível, onde cada rodada extra custa semanas de agenda. O mesmo vale para questionários: respostas abertas de dezenas de usuários podem ser agrupadas por tema e contradição pela IA antes de chegarem ao analista, transformando texto livre em insumo estruturado para o documento de requisitos.

O ponto que conecta essa mudança ao resultado de negócio é a apuração sobre má elicitação: Fernández et al. (2017) associam requisitos incompletos à fraca qualificação de profissionais e ao pouco uso de técnicas de elicitação. Projetos de IA sofrem exatamente desse problema — e é por isso que a maioria não sai do papel com retorno real, como mostra ROI de IA: por que só 5% das empresas colhem resultado real. Sem elicitação sólida, o modelo é treinado para resolver o problema errado. O padrão se repete em escala nacional: IA em escala no Brasil: por que só 5% das empresas têm retorno real mostra que a maioria das empresas vê valor potencial, mas poucas capturam retorno — e a causa raiz, com frequência, começa antes do modelo: na entrevista malfeita, no questionário mal interpretado, no requisito que ninguém validou.

Perguntas frequentes

Qual a diferença entre elicitação e levantamento de requisitos?

Na prática brasileira, os dois termos são usados como sinônimos para descrever a etapa de descoberta das necessidades do sistema junto aos stakeholders. A distinção mais técnica é que 'elicitação' é o termo usado na literatura internacional (elicitation) e enfatiza que os requisitos raramente estão prontos na cabeça do cliente — eles precisam ser extraídos com técnicas específicas, não apenas coletados.

Como fazer elicitação de requisitos quando o cliente não tem disponibilidade?

Combine técnicas de baixo custo de tempo do stakeholder: análise de documentos e artefatos já existentes, questionários assíncronos e indicação de um proxy de negócio que responda em nome do cliente. Gravações curtas de tela ou de processo, revisadas depois pela equipe, também substituem parte da observação presencial sem exigir agenda fixa.

O que a norma ISO/IEC/IEEE 29148 recomenda sobre elicitação de requisitos?

A norma orienta o uso de técnicas sistemáticas, como prototipagem e pesquisas estruturadas, para identificar e documentar proativamente as necessidades de clientes e usuários finais. Ela não prescreve uma técnica única, mas exige que o processo seja sistemático e rastreável, o que é especialmente relevante em domínios regulados.

Escolher a técnica certa resolve a coleta, mas o requisito só gera valor quando é registrado de forma estruturada e rastreável até o documento final — é nessa passagem de entrevista bruta para especificação formal que a maioria dos projetos perde tempo e qualidade, e é aí que o espacoia.com.br usa agentes de IA para transformar as informações elicitadas diretamente em documentação técnica de projeto.