Chapter 4. Project Planning and the Project Scope
4.3 Requirements Traceability Matrix
The project team should link the requirements to the activities and deliverables that satisfy them during the project. Requirements traceability matrix is a common structure that is used by project teams. It also shows each requirement’s relationship to other requirements. Traceability is used to help ensure that the solution conforms to requirements and to assist in scope, change, risk, time, cost, and communication management[1]. A formal traceability matrix is usually built hierarchically, starting with high-level requirements and filling in the details as the requirement is progressively elaborated. This hierarchy is similar to an outline that is filled in as more detail is known[2].
This matrix can include the information regarding:
- Requirement ID
- A unique identifier
- Associate ID
- A unique identifier for requirements associated with higher-level requirements
- Requirement category
- Requirement description
- A textual description of the requirement
- Current status
- E.g., active, canceled, deferred, added, approved, assigned, completed.
- Status date
- Business needs, goals, and objectives
- To address the rationale of inclusion
- Project objectives
- To address the rationale of inclusion
- WBS number
- The relationship of the requirement with project activities and milestones
- Design ID
- The relationship of the requirement with the design elements
- Build ID
- The relationship of the requirement with an implementation of a specific feature
- Test strategy and test scenarios (e.g., technical/system case tests, user/acceptance case tests)
- Test cases that will validate that the built features perform as required by the requirements.
Let’s create a small version of the requirements traceability matrix for Grocery LLC’s m-commerce project.
- ID (1): Customers shall log in to the application by using their usernames and passwords.
- ID (2): Customer profile information including the name, shipping and billing addresses, and payment accounts shall synchronize across all interfaces (mobile application, mobile website, and desktop website).
ID | Associate ID | Requirements Description | Current Status | WBS | Design ID | Build ID | Test case |
1 | 1.1 | Customers shall receive a one-time password to their mobile phones. | Active | 2.2
3.2 |
D3
D6 |
B3
B8 |
Case 2 |
1.2 | Customers shall be able to prefer signing in to the mobile application by swiping their fingerprints on their smartphones. | Active | 2.2
3.2 |
D3
D6 |
B3 | Case 3 | |
2 | 2.1 | The profile page consists of the fields “First Name”, “Middle Name”, “Last Name”, “Gender”, “Street Address”, “Apartment/Suite Number”, “City”, “State”, “Zip Code”, “Mobile Phone Number”, “Other Phone Number”, “Debit/Credit Card Number”, “Debit/Credit Card Expiration Date”, and “Debit/Credit Card Security Code”. | Active | 2.2
4.4 5.2 |
D2 | B2 | Case 6 |
2.2 | When customers type new information or edit existing information in their profile pages on only one of the interfaces, this information will be updated immediately on other interfaces. | Active | 2.2
4.4 5.2 |
D2
D9 |
B2 | Case 7 |