Traceability matrix: track what implements each requirement

Summary

Linking each planned feature to the routes, components, entities, and endpoints that deliver it makes gaps visible before build work exposes them. This requirements traceability matrix (RTM) is deliberately human-checked, not auto-generated, because each tick is a direct claim about how a requirement is met. The traceability report separates implementation links from test coverage, so you can see both what should satisfy a feature and what has been claimed to test it.

The question nobody can answer from the plan

Every project has a list of features, and every project has a design. They are almost never the same document. The features live in a spec, a backlog, or a slide someone made for a stakeholder; the design lives in a folder structure, a diagram, or a canvas. Both are true and neither can see the other.

So the question that decides whether the plan is finished — which parts of this application actually deliver this feature? — has no home. It gets answered from memory in a meeting, and memory is optimistic. The feature everyone assumed was obviously covered turns out to be covered by nothing, and it turns out that way in the third week of building.

Traceability in product development is about making that question answerable by looking rather than by remembering — requirements tracing is the third stage of software requirements management, and in Nodlume it is one tab in the workspace whose whole job is exactly that.

Two axes you already wrote

The matrix has features down the side and implementation across the top, and neither axis is something you fill in for the matrix's sake.

The rows are the features from Domain → Features — the same list you wrote when describing what the application is for, carrying the same Planned / In progress / Ready status. The columns are your live boards: the pages and components from Structure, the entities from Data, and the endpoints from Backend, each shown with its kind under its title.

Entities and endpoints sit on that axis for the same reason routes do. A feature is at least as likely to be implemented by a table or a POST /invites as by a page, and an axis that only offered you pages would quietly teach you that features are things pages do.

Because both axes are read from the live design, the grid changes when the design does. Add a route and a column appears. Rename a feature and its row is still the row it was — links are held against the feature's identity, not its text, so renaming "Trip sharing" to "Share a trip" keeps every tick you made.

It works like a traceability matrix template, except it stays live. Everything saves with the project, and in a shared project it syncs live, so a tick made by whoever is reviewing shows up for whoever is designing.

Ticking is the work

There is no Generate button on this tab. That is deliberate, and it is the one place in the product where the absence is the feature.

A tick is a claim — this endpoint is part of how we deliver that requirement — and it is a claim only a person holding the intent can make. A generated matrix would be a plausible guess at which boxes ought to be checked, printed into a document whose entire value is that its checks were checked by someone. Coverage that produces itself measures nothing.

The ticking is cheap in exchange. Row search and a status filter narrow the features, a column search matches nodes by title or kind, and the headers stay stuck to the edges while you scroll both ways, so a wide board still reads across.

The most useful five minutes is usually: filter rows to Ready, then read each one across. A feature somebody has already called done, with no cell ticked in its row, is either mislabelled or built out of nothing. Both are worth knowing before the demo.

Read it in both directions

This is what the literature calls bidirectional traceability, and it is less abstract than it sounds: a requirement traceability matrix has two kinds of emptiness, and they mean opposite things.

An empty row is a feature with nowhere to be implemented. Sometimes that is a real gap — nobody designed the surface it needs. Sometimes it means the feature is vague enough that no surface obviously claims it, which is a finding about the sentence, not about the design.

An empty column is a surface no stated requirement asked for. Occasionally that is honest scaffolding. Often it is the page that got drawn because applications have one, and it will cost the same to build as the ones somebody wanted.

Neither is automatically a defect, which is exactly why the tool does not flag them as errors. It shows you the shape and lets you decide which blanks are decisions.

Deleting a node removes its claims with it — the report only ever names surfaces that exist, so a matrix cannot go on crediting a feature to a route you deleted last week.

What the report says

The links leave the workspace in the generated project report, under Traceability matrix, and the section opens with the sentence that gets read aloud:

7 of 11 features are linked to implementing nodes.

Then a row per feature: its name, its status, and what implements it — each node by title and kind — or a plain — not linked where nothing does. Not linked is printed rather than omitted, because a report that lists only the covered features is a report that gets less accurate as the project gets worse.

If no features have been written down at all, the section says so instead of rendering an empty table. There is nothing to trace, and a blank grid would imply the tracing was done and came back empty.

The traceability report is built to stay honest, even when the project is not.

Traceability and coverage are different questions

The section immediately after it is Test coverage, and the distinction between them is worth being pedantic about.

Traceability asks does this feature have somewhere to live? Coverage asks does anyone claim to know when it works? A feature can pass the first and fail the second, and those are two different conversations with two different people.

Coverage builds on the links you made here. A feature counts as covered when a Test suite node tests something the feature is traced to, or when acceptance criteria are written beside one of those surfaces — both count, because a route with four written criteria is not untested merely because nobody drew a suite node at it. That gets its own counted line:

5 of 11 features are covered by a test suite or written criteria.

And criteria are criteria. Nothing in Nodlume runs, and the report never says a thing passed — only what has been claimed must be true. A report that inferred results from a plan would be the most dangerous document the tool could produce.

Sending it to somebody

The report exports as Markdown or as a standalone HTML document that prints to PDF, and a share link can render it instead of the canvas — so a client, a compliance reviewer, or the person who has to sign off can read what implements what without an account and without being taught a canvas.

That is usually the moment the matrix earns itself. "What does this app do, and what proves each part of it exists" stops being a meeting and becomes a link.

Where to start

Open a project that already has a few features and a first pass at Structure. Go to Traceability, filter the rows to Ready, and tick honestly for those first — including leaving blank the ones you cannot defend. Then flip the filter to Planned and look for the features whose whole row you cannot fill: those are the ones to design next, and the matrix just prioritised them for you. A live traceability matrix template earns its keep once the project has real features.

The Traceability tab reference covers the panel itself, and Domain covers the feature list the rows come from. For the criteria the coverage line counts, planning tests before the code exists is the companion to this one.

Q&A

Question: Why does the traceability matrix need to be filled in manually instead of generated automatically?

Short answer: Because each tick is a deliberate claim that a specific route, component, entity, or endpoint helps deliver a feature. Nodlume treats that claim as something a person must verify, not something the tool should guess. An auto-generated matrix might look complete while only reflecting likely matches, which would make the report less trustworthy.

Question: What does an empty row in the matrix usually mean?

Short answer: An empty row means a feature has not been linked to any implementing surface. That might reveal a real design gap, such as a missing route, component, table, or endpoint. It might also show that the feature is too vague to connect cleanly to the design. Either way, it is a useful finding before build work begins.

Question: What is the difference between traceability and test coverage in Nodlume?

Short answer: Traceability asks whether a feature has somewhere to live in the design. Test coverage asks whether someone has claimed a way to know that feature works. A feature can be linked to implementing nodes and still lack a test suite or written acceptance criteria, so the two report sections answer related but different questions.

Question: What happens to traceability links when the design changes?

Short answer: The matrix reads its columns from the live design, so adding a route, component, entity, or endpoint adds a column. Renaming a feature keeps its ticks, because links are held against the feature's identity rather than its text. Deleting a node removes its claims, so the report cannot keep crediting a feature to something that no longer exists.

Question: Who is the generated traceability report meant to help?

Short answer: Anyone who needs to understand what implements each feature without opening or learning the canvas — a client, a compliance reviewer, a stakeholder, or the person who has to sign off. It exports as Markdown or standalone HTML, prints to PDF, and can be shared as a link.