Alison Mills-Long discusses what a requirements traceability matrix is, its uses, and why you need one. She walks through step-by-step how to create a winning requirements traceability matrix, and also includes a list of some of the information that you should be tracking in your projects.
The Requirements Traceability Matrix captures each business requirement clearly and accurately and helps project teams successfully trace deliverables back to these requirements throughout project execution.
Requirements traceability matrix tracking information
Here is a list of the types of information that should be tracked to ensure successful project execution.
- Action Integration Test
- Approval Date ID #
- Change Control # Modification
- Charter Module / Object (what this requirement affects)
- Clarification MSP Task #
- Customer / Client Priority
- Requirement ID
- Data Conditions Requirement #
- Date Added Requirement Type
- Description Risk (risk breakdown structure)
- Design Specification Risk Type
- Have to Have (required) Scope (In / Out)
- Nice to Have (optional) Source (charter, business case, regulation, etc.)
- Trace from User Requirement UAT (user acceptance testing) Y/N or Pass / Fail
- Trace to System Requirement
- Trace to Design Specification Verification Y/N
- Trace to Test Script / Test Case #
- Trace to WBS (work breakdown structure)
Alison Mills-Long, PMP, CMQ/OE, RMT, TNLP, is the owner of Empowered by Source and has over 27 years of experience in the financial services industry in the disciplines of project management, operations, and vendor management. She is a founding member of the PMI Columbus, GA Chapter and has served in continuous officer positions for over 20 years and is a member of the American Society for Quality. Alison is the developer and lead instructor for Columbus State University Continuing Education Project Management Certificate Program. Alison writes about project scope and training.