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 1st entry in the requirement traceability matrix.
It all starts with a business case or statement of work (SOW) in pre-project phase. The approved business case or SOW is the 1st 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.
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.
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.
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.
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.
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.
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.
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.
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.
No comments:
Post a Comment