Requirements Traceability Matrix
The Requirements Traceability Matrix is an important cross reference document. It traces the progress of a requirement from inception to delivery. The document is crucial to understanding how the solution will meet the requirements, or where you have issues within your project. This document can have the tendency to become very large and overwhelming. So it is important to find the right level of detail to manage the project, but not so much detail that this document becomes impossible to maintain.
The Requirements Traceability Matrix should be focused on the components the project will create in order to support the requirements.
Getting ready
Before starting, it is important to have an understanding of the scope of the project and its high-level requirements. It is best to start the Requirements Traceability Matrix before you have detailed the requirements, so that you can arrange your requirements in the same structure as your traceability matrix. The Requirements Traceability Matrix does not contain the actual requirements, but merely a link to the requirement or detailed requirement via the unique number.
How to do it...
Creating the Requirements Traceability Matrix has several steps involved. The traceability matrix should be created for each project/work package:
- Create your numbering system: The numbering system should be hierarchical so that it is easy to understand and simple to follow. For example:
A typical hierarchical number system is as follows:
- The object name will be derived from the component that needs to be developed to support the requirements, and the sub-category is all the sub components which need to be developed for the component.
- The listed sub-categories under the object name should be limited to the actual sub-components, whose information needs to be gathered, documented, and agreed upon via stakeholders. This hierarchical numbering should be closely correlated information collected during detail requirements.
- The sub-category will be specific to each type of object needed to be developed. Different object types (Reports, Data, and so on) will have different sub categories:
- Open a spreadsheet application and create a tab for your project:
- In your spreadsheet create vertical swim lanes that correspond to your project methodology:
- Start with your Requirements column ( Column A in the figure above) and include your hierarchical numbering scheme. It is important to update this document at the end of each phase. For example, when you have gathered requirements, you would include all the requirements in this matrix.
- The matrix can be completed as you progress through the project lifecycle:
How it works...
The Requirements Traceability Matrix primarily maps requirements to components which are required to be developed. The matrix also tracks the progress of these components through the project development lifecycle. It helps to ensure the requirements are included into components, developed, tested, and released. It becomes the heart of the project as it tracks each individual component of the project.
There's more...
All your requirements may not have the entire hierarchy with all columns completed. This is acceptable, but each requirement must have a unique number. Therefore, a requirement may be at the project-level or the subject area-level, and will have a unique requirement number. This is important to note for the subsequent recipes.
Looking at the Requirements Traceability Matrix can seem overwhelming. It is important to establish this document early in the project and to make it a living document, which is managed and maintained real time within your project by key team members. Team members who should be responsible for updating the document are as follows:
- Solution Architect/Business Analyst — This role contributes the requirements and completes the initial part of the matrix.
- Technical Architect— This role adds the cross relationship from the requirements to the solution design. They can also be responsible for dividing the components into releases, and scheduling the releases.
- Business Analyst/Tester— This role is responsible for cross referencing the requirements with use cases and test scripts. Once the component is tested within an environment, the status is updated.
- Project Manager — This role can fill in the final step to indicate that the information is successfully promoted and closed within the release.
Not all projects will be large enough to have dedicated team members in these positions. Multiple roles will be assigned to individuals who will be required to update the Requirements Traceability Matrix.
Oracle Application Express is an application development environment, which is available as part of your Oracle database. This will need to be installed and configured. In Oracle Application Express (APEX), there is an application called Team Development.
This is a potential alternative to using a spreadsheet as a Requirements Traceability Matrix. This module within APEX can be used to manage the relationship between features (requirements), To Dos (project tasks), releases, and bugs.
This module has basic project management, feature management, and bug tracking capabilities.
- Click on the Features tab option:
- Click on the Create Feature button. From here you can enter the feature information. The following fields are similar to the columns and information in the Requirements Traceability Matrix:
- Feature is a requirement
- Focus Area is the same as the Subject Area
- Parent Feature is the main requirement
- Features can be linked in a hierarchical relationship. So the hierarchical naming and numbering system you created will still be valid. In order to relate features together, you have to assign the features to the same release. To view the relationship, click on the Tree tab:
The limitation that features belong to a release, makes it a little more challenging; features can be copied if you require, keeping the same structure. A feature may need to be released numerous times through the lifecycle. Due to this limitation of the software, you would require additional features, one for each release.
- Features also have the ability to have To Dos (tasks) associated with them. These to-dos would be all the tasks required to complete the feature.
