How to Create and Use a Requirements Traceability Matrix (RTM)

Chapters

Chapter 4: How to Create and Use a Requirements Traceability Matrix (RTM)

Chapters

How to Create and Use a Requirements Traceability Matrix (RTM)

Creating a Requirements Traceability Matrix (RTM) is a critical step for ensuring product quality and achieving regulatory compliance. In the previous section, we defined what a requirements traceability matrix is and its purpose. Now, we will shift focus to the practical application: how to build one that effectively tracks requirements through the development lifecycle.

Without a properly structured RTM, teams risk “orphan” requirements, features that are built but never tested, or scope creep, where features are built without a defined requirement. By following a structured approach to creating and using an RTM, you ensure that every requirement is accounted for, tested, and validated before release.

Steps to Create a Requirements Traceability Matrix

Creating a requirements traceability matrix (RTM) helps engineering teams connect requirements to design artifacts, test cases, and verification results throughout product development. Whether you’re using a spreadsheet or dedicated requirements management software, follow these eight steps to establish and maintain accurate traceability.

1. Identify and Organize Requirements

Start by gathering functional and non-functional requirements from stakeholder needs, system specifications, regulatory standards, and other relevant project documentation. Establish an approved or controlled version of the requirements to serve as the starting point for traceability. Requirements don’t need to remain unchanged throughout development, but teams should document revisions so they can identify which versions were used for design and verification.

2. Assign Unique Requirement IDs

Give each requirement a unique identifier that remains consistent across development artifacts. A structured naming convention makes it easier to identify requirements and trace relationships across systems. For example:

  • SYS-001: System-level requirement
  • SW-001: Software requirement
  • HW-001: Hardware requirement

Use these identifiers consistently in design specifications, test cases, and other related documentation to prevent confusion as requirements evolve.

3. Define Traceability Criteria

Determine which relationships your RTM needs to capture based on project complexity, development processes, and applicable industry standards. Common relationships include:

  • Stakeholder needs to system requirements
  • System requirements to subsystem or software requirements
  • Requirements to design specifications
  • Requirements to verification test cases
  • Safety requirements to associated risk controls

For regulated products, traceability may need to extend across multiple engineering disciplines to demonstrate that requirements have been implemented and verified.

4. Create the RTM Structure

Organize the matrix so each requirement can be traced to its source and relevant downstream artifacts. A basic RTM should include the following columns.

Column Information to capture
Requirement ID Unique identifier, such as SYS-001
Requirement description The expected functionality or constraint
Source Stakeholder need or higher-level requirement
Design reference Related design specification or component
Test case ID Linked verification test
Verification status Not Run, Passed, Failed, or Blocked
Risk control Associated risk mitigation, if applicable

Additional fields may include requirement version, verification method, approval status, and applicable regulatory references. Keep the structure focused on the relationships your team needs to maintain rather than adding fields that don’t support traceability or reporting.

5. Link Requirements to Test Cases

Connect each requirement that needs verification to the appropriate test case or other verification activity. These relationships establish forward traceability and help teams determine whether requirements have sufficient verification coverage. For example, a software requirement might specify that a user account must lock after five consecutive failed login attempts. The RTM would link that requirement to a test case verifying that the account locks after the fifth failed attempt. Some requirements require multiple test cases or different verification methods. Review the relationships to ensure the planned verification activities adequately cover each requirement.

6. Record Verification Results

As verification activities are completed, update the RTM with the corresponding results. Common statuses include:

  • Passed: The verification activity met its defined acceptance criteria.
  • Failed: The result did not meet the acceptance criteria and requires investigation.
  • Blocked: The verification activity could not be completed because of a dependency or unresolved issue.
  • Not Run: The verification activity has not yet been executed.

Where applicable, include references to test execution records and associated defects. This helps teams distinguish between requirements with planned verification coverage and requirements that have been successfully verified.

7. Maintain and Update the RTM Continuously

Update traceability relationships whenever requirements, designs, or verification activities change. For example, if a medical device requirement changes the maximum allowable alarm response time from five seconds to three seconds, teams should review the associated design specification, test cases, and verification evidence to determine what needs to be updated or repeated. Record the revised requirement version and reassess affected relationships so the RTM continues to reflect the current development baseline.

8. Review the RTM for Completeness

Regularly review the matrix to identify missing relationships, incomplete verification coverage, and outdated information. Check for:

  • Requirements without linked verification activities
  • Test cases or design artifacts without a documented source requirement
  • Failed, blocked, or incomplete verification activities
  • Traceability links that require reassessment following a change
  • Missing risk control relationships where applicable

Perform these checks throughout development and before major reviews or release milestones. A complete RTM should demonstrate that applicable requirements have traceable sources and sufficient evidence of implementation and verification.

Circle graph showing the steps to create a requirements traceability matrix

Ready to Find Out More?

Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started with a free 30-day trial, or book a demo!

How to Check an RTM for Missing Links and Test Coverage

After creating a requirements traceability matrix, teams should review it for missing relationships and incomplete verification coverage. A basic RTM review should identify:

  • Requirements without test cases: Requirements that lack linked verification activities.
  • Tests without requirements: Test cases that cannot be traced to an approved requirement.
  • Failed or incomplete tests: Requirements whose verification evidence does not demonstrate successful completion.
  • Outdated relationships: Links that need reassessment after requirements or design changes.
  • Missing risk controls: Safety-related requirements that lack applicable risk or mitigation references.

These checks help teams identify traceability gaps before formal reviews, testing milestones, or compliance audits.

How to Maintain an RTM When Requirements Change

A requirements traceability matrix must reflect changes to requirements, design specifications, and verification activities throughout development. When a requirement changes, teams should review its existing trace links, identify affected design and test artifacts, and determine whether additional verification is necessary. The updated requirement version and associated test results should be recorded so the matrix accurately reflects the current development baseline.

For example, if a medical device’s alarm response requirement changes from five seconds to three seconds, the associated design specification and verification test may also need updates. The RTM helps identify those dependencies and track whether the revised requirement has been verified. Maintaining these relationships as changes occur reduces the risk of outdated verification evidence and incomplete traceability during reviews or audits.

Best Practices for Using a Requirements Traceability Matrix

Creating an RTM establishes the relationships between requirements and development artifacts. Maintaining those relationships throughout development requires consistent processes, clear ownership, and regular reviews. The following best practices help teams keep traceability accurate and useful as projects evolve.

  • Standardize identifiers and relationship types: Establish consistent naming conventions and traceability rules across teams. This helps engineers understand how requirements connect to design, testing, and risk management activities without ambiguity.
  • Assign clear ownership: Define who is responsible for maintaining requirements and their associated traceability links. Clear accountability helps prevent gaps when requirements change or work moves between engineering teams.
  • Review traceability at key milestones: Assess requirements coverage and verification status during design reviews, testing milestones, and release readiness assessments. Regular reviews help teams identify missing or outdated relationships before they affect downstream activities.
  • Maintain change history and verification evidence: Document requirement revisions, approvals, and associated verification updates. This preserves the context behind changes and supports impact analysis and compliance audits.
  • Automate traceability as complexity increases: As requirements and dependencies grow, manual maintenance becomes harder to sustain. Dedicated requirements management software can help teams maintain relationships, identify coverage gaps, and assess changes across development artifacts.

Consistent traceability practices help ensure the RTM remains a reliable resource for engineering decisions, verification planning, and compliance throughout the product lifecycle.

Requirements Traceability Matrix Example

Consider a hypothetical medical device with a requirement that an audible alarm activate within five seconds of detecting an occlusion. In a requirements traceability matrix, that requirement would be linked to its source, the alarm design specification, the associated verification test, and any applicable risk controls.

If the verification test fails, the matrix helps engineers identify which requirement remains unverified and which related artifacts may need review. This provides a clear record of the relationship between the original requirement and its verification evidence.

An RTM becomes most valuable when applied to tangible development scenarios. For example, consider a development team building a secure login feature for a banking app. The RTM ensures each security requirement is strictly validated through linked test cases and results.

Spreadsheet of an example requirements traceability matrix in action

This RTM example shows how requirements, test cases, and results are linked in a single view, providing full visibility and compliance evidence. In this scenario, the “Failed” status on TC-203 immediately alerts the team that a critical security feature is not functioning, preventing a potential vulnerability from reaching production. Without an RTM, missing test cases or failed validations might go unnoticed until late in the project.

Supporting Automated RTM Creation With Jama Connect

As requirements and trace relationships grow, maintaining a spreadsheet-based RTM becomes more difficult. Jama Connect supports Live Traceability™ across requirements, design, testing, and risk management. Its Traceability Information Model (TIM) defines expected relationships between development artifacts, helping teams identify missing links, assess change impacts, and maintain verification coverage as development progresses.

See how Jama Connect supports requirements traceability and audit readiness. Start your free 30-day trial.

In This Webinar, Learn How to Improve Traceability and Enhance Coverage with Live Trace Explorer™

DEFINITION OF REQUIREMENTS TRACEABILITY MATRIX:

Requirements Traceability Matrix (RTM) is a document in which product teams track the relationships between requirements, verification, risks and other artifacts throughout the product development process.

Book a Demo

See Jama Connect in Action!

Our Jama Connect experts are ready to guide you through a personalized demo, answer your questions, and show you how Jama Connect can help you identify risks, improve cross-team collaboration, and drive faster time to market.