---
title: "Requirements Traceability Matrix Template"
methodology: "traditional"
complexity: "advanced"
owner: "mirichard"
updated: "2026-09-19"
primary_principles: ["evidence-based-decisions", "quality-by-design"]
secondary_principles: ["stewardship"]
principle_rationale: "Traces requirements through design, changes and test evidence to expose coverage gaps and support controlled acceptance decisions."
---

# REQUIREMENTS TRACEABILITY MATRIX (RTM)

## When to Use

- When requirements must be traced through design, change, and acceptance evidence.
- When reviewers need to identify untested requirements or unsupported scope changes.

## When NOT to Use

- To equate a populated traceability row with passing verification.
- Do not treat completed metadata or a filled checklist as evidence that the underlying work is done. See [Metadata theater](../../../../../../../docs/principles/anti-patterns.md#metadata-theater).

## Pairs Well With

- [Requirements Specification Template](../../../../../../../domains/uncertainty/industry-specializations/information-technology/software-development/requirements_specification_template.md).
- [Test Plan Template](../../../../../../../domains/measurement/industry-specializations/information-technology/software-development/test_plan_template.md).

Selection context: Delivery domain; traditional methodology; advanced complexity. Match the situations above to project phase, risk, team size, and industry using the [decision-engine context model](../../../../../../../meta/architecture-research/800-801-context-assessment-model.md).

## Document Control Information
**Document Title:** Requirements Traceability Matrix Template  
**Project Name:** *[Project Name]*  
**Document Version:** 1.0  
**Prepared By:** *[Name], [Title]*  
**Preparation Date:** *YYYY-MM-DD*  
**Last Updated By:** *[Name], [Title]*  
**Last Revision Date:** *YYYY-MM-DD*  
**Approved By:** *[Name], [Title]*  
**Approval Date:** *YYYY-MM-DD*

---

## Overview

The Requirements Traceability Matrix (RTM) is a document that maps and traces user requirements with test cases. It supports finding coverage gaps throughout the project lifecycle. Trace links alone do not prove delivery: record test results, unresolved defects, and acceptance evidence for each applicable requirement.

**Purpose:**
- Track requirements from inception through delivery
- Ensure all requirements are addressed in design and testing
- Verify completeness of deliverables against Statement of Work (SOW)
- Facilitate change impact analysis
- Support project closure and acceptance criteria validation
- Maintain audit trail for compliance and quality assurance

**Scope:**
- All functional and non-functional requirements
- Business requirements from stakeholders
- Technical requirements and constraints
- Regulatory and compliance requirements
- Integration and interface requirements

---

## Requirements Categories

### Requirement Types
- **BR**: Business Requirement
- **FR**: Functional Requirement
- **NFR**: Non-Functional Requirement
- **TR**: Technical Requirement
- **CR**: Compliance/Regulatory Requirement
- **IR**: Interface Requirement
- **SR**: Security Requirement
- **PR**: Performance Requirement
- **UR**: Usability Requirement

### Requirement Priorities
- **Critical**: Must have - project cannot proceed without this
- **High**: Should have - important but not critical
- **Medium**: Could have - desirable but not essential
- **Low**: Won't have this time - future consideration

### Status Definitions
- **Proposed**: Requirement identified but not yet approved
- **Approved**: Requirement approved and baselined
- **In Design**: Requirement being addressed in design phase
- **In Development**: Requirement being implemented
- **In Testing**: Requirement being tested
- **Completed**: Requirement fully implemented and tested
- **Verified**: Requirement validated and accepted
- **Deferred**: Requirement postponed to future release
- **Cancelled**: Requirement removed from scope

---

## Requirements Traceability Matrix

### Matrix Headers Explanation
- **Req ID**: Unique requirement identifier
- **Requirement Description**: Detailed description of the requirement
- **Source**: Origin of the requirement (SOW, stakeholder, regulation, etc.)
- **Type**: Category of requirement (BR, FR, NFR, etc.)
- **Priority**: Importance level (Critical, High, Medium, Low)
- **Status**: Current state of the requirement
- **Design Reference**: Design document/section addressing this requirement
- **Implementation**: Code module/component implementing the requirement
- **Test Case ID**: Test case(s) validating the requirement
- **Verification Method**: How requirement completion will be verified
- **Acceptance Criteria**: Specific criteria for requirement acceptance
- **Assigned To**: Person/team responsible for implementation
- **Target Date**: Planned completion date
- **Actual Date**: Actual completion date
- **Comments/Notes**: Additional information or issues

---

## Requirements Matrix

| Req ID | Requirement Description | Source | Type | Priority | Status | Design Reference | Implementation | Test Case ID | Verification Method | Acceptance Criteria | Assigned To | Target Date | Actual Date | Comments/Notes |
|--------|------------------------|--------|------|----------|--------|-----------------|----------------|--------------|-------------------|-------------------|-------------|-------------|-------------|----------------|
| REQ-001 | *[Example: System shall authenticate users via single sign-on]* | SOW Section 3.1 | FR | Critical | Approved | Design-Auth-001 | Module-Auth | TC-001, TC-002 | Testing & Demo | User logs in with SSO credentials | John Smith | 2024-03-15 | | |
| REQ-002 | *[Example: System shall respond to user queries within 2 seconds]* | Stakeholder Workshop | NFR | High | In Development | Design-Perf-001 | Performance Module | TC-003 | Performance Testing | Response time ≤ 2 seconds | Jane Doe | 2024-03-20 | | |
| REQ-003 | *[Example: System shall maintain 99.9% uptime]* | SLA Agreement | NFR | Critical | In Design | Design-Infra-001 | Infrastructure | TC-004 | Monitoring | 99.9% availability over 30 days | Mike Johnson | 2024-04-01 | | |
| REQ-004 | *[Example: Data shall be encrypted at rest and in transit]* | Security Policy | SR | Critical | Approved | Design-Sec-001 | Security Module | TC-005, TC-006 | Security Audit | Encryption standards verified | Alice Brown | 2024-03-25 | | |
| REQ-005 | *[Example: System shall integrate with existing CRM via API]* | Integration Spec | IR | High | Proposed | TBD | TBD | TBD | Integration Testing | CRM data flows correctly | Bob Wilson | 2024-04-10 | | |
| REQ-006 | *[Example: User interface shall be accessible per WCAG 2.1 AA]* | Compliance Requirement | CR | Medium | Approved | Design-UI-001 | UI Components | TC-007 | Accessibility Testing | WCAG 2.1 AA compliance | Carol Davis | 2024-03-30 | | |
| REQ-007 | *[Add additional requirements as needed...]* | | | | | | | | | | | | | |

---

## Detailed Requirements Specifications

### REQ-001: Single Sign-On Authentication
**Full Description:** The system shall provide single sign-on (SSO) authentication capability that integrates with the organization's Active Directory service. Users shall be able to access the system using their corporate credentials without requiring separate system-specific passwords.

**Business Rationale:** Reduce password fatigue and improve security by leveraging existing corporate authentication infrastructure.

**Acceptance Criteria:**
1. User can log in using corporate username and password
2. No separate registration process required
3. Session timeout aligns with corporate security policy
4. Failed authentication attempts are logged
5. Integration works with existing LDAP/Active Directory

**Dependencies:**
- Access to corporate Active Directory
- LDAP integration library
- Security team approval

**Assumptions:**
- Corporate AD is available during business hours
- AD schema includes necessary user attributes
- Network connectivity to domain controllers

**Risks:**
- AD service unavailability affects system access
- Changes to corporate authentication policy
- LDAP integration complexity

---

### REQ-002: Response Time Performance
**Full Description:** The system shall respond to user queries and page loads within 2 seconds under normal operating conditions with up to 100 concurrent users.

**Business Rationale:** Ensure user productivity and satisfaction through responsive system performance.

**Acceptance Criteria:**
1. 95% of page loads complete within 2 seconds
2. Database queries return results within 1 second
3. API calls respond within 500 milliseconds
4. Performance maintained with 100 concurrent users
5. Performance metrics collected and monitored

**Dependencies:**
- Adequate server resources
- Optimized database design
- Network bandwidth availability

**Assumptions:**
- Normal network latency conditions
- Standard user usage patterns
- Database properly indexed

**Risks:**
- Increased user load beyond design capacity
- Network performance degradation
- Database performance issues

---

*[Continue with detailed specifications for additional requirements as needed]*

---

## Requirements Coverage Analysis

### Coverage Summary
| Category | Total Requirements | Completed | In Progress | Not Started | Coverage % |
|----------|-------------------|-----------|-------------|-------------|------------|
| Business Requirements | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| Functional Requirements | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| Non-Functional Requirements | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| Technical Requirements | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| Security Requirements | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| **TOTAL** | **[#]** | **[#]** | **[#]** | **[#]** | **[%]** |

### Priority Coverage
| Priority | Total | Completed | In Progress | Not Started | Coverage % |
|----------|-------|-----------|-------------|-------------|------------|
| Critical | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| High | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| Medium | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| Low | *[#]* | *[#]* | *[#]* | *[#]* | *[%]* |
| **TOTAL** | **[#]** | **[#]** | **[#]** | **[#]** | **[%]** |

---

## Change Management

### Change Request Impact Analysis
When requirements changes are proposed, use this section to analyze impact:

| Change Request ID | Affected Requirements | Impact Assessment | Effort Estimate | Risk Assessment | Approval Status |
|-------------------|----------------------|-------------------|-----------------|-----------------|----------------|
| CR-001 | REQ-003, REQ-007 | Moderate - affects infrastructure design | 40 hours | Medium - potential schedule impact | Pending |
| CR-002 | REQ-001 | High - requires new authentication method | 80 hours | High - impacts security architecture | Approved |

### Requirements Change Log
| Date | Req ID | Change Description | Reason | Changed By | Approved By | Impact |
|------|--------|-------------------|--------|------------|-------------|--------|
| 2024-02-15 | REQ-001 | Modified authentication method from basic to SSO | Security enhancement | J. Smith | P. Manager | Medium |
| 2024-02-20 | REQ-008 | Added new reporting requirement | Customer request | A. Brown | P. Manager | Low |

---

## Testing Coverage Matrix

### Test Case Mapping
| Test Case ID | Test Case Description | Requirements Covered | Test Type | Test Status | Pass/Fail | Notes |
|--------------|----------------------|---------------------|-----------|-------------|-----------|-------|
| TC-001 | SSO Login Success | REQ-001 | Functional | Completed | Pass | |
| TC-002 | SSO Login Failure | REQ-001 | Functional | Completed | Pass | |
| TC-003 | Response Time Test | REQ-002 | Performance | In Progress | - | |
| TC-004 | System Uptime Test | REQ-003 | Reliability | Not Started | - | |
| TC-005 | Data Encryption at Rest | REQ-004 | Security | Completed | Pass | |
| TC-006 | Data Encryption in Transit | REQ-004 | Security | Completed | Pass | |
| TC-007 | Accessibility Testing | REQ-006 | Compliance | In Progress | - | |

### Test Coverage Metrics
- **Total Requirements**: *[#]*
- **Requirements with Test Cases**: *[#]*
- **Test Coverage Percentage**: *[%]*
- **Tests Passed**: *[#]*
- **Tests Failed**: *[#]*
- **Tests Pending**: *[#]*

---

## Validation and Verification

### Verification Methods
| Method | Description | Applicable Requirements |
|--------|-------------|------------------------|
| Inspection | Review of documentation and code | All design and implementation requirements |
| Demonstration | Show system functionality | Functional requirements |
| Testing | Execute test cases | All testable requirements |
| Analysis | Mathematical or logical proof | Performance and capacity requirements |

### Acceptance Criteria Validation
| Req ID | Acceptance Criteria | Validation Method | Validation Status | Validated By | Date |
|--------|-------------------|------------------|------------------|--------------|------|
| REQ-001 | SSO authentication working | Testing + Demo | Completed | QA Team | 2024-03-15 |
| REQ-002 | Response time ≤ 2 seconds | Performance Testing | In Progress | QA Team | - |
| REQ-003 | 99.9% uptime | Monitoring Analysis | Not Started | Ops Team | - |

---

## SOW Compliance Mapping

### Statement of Work Cross-Reference
| SOW Section | SOW Requirement | RTM Requirement(s) | Compliance Status | Deliverable |
|-------------|-----------------|-------------------|------------------|-------------|
| 3.1 | User Authentication | REQ-001 | Compliant | Authentication Module |
| 3.2 | System Performance | REQ-002, REQ-003 | In Progress | Performance Framework |
| 3.3 | Data Security | REQ-004 | Compliant | Security Implementation |
| 3.4 | System Integration | REQ-005 | Planned | Integration Layer |
| 3.5 | User Interface | REQ-006 | In Progress | UI Components |

### Deliverable Mapping
| Deliverable | Related Requirements | Completion Status | Acceptance Status |
|-------------|---------------------|------------------|------------------|
| Authentication System | REQ-001 | 100% | Accepted |
| Performance Framework | REQ-002, REQ-003 | 75% | Pending |
| Security Implementation | REQ-004 | 100% | Accepted |
| Integration Layer | REQ-005 | 25% | Pending |
| User Interface | REQ-006 | 80% | Pending |

---

## Risk Assessment

### Requirements-Related Risks
| Risk ID | Risk Description | Affected Requirements | Probability | Impact | Mitigation Strategy |
|---------|------------------|----------------------|-------------|--------|--------------------|
| RISK-001 | Changes to corporate AD structure | REQ-001 | Medium | High | Regular coordination with IT team |
| RISK-002 | Performance degradation under load | REQ-002 | Low | High | Comprehensive performance testing |
| RISK-003 | Third-party API changes | REQ-005 | Medium | Medium | API versioning strategy |

---

## Reporting and Metrics

### Weekly Status Report
**Reporting Period:** *[Start Date] - [End Date]*

**Requirements Progress:**
- Total Requirements: *[#]*
- Completed: *[#]* (*[%]*)
- In Progress: *[#]* (*[%]*)
- Not Started: *[#]* (*[%]*)

**Key Achievements This Week:**
- *[Achievement 1]*
- *[Achievement 2]*
- *[Achievement 3]*

**Issues and Risks:**
- *[Issue 1 - description and impact]*
- *[Issue 2 - description and impact]*

**Upcoming Milestones:**
- *[Milestone 1 - date]*
- *[Milestone 2 - date]*

### Quality Metrics
- **Requirements Defect Rate**: *[#]* defects per *[#]* requirements
- **Requirements Volatility**: *[#]* changes per week
- **Test Coverage**: *[%]* of requirements covered by tests
- **Requirements Completeness**: *[%]* of planned requirements defined

---

## Appendices

### Appendix A: Requirements Approval Matrix
| Req ID | Business Analyst | Technical Lead | Security Officer | Project Manager | Customer/Sponsor |
|--------|------------------|----------------|------------------|-----------------|------------------|
| REQ-001 | ✓ J.Smith 2024-02-01 | ✓ M.Jones 2024-02-02 | ✓ A.Brown 2024-02-03 | ✓ P.Manager 2024-02-04 | ✓ Customer 2024-02-05 |
| REQ-002 | ✓ J.Smith 2024-02-01 | ✓ M.Jones 2024-02-02 | N/A | ✓ P.Manager 2024-02-04 | ✓ Customer 2024-02-05 |

### Appendix B: Requirements Sources
| Source Document | Version | Date | Key Requirements |
|-----------------|---------|------|------------------|
| Statement of Work | 1.2 | 2024-01-15 | REQ-001, REQ-002, REQ-005 |
| Technical Specification | 1.0 | 2024-01-20 | REQ-003, REQ-004 |
| Security Policy | 2.1 | 2024-01-10 | REQ-004, REQ-007 |
| Stakeholder Workshop Notes | N/A | 2024-01-25 | REQ-006, REQ-008 |

### Appendix C: Glossary of Terms
| Term | Definition |
|------|------------|
| RTM | Requirements Traceability Matrix |
| SOW | Statement of Work |
| SSO | Single Sign-On |
| WCAG | Web Content Accessibility Guidelines |
| SLA | Service Level Agreement |
| API | Application Programming Interface |
| LDAP | Lightweight Directory Access Protocol |

---

## Document Revision History

| Version | Date | Author | Changes Made |
|---------|------|--------|-------------|
| 1.0 | *YYYY-MM-DD* | *[Name]* | Initial creation of RTM |
| 1.1 | *YYYY-MM-DD* | *[Name]* | Added requirements REQ-005 through REQ-007 |
| 1.2 | *YYYY-MM-DD* | *[Name]* | Updated status for completed requirements |

---

**Document Status:** *[Draft/Under Review/Approved/Final]*  
**Next Review Date:** *YYYY-MM-DD*  
**Document Owner:** *[Project Manager Name]*  
**Document Location:** *[Document repository/SharePoint/etc.]*

---

*This Requirements Traceability Matrix is a living document that should be updated throughout the project lifecycle to maintain accurate tracking of all requirements from inception through delivery and acceptance.*