Reference · Automotive SPICE 4.1
Common misconceptions, corrected
| Often said | What the sources say | Source |
|---|---|---|
| A company, or a tool, is "ASPICE Level 2". | Levels belong to processes of an organisational unit. Tools supply evidence and are not rated. | PAM §3.2, p. 17: the capability level is determined "of a given process" |
| Process attributes are rated 0–5. | PAs are rated N/P/L/F; levels are derived from them. | PAM Table 9, p. 22 |
| 4.1 includes cybersecurity (SEC processes). | Not in the 4.1 PRM. Cybersecurity is a separate VDA model that "remains a separate document". | Guidelines preface |
| Traceability gets you to level 2. | The consistency and traceability BPs are level 1. Traceability within one process's own work products isn't covered by them; it "may be considered" under GP 2.2.2. | Guidelines §2.3.4.2, p. 57 |
| Links prove consistency; a green checker proves compliance. | "Traceability alone … does not necessarily mean that the information is consistent." Assessors examine content. | PAM p. 45; Guidelines p. 39 |
| ASPICE has V-model phases. | The PAM "neither predefines, nor discourages, any order". The lifecycle is the project's (MAN.3.BP2). | PAM §3.3.4, pp. 26–27 |
| SYS.1 holds the system requirements. | SYS.1 is Requirements Elicitation (stakeholder requirements); system requirements are SYS.2. | PAM p. 15 |
| Verification must be independent. | Only SUP.1 quality assurance requires independence. Any independence rule for verification comes from other standards the project follows. | PAM SUP.1.BP1, p. 79 |
| SWE.6 results trace to risks. | SWE.6 traces measures to software requirements, and results to measures. | PAM SWE.6.BP4, p. 56 |
| Every item must trace downstream. | Some non-functional requirements legitimately don't; they are still verified. Redundant traceability is "not intended". | PAM SWE.1.BP5 notes 9–10, p. 45 |
| Atomic, tool-checked links are required. | Clusters, manual snapshot checks and informal consistency evidence "shall not be downrated". | Guidelines TAC.RL.1–3, pp. 58–60 |
| Information items are documents you must write. | They are what the assessor looks for; "shall not be interpreted as a required structure". | PAM §3.3.1–3.3.2, pp. 23–25 |
| Using AI lowers the rating. | AI use is a HOW. The assessor rates the WHAT and looks at control of the tools, models, settings and prompts. | Guidelines §2.5.5, pp. 98–99 |
| A process performance objective is a project goal. | Neither a project goal nor a restated outcome: a target for how one process is performed. | PAM GP 2.1.1 note 1, p. 101 |
| Unit tests generated from the code verify the unit. | Units are verified against the detailed design; testing code against itself "would just prove that the code works as programmed". | Guidelines §3.11.1, p. 154 |
| 100 % code coverage is the goal of unit verification. | Coverage is "accompanying information" about the completeness of the chosen tests, "not a verification objective". | Guidelines §3.11.1, p. 154 |
| A picture of the code is a detailed design. | It "is not a mere graphical representation of the source code logic"; it says what each unit shall do. | Guidelines §3.10.1, p. 144 |
| Every supplier must perform VAL.1 validation. | VAL.1 is about end users; it excludes pure embedded software, ECUs and drives. It is a flex process. | Guidelines §3.14.1, p. 163 |
Practised in Lesson 13; the last four in lessons 15 and 16. Course index · Glossary