Every automotive software team that has been through an Automotive SPICE assessment knows the feeling: weeks of preparation, and the assessor still finds gaps. Most of those findings are not deep process failures. They are small, mechanical omissions that nobody had time to catch across thousands of work items: a missing link here, an untestable requirement there. Here are five of the most common, and why each one is exactly the kind of problem automation is built to prevent.
1. Requirements with no downstream traceability
The finding: A requirement exists, but nothing links to it. No design element implements it, no test case verifies it. In SYS.2 and SWE.1 assessments, this surfaces as "requirement lacks downstream traceability to a design or test artifact."
Why it happens: Traceability is created manually, one link at a time, by engineers who are already stretched. When a requirement is added late or changed under deadline pressure, the links are the first thing to be skipped. Multiply that across a few thousand requirements and the gaps are invisible until someone goes looking, usually the assessor.
Why automation prevents it: A tool that continuously scans the full requirement set can flag every item missing a downstream link the moment it appears, not weeks later during audit prep. The work shifts from "manually check thousands of items once, under pressure" to "review a short list of flagged exceptions continuously."
2. Untestable requirements
The finding: "The system shall respond quickly." Quickly how? Under what load? Measured how? IEEE 29148 and ASPICE SWE.1 both expect every requirement to be verifiable, with a measurable acceptance criterion and a defined verification method. Vague requirements get marked P (partially achieved) or N (not achieved).
Why it happens: Writing precise, testable requirements is genuinely hard, and the people writing them are domain experts under time pressure, not technical-writing specialists. Ambiguity slips in and nobody systematically reviews every requirement for testability.
Why automation prevents it: AI can review each requirement against quality attributes such as measurability, unambiguity, and the presence of a verification method, and flag the weak ones before they ever reach an assessor. It turns an impossible manual review of thousands of items into an automated quality gate.
3. Missing or one-directional links between system and software requirements
The finding: A system requirement refines into software requirements, but the link only exists in one direction, or is missing entirely. ASPICE expects bidirectional traceability, so the assessor can navigate both up and down the V-model. "Requirements lack bidirectional traceability" is one of the most frequent findings in SYS.2 and SWE.1.
Why it happens: Most ALM tools let you create a link from one side without enforcing the reverse. Engineers create the link they are thinking about and move on. The missing direction is silent: nothing breaks, nothing warns you.
Why automation prevents it: A traceability engine can check both directions automatically and report every asymmetric or missing link. What is invisible in a manual workflow becomes a simple, reviewable list.
4. Test cases that do not trace back to requirements
The finding: Tests exist and they even pass, but they are not linked to the requirements they verify. From an assessment perspective, an unlinked test provides no verification evidence. SWE.5 and SWE.6 expect every test to trace to what it verifies, and every requirement to be covered by at least one test.
Why it happens: Tests and requirements often live in different parts of the ALM, created by different people at different times. Linking them is a manual, after-the-fact chore that competes with shipping the actual tests.
Why automation prevents it: Automated coverage analysis can map tests to requirements and immediately surface both unlinked tests and uncovered requirements. The coverage gap that would have been a finding becomes a task on a list, weeks before the audit.
5. No clear picture of capability level until it is too late
The finding: This is not a single finding. It is the meta-problem behind all of them. Teams often do not know their real ASPICE capability level until the assessment is underway, because measuring it manually across SYS.1 to SYS.3 and SWE.1 to SWE.6 is so laborious that it only happens right before the audit, if at all.
Why it happens: Determining capability level means counting work products, links, reviews, and coverage across every process area and base practice. Done by hand in spreadsheets, it is a multi-day effort that is out of date the moment it is finished.
Why automation prevents it: Deterministic scoring, which counts the same facts the assessor will count directly from the ALM, can produce a capability-level picture on demand, any day of the project, not just before the audit. When the score is always available, gaps get closed continuously instead of discovered in the room.
The pattern
None of these five findings are sophisticated. They are mechanical, repetitive checks across a volume of data too large for a human team to police by hand while also doing their actual engineering work. That is precisely the kind of problem that automation and AI are suited to: not replacing the engineer's judgment, but handling the tireless, large-scale checking that judgment depends on.
The assessment does not have to be the moment you find out. With continuous, automated analysis on top of the ALM you already use, the gaps surface while there is still time to fix them, and the assessment becomes a confirmation of what you already knew, rather than a discovery of what you missed.
Cadenza is an AI-powered intelligence layer for requirements engineering. It connects to your existing ALM, whether Polarion, Codebeamer, Jama, or DOORS Next, and automates traceability, gap detection, test generation, and capability scoring, without replacing your tools or migrating your data. See it in action.