Lesson 10 of 16 · Automation and AI · Automotive SPICE, the vital 20 %
Automated checks: structure, not consistency
Put requirements, architecture and tests in Git with trace links, and a CI job can check the whole graph on every commit. That's a real gain. This lesson is about exactly how much such a check establishes, and how much it doesn't.
At which capability level do the SYS/SWE "consistency and traceability" base practices count?
Components trace to groups of requirements rather than to each one. Acceptable, or a weakness?
Seat-Heat goes docs-as-code
What each check supports
| Check | Supports | Watch out for |
|---|---|---|
| 1 references resolve | The traceability BPs; SUP.8.BP7 consistency of baseline information. | Nothing: pure gain. |
| 2 required parent | The traceability BPs. | The required parent depends on context. In software-only development, software requirements can trace to stakeholder requirements[SWE.1.BP5 note 12, p. 45]. |
| 3 legal pairs | The V's pairings, e.g. unit verification ↔ units (SWE.4.BP4). "Redundant traceability is not intended" (note 9). | Don't forbid edges the PAM asks for. SWE.3.BP4 includes traceability from the detailed design to the software requirements[p. 49]. |
| 4 orphans | Coverage, one of the benefits the Guidelines list for traceability[§2.3.4.2, p. 57]. | Some items legitimately have no downstream link. Non-functional system requirements the software doesn't trace to "are still subject to verification" (SWE.1.BP5 note 10). Allow a recorded justification. |
| 5 IDs and metadata | Identification, storage and control: GP 2.2.2/2.2.3; SUP.8.BP1/BP2. | For the engineering processes this is level-2 evidence (GP 2.2.2/2.2.3). For SUP.8 itself, BP1/BP2 are base practices, so it counts at level 1 there. |
| 6 requirement wording | Requirement characteristics (SWE.1.BP1 notes 1–2: ISO 29148, INCOSE) and GP 2.2.1 quality criteria. | The PAM's examples are verifiability, unambiguity, freedom from design and non-contradiction. A sentence template like EARS is a HOW, not an ASPICE demand. |
Stricter than ASPICE is fine; just don't say ASPICE demands it
The Guidelines protect lighter approaches with "shall not be downrated" rules: cluster-level tracing (TAC.RL.1), manual snapshot checks (TAC.RL.2), and consistency shown through pair work or commit comments without formal review records (TAC.RL.3)[§2.3.4.3–5, pp. 58–60]. An automated, atomic, merge-blocking checker goes beyond all of them. That's a sound engineering choice, but it is not what the PAM requires.
What no structural check can establish
"Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent."[SWE.1.BP5 note 11, p. 45] A green CI run proves the graph is well-formed. It does not prove the architecture implements the requirement or that the test tests it, and assessors check exactly that content[Guidelines §1.4.3.3, p. 39]. Nor does it prove compliance: that is an assessor's judgement about a process.
Consistency needs a semantic check, and the repository has to show one happened. Information item 13-51 Consistency evidence accepts pair or group work, revision histories and repository meta-information showing corrections made against other documents[Guidelines §2.3.4.1, pp. 55–56]. For Seat-Heat, the natural fit is a reviewer approving the pull request that changes a requirement and its linked tests, with the review recorded.
Practice
For each rule or situation: does it support an ASPICE practice, go beyond what ASPICE asks, or is it wrong because it contradicts the PAM? The first question asks which property failed.
CI is green. A SWE.6 test checks a 90 s ramp; the requirement it traces to now says 60 s. What failed?
A new rule blocks any detailed-design record (SWE.3) that traces to a software requirement (SWE.1).
A rule forbids cluster-level links: every requirement must be traced individually.
CI blocks two records that share an ID.
The wording check is configured for "system requirements, process SYS.1".
In two sentences: what does a green traceability check establish, and what doesn't it?
It establishes that the trace graph is structurally sound: references resolve, links follow the V's pairings, IDs are unique and records are well-formed. It doesn't establish that linked items agree in content (consistency) or that any process is compliant; that needs recorded semantic review and, in the end, an assessor's judgement.
Your win: you can design a traceability checker that supports the right practices, doesn't reject valid structures, and isn't oversold.
To keep it: import this lesson's Anki deck (how).
Read next
The traceability BPs and their notes: SYS on PAM pp. 35–43, SWE on pp. 44–57; then Guidelines §2.3.4, pp. 55–60.
Have a check that isn't covered here? Ask your teacher to map it to a practice.