RHEMA
Como adotar
framework abertoMITmó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)

tripla ortogonal · avaliada por artefato

eixo
Tier
T0 → T4 RQM v1.7.0

Maturidade cumulativa em cinco níveis discretos, de identificação a aprovação formal. Cada tier agrega os invariantes dos anteriores.

eixo
Position
4 níveis RHM v1.2.1

Coordenadas na hierarquia theme → epic → feature → story. Garante rastreabilidade ascendente e decomposição até a folha atômica.

eixo
Decay
contínuo RDM v1.1.0
confiançatempo needs-reviewref-changed:RF-001
fresh0aging0,75 TTLstale1 TTL
ttl default
story · rf · rnf · rb · data-dictionary 90d
story critical 60d
rr 60d
rr critical 30d
adr accepted ∞
Degradação temporal da confiança no artefato. Tempo erode verificação; requisitos envelhecem e exigem re-aprovação explícita. Decay nunca rebaixa tier: sinaliza revisão, não regride maturidade.
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.

  • themeAutenticaçãochildren(r) ≠ ∅ · |1|
    • epicSSOchildren(r) ≠ ∅ · |1|
      • featureLogin com Googlechildren(r) ≠ ∅ · |2|
        • LEAFstoryTratar erro 401children(r) = ∅
        • LEAFstoryRenovar token expiradochildren(r) = ∅
∀ r ∈ R: type(r) = story ↔ children(r) = ∅
03 — cinco tiers cumulativos

Cinco tiers cumulativos

Cada tier adiciona uma classe de informação que não se deriva das anteriores e herda os invariantes delas. Promoção é explícita e fica registrada nos metadados do próprio artefato.

  1. T0
    base
    Identidade
    leitor suficiente · product manager

    O artefato existe e pode ser referenciado sem ambiguidade: ID único e título. Dá para enumerar, contar e priorizar.

    I0(a) ⇐ id(a) ≠ ∅ ∧ title(a) ≠ ∅

  2. T1
    herda T0
    Intenção
    leitor suficiente · stakeholder não técnico

    Comunica o que é desejado e por quê: narrativa, atores e propósito. Um stakeholder lê sem o autor ao lado.

    I1(a) ⇐ narrative ∧ actors ∧ purpose

  3. T2
    herda T0–T1
    Verificabilidade
    leitor suficiente · engenheiro de QA

    Contrato comportamental observável: critérios de aceite e ao menos dois cenários. QA escreve os testes sem perguntar.

    I2(a) ⇐ acceptance_criteria ∧ |scenarios| ≥ 2

  4. T3
    herda T0–T2
    Rastreabilidade
    leitor suficiente · arquiteto ou tech lead

    Embarcado no grafo: pai resolvível, cobre ao menos um RF ou RN, todo link resolve e a ligação é bidirecional. Responde “o que quebra se isto mudar?”.

    I3(a) ⇐ parent ∧ covers ∧ ∀ link: resolves(link)

  5. T4
    herda T0–T3
    Auditabilidade
    leitor suficiente · auditor externo

    Registro com integridade verificável: revisor nomeado, status aprovado, cenário de erro e métrica de sucesso. Auditável sem acesso aos autores.

    I4(a) ⇐ reviewed_by ∧ approved ∧ error_scenario ∧ success_metric

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
  1. P1Verificabilidade como critério de existência.

    Um requisito que não pode ser verificado não é requisito — é intenção.

  2. P2Maturidade é cumulativa.

    T3 implica T2 e T1. “T3 sem T2” é erro de classificação.

  3. P3Rastreabilidade sem resolução é risco.

    Link para ID inexistente é pior que ausência — cria falsa cobertura.

  4. P4Decay é inevitável.

    Frameworks que ignoram o tempo mentem. “Aprovado” não é permanente.

Grupo B · Estrutura do framework
  1. P5Hierarquia sem maturidade é estrutura vazia.

    Bem organizado ≠ bem especificado.

  2. P6Maturidade sem hierarquia é qualidade sem contexto.

    RF T4 sem épico pai é instrução técnica sem propósito rastreável.

  3. P7Cobertura multi-artefato.

    HU, RF, RN, RNF, UC, RR — nenhum tipo isento dos tiers.

  4. P8Independência das dimensões.

    tier, position e decay são ortogonais.

  5. P9Automação como aliada.

    Se não é predicado verificável, não é critério do RHEMA.

  6. 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.

HU

User Story

Necessidade de usuário com critérios de aceite.

---
id: HU-042type: storymaturity: T3parent: FT-PAR-01covers-rf: [RF-PAR-01, RF-PAR-02]---
posição típica · feature · story
RF

Requisito Funcional

Comportamento do sistema em resposta a entrada ou condição.

---
id: RF-PAR-03type: storymaturity: T3parent: FT-RF-PAR-001covers-hu: [HU-042]---
posição típica · story · atômico
RN

Regra de Negócio

Restrição ou política do domínio, independente de implementação.

---
id: RN-PAR-02type: storymaturity: T2domain: elegibilidadeapplies-to: [HU-042, RF-PAR-03]---
posição típica · story · feature
RNF

Requisito Não Funcional

Qualidade transversal — performance, segurança, acessibilidade.

---
id: RNF-PERF-01type: storyquality-attribute: performancemetric: P95 latência em mstarget: ≤ 2000ms---
posição típica · feature · theme
UC

Caso de Uso

Sequência de interações ator ↔ sistema com fluxos alternativos.

---
id: UC-PAR-01type: featurematurity: T3actor: Gestor de Entecovers-rf: [RF-PAR-03]---
posição típica · feature · story
opt-in
RR

Requisito Regulatório

Obrigação derivada de fonte normativa externa, com citação obrigatória.

---
id: RR-LGPD-01type: storylegal-source: Lei 13.709/2018, Art. 46negotiability: non-negotiablettl: 60d---
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; proveniência (generated-by, sources) carimbada por hook, não à mão.

rqm-validatelive
próximo passo

Adote os modelos, ignore o tooling — ou vice-versa.

Modelos, templates e validador acompanham o Requiem Forge, sob licença MIT e sem lock-in. Para adotar em um projeto, fale com a Requiem.

Falar com a Requiem