Requirements Traceability

Requirements traceability is the ability to follow a requirement from its origin (stakeholder need) through its implementation (design element) to its verification (test result). A traceability matrix links requirements to design items and test cases, proving that every requirement is implemented and verified.

Why companies use it

·Regulatory requirement in aerospace (DO-178C), medical devices (FDA 21 CFR Part 820), and automotive (ISO 26262)
·Enables impact analysis — any requirement or design change immediately shows what tests need to be re-run
·Identifies orphan requirements (no design element) and orphan tests (no requirement) — both represent risk
·Required for PPAP documentation in automotive and for design history files (DHF) in medical devices

What hiring managers look for

·Traceability is non-negotiable in regulated industries — candidates without it will fail compliance audits
·The ability to set up and maintain a traceability matrix in a requirements management tool is a practical, valued skill
·Bi-directional traceability (requirement ↔ design ↔ test) is the gold standard — many organisations only achieve one direction
·Understanding what happens when traceability breaks down (design changes without corresponding test updates) shows risk awareness

Typical interview questions

What is a Requirements Traceability Matrix (RTM) and what does it contain?

What is the difference between forward traceability and backward traceability?

How do you maintain traceability when requirements change late in a project?

What is an orphan requirement and why is it a risk?

How have you implemented or maintained requirements traceability in a previous project?

Common mistakes

·Building the traceability matrix retrospectively at the end of the project — it is not a documentation exercise, it must be maintained throughout
·Creating forward traceability only (requirement to test) without backward traceability (test back to requirement) — gaps hide in both directions
·Using a spreadsheet for traceability on large programmes — beyond ~200 requirements, manual spreadsheet maintenance becomes error-prone and unsustainable
·Not re-running traceability checks after design changes — a design change without a test update creates un-verified coverage
·Confusing test coverage (percentage of requirements with at least one test) with verified coverage (percentage of tests that have been run and passed)

Real engineering example

A software team developing medical imaging firmware maintained a bi-directional traceability matrix in DOORS linking 340 requirements to 1,200 test cases. During final verification, the matrix identified 18 requirements with no linked test case — they had been added during a late requirements change and the test plan had not been updated. Catching this before submission saved the company from an FDA 510(k) rejection that would have delayed market entry by 6–9 months.

Topics covered

traceabilityRTMrequirementsDOORSforward traceabilitybackward traceabilitycompliance

Related interview guides

Systems Engineer →Test Validation Engineer →Functional Safety Engineer →Embedded Software Engineer →