2.1: SWE.1 Software Requirements Analysis
Process Definition
Purpose
ASPICE PAM v4.0 Official Purpose:
The purpose is to establish a structured and analyzed set of software requirements consistent with the system requirements, and the system architecture.
Key Requirements (from purpose statement):
- Structured: Requirements must be organized, grouped, and prioritized (BP2)
- Analyzed: Requirements must be checked for correctness, technical feasibility, and impact (BP3, BP4)
- Consistent with system architecture: Bidirectional traceability must be established to both system requirements AND system architecture (BP5)
ASPICE Source: PAM v4.0 Section 4.4.1, Lines 1542-1544
Outcomes (ASPICE PAM v4.0)
IMPORTANT: These are the EXACT official outcomes from ASPICE PAM v4.0. SWE.1 has exactly 7 outcomes.
| Outcome | Official Description (PAM v4.0) | AI Support Level |
|---|---|---|
| O1 | Software requirements are specified. | L1-L2 (AI drafts, human validates) |
| O2 | Software requirements are structured and prioritized. | L1 (AI suggests structure, human decides) |
| O3 | Software requirements are analyzed for correctness and technical feasibility. | L2 (AI analyzes, human validates) |
| O4 | The impact of software requirements on the operating environment is analyzed. | L1 (AI assists analysis, human reviews) |
| O5 | Consistency and bidirectional traceability are established between software requirements and system requirements. | L2 (AI checks links, human validates) |
| O6 | Consistency and bidirectional traceability are established between software requirements and system architecture. | L2 (AI checks links, human validates) |
| O7 | The software requirements are agreed and communicated to all affected parties. | L0 (Human only - ASPICE accountability) |
Note on Verification Criteria: Verification criteria development is the responsibility of SWE.4 (Software Unit Verification), SWE.5 (Integration Verification), and SWE.6 (Software Verification) processes - NOT SWE.1. Requirements should be written with inherent verifiability (See PAM Note 2), but detailed verification criteria are developed during verification planning.
ASPICE Source: PAM v4.0 Section 4.4.1, Lines 1546-1554
Base Practices (ASPICE PAM v4.0)
IMPORTANT: SWE.1 has exactly 6 base practices. The table below uses EXACT PAM v4.0 descriptions.
| BP | Official Base Practice Description (PAM v4.0) | AI Level | AI Application | HITL Required |
|---|---|---|---|---|
| BP1 | Specify software requirements. Use the system requirements and the system architecture to identify and document the functional and non-functional requirements for the software according to defined characteristics for requirements. | L1-L2 | AI drafts requirements from system inputs, human validates completeness and correctness | YES - Human validates all requirements |
| BP2 | Structure software requirements. Structure and prioritize the software requirements. | L1 | AI suggests grouping/prioritization, human decides final structure | YES - Human decides prioritization |
| BP3 | Analyze software requirements. Analyze the specified software requirements including their interdependencies to ensure correctness, technical feasibility, and to support project management regarding project estimates. | L2 | AI performs quality analysis (correctness, feasibility, interdependencies), human validates findings | YES - Human validates feasibility |
| BP4 | Analyze the impact on the operating environment. Analyze the impact that the software requirements will have on elements in the operating environment. | L1 | AI identifies potential impacts, human validates critical impacts | YES - Human validates impacts |
| BP5 | Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between software requirements and system architecture. Ensure consistency and establish bidirectional traceability between software requirements and system requirements. | L2 | AI checks trace links and consistency, human validates critical relationships | YES - Human validates consistency |
| BP6 | Communicate agreed software requirements and impact on the operating environment. Communicate the agreed software requirements, and the results of the analysis of impact on the operating environment, to all affected parties. | L0 | Human only - ASPICE requires human accountability for agreements | YES - Human communication required |
Common Mistakes Corrected:
"Allocate to SW elements"- This is NOT an SWE.1 base practice (allocation happens in SWE.2 Architectural Design)"Develop verification criteria"- This is NOT an SWE.1 base practice (verification criteria are developed in SWE.4/5/6)"Ensure consistency" as separate BP- Consistency is part of BP5 in PAM v4.0
ASPICE Source: PAM v4.0 Section 4.4.1, Lines 1556-1596
Software Requirement Types
Functional Requirements
| Category | Example |
|---|---|
| Input processing | "SW shall debounce button input for 50ms" |
| Control logic | "SW shall activate lock motor on valid command" |
| Output generation | "SW shall send CAN acknowledgment within 10ms" |
| State management | "SW shall maintain door lock state" |
| Error handling | "SW shall set DTC on actuator timeout" |
Non-Functional Requirements
| Category | Example |
|---|---|
| Timing | "Task shall complete within 5ms" |
| Memory | "RAM usage shall not exceed 80%" |
| CPU | "CPU load shall not exceed 60%" |
| Power | "Sleep current shall be < 100μA" |
| Reliability | "Watchdog timeout = 100ms" |
AI-Assisted Requirements Derivation
L2: Requirements Generation
The diagram below shows how AI derives software requirements from system requirements, applying domain rules and coding standards to produce structured, traceable outputs for human review.
Requirement Example
---
ID: SWE-BCM-103
Title: Door Lock Actuator Command Timing
Type: Functional
Priority: High
Status: Approved
Version: 1.0
---
## Description
The door lock control software shall command all four door lock
actuators (FL, FR, RL, RR) to the locked position within 10ms of
receiving a validated lock command.
## Definitions
- **Validated lock command**: Command passed security validation (SWE-BCM-102)
- **Door lock actuators**: Hardware outputs to door lock motors
- **Locked position**: Actuator output state = LOCK (active high)
## Rationale
Derived from SYS-BCM-010. 10ms allocation provides margin within
200ms system-level timing requirement.
## Constraints
- All 4 actuators shall be commanded in sequence (not parallel)
due to hardware power limitation
- Maximum time between first and last actuator command: 1ms
## Verification Method
Unit test + integration test
## Verification Criteria
- VC1: Validated command to first actuator output: < 2ms
- VC2: All 4 actuators commanded within 10ms total
- VC3: Sequence order: FL, FR, RL, RR
## Traceability
- Derived from: SYS-BCM-010
- Allocates to: DoorLockControl_Task, DoorLockDriver module
- Verified by: SWE-UT-103, SWE-IT-050
Work Products (Information Items per ASPICE PAM v4.0)
IMPORTANT: ASPICE PAM v4.0 uses "Information Items" terminology. The IDs below are from the official PAM work product table.
| Information Item ID | Information Item Name | Outcomes Supported | AI Role |
|---|---|---|---|
| 17-00 | Requirement | O1, O2 | AI drafts requirements, human validates |
| 17-54 | Requirement Attribute | O2 | AI suggests structure/priority attributes, human decides |
| 15-51 | Analysis Results | O3, O4 | AI performs analysis (correctness, feasibility, impact), human validates |
| 13-51 | Consistency Evidence | O5, O6 | AI checks trace links, human validates consistency |
| 13-52 | Communication Evidence | O7 | Human only - documentation of agreements with stakeholders |
Note on Work Product IDs:
- 17-00 Requirement: Primary output - software requirements specification
- 17-54 Requirement Attribute: Metadata for requirements (priority, status, category, etc.)
- 15-51 Analysis Results: Documented analysis of correctness, feasibility, and impact
- 13-51 Consistency Evidence: Traceability matrices and consistency checks
- 13-52 Communication Evidence: Meeting minutes, sign-offs, approval records
Common Mistakes Corrected:
"17-08", "17-11", "17-12"- These IDs do NOT exist in ASPICE PAM v4.0"Verification criteria"- NOT an SWE.1 output (developed in SWE.4/5/6)
ASPICE Source: PAM v4.0 Section 4.4.1, Work Products Table (Lines 1598-1605)
Summary
SWE.1 Software Requirements Analysis - ASPICE PAM v4.0 Compliance:
- Process Purpose: Establish structured and analyzed software requirements consistent with system requirements and architecture
- Outcomes: 7 official outcomes (O1-O7)
- Base Practices: 6 official BPs (BP1-BP6)
- Information Items: 17-00 (Requirement), 17-54 (Attributes), 15-51 (Analysis), 13-51 (Consistency), 13-52 (Communication)
AI Integration by Base Practice:
- BP1 (Specify): L1-L2 - AI drafts, human validates
- BP2 (Structure): L1 - AI suggests, human decides
- BP3 (Analyze): L2 - AI analyzes, human validates
- BP4 (Impact): L1 - AI identifies, human validates
- BP5 (Traceability): L2 - AI checks, human validates
- BP6 (Communicate): L0 - Human only (ASPICE accountability)
Human-in-the-Loop (HITL) Requirements:
- ALL base practices require human review and validation
- BP6 (agreement/communication) is human-only (L0)
- AI assists with drafting, analysis, and checking - humans make final decisions
Key ASPICE Compliance Points:
- Requirements must be both STRUCTURED (BP2) and ANALYZED (BP3)
- Traceability required to BOTH system requirements AND system architecture (BP5)
- Human accountability for all agreements and communication (BP6)