research-document FE-BND-CARD-B03-M2
B03
card_id: B03
input: A set of requirements and their originating statements/actors/documents (pre-RS material) plus a baselined Requirements Specification (RS) and its downstream derived artifacts (post-RS material).
operation: Establish and maintain two distinguishable kinds of trace links: pre-RS traceability (linking a baselined requirement back to the originating statements, discussions, and individuals that produced it) and post-RS traceability (linking a baselined requirement forward/backward through derived design, code, test, and other lifecycle artifacts). The source's empirical recommendation is to capture pre-RS information eagerly (during production) and support lazy/on-demand retrieval later, because locating and accessing original sources/participants was the most commonly cited failure point.
output: A network of forward/backward-traceable links plus an ongoing ability to locate and contact the people responsible for a requirement's origin and evolution.
scope_conditions: Any requirements engineering process producing a Requirements Specification with subsequent lifecycle artifacts; applies to individual and group/organizational RE settings.
failure_conditions: Post-RS-only tooling treats the RS as a black box and cannot recover why a requirement exists; pre-RS traceability degrades when responsible individuals are inaccessible (turnover, undocumented contributors, political barriers) — empirically the single most commonly cited problem across 100+ practitioners studied.
predicted_effect: Improved ability to audit, re-open, and re-work earlier RE decisions, and more economical RS maintenance; direction only, drawn from the study's stated findings.
measurement: The paper's empirical method (questionnaires, focus groups, interviews, tool review) measured practitioner-reported RT problems by frequency/type. RE03 supplies a directly measurable operational proxy: percentage of commits linked to originating issues (60% average across 6 projects) and precision/recall of automated link recovery.
implementation_test: For a sampled requirement, attempt to retrieve (a) its originating statement/author (pre-RS) and (b) its forward derivation chain into design/code/test artifacts (post-RS); RE03 operationalizes an analogous test for commit-to-issue links, measurable by precision/recall.
decision_rights: Not centrally assigned in RE02; the paper recommends explicit job roles (project librarian, repository manager, RT facilitator) to own different parts of the traceability task.
uncertainty_handling: No calibrated mechanism; the paper documents that stakeholders hold conflicting, non-generalizable definitions of "traceability" and treats this as an open research problem.
verification: Trace-link retrieval audit for a sample of requirements/commits; RE03 reports precision (33-96%) and recall (50-96%) for automated link recovery.
provenance: RE02 sections 5.1-5.4, 6, 7, 8; RE03 abstract and approach sections.
implementation_cost: Not quantified in RE02; RE03 reports concrete precision/recall tradeoffs for an automated approach run against real project histories.
limitations: RE02 predates modern version-control-based traceability tooling; ISO/IEC/IEEE 29148:2018 remains abstract-only and was not read directly.
statement_basis: direct: ["pre-RS/post-RS definitions", "empirical finding that source-location is the most cited RT problem", "RE03 precision/recall figures"] inference: ["predicted_effect phrasing is curator paraphrase of the paper's stated benefits (auditing, repeatability, economic leverage)"]