Requirement traceability in a real time

Requirements are the most important aspect of a project and their collective validity is the sole reason for the continuity of a project. Managing the transformation of business requirements of a project into multiple work products in different phases of the project and finally converting the project business case into an envisaged project benefit successfully without missing any valid business requirement in the process is one of the keys to success of a project. Requirement traceability matrix (RTM) is a very useful tool for this purpose in a software development project. I wish to see a RTM in real time with more meaningful dimensions added to it and this is my objective of writing this blog. I would like to limit my writing in context of waterfall process using the PMI framework, PRINCE2 methodology and scrum model of agile process.

Requirement traceability matrix is used for mapping the work product of different phases of a project with a purpose of controlling the scope creep.

A brief journey of project requirements goes as follow -

a. Pre-Project phase:
It all starts with a business case or statement of work (SOW) in pre-project phase. The approved business case or SOW is the 1^st entry in the requirement traceability matrix.

b. Requirement analysis phase:
Business case or SWO is expanded into list of business and/or functional requirements in this phase. It’s called discovery or requirement analysis phase in waterfall and initiating a project process in PRINCE2 model. This phase delivers business and/or functional requirements and work break down structure(WBS) in a waterfall model and product breakdown structure (PBS) in PRINCE2 methodology respectively. Now, business and functional requirements are the next level of traceability in the RTM mapped against business case by one to many mapping. Release planning is an equivalent process in Scrum-agile model and release backlog is the output of this process.

c. Design & construction phase:
Depending on size and complexity of the project there could be multiple managed stages in design & construction phase of a PRINCE2 model. Design and construction are single phase each in a waterfall model. Design work delivers high level design (HLD) and/or low level design (LLD) document. Software entities like source code, files and database tables are created in the construction phase after completion of the design work. Now HDL & LLD, and software entities are updated in RTM using the references like section names of design documents, module name of source codes, files names and table names as next level of traceability entries of design traceability followed by construction or build traceability. Now, mapping can be one-one, one-many or many-many. Scrum model goes with sprint planning where the scrum team converts release backlog into sprint backlog. Release backlog together with sprint backlog serves the purpose of traceability matrix in scrum model in my opinion.

d. Software testing:
Testing is usually single stage of a waterfall model but it may have one or multiple managed stages in PRINCE2 model. Test scenarios/cases are referenced into RTM after the construction or build product references using one-many or many-many mapping. Scrum model delivers working software product at the end of each stage. Therefore, testing activity will be part of the sprint backlog.

e. Deployment & support handover:
Deployment & support handover phase creates deployment document, support hand-over document and user manual depending on size and complexity of the project and IT infrastructure. These work products are also mapped against the business requirements in a RTM logically.

f. Updating RTM:
The RTM starts with business case and keep expanding till testing phase. It again converges in deployment and support handover phases.  RTM is updated regularly as any new traceability element is created in any project phase. It should be also part to status reporting. Thus, ensuring the control of scope creep more effectively.

Adding performance parameters like risks, issues, quality, cost and schedule into RTM and mapping these parameter logically makes a RTM more meaningful.

And, here is my thought process -

a. Risk & Issue:
Risk and issue are usually maintained separately in issue and risk registers in waterfall & PRINCE2. Mapping risk and issue in RTM against the business requirements with a designed RAG (red, amber, green) color coding (combination of probability & impact) can give a more detail & granular view of the project risks & issues. It’ll also help in reviewing & managing the project risk & issue in more quantities terms. Risks and issues can be updated in RTM along with risk and issues register using a common format to avoid the rework effort. Risks & issues are maintained usually in daily scrum log of scrum model as we discuss the impediments/obstacles in the daily scrum.

b. Quality:
Quality is managed using quality register in PRINCE2 and various defect reports in waterfall model from quality control point of view. Quality can also mapped against the functional requirements in RTM using the defect metrics and quality register. Information like defect status, defect count, severity and rework effort can be mapped against the functional requirements. This mapping will give a quantitative display of quality across the functional requirements of the project in a real time. It’ll help in managing the quality more objectively. A common template can be used in building the defect metrics or quality register, and mapping them against the functional requirements of the RTM. Sprint review is the measure of quality or quality control process of scrum model. Sprint retrospective can add some lessons learnt quality management inputs to be used for rest of the release backlog.

c. Schedule & cost:
Schedule and cost performance can be mapped against the functional requirement using daily or weekly status of waterfall and checkpoint report of PRINCE2. This will represents a granular view of cost & schedule performance of the project in a real time and it offers a better analysis. Release and sprint burn down charts represent schedule and cost performance in a scrum model.

Managing a project performance would be more predictive if we map performance parameters like issues, risks, quality, cost and schedule into a requirement traceability matrix with a standard color codes using an automated process.

Requirement traceability matrix – a simple and a powerful tool

One of my colleagues quotes in his signature – “Help me understand your requirements clearly.. so I can help you better through our deliverables.” I too think understanding the requirements of your customer is the most important factor in delivering the project successfully in IT business. A requirement traceability matrix (RTM) is a simple and useful tool which facilitates this understanding throughout the lifecycle of the project. A RTM is useful in many ways.

1. It controls the scope creep. This is the main job of a RTM.
2. It gives very clear picture of project in a simple consolidation
3. It is very Helpful in scope verification
4. It helps in building the customer/stakeholders confidence
5. It simplifies the complex requirements
6. It facilitates in dealing with issues and risks

A RTM can be build in a simple excel sheet, in a SharePoint listing or as a part of an enterprise PM tool. Whatever the way one builds a RTM, it will have the references to all the deliverables of all the stages of the project with some meaningful descriptions.

How to develop a RTM -

The business requirements are built in planning phase of the project. They are decomposed into functional requirement/system requirement specification/WBS in planning phase itself as a part of the scope planning. There will be one -many mapping between business requirement and functional requirement usually. The first version of requirement traceability matrix should be built at this point by writing the requirements clearly along with unique requirement traceability numbers in a tabular form. It is also advisable to get the RTM approved by the customer or the responsible stakeholders after completing a project phase. Technical requirements are built during planning/define or design phase of the project depending on the complexity and business need of the project. Functional requirements and technical requirements can have one-many or many-one mapping. Technical requirements can be referred in RTM as a short description with reference to technical or system requirement specification document. HLD and LLD can be referred in RTM with reference numbers and reference pointers. It’s as simple to do as updating an excel cell. HLD and LLD will have one-one mapping with functional/technical requirement usually. Code references should be made with component name and address of the component and unit testing references should be made with testing case number and location of unit testing document. There will be one-one or one-many mapping between technical/functional requirement and code. Requirement to unit testing mapping will be one-many mostly. Finally, functional testing and system/integration testing should be referred with test case numbers and testing document location address or testing references of the testing tool if a testing tool is being used in the project. Some testing tools also provide in-built RTM. There will be one-many mapping between functional and system testing and the requirements.