Requiem Hierarchy Excellence Maturity Artifact
Modelo Formal de Qualidade de Requisitos de Software
26 slides · duas partes complementares
Três defeitos identificados em produção — CultBR · 219 HUs · ciclos 2025–2026
A pergunta "por que esta HU está em T2 e não T3?" não tinha resposta objetiva. Tiers eram acordos de equipe, não condições verificáveis. Inconsistência entre projetos e auditores.
HUs classificadas como T3 apontavam para RFs renomeadas ou removidas. Nenhum mecanismo de invalidação. Backlog reportava 94% de cobertura — cobertura real era significativamente menor.
maturity: T1 usado simultaneamente para "não especificado" e "épico pai". Falha ontológica que gerava falsos negativos em todas as análises de saúde do backlog.
Um backlog sem modelo de qualidade formal é dívida técnica de requisitos acumulando juros compostos — invisível até o momento da implementação.
Três dimensões ortogonais e independentemente verificáveis
| Modelo | Padrão | v | Pergunta |
|---|---|---|---|
| RHM Hierarchy Model |
STD-RHM-001 | 1.1 | Onde o artefato está na hierarquia? |
| RQM Quality Model |
STD-RQM-001 | 1.2 | Quão bem especificado e válido está? |
Funciona com qualquer metodologia (Scrum, SAFe, Kanban) e qualquer ferramenta (Jira, Notion, Markdown). Sem dependências obrigatórias de plataforma.
Seis non-scopes explícitos — evita confusões de adoção
Não define sprints, cerimônias, papéis nem cadências. Isso é responsabilidade do processo (Scrum, SAFe, SDD).
Funciona sobre qualquer metodologia como camada de qualidade de requisitos — não compete com elas.
Não gerencia assignees, sprints, burndown nem velocity. Isso é Jira, Linear ou GitHub Projects.
Não é UML, BPMN, SysML ou ER. Trabalha com artefatos textuais em Markdown + frontmatter YAML.
Não controla mudanças em código, não substitui Git. Decay é métrica de confiabilidade — não sistema de versão.
Não tem força de lei. Não auditável para ISO 9001, IEC 62443 ou DO-178C sem adaptação documental.
O RHEMA define o QUE é um requisito de qualidade e COMO medir isso — não COMO o trabalho deve ser feito.
NÍVEL TIPO MATURIDADE ───────────────────────────────────────── Estratégico Theme T0–T1 │ ├── Epic T1–T2 │ │ │ └── Feature T2–T3 │ │ │ └── Story ◄ LEAF T3–T4 (alvo) LEAF INVARIANT story(a) ↔ ¬∃ b : parent(b) = a
O tipo é estrutural, não estimativo. Uma Story é Story porque não tem filhos — independente de tamanho ou complexidade.
Stories são as únicas unidades atribuíveis a equipes, sprints ou agentes de IA. Espelha KAOS leaf goals (1993).
| Nível | Sprint? | Filhos? |
|---|---|---|
| Theme | Nunca | Sempre |
| Epic | Nunca | Sempre |
| Feature | Não | Sempre |
| Story ◄ LEAF | Sim | Nunca |
Tiers cumulativos com predicados formais.T3 ⟹ T2 ⟹ T1.
Determinada por relações, não por tamanho. Verificável por máquina.
Decay não regride tier. Dimensões ortogonais.
id + título existem
narrativa + atores + propósito
critérios + ≥2 Gherkin
parent + covers + bidirecional
reviewed_by + erro + métrica
Critérios de completude variam por tipo; a exigência de verificabilidade não.
RR — Requisito Regulatório. Tipo exclusivo para obrigações normativas externas (LGPD, LAI, Marco Civil). Distingue-se de RN pela fonte sempre externa e por non-negotiability invariante. T4 exige competência legal. · Breaux & Antón, IEEE TSE 2008 · Nòmos 2 (Siena et al., 2009)
Dois grupos com tensão produtiva
Um requisito que não pode ser verificado não é requisito — é intenção.
T3 implica T2 e T1. "T3 sem T2" é erro de classificação.
Link para ID inexistente é pior que ausência — cria falsa cobertura.
Frameworks que ignoram o tempo mentem. "Aprovado" não é permanente.
Bem organizado ≠ bem especificado.
RF T4 sem épico pai é instrução técnica sem propósito rastreável.
HU, RF, RN, RNF, UC, RR — nenhum tipo isento dos tiers.
tier, position e decay são ortogonais.
Se não é predicado verificável, não é critério do RHEMA.
Define critérios — não como o trabalho deve ser feito.
| Story ativa (padrão) | 90 dias |
| Story criticality:critical | 60 dias |
| Requisito Regulatório | 60 dias |
| ADR (accepted) | ∞ |
RF/RB modificado → needs-review · Artefato removido → orphaned. Requer tier ≥ T3.
Decay não causa regressão de tier. Tier captura completude histórica; decay captura validade atual. Perguntas diferentes, dimensões distintas.
rqm-validate.py21 regras CI-enforceable · zero ambiguidade · auditável
stories T3+ / total stories
target > 80%
stories T2+ / total stories
target > 95%
features c/ children / total
target > 95%
stories / features
faixa 3 – 8
sem parent / total
target ≈ 0%
(stale+review+orphan) / total
target < 5%
Políticas culturais — PNAB 2025
OCPP · Mobilidade Elétrica · ESS
Corpus em domínio completamente distinto. Confirmou D1–D3 sem ajuste do framework.
Setor: Energia · ESS
Transporte universitário municipal — Secretaria de Educação (AL)
Três domínios. Três setores. Um padrão.
Cultura · Energia · Educação públicaRequisito de qualidade → especificação sem ambiguidade → código rastreável
id + título + narrativa. Sem critérios ainda.
brainstorm → critérios + cenários Gherkin.
writing-plans → covers-rf + parent resolvidos.
decay ≠ orphaned, 0 ERROs → merge permitido.
Invariante central: uma HU em T3 é a forma mínima de especificação que o SDD precisa para funcionar sem ambiguidade.
modules/rhema/templates/rqm-validate.pyArtefatos T0..T4 continuam válidos — adoção não é big-bang.
rqm-validate como pre-commitvalidated-at)criticalViabilidade de pesquisa e publicação
Lucassen et al. · 2016 · RE Journal
✓ 13 critérios · 3 dimensões
⚠ Story-only · critérios planos · sem decay
Femmer · 2017 · TU München
✓ Separa artifact × process quality
⚠ Sem posição · sem decay
Frattini et al. · 2023–24 · RE Journal
✓ ƒ(artifact × activity × economic)
⚠ Não separa tier × decay
Starke & Hruschka
✓ 12 seções padronizadas
⚠ Requisitos são 2ª classe
Simon Brown · c4model.com
✓ 4 níveis de abstração
⚠ Só estrutura · sem requisito
Dardenne, van Lamsweerde, Fickas (1993)
Leaf goals — metas irrefináveis, atribuíveis a agentes.
→ Contribui: Leaf Invariant
Leffingwell (2011+)
Theme → Epic → Feature → Story como hierarquia de planejamento.
→ Contribui: hierarquia de 4 níveis
ISO/IEC/IEEE
9 características de requisito bem-formado.
→ Contribui: verifiable (T2), traceable (T3)
Breaux & Antón (2008) · Siena et al. (2009)
Formalização de obrigações, direitos e restrições normativas.
→ Contribui: tipo RR (obligation-type)
Bill Wake (2003)
Independent, Negotiable, Valuable, Estimable, Small, Testable.
→ Contribui: testability T2 · negotiability RR
Lucassen et al. (2016)
13 critérios story-centric com pontuação por critério.
→ Contribui: estendido · 6 tipos · tiers cumulativos
5 meta-classes irredutíveis (T0–T4), cada uma com predicados machine-verifiable. Resolve a ambiguidade dos modelos convencionais.
Diferencial: QUS/RQT definem critérios planos. RHEMA define progressão cumulativa com prova formal de monotonicidade.
Formalização do Leaf Invariant (type:story ↔ children(a) = ∅) e prova de ortogonalidade entre posição e maturidade.
Diferencial: nenhum modelo da literatura formaliza posição hierárquica como dimensão ortogonal de qualidade.
Separação formal entre completude histórica (tier) e validade temporal (decay). Dois mecanismos: TTL + triggers semânticos via grafo.
Diferencial: Femmer (2017) e Frattini (2023) não tratam obsolescência. RHEMA é o primeiro a formalizar com dois mecanismos.
T0–T4 aplicados a 6 tipos (HU, RF, RN, RNF, UC, RR), cada um com predicados adaptados. RR introduz rastreabilidade de obrigações normativas.
Diferencial: QUS é story-only. RHEMA é o único com cobertura completa e grounding acadêmico por tipo.
A = conjunto de todos os artefatos de requisitos.
Cada In inclui In−1 como conjunção. Irredutibilidade das classes garante hierarquia estrita. ∎
Bidirecionalmente verificável. Machine-checkable.
Estados estruturais dominam estados temporais.
PNAB 2025 · MinC · 219 HUs → 474 artefatos pós-migração
| Cód. | Tipo | Prevalência |
|---|---|---|
| D1 | Rastreabilidade Fantasma — links para IDs renomeados | ~6% dos artefatos |
| D2 | Conflação Dimensional — T1 como proxy de posição | 100% dos pais |
| D3 | Ausência de Decay — "aprovado" permanente | N/A — estrutural |
OCPP · Mobilidade Elétrica · ESS
Replicação cross-domínio. D1–D3 confirmados sem ajuste.
Transporte universitário · Sec. Educação (AL)
Setor público · 3 produtos. D1–D3 confirmados — 437 docs · 20 ADRs.
Detector de hierarquia não cobre mixing PT/EN em títulos (ex.: "épico parent"). Falso negativo documentado — regex deve ser ajustado antes de adoção em projetos com naming misto.
Os predicados I₀..I₄ de Story são canônicos e CI-enforced. Para os demais tipos, critérios são experimentais (RQM §8 v0.1). OQ-01: para RBs, source (origem normativa) é pré-requisito de T2 ou T3?
CultBR, microRED e SGTU são do mesmo ecossistema Requiem Forge. SGTU parcialmente satisfaz independência (stakeholder externo — Sec. Educação AL — e domínio distinto), mas ainda requer corpus com equipe completamente independente. Protocolo baseado em QUS pode ser reutilizado.
O mecanismo semântico (needs-review por trigger) está especificado, não implementado em CI. Questão: custo computacional de manter grafo de dependências atualizado em backlogs com 500+ artefatos?
Checks SEM-01..SEM-10 (coerência cross-HU) são manuais. Investigar se LLMs detectam contradições com precisão suficiente — conecta com Dalpiaz et al. (2024).
Qualidade de requisitos não é convenção. É predicado.