Arc Skills / Configuration and change control

Build a requirement traceability matrix

Use Arc Skills to build a requirement traceability matrix from a named snapshot and recorded relationships. The matrix shows where each requirement came from, what implements it and which evidence supports it, while keeping absent links and unexecuted tests visible.

Use this skill

Use Arc Skills to build a requirement traceability matrix.

Inputs:
- In-scope requirements with IDs, wording and revisions
- Recorded source, allocation and test links
- Results, evidence and tested configurations

Return a bidirectional RTM with source, requirement, allocation, test, result, evidence applicability, gap and owner. Do not infer trace links from similar wording. Reconcile all in-scope rows and explain the coverage denominator.

Set up the toolkit · Read the skill instructions

What you provide and what you get

Inputs and outputs
What you have	How it is used	What you get
A named requirement snapshot	Set scope and preserve IDs	One reconciled row per requirement
Recorded upstream and downstream links	Follow actual trace relationships	Source, implementation and test columns
Executed evidence and configuration	Distinguish planning from demonstrated results	Evidence status and gap register

Three requirements, two defined tests and one applicable result

Illustrative engineering example.

Baseline B contains three requirements. The export explicitly records two test links; it does not contain a test for REQ-03.

Scope: baseline B, REQ-01/02/03.
NEED-01 → REQ-01 rev B → SYS-10 → TEST-01. RUN-01 passed on hardware H2 / firmware F3.
NEED-02 → REQ-02 rev A → SYS-20 → TEST-02. TEST-02 has no run.
REQ-03 rev A has no source link, allocation or test in this export.

Three requirements, two defined tests and one applicable result
Requirement	Source / allocation	Test / result	Evidence status	Gap and owner action
REQ-01 rev B	NEED-01 / SYS-10	TEST-01 / RUN-01	Applicable to B: H2 / F3 matches the required configuration	No gap found in supplied trace; retain report locator
REQ-02 rev A	NEED-02 / SYS-20	TEST-02 / none	Test defined; execution evidence absent	Verification owner schedules execution
REQ-03 rev A	No recorded source / unallocated	No test / no result	No verification link recorded	Requirement owner resolves source and allocation; verification owner defines coverage

The denominator is three in-scope requirements. Recorded test links cover 2/3; applicable passing evidence covers 1/3. These counts measure different things and should not share a single “coverage” percentage.

REQ-03 may have evidence outside this export, but the supplied snapshot cannot establish it. Similar wording in another test is a candidate for owner review, not permission to invent a trace link.

Keep trace, plans and results in separate columns

Choose scope, snapshot and trace direction before counting completeness.
Resolve every recorded source and destination at its stated revision, preserving wording.
Show missing links, tests with no runs, failed runs and stale evidence as distinct findings.
Reconcile the requirement count and separately report link coverage and evidence status.

Questions about this task

How is an RTM different from a verification matrix?

An RTM follows recorded upstream and downstream relationships. A verification matrix defines how obligations will be verified. A proposed method is not an existing test link or executed evidence.

Sources and further reading

NASA Systems Engineering Handbook: configuration management: Background on identifying configurations and controlling baseline changes.

References inspected on 3 October 2026. The worked output is an authored example using the stated inputs.