Product
Traceability that is maintained, not reconstructed.
A traceability matrix built by hand in a spreadsheet is accurate on the day it is produced and decaying by the next. Here the links are part of the record: they are created as the work is done, they follow items when the structure changes, and anything you report is read from them.
What is connected to what
Links in any direction, not just a tree
A requirement can be linked to the scope line it delivers, the risk it carries, the assumption it rests on, the decision that shaped it and the source it was drawn from. Relationships are a graph over the hierarchy rather than a second hierarchy.
-
Links that survive a restructure
Moving a requirement to a different section, or promoting it a level, does not break what it is connected to. This is the property that makes traceability worth keeping — most manual matrices are abandoned at the first reorganisation, not the tenth.
-
Find the thing you mean, then link it
Links are made by searching for the item rather than by remembering an identifier, so the connection gets made while the analyst is still thinking about it.
-
Reports read from the record
Reports are generated from the live data and viewed in place, so the question "is this the current version?" does not arise. There is nothing to rebuild before a steering group.
-
A document your sponsor will accept
The requirements specification exports to Word in a consistent shape, produced from the same items the grid shows. It is the artefact your existing review and approval process already knows how to handle.
-
Everything is searchable
Items are findable by title or identifier from the keyboard without leaving what you are doing — which is the difference between a record people consult and one they only write to.
Ask the hard traceability question
Pick a requirement from a project you have delivered and ask where it came from, what it depended on, and what changed. That is the demonstration worth having.