Traceability at 1,000+ requirements — where the spreadsheet actually breaks

Past about 400 requirements, the traceability matrix stops being a tool and starts being a liability. Past 1,000, it's a document nobody on your team actually trusts, maintained in Excel by whoever drew the short straw that quarter.

I've seen the same failure mode in enough programs now to call it structural. It isn't a tooling problem in the sense of "pick a better spreadsheet." It's a data-model problem. The matrix is a two-dimensional projection of something that isn't two-dimensional, and every workaround teams invent to make it work — merged cells, colour-coded ranges, separate tabs per subsystem — makes it worse.

Here's what actually goes wrong, and what the engineering record looks like when you stop pretending the matrix is the record.

Where the matrix fails at scale

A single Class C software requirement on a realistic program traces to three or four user needs, two or three risk controls, four to seven design elements, and anywhere from three to fifteen test cases across unit, integration, and system levels. Write that out in a matrix. You either explode the row count by duplicating the requirement for each linkage, or you cram multiple references into one cell and lose the per-relationship metadata that actually matters.

Both choices are bad. The exploded matrix becomes unreadable past a few hundred rows. The crammed matrix loses the information needed to answer the questions reviewers actually ask — which specific design output implements this specific risk control, and which specific test verifies that it does so.

The worse problem is what the matrix doesn't show. It tells you what was documented. It doesn't tell you what's missing. A risk control with no implementing requirement is a finding. A requirement with no test is a finding. A design element with no requirement source is a finding. In a matrix, those gaps are only visible if someone knows to look at the right row or the right empty cell. In a graph, they're queryable.

The reconciliation tax

The real cost of spreadsheet traceability isn't the matrix itself. It's the reconciliation tax — the time engineering spends every month synchronising records across disconnected tools.

Requirements live in Jama or DOORS or Jira. Design elements live in Confluence or the architecture repo. Tests live in the test management tool. Risk items live in the risk file (usually Excel). SOUP lives in another spreadsheet. The matrix that ties them together is a separate document, updated manually against the other five sources.

Talked with a quality lead at a Class IIb cardiology startup last year. Their V&V manager estimated she was losing 18 hours a month just reconciling the traceability matrix against the upstream tools. At submission prep, that number tripled for six straight weeks. That's one senior engineer, most of a sprint, spent translating between systems that should all be talking to the same record. Her team had 240 requirements at the time. The math gets worse linearly.

When the matrix goes out of sync — not if, when — the gaps don't surface until someone runs a design review or starts submission prep. By then, the gap is historical: a change that happened nine months ago, a test that was added without updating the upstream requirement reference, a risk revision that didn't propagate. Reconstructing the current state is forensic work.

Traceability as a directed graph

The engineering reality isn't a matrix. It's a graph. Nodes are the artefacts: user needs, regulatory requirements, risk controls, software requirements, architectural elements, detailed design decisions, test cases, test results, SOUP items. Edges are typed relationships between them, directional and meaningful.

• User need → requirement: derives-from. This requirement exists because this user need exists.
• Risk control → requirement: implemented-by. This requirement is the design answer to this identified risk control.
• Requirement → design element: addressed-by. This architectural or detailed design decision implements this requirement.
• Design element → test case: verified-by. This test confirms this design decision meets its requirement.
• Test case → test result: evidenced-by. This executed test produces this objective evidence at this version.

The matrix you hand to a reviewer is one projection of this graph — a flat view of a subset of edges. The graph itself is richer. It shows the full dependency structure, the impact of changes, and the gaps that no matrix query will surface.

A worked example — a small slice of a Class C SaMD

Cardiac rhythm monitoring application. Class IIb under EU MDR, Class C under IEC 62304.

The user need: alert the clinician when a rhythm anomaly is detected. Risk analysis surfaces a hazard — delayed notification leading to missed intervention. The risk control specifies alerts delivered within a defined time threshold. That risk control generates a functional requirement: "When a rhythm anomaly is detected, the device shall generate an alert to the clinical dashboard within 10 seconds."

The requirement traces to a software architectural element: the alert dispatch service. The dispatch service links to a detailed design decision about notification priority queuing. That design decision is verified by a test case: "Inject a synthetic arrhythmia signal; confirm dashboard alert delivery within 10 seconds across 100 trials." The test result records pass/fail with timestamp, model version, and configuration.

Six nodes, six edges, one traceable path from clinical need to verified behaviour. The matrix would show one row. The graph shows the dependency chain, the severity classification inherited from the hazard, and — this is the part that matters — everything that breaks if the requirement changes.

What the graph answers that the matrix can't

Impact of a change. A risk control is revised after a post-market surveillance event suggests the original 10-second threshold is too loose. The graph surfaces every downstream artefact immediately: the requirements implementing it, the design elements addressing those requirements, the tests that now need re-running, the SOUP items whose version may matter. The matrix tells you what was documented. The graph tells you what needs re-evaluation.

Completeness gaps. Queryable: risk controls with no implementing requirements, requirements with no test coverage, design elements with no requirement source, orphaned test cases. These are the gaps that produce AI requests during review. In a matrix, finding them requires careful manual inspection. In a graph, they're structural properties.

Orphans. A requirement that no longer traces to any user need or risk control is a candidate for deletion — or evidence that a design decision was made without proper change control. A test that doesn't trace to any requirement is testing something not in your design record. Both are findings. The graph surfaces both.

Safety-critical paths. Requirements that trace to Class C risk controls carry a different verification obligation than requirements that trace to Class A. When that classification is a property of the graph structure, verification planning flows from it rather than being calculated by hand for each submission.

What has to change in your process

Adopting graph-based traceability isn't a tool change. It's a process change, and three practices matter more than which platform you use.

Create the link when you create the artefact. When you write a requirement, link it to the user need or risk control it came from, in the same action. Don't defer. A requirement without a source is an incomplete requirement, and deferring the link is how programs accumulate sourceless requirements at rate of five per sprint.

Run design reviews against the graph, not just the documents. A design review that checks individual documents misses structural gaps. A review that queries the graph — show me all risk controls with no implementing requirement, show me all requirements with no test — finds the gaps document review misses.

Change control that traces forward automatically. When a risk control changes, the change control process should surface every downstream artefact in the graph. Not as a manual lookup. As a structural query. Engineering still decides what to do with each affected artefact. The graph ensures they see all of them.

The submission matrix is a view, not the artefact

Teams that internalise this stop treating the traceability matrix as something to build and start treating it as something to generate. The matrix you hand to a reviewer is a formatted view of the graph — a projection of the relationships you've been maintaining throughout development. It isn't assembled from separate documents at submission. It reflects the current state of the engineering record at the moment you render it.

MANKAIND is built around this model because the alternative doesn't scale. Your design record is a live graph — user needs, risk controls, requirements, design decisions, SOUP items, and test results connected by typed relationships from day one. When a reviewer wants the matrix, it renders from the record. When a design change happens, every affected artefact is visible immediately, and the decision to update, defer, or waive is made with full information.

The reconciliation tax disappears. That's the point.