Traceability: linking requirement, implementation and check

There is a defect in production. “Which requirement does it violate” sounds like a simple question, but it cannot be answered: the requirement existed, people remember it, and where exactly it was written down and what was checked against it no longer is.

Traceability is usually presented as a document: a matrix with requirements down the side, tests across the top, ticks where they meet. The matrix gets created at the start of a project, maintained for six weeks and abandoned, because it sits apart from the work and therefore goes stale faster than it is updated.

Traceability that works is not a document. It is a property of the working artifacts: from any point in the chain you can reach the neighbouring ones without asking a living person.

The two questions that test it

There is no need to assess process maturity. It is enough to try to answer.

Take one line of the spec. Where is the code implementing it, and where is the check confirming it?
Take a defect from the last release. Which requirement does it violate?

If both answers come from one particular person’s memory, there is no traceability — there is a person. They will go on holiday, and the chain will break with them.

Why this belongs to the analyst, not the tester. Traceability is the only mechanism that turns a change of requirement into a change of check. Without it, an edit to the spec reaches the code and never reaches the test, and a release later the test is confirming behaviour that has already been cancelled.

Where the chain breaks

There are only a few breaks, and they are recognisable.

The requirement lives in two places

There is a document with the description, and there is a ticket in the tracker where someone retyped it in their own words. From then on, one of the two gets edited. A month later they have diverged, and nobody knows which is authoritative — which means nobody knows what to judge a defect against.

The cure is not discipline but a decision: one source, everything else a link to it. Which source hardly matters; what matters is that it is named and that there is no second one.

The test was written from the implementation

The quietest break of the lot. A tester opens the finished feature, observes how it behaves and writes that down as the expected behaviour. The test is green and worthless: it confirms that the system does what it does.

The tell is that the test could not have been written before development. If it leans on specific button labels and field order, it describes a screen rather than an acceptance criterion.

The defect is closed without a link to a requirement

A developer corrected the behaviour, a tester verified it, the ticket is closed. What did not happen: nobody looked at what the spec said. If the spec said otherwise, it is still wrong — and the next change will bring the defect back.

Which is why it pays to close a defect with one line: which requirement was violated, or “there was no requirement; this one has been added”.

The minimum that works

Traceability does not need a new system. It needs an identifier and four links placed where the work is happening anyway.

What is linked	By what	Sign the link is alive
Requirement → ticket	Requirement id in the ticket	The ticket shows what it implements
Ticket → code	Ticket number in the commit	A file can tell you why it changed
Requirement → check	The id in the test name	Searching the id finds the test
Defect → requirement	A link on closing	You can see whether a requirement existed

An identifier is not bureaucracy — it is what makes a link findable by search. A short scheme is enough:

REQ-114   access closes when the subscription expires
  ticket    TASK-2071
  commit    "TASK-2071: close access on expiry"
  test      test_REQ_114_access_closes_within_hour
  defect    BUG-388 → violates REQ-114

A scheme like this needs no tooling: it works on string search in any tracker and any repository.

Don’t stand up a separate traceability system. Any artifact that has to be updated by hand after every change goes stale — it is a matter of months. The link has to be made where someone is already typing: in the commit, in the test name, in a field of the ticket.

When there is no traceability at all

Retrofitting it across the whole product is pointless — large effort, deferred benefit. It is more sensible to start where it already hurts.

With defects. Every defect you triage gets a line saying which requirement it violates. Within a month you have a map of the murkiest areas.
With non-functional requirements. They most often have no test at all, and that gets discovered during an incident.
With whatever changes most often. Calculation rules, permissions, statuses — where a change arrives every quarter, a lost link costs the most.

The sign that the chain broke long ago: to find out how the system is supposed to behave, everyone reads the code.

A fifteen-minute check

Take the last closed defect and walk it backwards: test → ticket → requirement. Note the step at which you had to ask a person. That step is where to start.

What next

Traceability holds as long as requirements change in an orderly way. The next break is the moment a change arrives mid-development and someone has to decide: rewrite the spec, or file a new task.