Requirements traceability
The Requirements traceability Matrix is used to map and track requirements throughout the lifecycle of a project, ensuring all requirements are addressed and validated.
| Requirement ID | Requirement Description | Priority (High/Med/Low) | Business Objective | Design/Feature Reference (If Any) | Implementation Tasks | Test Case ID | Test Status (Pass/Fail/In Progress) | Defects (If Any) | Remarks |
|---|---|---|---|---|---|---|---|---|---|
| RQ-001 | User must be able to log in with SSO | High | Secure user authentication | Login Feature (DF-101) | TASK-001, TASK-002 | TC-001 | Pass | None | Functional. |
| RQ-002 | The system must display country code as a two digit code | Medium | Reference Data Management | Reference Data Management (DF-102) | TASK-003, TASK-004 | TC-002 | In Progress | DEF-101 (minor UI issue) | Requires retest. |
| RQ-003 | Implement error notification to provide data stewards with pending error count | Low | Proactive error monitoring | Erro Management (DF-103) | TASK-005 | TC-003 | Fail | DEF-102 (email not sent) | Fix required. |
Components Explained#
- Requirement ID: - A unique identifier for each requirement (e.g., RQ-001, FR-001, BR-101, etc.).
- Requirement Description: - A brief but detailed explanation of the requirement or functionality.
- Priority: - Indicate the requirement's criticality: High, Medium, or Low.
- Business Objective: - Link the requirement to overarching business goals or objectives (e.g., increase user registration, comply with GDPR, etc.).
- Design/Feature Reference: - Links the requirement to specific design artifacts, diagrams, or feature documentation like wireframes or workflows.
- Implementation Tasks: - Identify the system development tasks associated with fulfilling the requirement (referencing sprint backlog items or developer tasks, e.g., TASK-001, TASK-002).
- Test Case ID: - The ID of the test case(s) used to validate the requirement.
- Test Status: - The status of the test case: Pass, Fail, or In Progress.
- Defects: - Any defect IDs associated with the test case or requirement if it fails validation/testing.
- Remarks:
- Additional comments, including next steps, pending items, or change requests.
Tips for Customization#
Add Additional Columns: - If needed, you can include extra fields such as: - Owner or Assignee (who is responsible for implementing/testing it). - Affected Modules/UI Components. - Version for version-controlled requirements.
Example RTM Templates#
Excel:#
- Create your RTM in a straightforward Excel sheet using the structure above.
- Use filters to quickly query test results and requirements.
Azure DevOps/JIRA:#
- Use Work Item Linking to automatically establish traceability between:
- Epics → Features → Stories → Tasks → Test Cases.
By maintaining a clear and regularly updated Requirements Traceability Matrix (RTM), you ensure that every requirement is tracked from initiation to implementation, minimizing the risk of overlooked requirements. This practice also helps promptly identify and resolve gaps between implementation and testing, ensuring alignment with project objectives and quality standards.
Template Summary Comparison#
| Aspect | Excel-Based Matrix | ADO-Based Matrix |
|---|---|---|
| Best For | Small-to-medium projects, offline/manual tracking, and stakeholders who prefer Excel access. | Large-scale projects with dynamic traceability and seamless integration across teams. |
| Integration | Manual linking of design, tasks, and tests required. | Automated via Work Items linking (Parent-Child, Related). |
| Custom Queries | Requires manual filtering and sorting in Excel. | Queries and widgets make real-time traceability insights easier. |
| Flexibility | Easy customization of columns and structure. | Tightly coupled to ADO's Work Item structure. |