A Traced Requirement Can Still Be Wrong: The ASPICE Gap Assessors Keep Finding
A software requirement can be correctly, bidirectionally traced to its parent and still fail an ASPICE assessment, because nothing checked whether the parent itself was sound. Here's the difference between a trace that exists and a trace that's true.
A software requirement can trace cleanly to its parent system requirement, pass every link-completeness check in the traceability matrix, and still be built on a defect the matrix never surfaces. The link is real. What it points to is not sound. Nothing in a standard bidirectional trace check catches that difference, and it's the gap that shows up most often once an ASPICE assessor starts asking questions instead of scanning a spreadsheet.
What BP6 actually asks an assessor to check
SWE.1, Software Requirements Analysis, is one of the most frequently assessed processes in Automotive SPICE, and its sixth base practice is the one that trips up the most programmes. BP6 asks for bidirectional traceability between system requirements and software requirements: every software requirement traces back to something that justified it, and every system requirement that applies to software has at least one software requirement satisfying it. Starting at Capability Level 2, this isn't optional. An assessor without evidence of both directions has grounds to fail the practice outright, and SodiusWillert's breakdown of what assessors actually review makes the same point: traceability evidence isn't a formality tacked onto the review, it's usually the first thing pulled.
Most teams prepare for this by building a traceability matrix, sometimes in a dedicated ALM tool, often in a spreadsheet that started as a stopgap and never got replaced. The matrix answers one question well: does a link exist between this software requirement and a system requirement. That's a real and necessary check. It is also not the same question as whether the system requirement at the other end of that link says something that's actually true, unambiguous, and not contradicted somewhere else in the same document. An assessor rarely opens by debating a requirement's wording, either. They start by following a trace, and the conversation only shifts to engineering discipline once that trace lands on a parent requirement that contradicts something else in the same document.
A trace that's green and still wrong
Take a system requirement, SYS-0442: "The braking control unit shall enter degraded mode within 50 ms of sensor fault detection." A software requirement, SWR-1187, traces to it cleanly: "The braking control module shall transition to degraded mode within 50 ms of receiving a fault flag from the sensor abstraction layer." Read in isolation, that's textbook. Correct parent-child relationship, matching timing constraint, clear derivation. An RTM export shows a green checkmark on both the forward and backward link. Nothing here would make an assessor pause.
Three hundred pages later in the same system specification, a different author working a different failure mode wrote SYS-0891: "The braking control unit shall maintain full control authority for a minimum of 200 ms after sensor fault detection before any mode transition." Nobody flagged it during review, because SYS-0442 and SYS-0891 don't share vocabulary, aren't adjacent in the document, and were written by two engineers who had no reason to compare notes. But they directly disagree. One requirement says transition within 50 ms. The other says hold authority for at least 200 ms before transitioning. SWR-1187 is correctly, bidirectionally traced to a requirement that is itself in direct contradiction with another requirement in the same spec.
An assessor checking BP6 sees a complete trace and moves on. A supplier building against SWR-1187 builds exactly what was asked, and the mode-transition conflict surfaces during integration testing, or worse, during a field issue, months after sign-off. That's not a flaw in the matrix. It's a boundary nobody drew around what BP6 was ever meant to catch.
Two different questions wearing one checkbox
This is the part gap analyses tend to flatten: link-existence and requirement-soundness are different problems, and treating them as one checkbox is where the risk hides. A traceability tool, whether it's DOORS, Polarion, or a spreadsheet, answers one question: is there a connection. Walter Consulting's review of ASPICE traceability practice and the broader treatment of traceability across ASPICE and ISO 26262 both describe the same evidence assessors look for: parent-child links, coverage from stakeholder needs down through test cases, no orphaned requirements. None of that reads the parent requirement's text against every other requirement it might disagree with.
That's a semantic comparison problem, not a link-auditing one. Hybrid contradiction detection is built for exactly this gap: keyword or reference matching won't flag SYS-0442 and SYS-0891 disagreeing, since neither mentions the other and they share almost no vocabulary. Catching it means recognizing that "transition within 50 ms" and "maintain authority for 200 ms before transitioning" describe the same event with incompatible timing.
What changes past a few hundred requirements
At 50 requirements, a careful reviewer might catch SYS-0442 versus SYS-0891 by memory, or by chance, during a second read-through. That doesn't scale. A specification with 1,000 requirements has close to a million possible pairings if you wanted to check every requirement against every other one for contradiction, and most automotive system specifications this size have several thousand requirements before software decomposition even starts. The scale problem stops being theoretical well before a spec reaches a few thousand requirements. Manual review is already unmanageable at a size most SDV programmes hit today.
Across specifications running into the thousands of requirements, including complex tables and images, WYZER's own validated runs of this kind of hybrid check have flagged duplicate candidates at roughly one in eight of the total, with zero false conflicts reported on requirements that were genuinely clean. In separate runs against specifications that did contain real, direct conflicts, the same approach isolated a small minority, roughly 2 percent of all requirement pairs, as the high-risk set worth an engineer's attention, rather than burying that signal in a wall of low-confidence noise. Neither number is an ASPICE certification claim. What they show is that finding the SYS-0442/SYS-0891 kind of pair before someone traces software to one of them is tractable at scale in a way manual cross-referencing isn't.
Running the quality pass before the assessment window, not during it
The practical fix isn't a bigger spreadsheet. It's sequencing: run a contradiction and duplicate pass across the system requirements before software gets traced to them, not during assessment prep. Flag SYS-0442 against SYS-0891 before SWR-1187 exists, and the trace either doesn't get written against the unresolved requirement, or gets written with the conflict already routed to whoever owns that decision.
None of this grants ASPICE certification, and no tool does. What it removes is one recurring reason SWE.1 findings happen: traceability evidence and requirement-quality evidence get produced separately, on different schedules, and nobody reconciles them until an assessor asks a question the matrix wasn't built to answer. WYZER Detective runs this pass, the same dependency graph and quality-scoring analysis that surfaces conflicts like SYS-0442/SYS-0891, with Sherlock producing findings traceable back to a specific requirement pair, not a black-box score.
A trace that exists and a trace that's true look identical in an RTM export. The only way to tell them apart is to check the second thing separately from the first, and to check it before the assessment window opens rather than during it.