Most engineering programmes claim traceability. Far fewer can demonstrate it on a bad afternoon — when an assessor asks, a change lands, or a failure investigation needs the full chain from requirement to test result. This note looks at why traceability decays, and at the practices that keep it alive.
What traceability is for
Requirements traceability is the ability to follow a requirement in both directions: forward, from a requirement to the design, implementation and tests that realise and verify it; and backward, from any artefact to the requirement (or stakeholder need) that justifies it. The classic artefact is the requirements traceability matrix — a table linking each requirement to its downstream evidence.
The purpose is not paperwork. Traceability is what lets a programme answer four questions at speed: which requirement does this code serve? Which test verifies this requirement? What is affected if this requirement changes? And — hardest of all — which requirements have quietly lost their evidence?
How traceability decays
Manual links rot. Links created by hand are accurate on the day they are written. From that day on, every edit to a requirement, a design or a test can invalidate them, and nothing notices until someone follows the link and finds it leads nowhere.
The toolchain splits. Requirements live in one tool, design in another, code in a repository, tests in a third. Every boundary a relationship has to cross is a place it can be dropped — and toolchains are mostly boundaries.
Change outpaces upkeep. Traceability is usually maintained as an afterthought, behind development. After a busy quarter, the matrix can describe a system that no longer exists.
Reviews approve documents, not relationships. A review can find every individual artefact sound and still miss the structural failure: requirement 4.2 no longer has a verifying test, or a test verifies a requirement that was withdrawn months ago.
Keeping it intact
Traceability does not survive on diligence alone. It survives on structure:
Link artefacts, not documents. Keep the links with the things they connect — requirement to test case, test case to result — in one place, rather than recreating them inside reports and spreadsheets that immediately drift.
Make broken links visible continuously. Orphan requirements, unverified requirements and tests that verify nothing should surface in the normal workflow — in the pipeline, on the dashboard — not in an annual audit.
Tie traceability to change. Impact analysis consumes traceability; it should also regenerate it. Every change record ends with an update to the affected links, so the map moves with the system instead of lagging behind it.
Review the graph, not just the artefacts. A traceability review asks questions no document review can: are there requirements nothing traces to? Tests nothing needs? Evidence chains that terminate early?
What we are investigating
At Fallon Apus Orbital Systems, this is the practical core of our engineering-evidence research: architectures that connect requirements, assumptions, implementation changes, verification activities and results, so that relationships can be traced and maintained as the system evolves — with change-impact analysis as the natural first application.
Status: conceptual research and prototyping. This is not a finished product.
If traceability on your programme has quietly become a retrieval exercise, we would be glad to compare notes — write to Paul at paulorbitalsystems@proton.me. Each week’s newsletter also carries notes like this one; you can join below.