Traceability That Does Not Rot - Suspect Links and Change Impact in ALM

Almost every ALM tool lets you say “this requirement is related to that test” or “this change affects that risk.” That button is easy. The hard part is what happens on Tuesday, when the requirement text changed and the test did not.

If the link still looks green, you do not have traceability. You have a souvenir.

Real traceability is a claim about freshness. The relationship is either confirmed against the current content, or it is suspect and someone has to look.

What “suspect” actually means

A link becomes suspect when one side changed in a way that might invalidate the meaning of the link.

That is not the same as “someone touched the item.” A status flip from Draft to In Review might not change the requirement text. A rewrite of the acceptance criteria almost certainly does.

I treat three states as enough for a UI:

Confirmed. A person (or a rule you trust) said this link still holds after the last relevant change.
Suspect. Something material changed. The link stays, but it is visually and semantically “do not trust yet.”
Cleared / unset. A person looked and either confirmed or removed the relationship.

Two states (“linked” / “not linked”) hide the only question auditors and engineers care about: is this still true?

The UI has to make suspicion cheap to see

If suspect is a flag buried in a properties dialog, nobody will use it.

What works in practice:

A mark on the link itself, not only on the item header.
A filter: “show me only suspect links on this tree.”
A reason, even a short one: “target revised on 12 May” beats a red dot with no story.
Bulk confirm that still requires a person. Do not auto-clear because a job ran.

I have also learned to keep set and unset as explicit actions with a payload. A silent toggle that only lives in local UI state will drift from the server, and then two tools will disagree about the same pair of IDs.

Parity is the real product

The interesting systems I have worked on do not live in one tool. A requirement in tool A is linked to a work item in tool B. Each side has a URL, a predicate, and a last-modified stamp.

Parity means:

The same pair is present on both sides, or the missing side is a first-class “pending backlink.”
The suspect flag is not a decoration in one UI and absent in the other.
Clearing the link in one place does not leave a zombie in the other.

If you only implement the pretty tree in the tool you own, you have built a brochure. The other tool’s users will keep creating links you cannot see.

A practical test: export the link set from both sides, join on stable IDs, and list the deltas. If you cannot produce that list, you cannot claim parity.

Change impact is a query, not a screenshot

People ask “what does this change touch?” and expect a screenshot of a graph. Graphs are for talks. Impact is a query:

Start from the changed item.
Walk only the predicates that mean “depends on” or “verified by,” not every “related.”
Stop at a depth you can defend.
Surface the suspect edges first. Those are where the change is unpaid work.

If everything is related to everything, the graph is noise. Predicate hygiene is part of impact analysis. I would rather have four boring link types that mean something than twenty synonyms.

What I refuse to automate

I will automate detecting suspicion from a revision or a hash of the linked text. I will not automate confirming it because a model said the sentences still look similar.

Similarity is not verification. A test can still mention the old field name in a way that embeds nicely and fails in production.

The human confirm is the point. The software’s job is to make that confirm unavoidable and fast.

A small definition you can take to a team

Traceability is a set of links plus a freshness claim plus a way for two systems to agree.

If you are missing any of the three, say so. “We have a lot of related-to links” is an honest inventory. It is not a safety argument.

Related-to is a social feature