Lesson 6 of 16 · Automotive SPICE, the vital 20 %

Level 2, part 2: managing work products (PA 2.2)

PA 2.1 manages the activity; PA 2.2 manages what the activity produces. Four generic practices, in two pairs, and a close tie to SUP.1 and SUP.8.

The CR backlog breaches its limit, and the lead moves two stories out of the sprint to catch up. Which GP?

PA 1.1 P · PA 2.1 F · PA 2.2 F. Which level?

Four generic practices, two pairs

GP	Name	In practice
2.2.1	Define the requirements for the work products	Content and structure (often a template), quality criteria, review and approval criteria.
2.2.4	Review and adjust work products	Review against those criteria, and make sure the findings get resolved.
2.2.2	Define the requirements for storage and control	Where it lives, how it is identified and distributed, and a status model where the BPs need a status.
2.2.3	Identify, store and control the work products	Change control, versioning, baselining, availability with revision status.

Source: PAM §5.3.2, pp. 104–105. The Guidelines group them the same way: 2.2.1 with 2.2.4 (requirements, quality and review), 2.2.2 with 2.2.3 (storage and control)[Guidelines §4.2.3.1, p. 251].

The logic is "define, then do": first say what a good work product looks like and how it is kept, then show that it was kept that way and checked against the definition. A review with no defined criteria fails GP 2.2.4 half-way, because there is nothing to review against.

Which work products count

The relevant work products are the ones needed for level 1 plus the ones PA 2.1 and 2.2 themselves need, such as the plan or the review records. Records in tools count ("change requests or problem reports implemented in a workflow tool are also work products"). Process descriptions and role descriptions do not: they belong to level 3, so badly versioned process documents must not pull PA 2.2 down[Guidelines §4.2.1, p. 246].

Review evidence has a shape

Information item 13-19 Review evidence identifies the review object with its version, the reviewers with their roles, the date, the status, the review criteria and the non-conformances found[PAM Annex B, p. 139]. A GitHub or GitLab approval records most of that automatically. What it usually lacks is the criteria.

PA 2.2 and the SUP processes move together. The Guidelines expect SUP.1.BP2 to be in line with GP 2.2.1, SUP.1.BP3 with GP 2.2.4, SUP.8.BP2 with GP 2.2.2, and SUP.8.BP4/BP5 with GP 2.2.3, across the other processes[Guidelines §4.2.3.2, pp. 251–252]. When the Guidelines explain how rating rules are worded, their illustration is exactly this pairing: "SUP.1.BP3 shall not be rated higher than the ratings across GP 2.2.4 of all processes"[Guidelines §1.5.2, p. 42]. Weak configuration management or weak reviews tend to show up across the whole level-2 profile.

AI assistants are a PA 2.2 question

The Guidelines' section on AI assistance says tool use is a HOW-level choice, and that assessors still rate the WHAT. It names PA 2.2, SUP.8 and SUP.1, among others, as places AI tools reach, with examples: prompts that generate source code as new configuration items, approval of which AI tools may be used, and version control of "AI tools, models, and settings, because their behavior changes over time"[Guidelines §2.5.5, pp. 98–99]. Lesson 12 goes deeper.

Seat-Heat's software requirements (SWE.1) at level 2

Jira issue type "SW Requirement" with mandatory fields: ID, text, rationale, verification criteria, ASIL. A Confluence page lists the quality criteria: atomic, verifiable, no design, unambiguous. Workflow: Draft → In review → Approved → Obsolete. Only the SW lead can move to Approved. Jira keeps each issue's history; at every release a filter export is stored with the release tag. Reviews: the lead moves requirements to Approved after "a look". No checklist, no record of findings. Developers paste requirement text into an AI assistant to draft test cases; which model version was used is not recorded.

A. Which GP does each line speak to?

Mandatory fields plus the page of quality criteria.

The Draft → In review → Approved → Obsolete workflow, with only the lead approving.

Issue history, and the export stored with each release tag.

Approval after "a look", with no checklist and no record of findings. Which GP is weak?

The AI model version used to draft test cases isn't recorded. Which area do the Guidelines point to first?

B. Level 1 or level 2?

"Every feature has its software requirements written down."

"Every requirement is reviewed against the quality checklist before approval, and findings are closed."

"Each hardware-in-the-loop (HIL) test traces to the software requirement it verifies."

C. From memory

Name the four GPs of PA 2.2 and how they pair up.

2.2.1 define requirements for the work products, paired with 2.2.4 review and adjust against them. 2.2.2 define requirements for storage and control, paired with 2.2.3 identify, store and control accordingly.

Your win: you can audit a team's templates, tool workflows and reviews and say exactly which level-2 practice falls short. That completes level 2. Next: level 3, where the process itself becomes an organisational asset.

To keep it: import this lesson's Anki deck (how).