SWE.1 - Software Requirements Analysis

Official Purpose Statement (ASPICE v3.1/v4.0): "The purpose of the Software Requirements Analysis Process is to transform the software-related parts of the system requirements into a set of software requirements."

SWE.1 sits at the top of the left leg of the software V-model. It is the first process assessors evaluate because failures here cascade through the entire SWE chain. If requirements are missing, ambiguous, or untraceable, every downstream process (architecture, design, testing) is building on a broken foundation. SWE.1 is the #1 source of CL1 partial ratings in automotive supplier assessments.

SWE.1 Process Outcomes (PRM Level)

The six process outcomes define what "SWE.1 done right" looks like from the PRM perspective. These are what the assessor will ultimately verify, even though they collect evidence at the BP level:

These are the definitive BP definitions from the ASPICE PAM v3.1. During an assessment, each BP is rated individually. A BP rated "P" (Partially achieved) contributes to PA 1.1 being less than "F" - blocking CL1 achievement.

The most common source of SWE.1 findings is not a missing document - it is a document full of requirements that do not meet ASPICE's quality criteria. These are the rules that separate requirements that pass assessment from those that generate findings.

The SMART-V Requirement Template

A compliant software requirement must be: Singular (one requirement per ID), Measurable (quantified acceptance criteria), Attainable (feasible on the target HW), Relevant (traces to a system-level need), Traceable (has upstream and downstream links), Verifiable (a concrete test can confirm it).

Good vs. Bad Requirements - Side-by-Side

Non-Functional Requirement Categories - Don't Skip These

ASPICE BP1 explicitly requires non-functional requirements. These are the categories assessors check for completeness:

• Timing & Performance: Worst-case task execution times (WCET), response time targets, interrupt latency budgets, CAN bus load limits (≤40% recommended for HS-CAN)
• Memory: Flash memory budget (with margin), RAM allocation per task/module, stack depth limits
• Reliability/Availability: Allowed MTBF, diagnostic coverage targets (for ISO 26262 ASIL requirements)
• Interface Compatibility: Baud rates, voltage levels, communication matrix compliance, bootloader interface spec
• Standards Compliance: Which AUTOSAR version, which UDS services, which OBD-II PIDs - referenced by document and version
• Calibration: Which parameters are calibratable, their ranges, their default values

BP6 (bidirectional traceability) is the single most failed BP in SWE.1 assessments. Understanding exactly what it requires - and how to set it up correctly - is essential.

What "Bidirectional" Actually Means

Traceability has two directions, and both must be complete:

• Downward (Derivation): Every SWE.1 software requirement must point to the SYS.2 system requirement(s) it was derived from. This proves your SRS is grounded in customer/system needs.
• Upward (Coverage): Every SW-relevant SYS.2 requirement must have at least one SWE.1 requirement covering it. This proves nothing was dropped in translation.

An orphaned SWE.1 requirement (one with no upstream SYS.2 link) is called a derived requirement. Derived requirements are allowed - they represent implementation decisions not mandated by the customer - but they must be explicitly labeled as derived and justified. An unlabeled orphan looks like a traceability gap to an assessor.

Traceability Matrix Structure (Minimum Viable)

If you are not using a requirements management tool, a well-structured Excel matrix satisfies ASPICE for projects up to ~300 requirements:

Key rules: every row must have a value in the upstream column (STS-ID or [Derived - justification]). Every row must have a downstream link to a test case before the SWE.6 qualification test phase. Empty cells = traceability gaps = findings.

Toolchain Options

The requirements review is where CL2 GP 2.2.4 (Work Product review) is demonstrated for the SRS. A verbal "we checked it" does not satisfy this Generic Practice. Here is the exact evidence structure assessors expect.

Required Review Record Components

Review Checklist - ASPICE SWE.1 Criteria

The following checklist, completed per review, directly maps to the ASPICE SWE.1 BPs. Use it as a template:

• ☐ Every requirement has a unique ID (BP2)
• ☐ Every requirement is singular - one requirement per ID (BP2)
• ☐ Functional requirements are unambiguous - no "shall be fast", "shall be safe" (BP1)
• ☐ Non-functional requirements cover timing, memory, interfaces, and regulatory constraints (BP1)
• ☐ Every requirement has a verification method assigned (BP5)
• ☐ Every requirement has acceptance criteria quantified (BP5)
• ☐ Every requirement traces to a SYS.2 requirement or is explicitly labeled as Derived (BP6)
• ☐ No SYS.2 SW-relevant requirement is uncovered (BP6 - coverage direction)
• ☐ ASIL/safety classification applied to all safety-relevant requirements (BP2)
• ☐ Interface requirements reference the communication matrix version (BP4)
• ☐ Requirements analyzed for feasibility against target HW spec (BP3)
• ☐ Release mapping defined for all requirements (BP7)

CL2 requires PA 2.1 (Performance Management) and PA 2.2 (Work Product Management) on top of a fully achieved CL1. Here is what each Generic Practice looks like concretely for SWE.1: