Módulo 08

Levantamento de Requisitos com IA

Como usar IA antes, durante e depois de reuniões de levantamento — roteiro de entrevistas, processamento de notas, conflitos entre stakeholders e pacote de contexto.

entrevistarequisitosAS ISTO BEcontexto
Neste módulo
  1. Fluxo completo de levantamento
  2. Antes da reunião
  3. Após a reunião — processando com IA
  4. Técnicas de levantamento
  5. Montando o pacote de contexto
  6. Sinais de que o requisito não está pronto

Por que o levantamento é a etapa mais crítica

🔴
Custo do erro por fase: Erro de requisito descoberto antes do desenvolvimento → 1x. Durante o desenvolvimento → 5x. Em homologação → 10x. Em produção → 20x. A maioria dos retrabalhos não vem de código mal escrito — vem de requisitos mal levantados.
A
Antes da reunião
IA prepara roteiro de perguntas e analisa documentação existente para identificar lacunas.
H
Durante a reunião
Analista conduz a entrevista. Anota ou grava para processar depois.
A
Após a reunião
IA organiza notas em requisitos, identifica conflitos, ambiguidades e sugere follow-ups.

Antes da reunião

P-REQ-01Gerar roteiro de entrevista
Quando usar: Preparar perguntas antes de reunião de levantamento com stakeholder.
Você é analista de negócio se preparando para uma reunião de levantamento. Sistema: [Nome e descrição] Módulo a levantar: [Descreva] Perfil do stakeholder: [Ex: gerente comercial, usuário final] O que já sei: [O que você sabe até agora] Sensibilidades: [Ex: prazo curto, processo polêmico] Gere: 1. Objetivo da reunião (1 parágrafo) 2. Roteiro de perguntas por bloco: - Contexto e problema atual - Processo atual (como funciona hoje) - Processo desejado (como deve funcionar) - Regras e restrições - Integrações e sistemas relacionados - Critérios de sucesso 3. Perguntas a evitar (que geram respostas vagas) 4. Pontos de atenção com base no que já sei Dica: perguntas abertas antes de fechadas.
P-REQ-02Analisar doc existente antes da reunião
Quando usar: Entender o que já está documentado para não perguntar o que já se sabe.
Você é analista de negócio se preparando para levantamento. Documentação disponível: [COLE O DOCUMENTO] Reunião: vou discutir [TEMA] com [PERFIL DO STAKEHOLDER] Analise e me diga: 1. O que já está definido e documentado? 2. O que parece desatualizado ou inconsistente? 3. O que claramente está FALTANDO? 4. Perguntas específicas a fazer com base nas lacunas 5. Termos que devo confirmar o significado

Após a reunião

P-REQ-03Transformar anotações em requisitos
Quando usar: Você saiu da reunião e quer estruturar as notas em requisitos formais.
Você é analista de negócio. Transforme as anotações abaixo em requisitos estruturados. Módulo: [Nome] | Stakeholder: [Perfil] | Data: [Data] Anotações da reunião: [COLE — podem estar bagunçadas] Processe e retorne: 1. REQUISITOS FUNCIONAIS: RF-[número] — [o que o sistema deve fazer] 2. REQUISITOS NÃO FUNCIONAIS: RNF-[número] — [performance, segurança, etc.] 3. REGRAS DE NEGÓCIO: RN-[número] — [regra clara e testável] 4. AMBIGUIDADES E CONTRADIÇÕES: com sugestão de como clarificar 5. PERGUNTAS DE FOLLOW-UP: para quem perguntar e por quê 6. DECISÕES TOMADAS: o que deve ser registrado formalmente 7. PRÓXIMOS PASSOS Formato: Markdown por seção.
P-REQ-04Tratar requisitos conflitantes entre stakeholders
Quando usar: Dois stakeholders pediram coisas incompatíveis e você precisa estruturar o conflito.
Você é analista de negócio mediando conflito de requisitos. Contexto: [Descreva o módulo e a situação] Stakeholder A ([cargo/área]): [O que quer] Stakeholder B ([cargo/área]): [O que quer — conflita com A] Analise e retorne: 1. Natureza do conflito: prioridade, regra, processo ou interpretação? 2. Impacto de cada opção 3. Possibilidades de conciliação 4. Perguntas para levar à decisão 5. Rascunho de e-mail para escalar à liderança Tom: neutro e orientado à solução. Não tome partido.

Técnicas de levantamento

As 5 perguntas essenciais

Para qualquer requisito levantado, responda estas 5 perguntas. Se não souber alguma, é uma lacuna a resolver antes de escrever a US.

👤
1. Quem?
Qual persona executa ou é afetada por este requisito?
⚙️
2. O quê?
O que o sistema deve fazer exatamente?
⏱️
3. Quando?
Em que condição ou momento isso acontece?
📋
4. Como?
Quais são as regras que governam esse comportamento?
💡
5. Por quê?
Qual problema de negócio isso resolve?

Mapeamento AS IS × TO BE

Antes de especificar o sistema, documente o processo como é hoje (AS IS) e como deve ser (TO BE). A diferença entre os dois é o que o sistema precisa fazer.

P-REQ-05Mapear AS IS × TO BE
Quando usar: Documentar mudança de processo antes de especificar o sistema.
Você é analista de negócio documentando mudança de processo. Processo atual (AS IS): [COMO FUNCIONA HOJE] Processo desejado (TO BE): [COMO DEVE FUNCIONAR] Analise e gere: 1. Tabela de comparação por etapa 2. O que o sistema deve automatizar 3. O que permanece manual 4. Pontos de integração com outros sistemas 5. Riscos da transição 6. Lista de funcionalidades necessárias derivadas da diferença

O pacote de contexto — use com qualquer ferramenta

Crie um arquivo contexto-[modulo].md e use como base antes de qualquer prompt ou configuração de skill.

# Contexto: Módulo [NOME]

## Sistema
Nome: [Nome do sistema]
Descrição: [O que faz em 3-5 linhas]

## Personas
| Persona | Descrição | Permissões principais |
|---|---|---|
| [Nome] | [Descrição] | [O que pode fazer] |

## Regras de negócio globais
- RN-001: [Regra que vale para todo o sistema]

## Integrações existentes
- [Sistema X]: [como se integra]

## Padrões de nomenclatura
- IDs de US: US-[4 dígitos]
- Formato de data: DD/MM/AAAA

## Fora do escopo deste módulo
- [Funcionalidade que pertence a outro módulo]
🔧
No Claude Projects: suba como documento de referência — toda conversa herda o contexto. No NotebookLM: adicione como fonte. Em prompt avulso: cole no início antes de qualquer pedido.

Sinais de que o requisito não está pronto para virar US