Traditional Forward and Backward Analysis

Traditional Forward and Backward Analysis

Why this page comes first

flexo-rtm's primary surface is traditional Requirements Traceability Matrix (RTM) analysis, in the form that Doors, Jama, Polarion, and OSLC-RM users already recognize. Practitioners can adopt this analysis on day one to produce familiar requirements traceability reports — without committing to the deferred topological assurance framework. The topological framework (assurance triangles, V−F invariants, recursive completeness) extends traditional bidirectional analysis; it does not replace it.

This page specifies the v0.1 primary surface. Everything described here ships in v0.1 and is governed by the §9.A acceptance criteria in Design Spec — specifically X1 (determinism), X2 (replay), X3 (quantitative outcomes only), and X8 (structural completeness without dereferencing). The bidirectional analysis is exactly what those criteria anchor as the v0.1 release gate.

Historical context

Gotel and Finkelstein, in their 1994 paper An Analysis of the Requirements Traceability Problem, gave the foundational definition that has shaped the field for three decades: requirements traceability is "the ability to describe and follow the life of a requirement, in both forwards and backwards direction." They distinguished pre-RS traceability (the origins of a requirement — stakeholders, rationale, environmental constraints) from post-RS traceability (a requirement's life through design, implementation, and verification). The traditional RTM is the post-RS surface, and it is what virtually every industrial requirements tool ships today.

ISO/IEC/IEEE 29148:2018 codifies bidirectional traceability as a requirements engineering best practice. The standard articulates two complementary purposes: impact analysis when a requirement changes (which downstream artifacts are affected?) and completeness demonstration that every stated requirement has been addressed and every produced artifact ties back to a stated need. v0.1's bidirectional analysis serves both purposes directly.

The OSLC-RM 2.1 specification carries this lineage into the linked-data era. Its oslc_rm:tracedTo predicate is the canonical machine-readable form of the post-RS verification edge. v0.1 maps directly onto this predicate (see Mapping to OSLC-RM below).

Minimal vocabulary

v0.1 traditional analysis runs against a deliberately bare RTM kernel:

• rtm:Requirement — a stated requirement
• rtm:Artifact — evidence (a SysMLv2 model element, a proof script, a simulation result, a test report, an inspection record, …)
• rtm:satisfies (Artifact → Requirement) — the verification edge: "this artifact claims to satisfy this requirement"

That is the entire vocabulary needed for bidirectional analysis. Adopters MAY also populate the richer vocabulary described in Design Spec §4.2 (guidance, attestations, aspects), but v0.1 does not require it for forward and backward analysis to produce a valid report.

Forward traceability analysis

Definition. For each requirement $r \in R$, enumerate the artifacts that claim to satisfy it: ${a \in A : a \texttt{ rtm:satisfies } r}$. A requirement is forward-covered if this set is non-empty.

SPARQL pattern (illustrative):

PREFIX rtm: <https://flexo-rtm.org/ns/core#>

SELECT ?req (COUNT(?art) AS ?evidenceCount) WHERE {
  ?req a rtm:Requirement .
  OPTIONAL { ?art rtm:satisfies ?req . }
}
GROUP BY ?req
ORDER BY ?req

The ORDER BY clause is load-bearing for the determinism criterion X1: deterministic SPARQL solution ordering is what makes transcripts byte-identical across runs. The oracle wraps every query with stable ordering before recording it in the audit transcript.

A requirement is forward-covered iff evidenceCount > 0. Requirements with evidenceCount = 0 are forward gaps and surface as T1.orphan-requirement (below).

Backward traceability analysis

Definition. For each artifact $a \in A$, enumerate the requirements it claims to satisfy: ${r \in R : a \texttt{ rtm:satisfies } r}$. An artifact is backward-traced if this set is non-empty.

SPARQL pattern (illustrative):

PREFIX rtm: <https://flexo-rtm.org/ns/core#>

SELECT ?art (COUNT(?req) AS ?requirementCount) WHERE {
  ?art a rtm:Artifact .
  OPTIONAL { ?art rtm:satisfies ?req . }
}
GROUP BY ?art
ORDER BY ?art

An artifact is backward-traced iff requirementCount > 0. Artifacts with requirementCount = 0 are backward gaps and surface as T2.dangling-evidence (below). Foundational artifacts (axioms, immutable inputs the project takes as given) are excluded from the backward denominator by scope policy; the scope definition is itself a deterministic input recorded in the transcript.

Coverage statistics

Per the X3 criterion, coverage is always reported per dimension — never rolled into a single "% certified" headline number.

• Forward coverage $% = \dfrac{|{r \in R : r \text{ forward-covered}}|}{|R|}$
• Backward coverage $% = \dfrac{|{a \in A : a \text{ backward-traced}}|}{|A_\text{non-foundational}|}$

A v0.1 audit report carries both percentages, both raw counts, and the full per-row enumeration. It does not synthesize them into a single grade. Practitioners reading the report see exactly which requirements are uncovered and exactly which artifacts are dangling.

Traditional gap codes

v0.1's traditional analysis surfaces two gap codes drawn from the canonical gap taxonomy (see Gap Taxonomy):

Code	Meaning	Direction
T1.orphan-requirement	a requirement $r \in R$ with no incoming rtm:satisfies edge	forward
T2.dangling-evidence	an artifact $a \in A_\text{non-foundational}$ with no outgoing rtm:satisfies edge	backward

T1 and T2 are the only gap codes the v0.1 traditional analysis can produce. The remaining gap codes (T3–T8 for structural issues, G3–G9 for guidance-mediated and topological issues) require the additional vocabulary and the deferred framework respectively; see Gap Taxonomy.

Basic certification predicate

A graph passes basic certification at scope S iff (subject to configurable thresholds):

$$\text{Forward coverage } % \geq \theta_\text{forward} \quad \wedge \quad \text{Backward coverage } % \geq \theta_\text{backward}$$

Defaults: $\theta_\text{forward} = \theta_\text{backward} = 100%$. Thresholds are configurable per project; the chosen values are recorded in the transcript so the certification predicate is reproducible.

This predicate matches exactly what Doors/Jama practitioners call "RTM is complete." The oracle's certify --level=basic runs only this analysis: SPARQL-driven, fast, familiar, no commitment to guidance vertices or attestation structure.

Reports in familiar form

v0.1 produces the report views Doors/Jama users immediately recognize:

• Tabular RTM view — rows = requirements, columns = artifacts (or transposed); each cell indicates the presence or absence of an rtm:satisfies edge.
• Coverage summary — forward %, backward %, T1 count, T2 count, per-row enumeration of which requirements are orphaned and which artifacts dangle.
• Per-aspect breakdown — if aspect tags are present (functional, performance, safety, …), the same statistics are reported per aspect, consistent with X3.

Every report is generated from the recorded SPARQL transcript, so any consumer can replay the query and verify the report against the source graph (X2). Reports include the canonical input hash and the transcript hash so structural completeness (X8) can be confirmed without dereferencing external URIs.

Mapping to OSLC-RM

v0.1's traditional analysis maps directly onto OSLC-RM 2.1 core. The predicate equivalence is:

$$\texttt{oslc_rm:tracedTo} \equiv \texttt{rtm:satisfies}$$

with the verification direction preserved (artifact → requirement). A graph imported through the OSLC-RM adapter is immediately analyzable at the traditional level — no additional guidance vertices, no attestations, no profile composition required. This is by design: a team running Doors today can stand up a flexo-rtm instance, point it at their existing OSLC-RM endpoint, and produce a coverage report in minutes. See OSLC RM and QM Review for the full adapter mapping and roundtrip semantics.

What v0.1 does NOT do

The traditional bidirectional analysis is the v0.1 primary surface. It is intentionally narrow. The following capabilities are deferred to the future topological framework (see Design Spec §4.10) and are NOT part of v0.1's traditional analysis:

• No guidance vertices required. v0.1 does not require an rtm:Guidance node mediating each verification edge. (Adopters MAY add guidance — see Design Spec §4.2 — but bidirectional analysis runs without it.)
• No assurance triangle closure. v0.1 does not check that an artifact, a requirement, and a guidance vertex form a closed triangle with the required attestations on each face. Triangle closure is part of the deferred topological framework — see Topological Framework Future Work.
• No V−F invariant computation. v0.1 does not compute the vertex-minus-face topological invariant. That audit lands with the deferred framework.
• No adequacy/sufficiency judgment. v0.1 records rtm:AdequacyAttestation and rtm:SufficiencyAttestation when present, but bidirectional analysis does not surface adequacy or sufficiency findings; those are guidance-mediated gap codes (G3–G9) and require the deferred audit.
• No recursive guidance completeness. v0.1 does not check whether the guidance itself is fit-for-purpose. The recursive completeness check requires the registry and is deferred.
• No rolled-up grade. Per X3, no audit report contains a single "% certified" headline. Quantitative outcomes are always reported per dimension.

These capabilities live in the deferred framework. v0.1 reserves the vocabulary they will use (see Design Spec §4.2) so adopters can begin populating it now; the topological audit that consumes it ships later.

How the traditional analysis composes with the future framework

The traditional bidirectional analysis is not a stepping stone that is replaced; it is the persistent base layer the topological framework extends.

• Every future topological "pass" implies a traditional pass: the topological framework's verification edge IS rtm:satisfies.
• A traditional pass does NOT imply a topological pass: the topological framework adds requirements (closed triangles, named attestations on each face, V−F invariant).
• Adopters migrate incrementally. Coverage statistics are reported at both layers so progress is visible at every stage of adoption.
• A team that never adopts the future framework still gets an open-source, OSLC-RM-roundtrip-capable, transcript-replayable RTM with reproducible certification artifacts — a meaningful complement to whatever RM tooling they already use.

Reference implementation lineage

The ADCS prototype's traceability/audit.py module implements forward and backward analysis as independent checks today, and has done so since the project's early commits. The traditional analysis is well-trodden ground. What flexo-rtm adds is the explicit formalization as the v0.1 primary surface, with SPARQL-driven SPARQL/SHACL transcript replay (X1, X2), per-dimension quantitative outcomes (X3), and structural completeness verifiable without dereferencing external URIs (X8). See ADCS Prototype Lessons for the full carry-forward analysis.

Why this matters for adoption

Institutional requirements management today is well-served by Doors, Jama, Polarion, and similar incumbents — but their certification artifacts are proprietary and their data is locked behind commercial agreements. flexo-rtm adds three properties the existing ecosystem doesn't yet supply natively: open data portability (RDF graphs with OSLC-RM roundtrip), reproducible certification (canonical hashes + replayable transcripts), and federable verification (third parties can re-check without proprietary access; see Federated Audit and Composition). These are properties an organization gains regardless of whether it keeps using its existing RM tool or transitions; they are also properties incumbent vendors and their hosting partners can offer their customers atop the open standard.

Adopters can pick whichever path suits their context: pair flexo-rtm with existing RM tooling via OSLC roundtrip, run flexo-rtm standalone, or work through a vendor or hosting provider that supports the open standard. Each path produces the same artifact: a deterministic, replayable, lossless RTM with reproducible provenance. Those who later choose to commit to the topological framework can do so incrementally, on their own timeline, without abandoning the analysis they already trust. That dual-mode adoption path is the central rationale for putting traditional analysis first; see Mission and Thesis and Verifiable Self-Certification for the framing context, and Quantitative Outcomes for how the per-dimension reporting contract enforces X3.

See also

• Design Spec §4.1 (normative definitions), §9.A.5 (acceptance criteria X1–X3, X8), §4.10 (deferred topological framework)
• Topological Framework Future Work
• Certification Predicate
• Gap Taxonomy
• Quantitative Outcomes
• OSLC RM and QM Review
• ADCS Prototype Lessons