Bi-Directional Traceability Matrix – CMMi

What is Requirement Tracebility Matrix?
Today Let’s talk about the requirements traceability matrix in a bit detail? Please realize that traceability matrix is among the few very important component associated with CMMi process areas.

What is Vertical and Horizontal Requirement Tracebility Matrix?

Requirements traceability is the ability to relate your requirements with one another and with aspects of other project artifacts. The primary goal for RTM is to ensure that all of the requirements identified by your stakeholders have been met and validated.

Building a System Out of its Requirements - Dy...

Image via Wikipedia

I personally feel that RTM is a great idea in quite a few situations.

Image via Wikipedia

There are two types of Traceability Matrix:

  • Vertical traceability is an aspect which identifies the origin of requirements (for example, customer needs) and follows these requirements as they evolve through your project artifacts, typically from requirements to design, to the source code with the help of which you implement the design, and then the test cases / test plan that validate the requirements.
  • Horizontal traceability identifies relationships among similar items, such as between requirements itself. This enables us to anticipate major problems, such as assuming two subteams implementing the same requirement in two different components. To understand this better,lets take a very easy example for creating a ‘Single-Sign-On’ functionality. the requirement here remains similar but you implement it across various platforms.Hence a traceability is often maintained bidirectionally: You should be able to trace from your requirements to your tests and from your tests back to your requirements.
In short and simple words if a requirement or any work product changes and it will affect some other work product, potentially affecting the value you deliver, then it’s probably something that should be part of requirement traceability matrix.

How do they do it – Requirement Management – CMMi

All right, so this is it for learning, and now is the time for all of us to understand and see the implementation in real world.

The theme is based on ‘How do you do it’?

Let’s get started, believe me this is going to be a fun ride and the knowledge you all will have by the end of 10 days goes beyond your imagination!

Requirement Management:

<<This comes under Basic & Advanced Maturity>>

Whenever you sit for the requirement management, make sure to follow the below mentioned rules:

Problem you should solve – Requirements are managed and inconsistencies with project plans and work products are identified!

Objective should be – Your objective here is to explicitly ask your requirement owners about the meaning of each and every requirement they come up with!

Please describe how project personnel develop and understanding of the requirement? Do you also interact with requirement providers?

And the evidence you need to support this would be:

  • Statement of Work
  • System & Software Requirements Specification (SRS)
  • Business & User Requirements Specification
  • Use Cases
  • Minutes of meetings

    Good to provide

  • Acceptance criteria as part of SoW
  • Review and approval records of SoW
  • Requirement Reviews
  • Approval of SRS/Use cases

Problem you should solve – Obtain commitment to the requirements from the project participants!

Objective should be – You should surely have the documented evidence!

How do you obtain the commitments to the requirements from the resources associated with projects? Do you review / approve the requirements?

And the evidence you need to support this would be:

  • Project plan with resources allocated
  • System & Software Requirements Specification (SRS)
  • Business & User Requirements Specification
  • Requirements change request logs, with commitment (e.g., emails) and estimates of impact (e.g: functionality impact, interface impact, design impact, validation impact etc…).

    Good to provide

  • Project Kick off MoM
  • Requirements Review and approval Records
  • Minutes of meeting
  • Effort estimation Reports

How the changes to the requirements are managed? Whenever a change happens how do you manage that change? How do you assess the changes?

You should have the answer with following artefacts

  • Change Request
  • Evidence of Project Plan Update
  • System & Software Requirements Specification (SRS) / Revision History of SRS
  • Review records of SRS, Use Cases
  • Requirements Traceability Matrix (RTM).
  • Revisions to work products resulting from changed requirements.

    Good to provide

  • Project Kick off MoM
  • Requirements Review and approval Records
  • Minutes of meeting
  • Effort estimation Reports

Much of requirements management is change management. Tracking the status of project change requests is an eye-opener: how many of them are open and how many closed? How many requests were approved and how many rejected? How much effort was spent implementing each approved change?

You should have answer of all these, and the above mentioned document should give you proper answers on these.

How do you maintain the traceability between your requirements, plan, and work products?

You should have the answer with following artefacts

  • Requirements Traceability Matrix (RTM) / Both Horizontal & Vertical traceability
  • System & Software Requirements Specification (SRS)
  • Checklist associated with RTM

    Good to provide

  • Email exchanges related to RTM review
  • SQA Audit/Internal Audit reports containing issues related to traceability among requirements
  • RTM Review Records

How do you identify the inconsistency between the project plan and the requirements that you have identified?

You should have the answer with following artifacts

  • Review and approval records of project plan and its associated plans
  • Documentation which identifies that there is inconsistency between the project plan / work product / requirements.
  • CR against the requirements
  • CCB meeting which identifies that this change has a resource available.

    Good to provide

  • Email exchanges related to RTM review
  • SQA Audit / Internal audit reports
  • RTM Review Records

This should be good for now…will come up with another process area which will be RD tomorrow 🙂 Cheers!