# Requirements Traceability Matrix

# Requirements Traceability Matrix (RTM): {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

<!-- GUIDANCE: The RTM maps requirements through the full SDLC:
Business Requirement → Functional Requirement → User Story → Design → Code → Test Cases.
Purpose: Ensure every requirement is implemented and tested; catch gaps and orphans.
Maintain this document throughout the project — update it when requirements or tests change. -->

## 1. Purpose of Traceability

The Requirements Traceability Matrix serves four functions:

1. **Coverage Assurance** — Every business requirement has an implementation path and test cases
2. **Change Impact** — When a requirement changes, quickly identify all affected code and tests
3. **Gap Detection** — Identify requirements with no tests (coverage gap) or tests with no requirements (scope creep)
4. **Audit Trail** — Demonstrates compliance with processes for client sign-off and quality gates

**Traceability Directions:**
- **Forward Traceability** — BR → FR → Code → Test (did we build what was required?)
- **Backward Traceability** — Test → Code → FR → BR (does everything we built have a justification?)

---

## 2. Document References

| Document | Location | Version | Last Updated |
|----------|----------|---------|-------------|
| Business Requirements Document (BRD) | `[brd.md](brd.md)` | {{VERSION}} | {{DATE}} |
| Functional Requirements Spec (FRS) | `[functional-requirements.md](functional-requirements.md)` | {{VERSION}} | {{DATE}} |
| Non-Functional Requirements | `[non-functional-requirements.md](non-functional-requirements.md)` | {{VERSION}} | {{DATE}} |
| User Stories | `[user-stories.md](user-stories.md)` | {{VERSION}} | {{DATE}} |
| Acceptance Criteria | `[acceptance-criteria.md](acceptance-criteria.md)` | {{VERSION}} | {{DATE}} |
| Test Plan | `[../../TESTING/test-plan.md](../../TESTING/test-plan.md)` | {{VERSION}} | {{DATE}} |
| Test Cases | `[../../TESTING/test-case.md](../../TESTING/test-case.md)` | {{VERSION}} | {{DATE}} |

---

## 3. Forward Traceability Matrix

<!-- GUIDANCE: This is the primary traceability table. Every row = one business requirement.
Columns trace it through design, implementation, and testing.
Status codes: ✅ Complete | ⏳ In Progress | ❌ Not Started | N/A Not Applicable | ⚠️ At Risk -->

### 3.1 Functional Requirements Traceability

| BR ID | Business Requirement | FR ID | Functional Requirement | US ID | Design Reference | Code Module / Component | Unit Test | Integration Test | AC ID | Status |
|-------|---------------------|-------|----------------------|-------|-----------------|------------------------|-----------|-----------------|-------|--------|
| BR-001 | {{BUSINESS_REQ}} | FR-001 | {{FUNC_REQ}} | US-001 | `figma/screen-01` | `src/modules/{{MODULE}}` | ✅ | ⏳ | AC-001 | ⏳ In Progress |
| BR-002 | | FR-002 | | US-002 | | | ❌ | ❌ | AC-003 | ❌ Not Started |
| BR-003 | | FR-010 | | US-010 | | | | | | |
| BR-004 | | FR-011 | | US-011 | | | | | | |
| BR-005 | | FR-020 | User Registration | US-020 | `figma/register` | `src/auth/register` | ⏳ | ❌ | AC-010 | ⏳ |
| BR-006 | | FR-021 | User Login | US-021 | `figma/login` | `src/auth/login` | ⏳ | ❌ | AC-020 | ⏳ |
| BR-007 | | FR-030 | | | | | | | | |

### 3.2 Non-Functional Requirements Traceability

| NFR ID | Requirement | Target | Test Type | Test Case ID | Status |
|--------|------------|--------|-----------|-------------|--------|
| NFR-P01 | Page load time < 3s | < 3s (initial) | Performance | PERF-001 | ❌ |
| NFR-P03 | API response < 500ms | p95 < 500ms | Performance | PERF-002 | ❌ |
| NFR-SEC01 | Authentication | JWT/OAuth2 | Security | SEC-001 | ❌ |
| NFR-SEC06 | Input validation | No injection | Security / SAST | SEC-010 | ❌ |
| NFR-U03 | WCAG 2.1 AA | Level AA | Accessibility | A11Y-001 | ❌ |
| NFR-A01 | Uptime SLA ≥ 99.5% | 99.5% monthly | Operations | OPS-001 | N/A |
| NFR-COMP01 | GDPR compliance | Full compliance | Compliance audit | COMP-001 | ❌ |

---

## 4. Backward Traceability Matrix

<!-- GUIDANCE: Start from test cases and trace back to requirements.
This reveals whether any test cases test functionality that wasn't actually required (potential scope creep)
or whether test cases exist without requirements (danger zone). -->

| Test Case ID | Test Description | AC ID | FR ID | BR ID | Has Requirement? |
|-------------|-----------------|-------|-------|-------|-----------------|
| TC-001 | {{TEST_DESCRIPTION}} | AC-{{XXX}} | FR-{{XXX}} | BR-{{XXX}} | ✅ Yes |
| TC-002 | | | | | ✅ Yes |
| TC-010 | {{TEST_WITHOUT_REQUIREMENT}} | — | — | — | ⚠️ No — investigate |

---

## 5. Coverage Analysis

<!-- GUIDANCE: Update this section weekly during development.
Low coverage numbers are early warning signs — address before they become testing blockers. -->

### 5.1 Requirement Coverage Summary

| Category | Total Count | Fully Covered | Partially Covered | Not Covered | Coverage % |
|----------|-------------|--------------|-------------------|-------------|-----------|
| Business Requirements (BR) | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| Functional Requirements (FR) | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| Non-Functional Requirements (NFR) | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| User Stories (US) | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| Acceptance Criteria (AC) | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |

**Overall Requirement Coverage:** {{PCT}}%
**Target:** ≥ 95% before UAT; 100% before production release

### 5.2 Test Coverage Summary

| Test Type | Total Tests | Passing | Failing | Skipped | Coverage |
|-----------|------------|---------|---------|---------|----------|
| Unit tests | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| Integration tests | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| E2E / UAT scenarios | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{COUNT}} | {{PCT}}% |
| Performance tests | {{COUNT}} | | | | |
| Security tests | {{COUNT}} | | | | |

---

## 6. Gap Identification

<!-- GUIDANCE: A gap is a requirement that has no test case, or a test case that has no requirement.
List ALL gaps here and assign owners to close them before the next milestone. -->

### 6.1 Requirements Without Test Coverage

| Requirement ID | Description | Gap Type | Action Required | Owner | Target Date |
|---------------|-------------|----------|----------------|-------|-------------|
| FR-{{XXX}} | {{DESCRIPTION}} | No test cases written | Create test cases TC-{{XXX}} | QA | {{DATE}} |
| BR-{{XXX}} | | No functional requirement | Write FR-{{XXX}} | BA | {{DATE}} |

### 6.2 Test Cases Without Requirements (Orphans)

<!-- GUIDANCE: Orphaned test cases may indicate scope creep or deleted requirements.
Investigate each one — either link it to a requirement or delete the test case. -->

| Test Case ID | Description | Status | Action |
|-------------|-------------|--------|--------|
| TC-{{XXX}} | {{DESCRIPTION}} | Orphaned | Investigate: link to req or delete |

### 6.3 Requirements Without Design Reference

| Requirement ID | Description | Action |
|---------------|-------------|--------|
| FR-{{XXX}} | {{DESCRIPTION}} | Request design mockup from Designer |

---

## 7. Change Impact Tracking

<!-- GUIDANCE: When a requirement changes, this table tracks what else must change.
Use this BEFORE approving change requests to understand full impact. -->

| Change Request ID | Changed Requirement | Impact on FR | Impact on Code | Impact on Tests | Impact Assessment | CR Status |
|-----------------|--------------------|--------------|--------------|-----------------|--------------------|-----------|
| CR-001 | {{REQUIREMENT_CHANGE}} | FR-{{XXX}} needs update | `src/{{MODULE}}` affected | TC-{{XXX}} needs update | {{EFFORT_ESTIMATE}} | {{APPROVED/PENDING}} |

---

## 8. Traceability Status Dashboard

<!-- GUIDANCE: This summary is updated weekly and presented at sprint reviews.
It gives stakeholders a single-page view of requirements health. -->

**Last Updated:** {{DATE}}
**Updated By:** {{NAME}}

| Metric | Value | Target | Status |
|--------|-------|--------|--------|
| Total Business Requirements | {{COUNT}} | — | |
| BRs with FR coverage | {{COUNT}} / {{TOTAL}} | 100% | {{✅/⚠️/❌}} |
| FRs with test coverage | {{COUNT}} / {{TOTAL}} | 100% | {{✅/⚠️/❌}} |
| Test cases passing | {{COUNT}} / {{TOTAL}} | 100% | {{✅/⚠️/❌}} |
| Open gaps | {{COUNT}} | 0 | {{✅/⚠️/❌}} |
| Change requests open | {{COUNT}} | ≤ 3 at a time | {{✅/⚠️/❌}} |
| UAT sign-off pending | {{COUNT}} | 0 at launch | {{✅/⚠️/❌}} |

**Overall RTM Health:** {{GREEN / AMBER / RED}}

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Business Analyst | | | |
| QA Engineer | | | |
| Tech Lead | | | |
| AI Director (John) | | | |