Across projects · requirements engineering · verification
Traceability is a property of the architecture, not a spreadsheet
A trace is only worth having if it answers two questions quickly: why does this piece of the system exist, and what breaks if this requirement changes. I have kept those links alive four different ways — each chosen for its context, each with a place it broke.
01 — The chain
From a customer sentence to a transition guard, and back
This chain is from an adaptive cruise control exercise in my M.Eng requirements-engineering module. A natural-language requirement is refined into a formal function, then a signal-level system requirement, then an environment requirement, then a Stateflow chart that compiles and runs against the plant model. Forward, it explains why a guard exists. Backward, it is impact analysis.
ACC_Dev2.slx. Suspect-link behaviour mirrors DOORS, which the module used with object IDs mapped to Enterprise Architect aliases. Team coursework exercise.02 — Four mechanisms
Same goal, four implementations
No single tool keeps a trace honest. What works depends on who edits the source of truth and how often it changes. These are the four I have actually run.
Generate the views from the data
Pinout workbook is the source of truth; System Composer masks and CAN topology are outputs. The trace cannot drift because nobody edits the picture.
Link inside the model
Simulink Requirements links to blocks, Test Manager cases and coverage. At Mitsubishi, MC/DC closed ISO 26262 ASIL C/D findings; automated Simulink Test workflows cut manual test effort by 75%.
Gate the build on the trace
17 requirement IDs read straight from the spec. 11 traced, 6 untraced on purpose (hardware, write-up), 0 broken links. A broken link always fails; a coverage regression below 64.7% fails.
Trace behaviour back to its rule
Each replayed step names the transition-table row that fired, so a disagreement with the car points at a rule, not a debugger session. 89 of 89 real transitions aligned.
03 — Closing the trace
A link to a test is not proof the test was thorough
The last hop of any trace is "verified". What that word means depends on the coverage criterion. For safety-rated software the bar is MC/DC — each condition shown to flip the outcome on its own.
STATE COVERAGE
Every state entered. Says nothing about which transitions got you there.
DECISION COVERAGE
Every decision outcome hit once.
MC/DC
Required at ASIL C/D. What I tested to at Mitsubishi.
04 — Where the trace broke
The failures taught more than the passes
A requirement nobody wrote
A MATLAB release moved a folder and silently broke the Arduino support-package link. Days with MathWorks support produced a requirement the concept-car spec never had: toolchain versions stay compatible for the life of the project. Pinning is a requirement, not an implementation detail.
An interface spec with defects in it
Taking over Big Red's CAN database, I found 8 defects across its 16 signals before integration — wrong units, a wrong index, a duplicated signal, a converter reporting an inverter's temperature. A trace to a wrong interface is still wrong.
A test suite that could not fail
In the openpilot port, deleting the noEntry row left all 16 tests green: every test checked state, none checked alerts. One alert assertion later, the mutation fails the suite. A trace to a test proves nothing until the test has gone red for the right reason.
Evidence that never covered two states
5.5 hours of real driving exercised three of openpilot's five engage states. preEnabled and softDisabling are verified by unit tests only — and the page says so rather than letting 99.9963% imply otherwise.
05 — Contrast
Which trace architecture for which program
| Criterion | ALM tool of record (DOORS, Polarion, Codebeamer) | Links inside the model | Generated from interface data | Trace-as-code CI gate |
|---|---|---|---|---|
| Audit evidence for ISO 26262 / ASPICE | strongest — built for it | strong for model-level work | needs export to a record | needs export to a record |
| Resists silent drift | suspect links, if people clear them | while the model is the source | views cannot drift | build fails on a broken link |
| Impact analysis across teams | native | inside the model boundary | interfaces only | repository boundary |
| Cost to adopt on a small team | licences, admin, training | toolbox licences | spreadsheet + script | script + CI already present |
| Where I have used it | DOORS + EA in coursework; Polarion / Codebeamer not used | Mitsubishi, Fontaine | Big Red | concept car |
An ALM tool as the record auditors read, model-level links where the design lives, and a CI gate that fails a merge when a link breaks — with the gate's results pushed into the tool of record rather than kept beside it. Interface definitions stay as data, and every architecture diagram is generated from them.
Scope: the four mechanisms in section 02 are ones I have run. The combined production setup above is a recommendation, not a system I have deployed.