Traceability

Suspect links and impact analysis: what breaks when a requirement changes

What suspect links are, why regulated teams need them, and how impact analysis turns a change into a re-verification list instead of a spreadsheet fire drill.

By traceunified ·

When a requirement, test, risk, or SBOM component changes, linked items are potentially wrong until someone re-checks it. Suspect links are how a system of record marks that uncertainty, according to rules you configure. Impact analysis is how you see the blast radius before you commit the change — or after, when you need a worklist.

Without that, teams rebuild a requirements traceability matrix under audit pressure and hope nothing slipped.

What “suspect” means

A link is suspect when the source or target of a governed relationship changed in a way that may invalidate the relationship’s meaning — for example:

  • A requirement’s text or acceptance criteria changed after tests were written against the old wording
  • A mitigation changed after residual risk was accepted

Which changes raise suspect is configured, not assumed. Fields marked as triggersSuspect raise it according to your trace rule set; by default the flag goes one hop, to directly linked items, and an administrator can enable multi-hop cascade. Editing an architecture block’s content does not flag its links suspect automatically.

Suspect is not a failure. It is a queue for re-verification: confirm the link still holds, update the downstream artifact, or deliberately accept and clear the flag under your process.

Why spreadsheets cannot do this

A static RTM is a snapshot. It cannot watch the live graph. The moment you export coverage to Excel, change continues in the tools — and the matrix ages. Impact analysis in a system of record reads the current link graph, so the worklist matches reality rather than last Thursday’s export.

What good impact analysis shows

Before or after a change, you should be able to answer:

  1. What is directly linked (forward and backward)?
  2. What is transitively affected (requirement → architecture → tests → risk)?
  3. Which links are already suspect?
  4. What evidence (runs, signatures, baselines) referenced the old version?

That is the difference between “we think we checked” and a defensible re-verification plan. See Traceability for how the live matrix and suspect workflow sit in product.

Evaluation questions for any tool

  1. Show a requirement edit to a suspect-triggering field that flags linked tests and risks — without a manual matrix update.
  2. Can impact analysis run before you save, so reviewers see the blast radius?
  3. Is the suspect model configurable — which fields trigger it, and how many hops it carries?
  4. How do you clear suspect under a controlled review or signature when Part 11 is in scope?

See traceability work as one connected system.

Requirements, architecture, tests, risk, and SBOM on a single thread — audit-ready when you need it.

Try for free Tour the platform →