Software Requirements: Design Validation & the Validation Traceability Axis¶
Introduced in requirements baseline v1.9 (ADR-0084, Stage C — the validation axis of the
traceability model, traceability-model.md §4 view 3). This group covers design validation
in the ISO 13485 §7.3 sense — user needs, the validation cases that prove "the right product",
and the design elements that realize requirements — not the CSV validation of LQMS itself
(STR-014). The three trace-item types are additive registrations on the ADR-0078 substrate (the
extraction/registry/link/suspect/coverage engines are unchanged); the validation matrix is a
derived view (nothing stored).
| ID | Requirement | Trace |
|---|---|---|
| REQ-VAL-001 | A user need shall be a keyed trace item (node userNeed, fence :::user-need) inside a controlled document — the top of the V ("the right product") and the target of the validates edge — carrying the single FIXED attribute source (a free token naming who the need comes from) with the need statement in the block body. Its key shall be unique per scope across ALL trace-item types (the one keyspace, ADR-0078 §4) and its identity/versioning DERIVED from the defining document's content hash (no separate item state), exactly as a requirement item (REQ-DOC-034/035). Whether a document type may define user-need items shall be governed by the per-(scope, type) may-define flag (REQ-DOC-034). Registration shall be ADDITIVE — the extraction, registry, link, suspect and coverage engines are unchanged (ADR-0078) — and the block shall round-trip losslessly through the Markdown projection, render as a formatted PDF fence, and be swept through the full content lifecycle (freeze, derive, disposal, RLS, search). |
STR-001, STR-027; ADR-0084, ADR-0078, ADR-0057 |
| REQ-VAL-002 | A validation case shall be a keyed trace item (node validationCase, fence :::validation-case) carrying the single FIXED attribute intendedUseRef (a free token/text — the real linkage is the edge, so the item stays lean) with the case narrative in the body, and shall be a valid SOURCE of the new validates edge to a user need (REQ-VAL-001). The validates edge (REQ-REL-007) shall be authorable from a validation-case item OR from a document-level source (a whole Validation Plan/Report validating the need directly), and its suspect flag shall fire when the target user need's content changes. Whether a document type may define validation-case items shall be governed by the per-(scope, type) may-define flag (REQ-DOC-034); the registration is additive (engines unchanged, ADR-0078). |
STR-001, STR-027; ADR-0084, ADR-0078 |
| REQ-VAL-003 | A design element shall be a keyed trace item (node designElement, fence :::design-element) — the architecture/design how between a requirement and its verification — carrying the single FIXED attribute designKind (validated per REQ-VAL-004) with the element description in the body, and shall be a valid SOURCE of the existing satisfies edge to a requirement item (the design realizes the requirement; the edge gains a new source type type-agnostically, no vocabulary change — REQ-REL-007, the V055 edge finally getting its intended source type). Whether a document type may define design-element items shall be governed by the per-(scope, type) may-define flag (REQ-DOC-034); the registration is additive (engines unchanged, ADR-0078). |
STR-001, STR-027; ADR-0084, ADR-0078 |
| REQ-VAL-004 | A design element's designKind shall be constrained to a STRICT per-scope value set. The tool ships a default vocabulary (architecture, interface, component, unit) that a scope may OVERRIDE, editing the set on the per-scope QMS-configuration surface (REQ-UI-018), gated by ACTIVATE_CATALOG_ENTRIES to write and VIEW to read; the effective set is the scope's rows when it has any, else the shipped default (saving rows is a full per-scope override, clearing them reverts to the default). On save of a design element, a designKind that is a non-blank value OUTSIDE the scope's effective set shall be rejected with HTTP 422 naming the offending value and the allowed set, while a blank/unset designKind shall be tolerated (the pre-save authoring rule). The value set shall be content-plane, scope-keyed under RLS (never visible or writable across scopes). It is a configurable variation point — design taxonomies genuinely differ by project — NOT an escape hatch from the process (the opinionated-by-default principle). |
STR-003, STR-027; ADR-0084, ADR-0078 |
| REQ-VAL-005 | The system shall derive, per scope, a live VALIDATION MATRIX read model (VIEW_TRACEABILITY-gated, RLS-scoped, nothing stored): each user need → its inbound validates evidence (validation-case items and/or document-level validating records), each evidence carrying the ADR-0088 planned-vs-verified class and its release date; plus the design-realization leg (design elements → the requirements they satisfies). It shall roll up non-suppressible gap flags — NEED_NOT_VALIDATED (no visible validating source), VALIDATION_PLANNED_ONLY (validated only by planned-class evidence), SUSPECT_ON_PATH — and shall degrade an invisible/disposed source to ABSENT (never a leak; an existence-safe gap). It shall be exportable as a flat CSV matrix (one row per need→validation path), the export recording one scope-level EXPORTED audit event carrying the exporting tool version. The matrix shall surface on the traceability workspace as a sub-page + hub tile (REQ-UI-022) and as a section of the derived traceability report (REQ-REP-010). |
STR-011, STR-027; ADR-0084, ADR-0088, ADR-0080 |