Fases 1 a 3 — Necessidade, normas e especificação (S)

Fase 1 — Necessidade do negócio

Objetivo

Transformar demanda genérica em problema institucional definido, com valor esperado, público afetado, limites e critérios de sucesso.

Atividades

1. Registrar a demanda original.
2. Identificar unidade demandante.
3. Identificar usuários.
4. Descrever problema atual.
5. Descrever impacto institucional.
6. Definir resultado esperado.
7. Definir indicadores de sucesso.
8. Mapear processos de negócio afetados.
9. Identificar sistemas envolvidos.
10. Identificar dados tratados.
11. Identificar restrições legais e administrativas.
12. Classificar criticidade inicial.

Artefatos

Artefato	Conteúdo mínimo
BRD	Problema, contexto, objetivos, benefícios, restrições, atores, macroprocessos
PRD	Escopo funcional, jornadas, funcionalidades, regras, critérios de aceite
Mapa de stakeholders	Área demandante, usuários, gestores, TI, segurança, dados, auditoria
Mapa de valor	Que valor institucional será produzido
Backlog inicial	Épicos, funcionalidades, histórias preliminares

Uso de IA

A IA pode ajudar a:

• organizar entrevistas;
• resumir documentos de negócio;
• extrair requisitos de normas;
• sugerir perguntas de levantamento;
• identificar ambiguidades;
• propor histórias de usuário;
• comparar problema declarado com processos existentes.

Controle SinergIA

A IA não deve fechar escopo sozinha. Toda necessidade deve ser validada pelo validador de negócio, em linha com a Validação em múltiplas camadas e a Supervisão humana obrigatória.

Gate 1 — Validação da necessidade

A fábrica só deve avançar para especificação detalhada se houver:

Critério	Evidência
Problema descrito	BRD validado
Resultado esperado	PRD inicial
Usuários identificados	Mapa de stakeholders
Valor institucional	Mapa de valor
Criticidade preliminar	Registro de classificação
Validação humana	Ata, despacho, comentário formal ou aceite no sistema

---

Fase 2 — Normas, restrições e conformidade

Objetivo

Mapear o conjunto normativo, regulatório, institucional e técnico que condiciona o desenvolvimento. Para o panorama de instrumentos normativos sobre IA, ver Conformidade.

Itens a levantar

Categoria	Exemplos
Legislação geral	LGPD, LAI, Lei de Governo Digital, normas de processo administrativo
Normas de contratação	IN SGD/ME 94/2022, Lei 14.133/2021, regras do contrato
Segurança	Política de segurança institucional, PPSI, autenticação, logs, trilhas
Privacidade	Dados pessoais, base legal, retenção, minimização, compartilhamento
Acessibilidade	eMAG, WCAG, padrões de acessibilidade
Interoperabilidade	APIs, padrões de integração, barramentos, autenticação
Arquitetura	Padrões de cloud, banco de dados, linguagem, framework, observabilidade
Operação	SLA, ANS, sustentação, backup, continuidade
Auditoria	Evidências, trilha de decisão, aceite, registros de mudança

Artefatos

Artefato	Conteúdo mínimo
Matriz normativa	Norma, requisito, impacto no sistema, evidência esperada
Matriz de conformidade	Exigência, requisito associado, responsável, status
Checklist LGPD	Dados pessoais, base legal, finalidade, retenção, compartilhamento
Checklist segurança	Autenticação, autorização, logs, criptografia, vulnerabilidades
Critérios não funcionais	Desempenho, disponibilidade, segurança, usabilidade, acessibilidade

Uso de IA

A IA pode resumir normas, extrair obrigações, sugerir requisitos de conformidade, comparar requisitos com políticas institucionais e gerar checklist inicial. A validação deve ser humana, principalmente em matéria jurídica, privacidade, segurança e auditoria.

Gate 2 — Validação normativa

Critério	Evidência
Regras normativas mapeadas	Matriz normativa
Requisitos de conformidade associados	Matriz de conformidade
Dados pessoais identificados	Inventário preliminar de dados
Restrições de segurança	Checklist de segurança
Critérios não funcionais	Documento NFR
Validação técnica/jurídica quando aplicável	Registro de validação

---

Fase 3 — Especificação funcional e testes desde a origem

Objetivo

Transformar necessidade e normas em histórias, requisitos, regras, critérios de aceite e casos de teste definidos ainda na especificação. ESP cobre requisitos, histórias, regras, integrações, UX e critérios de aceite — ver ESP — Especificação. Para o ponto-chave: cada requisito funcional relevante deve nascer com critério de aceite e caso de teste correspondente.

Estrutura recomendada de história

# HNU-001 — Solicitar autorização institucional

## Necessidade vinculada
BRD-OBJ-001

## Ator
Servidor da área demandante

## História
Como servidor responsável, quero registrar uma solicitação para que a área competente possa analisar e deliberar.

## Regra de negócio
RN-001 — A solicitação deve conter justificativa, unidade, responsável e anexos obrigatórios.

## Critérios de aceite
CA-001 — O sistema não permite envio sem justificativa.
CA-002 — O sistema registra data, usuário e unidade.
CA-003 — O sistema gera número de protocolo interno.

## Casos de teste derivados
CT-001 — Tentativa de envio sem justificativa.
CT-002 — Envio válido com todos os campos obrigatórios.
CT-003 — Verificação de geração de protocolo.

## Evidência esperada
Print da tela, log de teste automatizado, registro no banco de homologação, relatório do pipeline.

Regra operacional

Para cada história aprovada:

Item	Obrigatório?	Observação
História de usuário	Sim	Deve ter identificador único
Regra de negócio	Sim	Se aplicável
Critério de aceite	Sim	Sem isso a história não entra em desenvolvimento
Caso de teste	Sim	Criado na fase de especificação
Protótipo	Recomendado	Obrigatório quando houver interface relevante
Evidência esperada	Sim	Deve ser definida antes da implementação
Risco ou dependência	Sim	Se houver impacto técnico, externo ou normativo

Ferramentas

Finalidade	Produtos sugeridos
Backlog e histórias	Jira, Azure DevOps, GitHub Projects, GitLab Issues
Documentação textual	Confluence, GitBook, Docusaurus, Markdown em Git
Protótipos	Figma, Lovable, v0, Uizard
Mapas de fluxo	Miro, FigJam, Draw.io
IA para especificação	ChatGPT, Claude, Gemini, NotebookLM
Validação textual	LanguageTool, Vale, markdownlint

Gate 3 — Ready for Architecture / Ready for Dev

Uma história só entra em arquitetura ou desenvolvimento se cumprir:

Critério	Evidência
História clara	Arquivo ou item no backlog
Regra de negócio documentada	RN vinculada
Critério de aceite	CA vinculado
Caso de teste definido	CT vinculado
Protótipo validado, se houver UI	Link ou anexo
Dados envolvidos identificados	Inventário ou anotação PDP
Dependências mapeadas	Registro no backlog
Validação do negócio	Aceite formal

---

Anterior: Fase 0 — Preparação · Próximo: Fases 4–5