ADR-0077: Requirement Items — Keyed Blocks Inside Controlled Documents¶
- Status: accepted (Nicolas 2026-07-17: item-level "yes, please"; keys scope-based; attributes full-fixed-set; PULSEMED tables migrate. Supersedes the gap-analysis §B "stay document-level" default and answers TD-paper D-2's granularity seam.)
- Date: 2026-07-17
- Deciders: Nicolas Burri, design by Claude.
- Relates to: ADR-0057 (tree-as-record — the identity/versioning substrate), ADR-0021/0049 (relations/trace matrix/coverage — extended one level down), ADR-0073 (scope config — the governance home), ADR-0068/0075 (import + honesty rules), docs/ai/td-dossier-options.md (the dossier's ITEM pin seam), docs/ai/gap-analysis-2026-07-15.md §B.
- Refined by: ADR-0088 (coverage gains evidence classes — planned vs verified derived at the read layer via a per-type evidence flag, with evidence dates surfaced)
Context¶
The legacy setup models requirements as prose + tables + duplicated Jira issues, synchronized by naming convention: the PULSEMED corpus holds its 77 requirements in FOUR places at once with zero machine-readable links (trace tables in prose, with wildcards). Tracking, linking and coverage are manual and unverifiable. Nicolas: "rather unsatisfying… makes tracking and linking for traceability very annoying."
Decision¶
A requirement is a keyed block INSIDE a controlled document — never a separate entity.
- The block (new tree node
requirement): {key, text (rich inline content), and the FIXED optional attribute set: kind (functional | non-functional | stakeholder | safety | other), priority, rationale, acceptance criteria}. NO custom-attribute engine — deliberately (the second-Jama slope); additions are future ADR-level decisions. - Identity & versioning are derived, never managed: the key is stable; the block's content hash across document versions IS the item history ("changed in v6" = hash differs). No item lifecycle, no item states: THE DOCUMENT'S LIFECYCLE IS THE ITEM'S LIFECYCLE (a requirement is approved/released/superseded exactly as its defining document version is).
- Definition governance (scope config, ADR-0073 pattern): a per-document-type flag "may define requirements", per scope (on for SRS/stakeholder/architecture-spec types, off elsewhere). A key is UNIQUE PER SCOPE and DEFINED IN EXACTLY ONE document; moving a definition between documents is a deliberate act (delete + redefine, both under document review). LINKS to requirements may originate anywhere.
- Keys are scope-configured conventions with auto-numbering (prefix rules like
SSRS_<AREA>_nnn; the editor suggests the next free key); uniqueness enforced at save against the scope registry. - Item links: typed relations item→item and item→document (
verifies,satisfies,derives-from,references), stored alongside the existing document relations (V032 family), RLS-scoped, cross-scope capable. Suspect semantics: when a new RELEASED version of the defining document changes a requirement's hash (or removes the key), every inbound link is flagged SUSPECT; clearing is a deliberate, audited act. Wildcard/glob links are NOT supported (the legacySSRS_IF_API_*convention imports as expanded, convention-derived links). - Registry & coverage: a scope-level requirements registry (read-only derivation): key, defining document+version, kind/priority, last-changed version, inbound/outbound links, suspect state. The trace matrix/coverage rules extend one level: per-item coverage ("N of M requirements of type SRS carry a verifies link from a TSTPLAN item"), with the uncovered list enumerable.
- Migration (PULSEMED first): the importer converts recognized requirement representations —
**KEY** (JIRA-key)prose headers AND table-form definitions (REC-007 style) — into requirement blocks; the Verifizierungsplan mapping table seeds item links (wildcards expanded, marked convention-derived); the red line (ADR-0075) applies unchanged.
Staging¶
- Stage 1: the block (editor + schema + freeze/derive/dispose/RLS/search/PDF sweep), scope key conventions + type flag, the registry view.
- Stage 2: item links + suspect flags + clearing flow.
- Stage 3: item-level coverage in the trace matrix + PULSEMED migration.
Consequences¶
- Full schema-extension lifecycle sweep for the new node (the ADR-0069-established discipline); registry/coverage are derivations — nothing stored that can drift.
- The TD dossier's
SectionPin.kind=ITEMseam becomes realizable (a dossier section may later pin requirement sets); not built here. - PDF export renders requirement blocks with their key + attributes (identity-stable print form).
- The projection/markdown round-trip must carry the block losslessly (fidelity gate extension).
Clarification (2026-07-19): the table-form half of §7 — stakeholder items + the satisfies matrix¶
Decided by Nicolas 2026-07-19 ("go with your recommendations"), after his live check: the SRS was migrated (stage 3, bold-prose recognition) but PULSEMED-REC-007's stakeholder requirements were not — §7 decided BOTH representations; this realizes the table-form half. Nothing above changes.
- Table-row recognition. REC-007's 72 keyed definition rows in four families —
NA(use requirements, 9),GA(legal/regulatory, 41),MA(market, 18),ZP(reliability/performance, 4) — become:::requirementblocks withkind="stakeholder"(the §1 fixed vocabulary's designed value; NOT a legacy-taxonomy invention — the defining document is the stakeholder requirements specification). TheSH-xxrows are stakeholder GROUPS (actors), not requirements — they stay a plain table. Non-key columns (Stakeholdergruppe, Verantwortlich, Zielwert…) fold into the block body as labeled lines — no content is dropped (ADR-0075 honesty). - Type governance stays narrow. The stakeholder-requirements page gets a name-derived subtype
STKREQ(the SRS/ARCH/RISK import pattern) andmay_define_requirementsis flagged for (PULSEMED, STKREQ) — NOT for REC scope-wide, which would let every record define requirements (against §3's deliberate-definition posture). Consequence: the document's human id changes on re-import (REC numbering compacts) — pre-production reseed culture, ADR-0058. - The manual traceability matrix becomes
satisfieslinks. The SRS's four Rückverfolgbarkeit tables (NA/GA/MA/ZP → SSRS/SAS key lists + per-row Begründung) seed item links: source = the SOFTWARE requirement key (the SRS authored the mapping — honest provenance), type =satisfies, target = the stakeholder key. Parsing is column-aware (stakeholder key from column 1, software tokens from column 2 ONLY — rationale prose also mentions keys and must not seed links). Token expansion reuses the stage-3 machinery (hyphen/en-dash ranges,_xxx/_*globs, escaped\*); unparseable fragments (e.g. the dangling, –003) are LOGGED, never guessed. Each link's V056notecarries the convention-derived marker plus the row's Begründung. - Coverage evidence extends to
satisfies(§6). A requirement counts as covered with ≥1 inboundverifiesORsatisfieslink; the two counts are reported SEPARATELY (a stakeholder requirement is satisfied by software requirements; a software requirement is verified by test/verification items — the data directions make each kind read correctly without special-casing). The coverage panel's kind filter now has real data to bite on. Suspect semantics (§5) apply to satisfies links unchanged — an SRS requirement changing under a stakeholder link flags it.