Hands-On: Mock Assessment Exercise

📋 Exercise Objectives

• Conduct a simulated SWE.1 and SWE.2 interview from both assessor and supplier perspectives
• Review a set of provided work products and identify Findings, Weaknesses, and Strengths
• Apply the N/P/L/F rating scale to a real evidence set and produce PA ratings
• Classify observations using the correct finding taxonomy
• Practice the evidence navigation skills that determine assessment outcomes

🎭 Interview Transcript - SWE.1

Assessor: "Walk me through how a new software requirement from PremiumCar ends up in your SRS. What's the first step?"

RE: "When we receive a customer specification update - typically the System Technical Specification from PremiumCar - we run a delta analysis against the current SRS. Our requirements engineers review the changed sections of the STS, write or update the corresponding SRS requirements, give them IDs in our numbering scheme, and submit for internal review."

Assessor: "How do you structure the link from an SRS requirement back to the STS? Can you show me an example?"

RE: [Navigates to SRS-001 in SharePoint] "Here - requirement SRS-042 is the wheel speed sensor signal filtering requirement. You can see in the 'Source' column it links to STS-PremCar-AWD-107. That's the customer STS item."

Assessor: "Good. And in the other direction - from STS-PremCar-AWD-107, can you find all the SRS requirements it decomposes into?"

RE: [Pauses, switches to Traceability Matrix TRM-001] "Yes, if I filter this matrix by STS-107, I get SRS-042, SRS-043, and SRS-044. Those are the three software requirements that decompose that system requirement."

Assessor: "I see SRS-043 has no entry in the 'Verification Method' column. Is that intentional?"

RE: "Hmm, that's missing. SRS-043 is a performance requirement - it should have been marked as 'Test.' I'll note that as an action."

Assessor: "Let me pick a few requirements randomly. SRS-089, SRS-156, SRS-201 - can you show me the upstream link for each?"

RE: [Navigates through TRM-001] "SRS-089 links to STS-PremCar-AWD-198. SRS-156... [pause] ...I'm not finding an entry for SRS-156 in the traceability matrix. Let me check the SRS directly." [Opens SRS] "It's there in section 4.2, but it doesn't have a source entry. This might be an internal requirement we added during architecture - those sometimes don't make it back into the matrix."

Assessor: "SRS-201?"

RE: "SRS-201 links to STS-PremCar-AWD-244."

❓ Analysis Questions - SWE.1 Segment (Answer Before Reading Debrief)

1. What Base Practice(s) does the 'Verification Method' gap in SRS-043 affect? Is this a Finding or a Weakness? Why?
2. SRS-156 has no upstream traceability link. What BP does this violate? How would you rate this - N, P, L, or F - for BP6, given that 2 out of 3 sampled requirements have upstream links?
3. The interviewee demonstrated downstream traceability (STS → SRS) and upstream traceability (SRS → STS) using TRM-001. Which BPs does this satisfy? What GP (if any) does the traceability matrix serve?
4. What follow-up questions would you ask next if you were the assessor?

🎭 Interview Transcript - SWE.2

Assessor: "Please walk me through the architecture of the ABS software. What are the main components and how did you decide on this decomposition?"

SA: [Opens SAD-001] "We have four main software components: WheelSpeedProcessor, SlipController, HCUActuator, and CANInterface. The decomposition follows functional boundaries - sensor processing, control logic, actuation, and communication are each in their own component. This came from the function allocation in the SYS.3 system architecture document."

Assessor: "Show me the interface specification between SlipController and HCUActuator."

SA: [Navigates to SAD section 3.2] "Here - SlipController provides a sender port 'ValveCommands' of type SlipCtrl_ValveCmd_Type, and HCUActuator has a receiver port with the same data type. The data type definition is in the ARXML and the interface is specified in section 3.2.4."

Assessor: "And SAD-001 is version 1.8 - it's marked 'Under Review.' Is there a previous approved version?"

SA: "v1.7 is the last approved baseline. v1.8 adds the multi-wheel event handling that came from a late customer requirement change. The review is in progress - we expect it closed by end of next week."

Assessor: "Who is conducting the review of v1.8?"

SA: "It's a peer review - myself, the lead systems engineer, and the safety manager."

Assessor: "Do you have a review record for v1.7?"

SA: "Yes." [Opens RVW-SAD-001 in SharePoint - a spreadsheet with 23 review issues listed, dates, and disposition status]

Assessor: "Issue #14 - 'Interface description of CANInterface RX buffer size missing' - is marked 'Open.' Is this still open?"

SA: "That was resolved in v1.8 actually - the buffer size is now specified in section 4.1.3. The review record wasn't updated when we closed it."

Assessor: "From SWE.1, I saw requirement SRS-042 (wheel speed filtering). Which architectural component implements it?"

SA: "WheelSpeedProcessor." [Navigates to allocation table in SAD] "Here in Table 2 - SRS-042 is allocated to WheelSpeedProcessor, component WS_Filter."

Assessor: "SRS-156 - the one without upstream traceability we noted in SWE.1 - can you find it in the allocation table?"

SA: [Searches] "No, SRS-156 is not in the allocation table."

❓ Analysis Questions - SWE.2 Segment (Answer Before Reading Debrief)

1. Review issue #14 is marked Open but was resolved in v1.8. What BP and GP does the failure to close this record in the review log affect? Is this a Finding or Weakness?
2. The SAD is currently "Under Review" at v1.8 but the approved version is v1.7. What does this mean for PA 2.2 evidence for SWE.2? Can the assessor accept v1.8 as evidence?
3. SRS-156 has no upstream trace (found in SWE.1) AND no allocation to an architectural component (found in SWE.2). What does this cross-process issue tell you about the systemic traceability health of the project?
4. Rate SWE.2 PA 1.1 based on what you have seen so far. What additional information would you need before finalizing the rating?

📄 Excerpt: Project Status Meeting - ABS ECU SW - Week 34

Date: 2024-08-22 | Attendees: PM (chair), RE Lead, SW Architect, QA Lead

Agenda item 2 - Schedule Status:

SWE.1 baselining completed 2024-08-15, 3 days late (planned 2024-08-12). Root cause: late receipt of updated STS v2.1 from PremiumCar on 2024-08-09. No impact on downstream SWE.2 milestone (planned 2024-09-05).

SWE.2 architecture review scheduled for 2024-09-01 - on track.

Agenda item 3 - Open Actions:

Action #AR-034 (open from Week 32): Update CANInterface port specification in SAD - Owner: SA, Due: 2024-09-05, Status: In Progress.

Action #AR-036 (new): Complete SRS-156 upstream traceability - Owner: RE Lead, Due: 2024-08-29, Status: Open.

Agenda item 4 - Risk Review:

Risk R-007 (STS stability from customer) elevated from Medium to High. Mitigation: formal change request process with PremiumCar, weekly STS change notification emails. PM to raise with PremiumCar PM on next joint call.

❓ Questions - PSM-005

1. Which GP(s) does this meeting minute satisfy? Be specific about which AO within the GP is addressed.
2. The meeting shows a schedule deviation with documented root cause and a no-impact analysis. Does this satisfy GP 2.1.3 (monitor performance and adjust plans)? What would be needed to make the evidence stronger?
3. Action AR-036 addresses the SRS-156 traceability gap. Does the existence of this action in the meeting minutes change your rating of SWE.1 BP6? Why or why not?

📄 Excerpt: QA Audit Report #3 - SWE.1 Compliance Audit

Audit Date: 2024-07-18 | Auditor: Maria Fischer, QA Engineer | Project: ABS ECU SW

Scope: SWE.1 process compliance - requirements specification and traceability

Findings:

NC-001: 8 requirements (SRS-156, SRS-201, SRS-245, SRS-246, SRS-289, SRS-301, SRS-302, SRS-303) have no upstream link to STS. Severity: Major. Due Date: 2024-08-30. Owner: RE Lead.

OBS-001: SRS section 5 (timing requirements) uses non-measurable language ("shall respond quickly"). Recommend adding quantitative acceptance criteria. Severity: Observation.

Auditor Independence: Maria Fischer is a QA Engineer in the ABS project QA team. She reports to the QA Manager, not the project manager. No development responsibilities.

❓ Questions - QAR-003

1. NC-001 was raised on 2024-07-18 covering 8 requirements with missing upstream traceability, including SRS-156. The status meeting PSM-005 (2024-08-22) shows only SRS-156 with an open action. What does this suggest about NC-001 closure? How would you investigate further?
2. Is Maria Fischer sufficiently independent for SUP.1? The ASPICE PAM requires that QA auditors be "independent of the project" - what does that mean specifically, and does this structure satisfy it?
3. OBS-001 (non-measurable timing requirements) - which SWE.1 BP does this relate to? Is it a Finding or a Weakness from an ASPICE perspective?

✅ Q1: SRS-043 missing verification method

BP affected: SWE.1.BP5 (Develop verification criteria). The verification method is explicitly required by BP5. Classification: Weakness - not a Finding, because 11 out of 12 sampled requirements correctly have verification methods defined. One gap in an otherwise well-implemented BP is a minor weakness that allows PA 1.1 to be rated L for this indicator, but does not by itself drive it to P. If further sampling revealed a higher proportion of missing methods (say 20%+), reclassify as Finding.

✅ Q2: SRS-156 missing upstream traceability

BP affected: SWE.1.BP6 (Bidirectional traceability). This is the most critical BP in SWE.1. With NC-001 context: this is a Finding.} NC-001 documents 8 requirements without upstream traceability. That is a systemic issue - not an isolated case. 2 out of 3 sampled in the interview appeared correct, but the QA audit found 8 more. The scope of the gap across the full requirements set is material. PA 1.1 would be rated P (Partially) not L, because BP6 - a core outcome driver - has a significant coverage gap. BP6 = P → PA 1.1 cannot be F → CL1 not achieved → CL2 check does not proceed.

✅ Q3: BPs served by traceability matrix demonstration

Demonstrating STS → SRS in TRM-001 satisfies BP6 for the links that exist. The traceability matrix also serves as a work product for GP 2.2.3 (identified, documented, controlled) - it is in SharePoint with version control. The matrix itself does not directly serve a GP in terms of process management, but its existence and quality as a work product is evidence for PA 2.2 (Work Product Management) indicators.

✅ Q1: Review issue #14 marked Open but resolved

BP/GP affected: GP 2.2.4 (Review and adjust work products) - specifically, the requirement to document review findings and their disposition. If a review issue is resolved but the record is not updated, the review record does not accurately reflect the final disposition. Classification: Weakness - the review was done, the issue was resolved, the work product was updated (v1.8 added the buffer spec). The administrative failure to update the review log is a minor discipline gap, not a material process failure. The assessor would note it as a weakness and recommend updating the record during the assessment.

✅ Q2: SAD at v1.8 "Under Review" - what version counts?

For PA 2.2 evidence, the assessor can use the approved baseline (v1.7) as the primary evidence object. v1.8 is a work-in-progress and cannot be treated as a controlled baseline. The assessor would assess v1.7 for GP 2.2.3/2.2.4 compliance (it has an approved review record). The existence of v1.8 under review at the time of the assessment is a normal development state - it is not a finding unless v1.8 has been used to implement changes that are not traceable back through v1.7.

✅ Q3: SRS-156 no upstream trace AND no architectural allocation

This cross-process correlation is exactly what skilled assessors look for. SRS-156 appears in the SRS but has: no upstream link to a customer/system requirement, no architectural component allocation in the SWE.2 allocation table. This means the requirement is either an internal architecture constraint (which should be explicitly labeled as such) or a forgotten requirement that slipped through the requirements intake process. Either way, it is evidence of a systemic traceability process gap - not just a single record error. This strengthens the Finding classification for SWE.1 BP6 and adds a Finding for SWE.2 BP2 (requirements allocation).

✅ Key Learning: The Cross-Process Pattern

Notice how SRS-156 appeared as a clue in SWE.1 (no upstream trace), reappeared as a gap in SWE.2 (no architectural allocation), and was already flagged by QA in SUP.1 (NC-001). A skilled assessor connects these dots across processes to identify systemic issues rather than treating each observation in isolation. When you prepare for an assessment, think about your evidence across the full traceability chain - a gap that appears small in one process is often the visible tip of a larger systemic issue.