Traceability Matrix

That feature is not supported from CodeBeamer 7.4; its being replaced by the Traceability Browser! The Traceability Matrix Wiki plugin is available henceforward, see Wiki Markup and Plugins page!

What is a Traceability Matrix?

In codeBeamer, a Traceability Matrix is essentially a table that correlates any two set of requirements (or tests, tasks, or any other issue types) and visualizes dependencies between those items. It is often used not only to view, but to edit the dependencies.

You can reach through the Traceability Matrix link in the more menu while browsing a tracker. In the first step, you have to select two tracker filters to feed the issue input for the left column and the top row, and then you can view the result and edit it.

A picture tells a thousand words:

To see some details about an issue just move your cursor above the header cell of that issue, wait two seconds and an issue bubble will pop over:

Dependencies

In a traceability matrix, each cells represents a dependency relation between the requirements of the given row and column. Dependencies have the following attributes:

• Direction: it can be one of "A depends on B", "B depends on A", "A and B depend on each other" or "A and B are independent" (where "A" and "B" are the requirements of the given row and column).
• Suspected link trigger: whether an update on the influential requirement should trigger a so-called suspected link to the affected requirement. It is a boolean (ON/OFF) attribute. See the next section for more explanation.

It's important to know that dependencies are represented by associations of depends type in codeBeamer.

Suspected Links

"Suspected links" are based on a very trivial need: if you have two requirements "A" and "B", furthermore "A depends on B", then every time when B gets a update, it is advisable to review A, as well. To ease tracking these updates, codeBeamer provides a special mechanism.

If you turn on the suspected link trigger for this dependency, then any update on "B" will generate a suspected link between "A" and "B". The actual suspected link will be visible in the Document View, visualized with a small red sign.

What to do with a suspected link? You should review the affected requirement, and make updates on that if you decide so. When done, you can clear the suspected link by clicking the small "X" in the red rectangle.

This is a very effective method to validate your requirements and preserve their internal consistency.

See the next section for an example that illustrates this with a real life scenario.

Example

Here is a simplistic example, which may not be totally correct from a car manufacturer point of view (we are not mechanical engineers, sorry), but explains the concepts well.

Say you are collecting requirements in a car manufacturing project. You have two separate requirements:

1. "Total weight must be < 1100kg" (A)
2. "Engine must produce 140HP or more" (B)

For this, you may want to set up a bidirectional dependency "A depends on B, and B depends on A, too". Why? Because the total weight depends on the engine performance, as higher performance usually requires a heavier engine. Also, if the maximum allowed weight changes, it may affect the engine performance that can be potentially achieved.

Beside setting the direction to bi-directional, it is a good idea to turn the suspected link trigger on not to forget to update the dependant requirement if something changes.

All right. From this moment, any of "A" or "B" changes, a suspected link will appear, suggesting that the other requirement should be reviewed, too.

It's really that simple.

Using Traceability

Editing Dependencies via the Traceability Matrix

If you double click to any cell of the matrix, a small popup will appear to:

• Choose the direction of the dependency between the two requirements, or remove the dependency by selecting None.
• Turn the suspected link trigger on or off.

Propagating Changes on Requirements

Using suspected links has the real power when you set up the full network of dependency relations with suspect link triggers properly configured.

With those in place, if you decide to update the affected requirement, that change may trigger further suspected links, effectively propagating the impact of the original change.

Consider our previous example, if you change the engine performance requirement, it triggers a suspected link to the total weight requirement, which may trigger further suspected links to other requirements like maximum weight of the car body or materials used in the interior. By the time you clear all suspected links, you will have a consistent set of requirements, again.

Export to Excel

There is ability to export the displayed table into Excel format (XLS) by clicking the Export to Excel link on the top left section of the table, so you can work with the traceability data further on.