ESP — Especificação (S)

Autoridade: o ESP é o ponto de vista de maior autoridade sobre o “o quê” do sistema. Todos os demais pontos de vista consomem artefatos publicados pela Especificação.

Responsável por estruturar o conhecimento de negócio, regras, requisitos, integrações, conformidade, autenticação, acessibilidade e comunicação institucional.

---

Os 11 tipos de história

Sigla	Nome	Origem
HNI	Histórias de Negócio Institucionais	Alta gestão, normas, leis
HNE	Histórias de Negócio Especializadas	Área gestora da solução
HNU	Histórias de Negócio de Usuário	Equipes usuárias e executoras
HS	Histórias de Sistema	Tradução técnica dos requisitos
HI	Histórias de Integração	Interoperabilidade e APIs
HRD	Histórias de Regra de Decisão	Lógicas e critérios automatizáveis
HUX	Histórias de Experiência do Usuário	Jornada, interface, usabilidade
HC	Histórias de Conformidade	Requisitos legais e regulatórios
HAI	Histórias de Autenticação e Identidade	Autenticação, gov.br
HAC	Histórias de Acessibilidade	Acessibilidade digital
HIVC	Histórias de Identidade Visual e Comunicação	Padrões de interface e comunicação

---

Ciclo de vida das histórias

Toda história percorre estados definidos antes de ser considerada válida para consumo pelos demais pontos de vista:

---

Regras obrigatórias

Toda história da especificação deverá possuir identificador único, versão, origem, data de geração, data de revisão, autor ou responsável, dependências, criticidade e vínculo com os demais artefatos afetados.

Toda história deverá possuir rastreabilidade bidirecional entre documentos de origem, protótipos, infraestrutura, código, testes, implantação, operação, documentação e evidências.

Toda história deverá ser submetida a validação de alucinação em dois níveis:

Validação de alucinação

1. por outra engine de IA em contexto distinto;
2. por validação humana, quando aplicável, exercida pelo papel de supervisão correspondente.

Critério de divergência obrigatória

Configura divergência relevante que obriga escalada ao Validador humano toda divergência entre engines que envolva requisito de segurança, dado pessoal ou sensível, lógica de negócio crítica, regra de conformidade ou impacto em autenticação. Divergências de estilo, formatação ou nomenclatura não configuram divergência relevante.

Toda história que envolva usuário externo deverá indicar o mecanismo de autenticação e o nível de autenticação gov.br compatível com a natureza do requisito de negócio.

Toda história que envolva interface, navegação ou interação humana deverá conter requisitos mínimos de acessibilidade.

Toda história que envolva comunicação com o usuário deverá indicar mensagens obrigatórias, disclaimers, avisos institucionais e elementos mínimos de transparência.

---

Evidências da Especificação

• evidência de origem documental;
• evidência de validação por IA secundária;
• evidência de validação humana;
• evidência de aprovação da história;
• evidência de rastreabilidade com protótipo, código, teste ou infraestrutura.

Captura de evidências

As evidências de validação e aprovação humana deverão ser preferencialmente capturadas via metadados de ferramentas: aprovação de Pull Request, commit assinado com identidade rastreável ou registro em sistema de gestão.

---

Documentos estruturantes

Sigla	Nome	Finalidade
VIS	Vision Document	Visão de alto nível da solução
BRD	Business Requirements Document	Requisitos de negócio formalizados
PRD	Product Requirements Document	Requisitos detalhados do produto
DOM	Domain Model	Modelo de domínio conceitual
STY	Style Guide	Padrão visual e de comunicação

Style Guide como insumo de IA

O STY deverá ser gerado em formato estruturado (JSON ou YAML) para consumo direto pelos agentes de IA da PRO (Prototipação) e da IMP (Implementação).

---

← Estrutura do Framework · INF — Infraestrutura →