[ OPERATING INTERSECTION ]
Requirements → controls → evidence
The traceability chain from intended need to implemented control and accepted proof.
What this page does not claim
SPEQ synthesis for education. Confirm applicable law, current guidance, standards editions, contractual duties, and organization-specific controls before making a regulated decision.
The seam below, its failure modes and its decision boundaries are SPEQ’s practitioner framing — not a regulatory requirement, and not an assessment of any organization.
OPERATING QUESTION
Can every critical requirement be followed to the control that satisfies it and the evidence that proves it?
Capabilities in the same decision
Why this is hard
The chain is built forwards and read backwards, and it is only ever tested in the direction it was built. On a project it is assembled in one order — someone states a need, someone else implements something that satisfies it, someone else produces a result that accepts the implementation — and each of those three artifacts is written by a different community, at a different time, in a different vocabulary, each internally complete and each correct on its own terms. But every occasion on which the chain actually matters runs the other way: an investigation starts from a result, a change starts from an implemented control, an assessor starts from a record and asks which need it serves. Traversed backwards, a chain assembled perfectly forwards can be useless — thirty requirements point at one test script, so a discrepancy at step nineteen suspends an unknown subset of claims and the impact assessment becomes an act of reconstruction. The second asymmetry is decay. Requirements and accepted results are frozen artifacts; the controls between them are living ones. Every later configuration change moves the control without touching either document that describes it, so the ordinary failure here is not absence but quiet staleness, discovered on the day it was needed.
How it fails
Each of these happens with every function doing its own job correctly. That is what makes them seam failures rather than performance problems.
Complete forwards and unusable backwards
Every requirement carries a reference to a test, so the coverage check passes and the package is signed. The tests, though, were aggregated for efficiency: one script exercises a whole functional area and its outcome is recorded as a single pass. When a step later shows a discrepancy, nothing in the record says which of the requirements riding on that script is now unproven, so the impact assessment becomes a reconstruction from memory of what the script was thought to cover.
Criticality is fixed before the design exists
Criticality drives how hard a requirement is tested, and it is assigned when the requirement is written, which is before anyone knows how it will be met. A need rated low because it was assumed to be a hardwired interlock stays rated low after the design realises it as a configurable software parameter any administrator can change. The rating is never revisited, because revisiting it is nobody’s scheduled task and no artifact goes stale in a way anyone can see.
The control moves and the requirement never hears
A parameter is adjusted through routine change control by the team that owns the system, assessed correctly against the risks that team can see. Nothing in the change record points back at the requirement the parameter was implementing, so the requirement and its accepted result continue to describe behaviour the system no longer has. The divergence stays invisible until a periodic review, an investigation or an inspection traverses the chain in the backwards direction.
The test proves the build, not the need
Scripts written from the design specification verify the implementation against itself, and everything passes. The requirement said the operator must be prevented from proceeding without a second check; the design implemented a warning message; the script confirmed that the warning message appears. Coverage is total, the results are genuine, and the user need is unmet — a gap no additional testing will reveal, because the additional testing is written from the same source as the first round.
What good looks like
Requirements are written so that a failing condition can be stated: if nobody can describe what “not met” would look like, there is nothing to verify and the entry is a preference. One identifier per requirement travels unchanged into design, into test and into the record that accepts it, so the backwards traversal is a lookup rather than an archaeology. Where a single script covers many requirements — often the sensible thing to do — each step records which requirement it evidences, so the granularity of a failure matches the granularity of a claim. Criticality is examined a second time once the design is known, and the implementing team is expected to say when its chosen implementation has changed the risk the requirement was rated against. Verification is authored from the requirement by someone who has not read the design, or at least reviewed by someone in that position. And every change to a control asks what need it serves, so the chain is repaired at the moment of change rather than rebuilt years later under pressure.
Who decides what
The requirement and its criticality belong to the process owner who will use the system, and belong to them after the design lands rather than only before it — a rating nobody may revise is a rating nobody owns. The implementing function owns how the need is met, and owns one decision that is regularly skipped: declaring when its implementation choice has changed the risk profile of the need it satisfies. Assurance owns whether the result supports the claim as written. Quality owns whether the remaining gap is acceptable, and can only exercise that when the gap is expressed as a named requirement rather than as an open test. The authority to settle in advance is who may narrow verification — reduce rigour, rely on a supplier’s testing, defer a check to periodic review. It is exercised on every project without exception; where it is unassigned, the schedule exercises it and nothing in the record shows that a decision was made at all.
Questions practitioners ask
Is a trace matrix the same as traceability?
No. The matrix is an artifact; traceability is the property that the chain can be walked in either direction and still return an answer that is true today. A matrix produced at the end of a project documents the chain at the moment of its greatest accuracy, after which every configuration change erodes it unless the change process is the thing that maintains it.
Can a supplier’s testing be used as evidence?
Often it can, and repeating it wholesale is waste. The conditions are knowing which of your requirements it covers, under which configuration it was performed, and whether your installed configuration is the one that was tested. Supplier testing addresses the product as shipped; the requirement concerns the system as configured and used, and the space between those two is exactly where the gap tends to sit.
What makes a requirement untestable?
Two things, and both are common. A requirement that cannot be false — that a system be robust, user friendly or secure — offers nothing to verify. And a requirement bundling several needs into one sentence can be partly satisfied, with no way to record which part failed, so the outcome is logged as a pass with a comment that nobody reads again.
Does more testing produce better traceability?
Usually not, and often the reverse. Volume pushes teams towards aggregated scripts, which is the specific practice that breaks the backwards traversal. Effort should follow consequence: a thin, exact record covering the handful of requirements whose failure would reach a patient is worth more than an exhaustive one in which those requirements are indistinguishable from the rest.
Critical handoffs
- Users define intended need and criticality.
- Engineering and digital teams implement the control.
- Assurance verifies it; Quality accepts the bounded conclusion.
Shared evidence
- Approved requirements and risk assessment
- Design and configuration baseline
- Trace matrix, test result, deviation, and acceptance