Coletar os Requisitos — PMBOK 8: Guia Completo (2026)

Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.

Cadastre-se para navegar sem anúncios e participar do Project Together →

Elicitar e Analisar Requisitos: O Processo que Transforma Necessidades Vagas em Especificações Concretas (PMBOK 8)

Anteriormente: Coletar os Requisitos (PMBOK 6)

Imagine este cenário: o gerente de projeto recebe a aprovação para iniciar o projeto e, na primeira reunião, pede aos stakeholders que “mandem os requisitos por e-mail”. Três semanas depois, chegaram 47 e-mails com pedidos vagos, contraditórios e sem prioridade. O diretor comercial quer “um sistema rápido”. O diretor financeiro quer “relatórios completos”. O usuário final quer “algo fácil de usar”. Ninguém definiu o que “rápido”, “completo” ou “fácil” significa em termos mensuráveis. A equipe começa a desenvolver com base em interpretações pessoais, e quando a primeira entrega é apresentada, todos dizem a mesma coisa: “Não era isso que eu queria.” Esse cenário é o resultado previsível de coletar requisitos sem método.

No PMBOK 8, o processo Elicitar e Analisar Requisitos é o Processo 11, o segundo do Domínio de Escopo (código 2.2.2.2). A mudança de nome em relação ao PMBOK 6 (“Coletar os Requisitos”) não é cosmética — reflete uma mudança de abordagem: não basta coletar passivamente o que os stakeholders pedem; é preciso elicitar ativamente (extrair, provocar, explorar) e analisar criticamente (avaliar consistência, viabilidade, prioridade e rastreabilidade) antes de aceitar qualquer requisito como válido.

Neste guia completo você vai encontrar:

• O que é o processo Elicitar e Analisar Requisitos e onde ele se encaixa no PMBOK 8
• Por que usá-lo — e o que acontece quando você não usa
• ITTO completo — Entradas, Ferramentas/Técnicas e Saídas em tabela detalhada
• Passo a passo prático para aplicar o processo do zero
• Quando aplicar — cenários e gatilhos que indicam que é hora de elicitar requisitos
• Exemplos práticos — Projeto Horizonte (Horizonte Transportes) e Projeto ProjectAdm (Desenvolvimento de Software SaaS)
• Atalhos, templates e dicas para acelerar a elicitação
• 5 erros comuns — e como evitá-los
• Tailoring para contextos Preditivo, Ágil e Híbrido
• Interações com outros processos e domínios
• Checklist de aplicação rápida com 7 itens para usar hoje

1. O que é o Processo Elicitar e Analisar Requisitos

Elicitar e Analisar Requisitos é o processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas para atender aos objetivos do projeto. Ele vai além da simples coleta passiva: envolve técnicas ativas de extração de informação, análise crítica de consistência e viabilidade, priorização e documentação estruturada.

No PMBOK 8, este é o Processo 11, segundo do Domínio de Escopo. O nome foi atualizado de “Coletar os Requisitos” (PMBOK 6) para “Elicitar e Analisar Requisitos” para enfatizar duas dimensões igualmente importantes:

• Elicitar: Extrair ativamente os requisitos dos stakeholders, usando técnicas que vão além de simplesmente perguntar “o que você quer?” — inclui observar comportamentos, analisar processos existentes, prototipar soluções e facilitar sessões colaborativas.
• Analisar: Avaliar criticamente cada requisito quanto a sua clareza, consistência, viabilidade técnica, alinhamento com os objetivos do projeto, interdependências e prioridade relativa.

O processo produz duas saídas fundamentais:

• Documentação dos Requisitos (Requirements Documentation) — documento que descreve como requisitos individuais atendem às necessidades de negócio do projeto. Os requisitos podem ser de alto nível (no início) e progressivamente detalhados. Incluem requisitos funcionais, não funcionais, de negócio, de stakeholders, de solução, de transição e de projeto.
• Matriz de Rastreabilidade dos Requisitos (Requirements Traceability Matrix) — tabela que liga os requisitos desde a sua origem até as entregas que os satisfazem. Fornece um meio de rastrear requisitos ao longo do ciclo de vida do projeto, garantindo que cada requisito tenha uma origem identificada, uma entrega associada e um critério de validação.

Diferença entre Elicitar e Analisar

Aspecto	Elicitar	Analisar
Objetivo	Extrair e capturar necessidades dos stakeholders	Avaliar qualidade, consistência e viabilidade dos requisitos
Técnicas	Entrevistas, brainstorming, questionários, observação, prototipagem	Análise de conflitos, priorização, validação cruzada, decomposição
Resultado	Lista bruta de requisitos capturados	Requisitos refinados, priorizados e validados
Stakeholders envolvidos	Fontes de requisitos (usuários, clientes, reguladores)	Equipe do projeto, analistas de negócio, especialistas técnicos
Momento	Quando informações precisam ser capturadas	Após a captura, antes da aprovação

Na prática, elicitação e análise são iterativas — não sequenciais. Enquanto se elicita, já se analisa. E a análise frequentemente revela gaps que exigem nova elicitação.

2. Por que Usar o Processo Elicitar e Analisar Requisitos

Requisitos são a fundação do escopo. Se os requisitos forem ambíguos, contraditórios, incompletos ou não priorizados, o escopo será construído sobre areia movediça — e todo o projeto sofrerá as consequências.

Benefícios diretos

• Clareza sobre o que deve ser entregue: Requisitos bem elicitados e analisados eliminam ambiguidade. Em vez de “o sistema deve ser rápido”, o requisito documenta “o tempo de resposta para consultas de relatório deve ser inferior a 3 segundos para 95% das requisições”.
• Alinhamento entre stakeholders: O processo de elicitação envolve múltiplos stakeholders, revelando expectativas divergentes antes que se tornem conflitos durante a execução. Quando o diretor comercial e o diretor financeiro querem coisas diferentes, é melhor descobrir isso durante a elicitação do que durante a entrega.
• Base para validação objetiva: A documentação dos requisitos com critérios de aceitação fornece a base objetiva para validar as entregas. Não há discussão subjetiva sobre “qualidade” quando os critérios estão escritos e aprovados.
• Rastreabilidade completa: A matriz de rastreabilidade conecta cada requisito à sua origem, à entrega que o implementa e ao teste que o valida. Se um requisito for questionado, alterado ou removido, o impacto é rastreável.
• Priorização racional: A análise de requisitos inclui priorização baseada em critérios objetivos (valor de negócio, risco, custo, dependência), evitando que a “voz mais alta” defina prioridades.
• Prevenção de scope creep: Requisitos documentados e priorizados formam a referência contra a qual novas solicitações são avaliadas. Se um novo pedido entra, ele é comparado com os requisitos aprovados e tratado pelo processo de mudança.

O que acontece quando o processo é ignorado

• Requisitos fantasma: Stakeholders assumem que certos requisitos “são óbvios” e não os documentam. A equipe descobre esses requisitos implícitos quando a entrega é rejeitada.
• Gold plating: Sem requisitos claros, a equipe adiciona funcionalidades que ninguém pediu, consumindo tempo e orçamento em entregas de valor questionável.
• Requisitos conflitantes não resolvidos: Diferentes stakeholders pedem coisas contraditórias, e ninguém percebe até a implementação revelar a incompatibilidade.
• Retrabalho massivo: Estudos do Standish Group indicam que erros de requisitos são responsáveis por 40-60% do retrabalho em projetos de software. Corrigir um requisito durante a execução custa 10 a 100 vezes mais do que corrigi-lo durante a elicitação.
• Validação impossível: Sem critérios de aceitação documentados, a validação se torna subjetiva. O cliente pode rejeitar entregas perfeitas porque sua expectativa (não documentada) era diferente.

O princípio “Incorpore Qualidade” do PMBOK 8 é aplicável diretamente aqui: a qualidade do projeto começa na qualidade dos requisitos. Requisitos mal elicitados geram entregas mal definidas que geram retrabalho e insatisfação.

3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)

A tabela abaixo apresenta o ITTO completo do processo Elicitar e Analisar Requisitos, conforme o PMBOK 8:

Entradas	Ferramentas e Técnicas	Saídas
Termo de abertura do projeto Plano de gerenciamento do projeto (plano de gerenciamento do escopo, plano de gerenciamento dos requisitos, plano de engajamento das partes interessadas) Documentos do projeto (registro das premissas, lições aprendidas, registro das partes interessadas) Acordos Fatores ambientais da empresa (FAE) Ativos de processos organizacionais (APO)	Opinião especializada Coleta de dados (brainstorming, entrevistas, grupos focais, questionários e pesquisas, benchmarking) Análise de dados (análise de documentos) Tomada de decisão (votação, análise de decisão por multicritérios) Representação de dados (diagramas de afinidade, mapa mental) Habilidades interpessoais e de equipe (técnica de grupo nominal, observação, facilitação) Diagramas de contexto Protótipos	Documentação dos requisitos Matriz de rastreabilidade dos requisitos

Detalhamento das Entradas

Termo de abertura do projeto: Fornece os objetivos de alto nível, as entregas principais, as premissas e restrições que direcionam a elicitação de requisitos. Os requisitos devem estar alinhados com o propósito e os objetivos documentados no Termo.

Plano de gerenciamento do projeto: O plano de gerenciamento do escopo define como os requisitos serão documentados e controlados. O plano de gerenciamento dos requisitos define as técnicas de elicitação, categorias, critérios de priorização e rastreabilidade. O plano de engajamento das partes interessadas indica como acessar os stakeholders para a elicitação.

Documentos do projeto: O registro das premissas identifica suposições que podem gerar requisitos. As lições aprendidas de projetos anteriores indicam técnicas que funcionaram (ou falharam). O registro das partes interessadas identifica quem deve ser consultado como fonte de requisitos.

Acordos: Contratos e acordos podem conter requisitos explícitos (cláusulas contratuais) ou implícitos (padrões de qualidade esperados). São fontes importantes de requisitos regulatórios e de conformidade.

Fatores ambientais da empresa (FAE): Cultura organizacional, padrões do setor, regulamentações, infraestrutura disponível e condições de mercado que influenciam os requisitos.

Ativos de processos organizacionais (APO): Templates de documentação de requisitos, repositórios de requisitos de projetos anteriores, políticas de qualidade e padrões de documentação.

Detalhamento das Ferramentas e Técnicas

Opinião especializada: Consulta a especialistas em análise de negócios, no domínio do projeto, em técnicas de elicitação e em regulamentação aplicável. Especialistas ajudam a identificar requisitos implícitos que os stakeholders não conseguem articular.

Coleta de dados:

• Brainstorming: Sessão de geração de ideias com stakeholders para identificar requisitos de forma criativa e colaborativa. Eficaz para gerar volume de requisitos rapidamente.
• Entrevistas: Conversas estruturadas ou semiestruturadas com stakeholders individuais. Eficazes para requisitos sensíveis, contexto político ou quando stakeholders têm visões muito diferentes.
• Grupos focais: Reunião com stakeholders do mesmo perfil para discutir requisitos em grupo. Eficazes para captar perspectivas de usuários com experiências semelhantes.
• Questionários e pesquisas: Instrumentos escritos para coletar requisitos de um grande número de stakeholders. Eficazes quando os stakeholders estão dispersos geograficamente.
• Benchmarking: Comparação com projetos ou produtos similares para identificar requisitos que podem ter sido esquecidos ou que representam boas práticas do setor.

Análise de dados: A análise de documentos examina documentação existente (processos atuais, manuais, relatórios, contratos) para extrair requisitos implícitos que não seriam capturados apenas por entrevistas.

Tomada de decisão: Votação (para priorizar requisitos em grupo) e análise de decisão por multicritérios (para avaliar requisitos conflitantes com base em critérios ponderados como valor, custo, risco e complexidade).

Representação de dados: Diagramas de afinidade agrupam requisitos em categorias lógicas. Mapas mentais organizam visualmente as relações entre requisitos, facilitando a identificação de gaps e redundâncias.

Habilidades interpessoais e de equipe: Técnica de grupo nominal (priorização individual seguida de consolidação), observação (job shadowing para captar requisitos que os usuários não conseguem verbalizar) e facilitação (condução de workshops produtivos).

Diagramas de contexto: Representação visual que mostra os limites do sistema ou produto, as entidades externas que interagem com ele e os fluxos de dados entre eles. Eficaz para definir o que está dentro e fora do escopo.

Protótipos: Versões iniciais do produto (mockups, wireframes, protótipos funcionais) que permitem aos stakeholders visualizar e interagir com uma representação da solução antes que ela seja construída. Extremamente eficazes para validar requisitos de interface e usabilidade.

Detalhamento das Saídas

Documentação dos Requisitos: Documento que descreve como os requisitos atendem às necessidades de negócio do projeto. Deve incluir: requisitos de negócio (objetivos organizacionais), requisitos das partes interessadas (necessidades dos stakeholders), requisitos de solução (funcionais e não funcionais), requisitos de transição (migração, treinamento), requisitos de projeto (níveis de serviço, conformidade) e requisitos de qualidade (critérios de aceitação). Cada requisito deve ser único, rastreável, completo, consistente, inequívoco e testável.

Matriz de Rastreabilidade dos Requisitos: Tabela que conecta cada requisito a: sua origem (quem pediu e por quê), o objetivo de negócio que atende, a entrega da EAP que o implementa, o componente do produto que o satisfaz e o teste que o valida. A matriz garante que nenhum requisito se perca durante o projeto e que nenhuma entrega exista sem um requisito que a justifique.

4. Como Aplicar o Processo Passo a Passo

O passo a passo abaixo pode ser adaptado conforme a complexidade do projeto, mas a sequência lógica se aplica a qualquer contexto:

Passo 1 — Identifique as fontes de requisitos

Com base no registro de partes interessadas e no Termo de Abertura, mapeie todas as fontes de requisitos:

• Stakeholders-chave (patrocinador, cliente, usuários finais, gerentes de área)
• Documentos existentes (processos atuais, contratos, regulamentações, manuais)
• Sistemas atuais (funcionalidades existentes que devem ser mantidas ou melhoradas)
• Projetos anteriores (lições aprendidas, requisitos recorrentes)
• Padrões do setor (benchmarks, melhores práticas, normas técnicas)

Dica prática: Nem toda fonte de requisito tem o mesmo peso. Classifique as fontes por autoridade (quem pode definir requisitos obrigatórios) e por conhecimento (quem entende melhor as necessidades reais). O patrocinador pode ter autoridade, mas o usuário final tem o conhecimento do dia a dia.

Passo 2 — Selecione as técnicas de elicitação adequadas

Com base no plano de gerenciamento dos requisitos, selecione as técnicas mais adequadas para cada fonte:

Situação	Técnica recomendada
Stakeholders executivos com pouco tempo	Entrevistas individuais (30-45 min)
Grupos de usuários com experiência similar	Workshops / grupos focais
Grande número de stakeholders dispersos	Questionários e pesquisas
Requisitos de interface e usabilidade	Protótipos e mockups
Processos complexos existentes	Observação + análise de documentos
Inovação e geração de ideias	Brainstorming
Priorização de muitos requisitos	Técnica de grupo nominal + votação

Passo 3 — Conduza as sessões de elicitação

Para cada técnica selecionada:

• Prepare a pauta e os materiais com antecedência
• Envie contexto prévio aos participantes (objetivos do projeto, escopo de alto nível)
• Registre todos os requisitos capturados em tempo real (usar um escriba dedicado)
• Valide com os participantes antes de encerrar (“Entendi corretamente que…”)
• Registre a origem de cada requisito (quem pediu e por quê)

Dica prática: Nunca conduza uma sessão de elicitação sem objetivo claro. Defina antes: “Nesta sessão vamos levantar os requisitos de [área/módulo/processo específico].” Sessões genéricas de “levantamento de requisitos” produzem listas genéricas e desconexas.

Passo 4 — Analise os requisitos coletados

Após a elicitação, analise criticamente cada requisito:

• Clareza: O requisito é inequívoco? Qualquer pessoa da equipe interpretaria da mesma forma?
• Completude: O requisito tem informação suficiente para ser implementado e testado?
• Consistência: O requisito entra em conflito com outros requisitos já documentados?
• Viabilidade: O requisito é tecnicamente realizável dentro das restrições do projeto (prazo, orçamento, tecnologia)?
• Testabilidade: É possível criar um teste que verifique se o requisito foi atendido?
• Rastreabilidade: O requisito tem uma origem identificada e um objetivo de negócio associado?

Passo 5 — Resolva conflitos e priorize

Quando requisitos entram em conflito:

1. Identifique a natureza do conflito (técnico, de negócio, de prioridade, de recurso)
2. Reúna os stakeholders envolvidos para discutir
3. Aplique critérios de priorização definidos no plano de gerenciamento dos requisitos (MoSCoW, WSJF, valor vs. esforço)
4. Documente a decisão, a justificativa e os stakeholders que participaram
5. Comunique o resultado a todas as partes afetadas

Passo 6 — Documente formalmente

Registre cada requisito aprovado na documentação de requisitos com:

• ID único
• Descrição clara e inequívoca
• Categoria (funcional, não funcional, de negócio, de transição)
• Origem (stakeholder, documento, regulamentação)
• Prioridade (com critério usado)
• Critério de aceitação (como saber que foi atendido)
• Status (proposto, aprovado, implementado, validado)
• Responsável pela validação

Passo 7 — Construa a Matriz de Rastreabilidade

Para cada requisito documentado, preencha a matriz com:

• Requisito → Objetivo de negócio (por que este requisito existe)
• Requisito → Entrega da EAP (o que vai implementar este requisito)
• Requisito → Caso de teste (como será verificado)
• Requisito → Status de validação (aguardando, validado, rejeitado)

Dica prática: A matriz de rastreabilidade é um documento vivo. Atualize-a a cada mudança de requisito, cada nova entrega e cada validação. Uma matriz desatualizada é pior que não ter matriz — gera falsa sensação de controle.

Passo 8 — Valide com os stakeholders

Antes de considerar a elicitação concluída, apresente a documentação de requisitos e a matriz de rastreabilidade aos stakeholders-chave para validação. Pergunte:

• “Todos os seus requisitos estão contemplados?”
• “As prioridades refletem sua visão de negócio?”
• “Os critérios de aceitação são realistas e verificáveis?”
• “Existe algum requisito faltando que você lembrou depois das sessões?”

5. Quando Aplicar o Processo

Cenários obrigatórios

• Após o planejamento do gerenciamento do escopo: Sempre. A elicitação segue o planejamento — nunca o contrário. As regras para coletar, priorizar e documentar requisitos devem existir antes de começar a elicitar.
• Antes de definir o escopo detalhado ou construir a EAP: Os requisitos são a base para a declaração de escopo e para a decomposição em pacotes de trabalho.
• Ao iniciar uma nova fase ou release: Se o projeto é dividido em fases, cada fase pode ter requisitos específicos que precisam ser elicitados.

Cenários recomendados

• Quando stakeholders mudam: Novos stakeholders trazem novos requisitos. Se o patrocinador muda, se um novo departamento é incluído no escopo ou se um parceiro externo entra no projeto, é prudente conduzir nova elicitação.
• Quando o contexto de negócio muda: Mudanças regulatórias, de mercado ou estratégicas podem invalidar requisitos existentes e gerar novos.
• Quando entregas são rejeitadas na validação: Se entregas estão sendo sistematicamente rejeitadas, a causa provavelmente está em requisitos ambíguos ou incompletos — revisitar a elicitação é a ação corretiva.

Gatilhos que indicam que a elicitação é necessária

• Stakeholders fazem solicitações que contradizem requisitos documentados
• A equipe não consegue definir critérios de aceitação para uma entrega
• Surgem requisitos “óbvios” que ninguém havia documentado
• O escopo está crescendo sem que ninguém consiga explicar a origem das novas demandas
• Diferentes membros da equipe interpretam o mesmo requisito de formas diferentes
• A matriz de rastreabilidade tem requisitos sem entrega associada ou entregas sem requisito justificador

6. Exemplos Práticos por Setor

Exemplo 1 — Implantação do PMO: Projeto Horizonte

Contexto: A Horizonte Transportes (280 funcionários, Campinas-SP) está implantando o PMO (Projeto Horizonte, R$ 320.000, 6 meses). Ana Silveira (GP) precisa elicitar e analisar os requisitos de todas as partes interessadas — desde a diretoria até os gerentes operacionais que vão usar o PMO diariamente.

Como o processo foi aplicado:

1. Mapeamento de fontes: Ana identificou 4 categorias de fontes: (a) Estratégica: Roberto Campos (CEO) e Fernanda Lopes (Gerente Financeira), (b) Operacional: Marcos Tanaka (Gerente de Operações) e 3 coordenadores de logística, (c) Técnica: Diego Carvalho (Analista Sênior) e Carolina Mendes (Consultora ProjectAdm), (d) Documental: processos atuais de gestão de projetos (informais), relatórios de falhas de entrega, contratos com clientes que exigiam SLAs.
2. Elicitação por técnica:
   • Entrevistas individuais com Roberto Campos (requisitos estratégicos: visibilidade de portfólio, indicadores de ROI, capacidade de priorização de projetos) e Fernanda Lopes (requisitos financeiros: controle de orçamento por projeto, relatórios de custos reais vs. planejados, integração com o ERP financeiro).
   • Workshop de 3 horas com Marcos Tanaka e os 3 coordenadores de logística (requisitos operacionais: metodologia simples de gestão de projetos, templates padronizados, processo de aprovação de projetos com menos de 3 etapas).
   • Sessão de prototipagem com Diego Carvalho e Carolina Mendes para requisitos técnicos do ProjectAdm (dashboards, campos customizados, relatórios automatizados, integração com calendário e e-mail).
   • Análise de documentos: 12 relatórios de falhas de entrega dos últimos 2 anos, 3 contratos com SLAs explícitos, e o organograma atual.
3. Análise e resolução de conflitos: O workshop revelou um conflito: Roberto Campos queria relatórios detalhados por projeto (12 indicadores), enquanto Marcos Tanaka queria no máximo 3 indicadores “que caibam em uma tela de celular”. Ana conduziu uma sessão de priorização usando MoSCoW: 5 indicadores foram classificados como Must Have (incluindo os 3 de Marcos), 4 como Should Have e 3 como Could Have. Roberto aceitou a priorização ao entender que os indicadores detalhados estariam disponíveis em drill-down, não no dashboard principal.
4. Documentação: 47 requisitos documentados, categorizados em: estratégicos (8), operacionais (15), técnicos (12), regulatórios (4), de treinamento (5) e de transição (3). Cada requisito com ID, origem, prioridade MoSCoW e critério de aceitação.
5. Matriz de rastreabilidade: Cada requisito foi vinculado ao objetivo de negócio do Termo de Abertura, à entrega correspondente e ao critério de validação. Ana usou uma planilha no ProjectAdm para manter a rastreabilidade viva.

Resultado: Quando a equipe chegou à fase de configuração do ProjectAdm, todos os requisitos técnicos já tinham critérios de aceitação claros. Diego Carvalho configurou os dashboards com base nos 5 indicadores Must Have, e a primeira demonstração para Roberto Campos e Marcos Tanaka foi aprovada sem ajustes significativos — porque os requisitos já refletiam as necessidades reais de ambos.

Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm

Contexto: A equipe ProjectAdm (5 profissionais, R$ 120.000, 12 meses) está desenvolvendo uma plataforma SaaS. Eduardo Montes (GP) e Henry Douglas (LT/PO) precisam elicitar requisitos de múltiplas fontes: usuários-alvo do software, equipe técnica, especialistas em PMBOK e potenciais clientes corporativos.

Como o processo foi aplicado:

1. Identificação de fontes: Eduardo e Henry mapearam: (a) Usuários-alvo: gerentes de projeto de PMEs que usariam a plataforma, (b) Equipe técnica: desenvolvedores que implementariam os requisitos, (c) Especialistas: Eduardo Montes como especialista em PMBOK 8 (requisitos de aderência aos 40 processos), (d) Mercado: análise de 5 plataformas concorrentes (Asana, Monday, ClickUp, MS Project Online, Wrike).
2. Elicitação por técnica:
   • Entrevistas com 8 gerentes de projeto (potenciais clientes) para captar requisitos de usabilidade, funcionalidades essenciais e frustrações com ferramentas atuais.
   • Benchmarking das 5 plataformas concorrentes: mapeamento de funcionalidades, gaps e oportunidades de diferenciação.
   • Workshop interno com a equipe técnica para requisitos não funcionais (performance, segurança, escalabilidade, disponibilidade).
   • Prototipagem: Henry criou wireframes de 3 módulos-chave (dashboard, cronograma, relatórios) e validou com 4 dos 8 gerentes entrevistados.
   • Análise de documentos: PMBOK 8 (referência oficial) para mapear os 40 processos que a plataforma deveria suportar com templates integrados.
3. Análise: A análise revelou 3 conflitos principais: (a) Usuários queriam interface “minimalista”, mas também queriam “todas as funcionalidades do MS Project” — conflito resolvido com abordagem de progressive disclosure (funcionalidades avançadas escondidas por padrão, acessíveis por configuração), (b) Requisito de performance (<2 segundos para qualquer tela) vs. requisitos de relatórios complexos (que exigem processamento pesado) — resolvido com processamento assíncrono e cache, (c) Suporte a templates PMBOK 8 (40 processos × templates) vs. prazo de 12 meses — resolvido com priorização: 15 templates na v1.0, restantes na v1.5.
4. Documentação como user stories: 124 user stories documentadas no formato “Como [persona], quero [funcionalidade] para [benefício]”. Cada story com critérios de aceitação, prioridade WSJF, épico associado e estimativa em story points.
5. Matriz de rastreabilidade: Implementada no Jira com links entre: story → épico → objetivo de negócio → release planejada → testes automatizados.

Resultado: Na sprint review 3, quando um potencial cliente pediu “integração com SAP” (requisito não previsto), Henry consultou a documentação de requisitos e a priorização WSJF: o item foi adicionado ao backlog com prioridade Should Have para a release 2.0, sem impactar a release 1.0. A decisão foi objetiva, baseada em critérios documentados — não em pressão de vendas.

7. Atalhos, Templates e Dicas

Templates recomendados

• Template de Documentação de Requisitos: Documento com seções: requisitos de negócio, requisitos de stakeholders, requisitos funcionais, requisitos não funcionais, requisitos de transição. Cada requisito com ID, descrição, origem, prioridade, critério de aceitação e status.
• Template de Matriz de Rastreabilidade: Planilha com colunas: ID, descrição, origem, objetivo de negócio, entrega EAP, caso de teste, status. Pode ser Excel, Google Sheets ou ferramenta integrada.
• Template de Roteiro de Entrevista: Guia com perguntas abertas (“Quais são os 3 maiores problemas do processo atual?”), perguntas fechadas (“O relatório deve ser gerado em menos de 5 segundos?”) e espaço para anotações e follow-up.
• Template de User Story: Cartão com: título, “Como [persona], quero [funcionalidade] para [benefício]”, critérios de aceitação (dado que… quando… então…), prioridade, estimativa e dependências.

Ferramentas digitais

• Miro / Mural: Para workshops de elicitação e diagramas de afinidade
• Figma / Balsamiq: Para protótipos e wireframes
• Jira / Azure DevOps: Para documentar e rastrear user stories
• Google Forms / Typeform: Para questionários e pesquisas
• Lucidchart / Draw.io: Para diagramas de contexto
• Excel / Google Sheets: Para a matriz de rastreabilidade em projetos menores

Dicas avançadas

• Combine pelo menos 3 técnicas de elicitação: Nenhuma técnica isolada captura todos os requisitos. Entrevistas captam contexto político e estratégico. Observação capta requisitos que os usuários não conseguem verbalizar. Protótipos validam requisitos de interface. Use a combinação que cobre seus gaps.
• Elicite requisitos negativos: Pergunte “O que o sistema NÃO deve fazer?” e “O que estaria fora do escopo?” Requisitos negativos são tão importantes quanto positivos para evitar scope creep.
• Valide requisitos com exemplos concretos: Em vez de aceitar “o sistema deve ser rápido”, peça: “Pode me dar um exemplo de operação que precisa ser rápida e o que ‘rápido’ significa para você?” Exemplos concretos transformam requisitos vagos em especificações testáveis.
• Use a regra INVEST para user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable. Se a user story não atende esses critérios, precisa ser refinada.
• Documente as decisões, não só os requisitos: Quando um requisito é rejeitado, adiado ou modificado, documente o porquê. Essa informação é valiosa quando o mesmo requisito ressurge meses depois.

8. Erros Comuns e Como Evitá-los

Erro 1 — Aceitar requisitos vagos sem detalhar

Por que acontece: O stakeholder diz “o sistema precisa ser fácil de usar” e o analista registra essa frase como requisito. O problema é que “fácil de usar” não é testável, não é mensurável e cada pessoa interpreta de forma diferente.

Como evitar: Aplique a regra: todo requisito deve ser testável. Se não é possível criar um teste que verifique se o requisito foi atendido, ele não está detalhado o suficiente. “Fácil de usar” se torna: “Um novo usuário deve ser capaz de criar um projeto completo em menos de 10 minutos sem consultar o manual.”

Erro 2 — Elicitar apenas com uma técnica

Por que acontece: A equipe usa apenas entrevistas (porque é a técnica mais conhecida) e assume que capturou todos os requisitos. O problema é que entrevistas captam o que os stakeholders conseguem verbalizar — mas muitos requisitos estão em processos que as pessoas fazem automaticamente e não conseguem descrever.

Como evitar: Use pelo menos 3 técnicas complementares. Entrevistas + observação + análise de documentos é uma combinação eficaz para a maioria dos projetos. Para projetos de software, adicione prototipagem. Para projetos com muitos stakeholders, adicione questionários.

Erro 3 — Não priorizar requisitos

Por que acontece: A equipe documenta 80 requisitos e trata todos como iguais. Quando o prazo ou orçamento aperta, não há critério para decidir o que cortar. A decisão acaba sendo política ou emocional.

Como evitar: Priorize usando um framework explícito: MoSCoW (Must/Should/Could/Won’t), WSJF (Weighted Shortest Job First), ou valor vs. esforço. Documente a prioridade de cada requisito e o critério utilizado. Quando for necessário cortar escopo, a decisão já está objetivamente fundamentada.

Erro 4 — Construir a matriz de rastreabilidade depois, não durante

Por que acontece: A equipe elicita e documenta todos os requisitos primeiro, e depois tenta montar a matriz de rastreabilidade retroativamente. O problema é que, retroativamente, muitas conexões se perdem — origens são esquecidas, justificativas são perdidas e a matriz fica incompleta.

Como evitar: Construa a matriz ao mesmo tempo que documenta os requisitos. Cada novo requisito registrado deve ter, imediatamente, sua origem e seu objetivo de negócio vinculados. As colunas de entrega e teste serão preenchidas posteriormente, mas a origem e o propósito devem ser registrados no momento da elicitação.

Erro 5 — Ignorar requisitos não funcionais

Por que acontece: Stakeholders naturalmente falam de funcionalidades (“quero um relatório de vendas”) e raramente mencionam requisitos não funcionais (performance, segurança, escalabilidade, disponibilidade). A equipe foca no que é pedido e ignora o que é assumido.

Como evitar: Inclua requisitos não funcionais como categoria obrigatória na documentação. Para cada módulo ou funcionalidade, pergunte explicitamente: “Qual é o tempo de resposta aceitável? Quantos usuários simultâneos? Qual é o nível de segurança necessário? Qual é a disponibilidade esperada (99%? 99,9%)? Existem regulamentações que afetam esse módulo?”

9. Tailoring: Preditivo, Ágil e Híbrido

Ambiente Preditivo (Waterfall)

• Elicitação: Intensiva e upfront. Todas as técnicas aplicadas nas fases iniciais do projeto. Objetivo: capturar o máximo de requisitos antes de iniciar o design e a execução.
• Documentação: Formal, detalhada, com especificação completa de cada requisito. Requisitos categorizados, numerados e com critérios de aceitação explícitos.
• Matriz de rastreabilidade: Completa, com rastreabilidade bidirecional (requisito → entrega e entrega → requisito).
• Aprovação: Formal, com sign-off dos stakeholders antes de prosseguir para design/execução.

Quando usar: Escopo bem definido, requisitos estáveis, contratos de preço fixo, regulamentação pesada.

Ambiente Ágil

• Elicitação: Contínua e iterativa. Requisitos capturados como user stories e refinados a cada sprint. Discovery inicial seguida de elicitação incremental.
• Documentação: User stories com critérios de aceitação. Menos formalidade, mais conversação. O “cartão é um lembrete para uma conversa” (Ron Jeffries).
• Matriz de rastreabilidade: Gerenciada pela ferramenta (Jira, Azure DevOps) com links automáticos entre story, épico e objetivo. Menos formal, mais dinâmica.
• Aprovação: Product Owner aprova stories como “ready” para sprint. Validação na sprint review.

Quando usar: Requisitos emergentes, alta incerteza, feedback contínuo de usuários.

Ambiente Híbrido

• Elicitação: Requisitos de alto nível elicitados upfront (preditivo). Requisitos detalhados elicitados iterativamente (ágil). Dois “ciclos” de elicitação coexistem.
• Documentação: Requisitos estratégicos e regulatórios documentados formalmente. Requisitos funcionais e técnicos como user stories com critérios de aceitação.
• Matriz de rastreabilidade: Dois níveis: formal para requisitos de alto nível, integrada à ferramenta para requisitos de sprint.
• Aprovação: Formal para baseline de requisitos de alto nível. Iterativa pelo Product Owner para stories de sprint.

Quando usar: Projetos com requisitos parcialmente definidos e parcialmente emergentes.

Resumo comparativo do Tailoring

Aspecto	Preditivo	Ágil	Híbrido
Elicitação	Upfront e intensiva	Contínua e iterativa	Alto nível upfront + detalhe iterativo
Documentação	Formal e completa	User stories + conversas	Formal (alto nível) + stories (detalhe)
Rastreabilidade	Bidirecional completa	Via ferramenta (links automáticos)	Dois níveis
Priorização	MoSCoW ou análise multicritérios	WSJF ou valor vs. esforço	Multicritérios (alto nível) + WSJF (sprint)
Aprovação	Sign-off formal	PO aprova como “ready”	Formal + iterativa

10. Interações com Outros Processos e Domínios

Processos que alimentam este processo (dependências de entrada)

Processo de origem	Domínio	O que fornece
Iniciar Projeto ou Fase	Governança	Termo de Abertura com objetivos e requisitos de alto nível
Planejar o Gerenciamento do Escopo	Escopo	Plano de Gerenciamento dos Requisitos (técnicas, critérios, formato)
Identificar Partes Interessadas	Partes Interessadas	Registro das partes interessadas (fontes de requisitos)
Integrar e Alinhar os Planos	Governança	Plano de gerenciamento do projeto (abordagem de desenvolvimento)

Processos que dependem deste processo (dependências de saída)

Processo que recebe a saída	Domínio	O que recebe
Definir o Escopo	Escopo	Documentação dos Requisitos para elaborar a Declaração do Escopo
Desenvolver a Estrutura do Escopo (Desenvolver a Estrutura do Escopo)	Escopo	Requisitos que serão decompostos em pacotes de trabalho
Validar o Escopo	Escopo	Critérios de aceitação dos requisitos para validação de entregas
Monitorar e Controlar o Escopo	Escopo	Matriz de Rastreabilidade como referência para controle de mudanças
Identificar Riscos	Riscos	Requisitos com alta incerteza ou conflito como fontes de risco
Planejar o Gerenciamento dos Custos	Finanças	Requisitos que determinam o esforço e, consequentemente, o custo

Interações com os Domínios do PMBOK 8

Governança: Os requisitos aprovados se integram ao plano geral do projeto. Mudanças nos requisitos ativam o controle integrado de mudanças.

Cronograma: Os requisitos determinam o trabalho a ser realizado, que é a base para definir e sequenciar atividades. Requisitos mais complexos exigem mais tempo.

Finanças: Cada requisito tem um custo de implementação. A priorização de requisitos é essencialmente uma decisão de alocação de orçamento.

Riscos: Requisitos ambíguos, incompletos ou conflitantes são fontes diretas de risco. A análise de requisitos identifica riscos que devem ser registrados no registro de riscos.

Recursos: Requisitos técnicos determinam as competências necessárias na equipe. Requisitos com tecnologias novas podem exigir contratação ou treinamento.

Partes Interessadas: A elicitação de requisitos é uma das formas mais diretas de engajamento de stakeholders. A qualidade da elicitação depende diretamente do nível de engajamento das partes interessadas.

11. Checklist de Aplicação Rápida

Use estes 7 itens como referência rápida antes de considerar a elicitação e análise de requisitos concluída:

1. Todas as fontes de requisitos foram identificadas e consultadas (stakeholders-chave, documentos, sistemas existentes, regulamentações)?
2. Pelo menos 3 técnicas de elicitação foram utilizadas para capturar diferentes perspectivas (entrevistas, workshops, protótipos, análise de documentos, observação)?
3. Cada requisito documentado é claro, completo, consistente, viável e testável?
4. Os requisitos foram priorizados usando um critério explícito e documentado (MoSCoW, WSJF, valor vs. esforço)?
5. A Matriz de Rastreabilidade dos Requisitos foi construída com origem, objetivo de negócio e critério de aceitação para cada requisito?
6. Conflitos entre requisitos foram identificados, discutidos com os stakeholders afetados e resolvidos com decisão documentada?
7. Os stakeholders-chave validaram a documentação de requisitos e confirmaram que suas necessidades estão contempladas?

Regra prática: Se menos de 5 destes itens foram atendidos, a elicitação não está completa. Requisitos mal elicitados geram escopo mal definido, que gera entregas rejeitadas, que gera retrabalho — o ciclo mais caro do gerenciamento de projetos.

12. Faça agora com IA: o Processo 4 do PMBOK 8 Together

O PMBOK 8 Together é o curso gratuito que executa este processo no seu projeto: você responde no seu quadro, roda o processo e ele escreve o documento — preenchido, no modelo pronto. É o Processo 4 de 40.

O que este processo lê do seu quadro

• as respostas do 5W2H (o Termo de Abertura)
• a árvore do escopo (EAP ou Product Backlog)

O que ele entrega

• Documentação dos requisitos

Como rodar

1. Responda no seu quadro do projeto (ProjectAdm).
2. Rode o processo 4 — ele devolve o prompt pronto, com os seus dados, na área de transferência.
3. Cole na sua IA. Ela propõe; você decide.
4. Cole a resposta na Caixa de entrada do quadro e rode o processo de novo — agora ele escreve o documento.

Baixar o pacote do curso — gratuito e sem instalar nada. Primeira vez? Veja a instalação padrão (5 minutos). As 40 aulas, com certificado, você recebe inscrevendo-se na página do curso.

Para se aprofundar em cada saída

• Documentação dos requisitos

Conclusão

O processo Elicitar e Analisar Requisitos é, junto com o planejamento do escopo, a base sobre a qual todo o escopo do projeto será construído. A mudança de nome em relação ao PMBOK 6 reflete uma evolução importante: não basta coletar passivamente — é preciso extrair ativamente e analisar criticamente.

Os três pontos essenciais para levar para a prática:

• Elicitar é mais do que perguntar. As melhores técnicas de elicitação vão além da pergunta direta: observação, prototipagem e análise de documentos capturam requisitos que os stakeholders não conseguem verbalizar. Use múltiplas técnicas — cada uma revela uma camada diferente de necessidades.
• Analisar é tão importante quanto elicitar. Um requisito capturado não é um requisito válido. Ele precisa ser claro, consistente, viável, testável e priorizado. A análise é o filtro de qualidade que transforma uma lista de desejos em uma especificação implementável.
• A Matriz de Rastreabilidade é a rede de segurança do escopo. Ela garante que nenhum requisito se perca, que nenhuma entrega exista sem justificativa e que qualquer mudança seja rastreável desde a origem até o impacto. Construa-a desde o primeiro requisito — não retroativamente.

Próximo passo concreto: Abra a documentação de requisitos do seu projeto atual. Cada requisito tem um critério de aceitação testável? Cada requisito tem uma origem identificada na matriz de rastreabilidade? Se a resposta for “não” para mais de 20% dos requisitos, você tem um gap de elicitação que precisa ser corrigido antes que esses requisitos vagos se transformem em entregas rejeitadas.

Veja todos os artigos do PMBOK 8 no Indice Completo

---

Read this article in English

CTA Final

Gostou do artigo?

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

Cadastre-se para navegar sem anúncios e participar do Project Together →

Disclaimer:
Este artigo tem caráter informativo e educacional, com o objetivo de apresentar uma análise independente sobre o Guia PMBOK®. O conteúdo aqui publicado não reproduz nem substitui o material original do PMI e respeita integralmente seus direitos autorais. As marcas PMI e PMBOK® Guide são registradas pelo Project Management Institute. Para acesso ao conteúdo completo e oficial, adquira o guia pela Amazon ou baixe de forma gratuita em https://www.pmi.org/standards/pmbok se você é membro do PMI.

Como Associado da Amazon, a escritoriodeprojetos.com.br recebe por compras qualificadas. Os links para a Amazon nesta página são links de afiliado; o preço que você paga não muda.