HU
User Story
Necessidade de usuário com critérios de aceite.
posição típica · feature · story
framework·v1.0.0·MIT·módulo Requiem Forge
RHEMA
Requiem · Hierarchy · Excellence · Maturity · Artifact
Engenharia formal de requisitos — hierarquia verificável, maturidade cumulativa, degradação temporal.
AssinaturaRQM(a) = (tier, position, decay)
A fronteira entre intenção e especificação.
01 — uma tripla ortogonal
Uma tripla ortogonal
Todo artefato a é caracterizado por três coordenadas simultâneas. Nenhum eixo substitui os outros — qualidade é produto das três.
RQM(a) = (tier, position, decay)
- eixoTierT0 → T4
Maturidade cumulativa em cinco níveis discretos, de identificação a aprovação formal. Cada tier agrega os invariantes dos anteriores.
- eixoPosition4 níveis
Coordenadas na hierarquia theme → epic → feature → story. Garante rastreabilidade ascendente e decomposição até a folha atômica.
- eixoDecaycontínuo
Degradação temporal da confiança no artefato. Tempo erode verificação; requisitos envelhecem e exigem re-aprovação explícita.
02 — decomposição verificável
Decomposição verificável
Quatro níveis cumpridos pela totalidade dos artefatos. A definição de folha é sintática — não depende de interpretação humana.
theme
Autenticação
epic
SSO
feature
Login com Google
LEAF
story
Tratar erro 401
03 — cinco tiers cumulativos
Cinco tiers cumulativos
Cada nível herda os invariantes dos anteriores. Promoção é explícita, responsabilizada e rastreável em metadados do próprio artefato.
- T0Identificadopromove: qualquer membroID único e tipo definido. Existe como entidade endereçável no backlog.
- T1Nomeadopromove: qualquer membroTítulo descritivo e épico pai identificado. Localizável na hierarquia.
- T2Descritopromove: analista ou PONarrativa Como/Quero/Para que com contexto suficiente para discussão técnica.
- T3Rastreável e verificávelpromove: analista ou POPré-condições, quatro ou mais cenários de aceite, fluxos alternativos e métricas observáveis.
- T4Aprovadopromove: revisor designadoRevisão humana formal documentada. Assinado, datado, versionado.
Invariante de monotonicidade
tier(a) ≥ Tn+1 ⇒ tier(a) ≥ Tn ∀ n ∈ {0, 1, 2, 3}
04 — dez princípios guia
Dez princípios guia
Dois grupos em tensão produtiva — critérios de qualidade e estrutura do framework.
Grupo A · Critérios de qualidade
- P1Verificabilidade como critério de existência.
Um requisito que não pode ser verificado não é requisito — é intenção.
- P2Maturidade é cumulativa.
T3 implica T2 e T1. “T3 sem T2” é erro de classificação.
- P3Rastreabilidade sem resolução é risco.
Link para ID inexistente é pior que ausência — cria falsa cobertura.
- P4Decay é inevitável.
Frameworks que ignoram o tempo mentem. “Aprovado” não é permanente.
Grupo B · Estrutura do framework
- P5Hierarquia sem maturidade é estrutura vazia.
Bem organizado ≠ bem especificado.
- P6Maturidade sem hierarquia é qualidade sem contexto.
RF T4 sem épico pai é instrução técnica sem propósito rastreável.
- P7Cobertura multi-artefato.
HU, RF, RN, RNF, UC, RR — nenhum tipo isento dos tiers.
- P8Independência das dimensões.
tier, position e decay são ortogonais.
- P9Automação como aliada.
Se não é predicado verificável, não é critério do RHEMA.
- P10Framework, não metodologia.
Define critérios — não como o trabalho deve ser feito.
05 — síntese, não substituição
Síntese, não substituição
RHEMA não compete com frameworks estabelecidos — convive com eles. O que cada um cobre, onde deixa em aberto, e o que RHEMA adiciona.
IEEE 29148:2018
- Cobre
- Nove características de qualidade.
- Em aberto
- Flat — sem progressão cumulativa, sem dimensão temporal.
- Adiciona
- Tiers T0–T4 cumulativos mais decay.
SAFe
- Cobre
- Hierarquia Epic → Feature → Story de planejamento.
- Em aberto
- Sem critérios formais de maturidade.
- Adiciona
- RHM com invariantes; RQM define o que é pronto.
arc42
- Cobre
- Documentação arquitetural estruturada.
- Em aberto
- Requisitos como segunda classe.
- Adiciona
- Sistema requisito-cêntrico.
C4 Model
- Cobre
- Visualização em quatro níveis.
- Em aberto
- Não trata requisitos.
- Adiciona
- Alimenta as decisões que C4 documenta.
QUS Framework
- Cobre
- Treze critérios de qualidade para user stories.
- Em aberto
- Story-centric; sem tiers cumulativos.
- Adiciona
- Seis tipos de artefato, critérios por tier.
Camada de síntese — adota o que cada um deixa em aberto, não pede que você abandone o que já usa.
06 — seis tipos de artefato
Seis tipos de artefato
Todos compartilham o mesmo frontmatter canônico. Cada tipo tem posição típica na hierarquia e critérios de tier específicos.
RF
Requisito Funcional
Comportamento do sistema em resposta a entrada ou condição.
posição típica · story · atômico
RN
Regra de Negócio
Restrição ou política do domínio, independente de implementação.
posição típica · story · feature
RNF
Requisito Não-Funcional
Qualidade transversal — performance, segurança, acessibilidade.
posição típica · feature · theme
UC
Caso de Uso
Sequência de interações ator ↔ sistema com fluxos alternativos.
posição típica · feature · story
RR
Requisito Regulatório
Obrigação derivada de fonte normativa externa, com citação obrigatória.
posição típica · story · atômico
07 — adote o que couber
Adote o que couber
Dois caminhos, mesma base canônica. O investimento em frontmatter permanece compatível se você migrar entre eles.
caminho 01
RHEMA standalone
Apenas modelos e templates. Zero dependência técnica. Funciona em Confluence, Notion, Markdown versionado ou Jira.
O frontmatter canônico é compatível com qualquer ferramenta que aceite metadados estruturados.
caminho 02
RHEMA + Requiem Forge
Validação automatizada via rqm-validate, hooks de CI, relatórios de saúde de backlog, integração com SDD.
Promoção de tier bloqueada por invariantes não-satisfeitos; decay calculado automaticamente.
rqm-validatelive
próximo passo
Adote os modelos, ignore o tooling — ou vice-versa.
Spec pública, validadores opcionais, sem lock-in. Comece pela apresentação completa.