To build a requirements traceability matrix with AI, freeze an approved requirements baseline, assign unique IDs, and define the relationships the matrix is allowed to contain. Ask AI to propose candidate links only when it can quote the supporting text and identify the source. Then have requirement, design, implementation, test, safety, and compliance owners confirm every relationship and result.

An RTM is evidence infrastructure, not a spreadsheet generated once at the end. It should support forward tracing from each approved requirement to design, implementation, verification, and evidence, plus backward tracing from implementation and tests to an authorized requirement. AI can reduce clerical effort, but it must not invent requirements, mappings, test outcomes, waivers, or compliance conclusions.

Use a separate project plan for schedules and dependencies. The broader guide to using AI explains how to limit model authority, while the human-approval workflow can bind approvals to a versioned matrix export.

Key Takeaways

Start with approved, uniquely identified, versioned requirements.

Make every relationship explicit and supported by quoted evidence.

Treat AI output as candidate mappings, never accepted truth.

Trace both forward coverage and backward authorization.

Distinguish planned verification from executed, reviewed evidence.

Maintain the matrix whenever requirements or downstream artifacts change.

Step 1: Freeze the requirements baseline

Identify the authoritative source: approved specification, contract, policy, architecture decision, regulatory interpretation, or controlled backlog. Record the baseline version, approval authority, date, scope, and change-control process. Preserve a read-only copy so later reviews can distinguish a changed requirement from a changed mapping.

Assign each requirement a unique, stable ID. Do not use a row number that changes when items are sorted. Capture the exact text, source location, rationale, owner, priority or criticality where approved, and current lifecycle status.

NASA’s requirements-management guidance describes establishing, controlling, verifying, validating, and tracing requirements through the lifecycle.［1］ That lifecycle perspective matters: an RTM must reflect controlled changes, not merely the latest collection of sentences.

Separate requirements from background explanation, goals, design ideas, assumptions, and examples. AI may identify a sentence as requirement-like, but only the authorized requirements process can accept it. Place unapproved candidates in an intake queue rather than silently assigning them requirement IDs.

Step 2: Improve atomicity and verifiability before mapping

Review each requirement for one bounded obligation, an identifiable subject, clear conditions, and a verifiable outcome. A compound statement joined by several “and” clauses may need approved decomposition. Preserve parent-child relationships and the original text; do not let AI rewrite contractual or regulated language as if the rewrite were authoritative.

Ask these questions:

Is the actor or system boundary clear?
Is the required behavior or quality observable?
Are triggering conditions and exceptions defined?
Are units, thresholds, and tolerances unambiguous?
Can a verification method determine pass or fail?
Does it conflict with or duplicate another approved requirement?

NASA’s requirements-validation guidance focuses on ensuring requirements are well formed, clear, complete, consistent, feasible, and verifiable before relying on them downstream.［3］ Record defects and route them to the requirement owner; do not repair them only inside the matrix.

Step 3: Define the matrix schema and allowed states

Choose fields before extraction. A useful template is:

Requirement ID	Source	Requirement text	Rationale	Owner	Status	Design	Implementation	Test or evidence	Result	Version
REQ-001	SPEC-3.2	Exact approved text	Approved rationale	Product owner	Baseline	DES-014	MOD-07	TP-031 / EV-031	Reviewed pass	2.1

Use the example only as a format. Define allowed values, such as candidate, reviewed, approved, implemented, verified, deferred, and retired, with who may set each one. Avoid a generic “done.” A requirement can be implemented but not verified, or tested but failed.

Represent links as stable artifact IDs plus versions, not informal descriptions. If a design document or test changes, the matrix should identify whether the previous review still applies. Include the exact evidence location—section, test case, result record, or controlled URL—so another reviewer can open it.

Step 4: build a requirements traceability matrix with AI from quoted candidate mappings

Provide only approved or clearly labeled artifacts, a glossary, the schema, and relationship rules. Split large source sets into reviewable batches while preserving artifact IDs and version metadata.

A controlled prompt is:

For each approved requirement, propose candidate relationships to the supplied artifacts. Return the requirement ID, target artifact ID and version, relationship type, an exact supporting quotation with location, and a short rationale. Use only supplied text. If support is ambiguous or absent, return UNRESOLVED. Do not create requirement IDs, artifacts, test results, statuses, waivers, or compliance claims.

Ask the model to cite both sides of a proposed link. Keyword overlap alone is insufficient: a test that mentions “timeout” may not verify the required timeout behavior. Require a reviewer to examine whether the target actually realizes or verifies the obligation and its conditions.

Protect sensitive specifications and security designs according to approved-tool, access, retention, and data-location rules. Minimize the material provided. NIST’s Generative AI Profile identifies confabulation, privacy, information security, and information-integrity risks that require governance and human oversight.［4］

Step 5: Resolve ambiguity, duplicates, and orphans

Review candidate mappings in small batches. For each link, select accept, reject, needs clarification, or needs owner. Record the reviewer, date, reason, and matrix version. Never treat a model confidence score as approval.

Look specifically for:

requirements with no design, implementation, test, or evidence;
one test linked to many requirements without proving each condition;
duplicate requirements with different IDs;
conflicting requirements or versions;
implementation that exceeds or contradicts the approved scope;
tests that exercise behavior no requirement authorizes;
links based only on similar words;
results copied from a plan rather than an executed record.

An orphan is a review signal, not automatic proof of failure. A newly baselined requirement may legitimately await design. Conversely, an implementation without a requirement might be necessary infrastructure, a defect fix, an undocumented requirement, or unauthorized scope. Route it to the accountable owner.

Use fact-checking controls when the matrix references external standards or claims. AI summaries of a standard are not a substitute for the approved interpretation.

Step 6: Establish forward traceability

Forward tracing asks whether every approved requirement has appropriate downstream realization and verification. Follow this chain:

requirement to architecture or design decision;
design to implementation component or configuration;
requirement to verification method and test procedure;
procedure to execution record and evidence;
evidence to reviewed result and disposition.

Do not skip the distinction between procedure and result. A test case ID proves only that a test was planned. A pass requires an executed result tied to the correct version and environment, plus review under the project’s process.

For non-test verification such as inspection, analysis, demonstration, or certification, record the method and evidence explicitly. A link to a folder is usually too broad; identify the artifact and section that demonstrates the requirement.

NASA’s bidirectional traceability guidance emphasizes tracing software test procedures to requirements and requirements to test procedures, with relationships maintained through the lifecycle.［2］ The exact artifacts vary by project, but both directions should be reviewable.

Step 7: Run the backward coverage check

Start from designs, implemented components, configurations, test procedures, and evidence. Ask which approved requirement authorizes or requires each artifact. This reveals gold plating, obsolete tests, undocumented behavior, and accidental scope expansion.

AI can group unlinked artifacts and suggest possible owners, but it must not create a requirement to justify them. Classify each item as:

linked and confirmed;
shared infrastructure with documented rationale;
defect correction linked to an approved issue or requirement;
candidate new requirement awaiting approval;
obsolete or out of scope;
unresolved.

Have architecture and implementation owners review the backward pass because requirement authors may not know every downstream artifact. For safety, security, regulated, or contractual work, use the project’s approved traceability tooling and domain-specific review process; this tutorial does not replace them.

Step 8: Maintain ownership and change control

Assign an owner for each requirement and for the matrix as a controlled artifact. Define review triggers: a baseline change, design revision, code change, test change, failed result, waiver, release candidate, or audit request.

When something changes:

record the change request and approval;
create the new artifact version;
identify affected relationships;
mark prior reviews as needing reassessment where appropriate;
rerun forward and backward checks;
collect new evidence;
approve and export a dated matrix snapshot.

Automated tools can flag stale links, missing fields, duplicate IDs, or invalid states. They cannot decide that changed evidence remains adequate. Keep that decision with named reviewers.

Convert the maintenance routine into an SOP or checklist, including access controls, backup, review frequency, and export format. Avoid parallel private copies that diverge from the controlled matrix.

Sample the matrix manually as well as checking completeness. Select several high-criticality requirements, several apparently simple ones, and several recently changed artifacts. Reconstruct each chain without relying on the person who created it. Sampling can expose precise-looking links that point to the wrong version or evidence that does not test the required condition. Record the sample, reviewer, findings, and corrective action with the matrix version.

Approval checklist

Before a release or formal review, confirm that:

the baseline and included versions are identified;
all requirement IDs are unique and approved;
every accepted link includes a target ID and review evidence;
all requirements have an appropriate forward disposition;
backward tracing found no unexplained implementation or test scope;
planned tests are not represented as passed results;
failed, deferred, waived, and unresolved items remain visible;
sensitive artifacts are protected;
specialist reviewers approved required safety or compliance interpretations;
the export and approval record refer to the same matrix version.

FAQ

What is a requirements traceability matrix?

It is a controlled mapping between approved requirements and related design, implementation, verification, evidence, results, ownership, and versions.

Can AI write requirements for the RTM?

It may identify candidate requirement-like text, but only the authorized process can create or approve a requirement. Keep candidates outside the accepted baseline.

What makes traceability bidirectional?

Forward tracing checks that requirements are realized and verified. Backward tracing checks that designs, implementation, and tests are supported by approved requirements or documented rationale.

Can one test cover several requirements?

Yes, if reviewers confirm that the procedure and evidence verify every linked condition. Do not infer coverage from shared vocabulary.

Is a link to a test plan enough?

No. A plan shows intended verification. Record the executed result, environment and version, evidence location, and reviewed disposition separately.

How often should an RTM be updated?

Update it whenever requirements or linked artifacts change and at defined review gates. Traceability that is refreshed only before an audit is likely to be stale.

What should happen to an orphan requirement?

Assign an owner and disposition: design needed, test needed, deferred, retired, duplicate, invalid, or unresolved. Do not hide it or ask AI to fabricate a link.

Can an RTM prove regulatory compliance?

Not by itself. It can organize approved obligations and evidence, but qualified experts and the applicable assurance process determine compliance.

Sources

NASA, Requirements Management — https://www.nasa.gov/reference/6-2-requirements-management/
NASA Software Engineering Handbook, Bidirectional Traceability Between Software Test Procedures and Software Requirements — https://swehb.nasa.gov/spaces/7150/pages/16449898/SWE-072%2B-%2BBidirectional%2BTraceability%2BBetween%2BSoftware%2BTest%2BProcedures%2Band%2BSoftware%2BRequirements
NASA Software Engineering Handbook, Requirements Validation — https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695440/SWE-055%2B-%2BRequirements%2BValidation
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 29 August 2026.

How to Build a Requirements Traceability Matrix with AI