Entrevista de Levantamento de Requisitos: Roteiro Pronto p/ Usar
Guia com roteiro pronto para entrevista de levantamento de requisitos: perguntas por etapa, erros comuns e como virar documento — copie e use na próxima reunião.
Segundo Sommerville, erros na compreensão dos requisitos respondem por até 56% dos defeitos em sistemas entregues — e a maioria desses erros nasce numa entrevista mal conduzida, sem roteiro e sem pergunta de aprofundamento. Uma entrevista de levantamento de requisitos bem feita resolve isso antes de qualquer linha de código: ela é a reunião estruturada entre quem vai construir o sistema e quem conhece o processo de negócio, com o objetivo de transformar respostas soltas em requisitos rastreáveis.
Resumo em 30 segundos
- A entrevista de levantamento de requisitos é uma reunião estruturada entre analista (entrevistador) e stakeholder (entrevistado) para extrair necessidades de negócio antes da especificação.
- Existem três formatos: entrevista fechada (perguntas definidas antecipadamente), aberta/não estruturada (conversa livre) e semiestruturada (roteiro base com espaço para aprofundar).
- Erros na compreensão dos requisitos respondem por até 56% dos defeitos em sistemas entregues, segundo Sommerville (2011).
- Um roteiro eficaz cobre quatro blocos: perfil do entrevistado, processo atual, dor e critério de sucesso, e requisitos não funcionais (segurança, integrações, LGPD).
- As respostas da entrevista só geram valor quando são convertidas em requisitos funcionais e não funcionais dentro de um documento rastreável, como um SRS.
O que é uma entrevista de levantamento de requisitos e quando usá-la
Uma entrevista de levantamento de requisitos é uma reunião estruturada entre o analista responsável pelo projeto e um interessado no sistema — o stakeholder que conhece o processo, a dor ou a operação que o software vai atender. Segundo material acadêmico da UFES, nesse formato o analista formula questões para os interessados e os requisitos são derivados diretamente das respostas obtidas. Não é uma conversa livre: tem objetivo, tem escopo e tem um destino claro — virar informação estruturada em um documento de requisitos.
A ACerT complementa essa definição de um jeito prático: são reuniões, formais ou informais, em que a equipe de engenharia de requisitos coloca perguntas específicas sobre o processo de trabalho atual do cliente. É esse foco no "como funciona hoje" que diferencia a entrevista de uma apresentação de produto ou de um bate-papo exploratório sem pauta. Se ao final da conversa você não conseguir escrever pelo menos três frases do tipo "o sistema deve fazer X", a entrevista não cumpriu sua função.
A entrevista é a técnica certa quando existe um número pequeno de interessados-chave que dominam o processo e quando as respostas exigem nuance — coisas como "por que essa exceção acontece" ou "o que realmente trava sua rotina", que um formulário fechado não captura. Ela perde eficiência quando o público é grande e disperso (aí o questionário escala melhor), quando o processo é mais fácil de ver do que de descrever (a observação direta do usuário trabalhando revela gargalos que ele nem verbaliza) ou quando várias áreas com interesses conflitantes precisam alinhar prioridades ao mesmo tempo — cenário em que uma sessão JAD (Joint Application Development) resolve mais rápido que entrevistas sequenciais. Na prática, a maioria dos projetos combina as três: entrevista para profundidade, questionário para volume, observação para validar o que foi dito. O output de qualquer uma delas, aliás, segue o mesmo destino: alimentar um documento de requisitos completo ou, em projetos que seguem norma internacional, um SRS baseado na ISO/IEC 29148.
Entrevista estruturada, semiestruturada ou aberta: qual escolher
A escolha do formato muda o resultado da entrevista de levantamento de requisitos mais do que qualquer técnica de pergunta. No extremo fechado está a entrevista estruturada, definida pela QConcursos como aquela cuja "natureza estruturada" vem de perguntas definidas antecipadamente — o analista chega com roteiro fixo, segue a ordem e compara respostas de forma objetiva entre stakeholders diferentes. No outro extremo está a entrevista aberta, sem roteiro fechado, pensada para explorar um problema que ninguém sabe descrever direito ainda. Entre os dois há a semiestruturada, que mistura perguntas fixas com espaço para aprofundar o que surgir na conversa — é o formato mais usado na prática, porque raramente um stakeholder cabe inteiro num roteiro rígido.
O treinamento WAEI/MSE descreve bem esse contraste ao separar a entrevista desestruturada — tratada como "conversa informal, primeiro contato" — da entrevista planejada, em que se envia uma pauta prévia sobre o que será abordado. Na prática, isso define o momento certo de usar cada uma: a conversa informal serve para o primeiro encontro com um stakeholder novo, quando você ainda não sabe o vocabulário dele nem os limites do problema; a entrevista planejada serve para validar hipóteses, fechar escopo ou levantar requisitos não funcionais específicos, como regras de segurança e integrações — temas que exigem pergunta certeira, não bate-papo. Um exemplo comum: numa migração de sistema legado de RH, a primeira conversa com o gestor de folha de pagamento costuma ser aberta, para mapear o processo real; já a entrevista seguinte, com o time de TI sobre integrações com o eSocial, precisa ser fechada e com pauta enviada com antecedência, porque toca prazos legais e não há espaço para descobrir o problema durante a reunião.
| Formato | Quando usar | Risco se usar errado |
|---|---|---|
| Aberta / não estruturada | Primeiro contato, problema ainda mal definido | Reunião longa sem direção, difícil de comparar com outras entrevistas |
| Semiestruturada | Maioria dos casos: aprofundar processo e dor do usuário | Se mal calibrada, vira aberta disfarçada |
| Fechada / estruturada | Validar hipótese, levantar requisito não funcional, prazo apertado | Perde informação relevante fora do roteiro |
Na prática de projetos que viram documento de requisitos formal, o caminho mais eficiente é começar aberto com o patrocinador do projeto, fechar em semiestruturado com os usuários-chave e usar entrevista estruturada apenas nas rodadas de validação final, quando o objetivo já não é descobrir, mas confirmar.
Roteiro pronto: as perguntas para levar na reunião
O roteiro abaixo expande o modelo clássico de Rafael RJP — que já trazia perguntas como "quais são suas principais responsabilidades?" e "que saídas você produz? Para quem?" — e adiciona um bloco que praticamente nenhum material disponível cobre: requisitos não funcionais. Segurança, LGPD e integrações raramente entram na pauta de uma entrevista de levantamento de requisitos, e é exatamente essa lacuna que gera retrabalho depois, quando o time técnico descobre tarde demais que o sistema precisa de autenticação em dois fatores ou de integração com um ERP legado.
Divida a entrevista em quatro blocos. Use a ordem abaixo como sequência lógica da conversa — ela vai do genérico (quem é o entrevistado) ao específico (o que o sistema não pode falhar em fazer):
- Bloco 1 — Perfil e responsabilidades: Quais são suas principais responsabilidades no processo? Quem mais participa dessa rotina e qual o papel de cada um? Que decisões você toma hoje que dependem de informação de outra área? Que saídas (relatórios, aprovações, documentos) você produz, e para quem elas vão?
- Bloco 2 — Processo atual: Como esse processo funciona hoje, passo a passo? Quais ferramentas ou planilhas são usadas em cada etapa? Onde ocorrem os maiores atrasos ou retrabalhos? Existe alguma etapa manual que poderia ser automatizada?
- Bloco 3 — Dor e critério de sucesso: Qual problema esse projeto precisa resolver? Como você resolve esse problema hoje, sem o sistema? Como você vai saber que o projeto deu certo — que número ou indicador vai mudar? O que aconteceria se nada fosse feito?
- Bloco 4 — Requisitos não funcionais: Quantas pessoas vão usar o sistema simultaneamente? Existe dado pessoal ou sensível envolvido, que exija tratamento sob a LGPD? O sistema precisa se integrar com algum software já existente (ERP, CRM, planilha)? Há exigência de disponibilidade (o sistema pode ficar fora do ar em algum horário) ou de auditoria de acesso?
Esse último bloco é o que separa um levantamento superficial de um documento de requisitos completo. Sem ele, você chega ao documento SRS só com requisitos funcionais — e volta a campo semanas depois para perguntar o que devia ter sido perguntado na primeira reunião.
Como conduzir sem travar: stakeholder vago, conflito e follow-up
O roteiro pronto resolve metade do problema. A outra metade acontece na sala (ou na chamada de vídeo), quando a resposta vem torta, o stakeholder trava ou dois interessados discordam na sua frente. Nessas horas, a condução importa mais que a lista de perguntas.
Comece explicando a dinâmica antes de disparar a primeira pergunta: quanto tempo vai durar, o que você vai fazer com as respostas e, se for gravar, peça autorização explícita — essa transparência reduz a intimidação do entrevistado e aumenta a qualidade das respostas, conforme recomenda o iMasters. Grave sempre que possível: transcrição automática (Zoom, Teams ou uma ferramenta de IA dedicada) libera você para ouvir de verdade em vez de digitar, e vira material bruto para revisar depois, antes de transformar a conversa em requisitos funcionais e não funcionais.
A segunda regra é comportamental e não negociável: o entrevistado é o especialista no processo dele, não você. O DevMedia é direto nisso — o analista nunca deve criticar a credibilidade de quem responde, mesmo quando a resposta parece contraditória ou incompleta. Se o gerente financeiro descreve um processo de forma diferente do que o analista de operações contou na entrevista anterior, isso não é erro de um dos dois: é sinal de que o processo real é diferente do processo formal, e essa divergência é justamente o tipo de achado que justifica a entrevista.
Quando a resposta vem vaga — "o sistema precisa ser mais ágil", "a gente perde tempo com isso" — não avance para a próxima pergunta do roteiro. Aprofunde com uma sequência curta: peça um exemplo concreto da última vez que isso aconteceu; pergunte o impacto em número (horas, retrabalho, clientes perdidos); e repita
Da entrevista ao documento: transformando respostas em requisitos
A entrevista termina, você tem páginas de anotações ou uma transcrição gerada por IA — e agora? O erro mais comum é deixar esse material solto em um documento de texto corrido, sem classificação, até que alguém precise caçar uma informação específica dois meses depois. O caminho correto é tratar cada resposta como matéria-prima a ser processada, não como registro final. Isso significa separar o que o entrevistado disse em duas categorias: o que o sistema precisa fazer (requisito funcional) e como o sistema precisa se comportar (requisito não funcional). Se você ainda tem dúvida sobre essa distinção na prática, o guia Requisitos Funcionais e Não Funcionais: Guia com Exemplos traz exemplos lado a lado que ajudam a treinar esse filtro antes mesmo de entrar na sala de reunião.
Na prática, a triagem funciona assim: quando o stakeholder responde "hoje eu aprovo cada pedido de compra manualmente e demoro dois dias", isso é a semente de um requisito funcional — "o sistema deve permitir aprovação de pedidos de compra com fluxo configurável de alçada". Já quando ele diz "não posso ter esse dado fora do Brasil por causa da LGPD" ou "precisa aguentar 500 usuários simultâneos no fechamento do mês", isso vira requisito não funcional — restrição de conformidade e de performance, respectivamente. É exatamente essa segunda categoria que a maioria dos roteiros de entrevista ignora, porque o foco fica todo no processo de negócio e na dor do usuário, deixando de fora perguntas sobre segurança, integrações e limites técnicos que aparecem tarde demais, já em desenvolvimento.
Depois de classificada, cada resposta precisa de rastreabilidade: de qual pergunta ela veio, quem respondeu, e qual seção do documento final ela alimenta. Um exemplo prático — numa entrevista para um sistema de gestão de estoque, a resposta "eu preciso saber quando o saldo cai abaixo de 10 unidades" se transforma em um requisito funcional específico dentro do módulo de alertas, referenciado de volta à entrevista original caso precise de validação. Sem esse elo, o documento final vira uma lista de frases bonitas sem lastro. Para estruturar esse rastreamento seguindo padrão internacional, vale usar o modelo do SRS Documento: Guia com Modelo Pronto Baseado na ISO/IEC 29148, ou, para times que preferem algo mais direto, o Modelo de Documento de Requisitos: Estrutura Completa p/ Baixar já traz as seções prontas para colar as respostas classificadas.
Perguntas frequentes
Qual a diferença entre entrevista estruturada e não estruturada para levantamento de requisitos?
Na entrevista estruturada (ou fechada), as perguntas são definidas antecipadamente e seguidas em ordem, o que facilita comparar respostas de vários stakeholders. Na não estruturada, a conversa é livre e sem roteiro fixo, útil no primeiro contato para mapear o contexto antes de aprofundar com perguntas fechadas.
Existe um modelo de perguntas prontas para levantar requisitos com o cliente?
Sim: um roteiro eficaz cobre quatro blocos — perfil e responsabilidades do entrevistado, como o processo funciona hoje, qual a dor e como o sucesso é medido, e requisitos não funcionais como segurança e integrações. Esse roteiro pode ser levado por escrito e adaptado durante a conversa.
Quantas pessoas devem participar de uma entrevista de levantamento de requisitos?
O formato mais comum é um analista entrevistando um interessado por vez, o que evita que uma opinião domine a conversa e facilita o registro fiel das respostas. Quando o processo envolve várias áreas, o ideal é repetir a entrevista com cada perfil em vez de juntar todos numa única reunião.
O que fazer quando o stakeholder não sabe explicar o que precisa?
Nesses casos, troque perguntas abertas por perguntas concretas sobre o dia a dia, como 'como você resolve esse problema hoje?' e 'o que acontece quando isso dá errado?'. Pedir exemplos reais e recentes costuma destravar respostas mais úteis do que perguntar diretamente 'quais são seus requisitos'.
Com o roteiro em mãos, o próximo passo é levar essas respostas para um formato que a equipe técnica consiga usar sem retrabalho — e é exatamente essa ponte entre a conversa com o cliente e o documento final que o espacoia.com.br automatiza, transformando entrevistas em requisitos estruturados prontos para o time de desenvolvimento.