SYS.1–SYS.5 - System Engineering Processes - ASPICE & Process

SYS Processes Overview

The five System Engineering (SYS) processes in ASPICE cover the system-level V-model left leg (SYS.1–SYS.3, from stakeholder needs to system architecture) and right leg (SYS.4–SYS.5, from system integration to system qualification). They sit above the Software Engineering (SWE) and Hardware Engineering (HWE) processes and define the technical environment that governs both.

In a typical automotive ECU project, the SYS processes answer fundamental questions that cannot be answered at the software level alone:

What does the OEM (the vehicle-level customer) actually need this ECU to do? (SYS.1)
What are the specific, measurable, testable system requirements - including safety requirements with ASIL ratings? (SYS.2)
How is functionality partitioned between software, hardware, and mechanical subsystems? (SYS.3)
How do the SW and HW subsystems get integrated and tested against the architecture? (SYS.4)
Does the complete integrated system satisfy all system requirements? (SYS.5)

📋 Learning Objectives

Recite the purpose statement of each SYS process (SYS.1–SYS.5) - assessors ask this
Explain the key Base Practices and Work Products for each SYS process
Describe the traceability chain from SYS.1 stakeholder requirements through SYS.5 qualification test results
Determine which SYS processes are in scope for a given supplier role (SW-only, full system, software+integration)
Identify the critical interface between SYS.2 and SWE.1 - the most frequently assessed handoff in the entire V-model

SYS Processes in the ASPICE V-Model

V-Leg	Process	Role	Paired With
Left (define)	SYS.1	Stakeholder requirements collection	-
Left (define)	SYS.2	System requirements specification	SYS.5
Left (design)	SYS.3	System architecture + HW/SW partition	SYS.4
Right (verify)	SYS.4	HW/SW integration testing	SYS.3
Right (validate)	SYS.5	System qualification against SYS.2 requirements	SYS.2

SYS.1 - Requirements Elicitation

Purpose: "The purpose of the Requirements Elicitation process is to gather, process and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service so that stakeholder requirements are defined."

SYS.1 is the entry point of the entire development lifecycle. It captures what external stakeholders - primarily the OEM vehicle program team, but also regulatory bodies, field service, and end users - need the system to do, before those needs are formally analyzed and specified as requirements.

Key Base Practices (SYS.1 BPs)

BP	Activity	Evidence Expected
SYS.1.BP1	Obtain stakeholder requirements. Identify stakeholders and elicit their requirements through structured methods (interviews, workshops, analysis of existing system specifications).	Stakeholder list; meeting minutes from requirements workshops; customer specification documents (e.g., OEM Technical Specification, Target Agreement)
SYS.1.BP2	Understand stakeholder expectations. Analyze and document stakeholder needs, including operational context, constraints, and success criteria.	Operational scenarios, use case descriptions, or concept of operations documents
SYS.1.BP3	Agree on requirements. Confirm requirements with stakeholders and manage conflicting requirements through a defined resolution process.	Requirements review sign-off records; conflict resolution log
SYS.1.BP4	Establish bidirectional traceability. Link each stakeholder requirement to the customer specification source and downstream SYS.2 system requirements.	Traceability matrix (customer spec → SRS or equivalent)
SYS.1.BP5	Identify the content of the product release. Agree with the customer on which requirements are addressed in each system release.	Release scope agreements, feature freeze records

Practical Reality for Tier-1 Suppliers

SYS.1 is frequently the most contentious process in supplier assessments because of the question: who is the stakeholder? For a Tier-1 ECU supplier, the OEM is the primary stakeholder, and the OEM-provided Technical Specification (TS) or Request for Quotation (RFQ) is the primary input. The supplier's SYS.1 process must demonstrate that they systematically extract, analyze, and track requirements from OEM documents - not just receive a PDF and start designing.

Common SYS.1 weakness: the OEM specification changes during development (which it always does in automotive programs), and the supplier has no formal process to detect, capture, and impact-analyze those changes. This surfaces as a SUP.10 (Change Request Management) finding as well as a SYS.1 finding.

⚠️ SYS.1 Scope Question

SYS.1 is NOT in the HIS default assessment scope. OEMs often argue that SYS.1 is their (the OEM's) responsibility, not the supplier's. However, for a Tier-1 who has a system engineering function and who holds the system-level requirements internally (not just forwards the OEM TS directly to software), SYS.1 may be in scope. Clarify this explicitly in the Assessment Contract.

SYS.2 - System Requirements Analysis

Purpose: "The purpose of the System Requirements Analysis process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system."

SYS.2 is arguably the most critical process in the entire ASPICE framework for an ECU supplier. It is the bridge between what the OEM asked for (SYS.1) and what the engineers will design and build (SWE.2, HWE.2). A weak SYS.2 means everything downstream is built on an ambiguous foundation - a problem that typically surfaces at SYS.4 integration testing, by which time it is extremely expensive to fix.

What "Transform" Means in Practice

SYS.2 is not simply copying OEM requirements into another document. Transformation means:

Decomposition: Breaking a high-level stakeholder need (e.g., "the ECU shall manage the electric motor speed") into measurable, implementable system requirements ("the system shall regulate motor speed to ±2 rpm of the setpoint within 50ms under all operating temperatures from -40°C to +125°C")
ASIL allocation: Assigning safety integrity levels per the ISO 26262 safety analysis. Each SYS.2 requirement that has a safety-relevant character must carry its ASIL (QM, A, B, C, or D) inherited from the safety analysis
Measurability: Every SYS.2 requirement must be verifiable - it must have a measurable acceptance criterion. "The system shall be reliable" is not a SYS.2 requirement. "The system shall have a FTTI of ≤ 20ms for safety goal XYZ" is.
Interface definition: SYS.2 must define the system's external interfaces - electrical connectors, communication signals (CAN, LIN, Ethernet), and environmental constraints

Key Work Products

Work Product	Typical Document Name	Key Characteristics
System Requirements Specification	SRS, Technical Specification (TS), System Technical Requirement (STR)	Every requirement has a unique ID; acceptance criteria defined; ASIL annotated where applicable; no ambiguous "shall be good" requirements
System interface definition	Interface Control Document (ICD), DBC/ARXML for signals	All external interfaces defined; data types, timing, value ranges, error behaviors documented
Analysis results	Completeness check, consistency review records	Evidence that requirements were analyzed for correctness, feasibility, completeness, and freedom from ambiguity
Bidirectional traceability	Requirements traceability matrix or tool export	Every SYS.2 requirement traced to ≥1 SYS.1 stakeholder requirement AND to ≥1 SWE.1/HWE.1 requirement downstream

🔍 The SYS.2/SWE.1 Interface - The Most-Failed Handoff

Assessors consistently find the weakest traceability link in the entire V-model is the transition from SYS.2 to SWE.1. The failure pattern: the SRS exists and the Software Requirements Specification exists, but the SWE.1 document was created independently of SYS.2, with different ID schemes, different granularity, and no explicit links between them. Software engineers read the SRS and wrote their own requirements from it - a valid approach if the traceability links are recorded, but they almost never are. The result: no bidirectional traceability between the two levels, and a finding at both SYS.2 (no downstream trace) and SWE.1 (no upstream trace).

SYS.3 - System Architectural Design

Purpose: "The purpose of the System Architectural Design process is to establish a system architectural design and identify which system requirements are to be allocated to which elements of the system."

SYS.3 is where the system is split into concrete, buildable parts. For an ECU, this means partitioning the system requirements from SYS.2 into software requirements (→ SWE.1), hardware requirements (→ HWE.1), and potentially mechanical requirements. It also defines all internal interfaces between subsystems - the exact signals, protocols, timing, and data contracts between the SW and HW layers.

The HW/SW Partition: Core Deliverable of SYS.3

The most important output of SYS.3 is the documented decision of which functions are realized in software and which in hardware. This is not a trivial decision - it has cascading effects on:

Safety: An ASIL-D function realized in software requires a completely different development approach (SWE process with ASIL-D methods) than one realized in hardware (a certified ASIC or microcontroller safety mechanism)
Cost and lead time: Hardware changes after SYS.3 approval are enormously expensive (new PCB spins, hardware validation); software changes are possible but still costly at late project phases
Testability: The partition determines how SYS.4 integration testing is structured - specifically, which interfaces are software-hardware boundaries that require specific integration test coverage

Static and Dynamic Views

A complete SYS.3 architectural design document includes both:

Static view: Block diagram or component diagram showing subsystems (SW ECU application, AUTOSAR BSW, microcontroller, peripherals, external sensors/actuators) and their relationships
Dynamic view: Sequence diagrams or timing diagrams showing how subsystems interact over time - especially for safety-relevant functions where timing constraints matter (response time, fault detection time, watchdog timings)

Many teams produce the static view but neglect the dynamic view. Assessors checking SYS.3 for CL2 will ask for both. A missing dynamic view is a typical SYS.3.BP finding.

SYS.4 - System Integration and Integration Testing

Purpose: "The purpose of the System Integration and Integration Testing process is to integrate the system elements and to ensure that the integrated system is consistent with the system architectural design."

SYS.4 receives the qualified software (from SWE.6) and the validated hardware and integrates them into the complete system. Testing at SYS.4 verifies that the interfaces defined in SYS.3 work correctly in practice - specifically, the SW/HW boundary behaviors, timing, and communication protocols that cannot be verified at the software-only level (SWE.5) or hardware-only level (HWE.3).

SYS.4 vs SWE.5: What's the Difference?

This is one of the most commonly confused distinctions in ASPICE assessments:

Aspect	SWE.5 (SW Integration)	SYS.4 (System Integration)
What is integrated	Software units and SW components into integrated software	SW + HW + mechanical into complete system
Test basis	SWE.2 software architectural design interfaces	SYS.3 system architectural design interfaces
Test environment	SIL (Software-in-the-Loop) or target HW with SW focus	Target ECU hardware + HIL or vehicle bench
Typical coverage	SW module-to-module interfaces; AUTOSAR port connections	ECU ↔ sensor signal chains; ECU ↔ CAN network; ECU actuator control under real electrical conditions
Defect types found	Interface contract violations, integration sequencing errors	Signal timing violations, EMC issues, hardware tolerance interactions, real-world sensor nonlinearities

HIL Testing as SYS.4 Evidence

Hardware-in-the-Loop (HIL) testing is the standard environment for SYS.4 in automotive. A HIL bench replaces the vehicle with simulated electrical signals and load conditions, allowing repeatable, automated system integration testing. ASPICE does not mandate HIL - but if a project uses HIL, assessors will expect the HIL test cases to be explicitly traceable to SYS.3 architecture interfaces and SYS.2 system requirements that involve HW/SW interaction.

Key evidence for SYS.4: integration test plan (with integration order and test case references), test execution results (with pass/fail status and defect links for failures), regression test records, and a system integration specification that shows which SYS.3 interfaces were tested and how.

SYS.5 - System Qualification Testing

Purpose: "The purpose of the System Qualification Testing process is to ensure that the integrated system is tested to provide evidence for compliance of the system with the system requirements."

SYS.5 is the closing process of the system V-model right leg. It tests the fully integrated system (output of SYS.4) against the system requirements defined in SYS.2. This is the formal "does the system do what we said it would do?" verification - the basis for the system-level acceptance that precedes delivery to the OEM for vehicle-level integration.

SYS.5 Test Strategy

SYS.5 test cases must be traceable directly to SYS.2 requirements. The qualification test report must show:

Every SYS.2 requirement that has a testable acceptance criterion has at least one test case covering it
All test cases have been executed with recorded results (pass/fail/blocked)
All failures have been linked to defect reports in the problem tracking system (SUP.9)
Requirements coverage is measured and reported - 100% of safety-relevant requirements must be covered; for non-safety requirements, the coverage target is defined in the project test strategy

Regression Testing at SYS.5

A critical weakness in many SYS.5 implementations: regression testing is not maintained. After a software change (triggered by a bug fix or late requirement change), only the new functionality is tested. ASPICE SYS.5 requires evidence that regression tests were re-run after significant changes, and that the results were recorded. An unexecuted regression suite is equivalent to no regression suite in an assessment context.

The SYS–SWE Traceability Chain

The complete traceability chain from stakeholder need to software unit test result is the backbone of ASPICE compliance. Understanding this chain in both directions is essential for every engineer involved in a project being assessed.

Level	Document	Links Down To	Links Up To
SYS.1	Stakeholder Requirements (OEM TS)	SYS.2 System Requirements	-
SYS.2	System Requirements Specification (SRS/STR)	SWE.1 SW Req / HWE.1 HW Req	SYS.1 Stakeholder Requirements
SYS.3	System Architectural Design	SWE.2 SW Architecture / HWE.2 HW Design	SYS.2 System Requirements
SWE.1	Software Requirements Specification	SWE.2 SW Architecture	SYS.2 System Requirements
SWE.2	SW Architectural Design	SWE.3 Detailed Design	SWE.1 SW Requirements
SWE.3	Detailed Design / Source Code	SWE.4 Unit Tests	SWE.2 SW Architecture
SWE.4	Unit Test Cases + Results	-	SWE.3 Detailed Design
SWE.5	SW Integration Test Cases + Results	-	SWE.2 SW Architecture interfaces
SWE.6	SW Qualification Test Cases + Results	-	SWE.1 SW Requirements
SYS.4	System Integration Test Cases + Results	-	SYS.3 System Architecture interfaces
SYS.5	System Qualification Test Cases + Results	-	SYS.2 System Requirements

An assessor following a traceability path from a single SYS.2 requirement should be able to find: the SWE.1 software requirement derived from it, the SWE.2 architectural component that implements it, the SWE.3 unit(s) that code it, the SWE.4 unit test that verifies the implementation, the SWE.6 qualification test that verifies the SW requirement, and the SYS.5 qualification test that verifies the system requirement. If any link is missing, that is a finding at the process level responsible for establishing that link.

Supplier Scope Boundaries for SYS Processes

One of the most practically important questions in any SYS process assessment is: which SYS processes does this supplier actually own? The answer varies by supplier role and must be explicitly agreed before the assessment.

Supplier Role	Typical SYS Scope	Notes
Full ECU supplier (HW+SW+Integration)	SYS.1 (optional), SYS.2, SYS.3, SYS.4, SYS.5	Standard HIS scope. Supplier owns the full system V-model for the ECU.
Software-only supplier	SWE.1–SWE.6 only; SYS.2 as input consumer	SYS.2 requirements are provided by the customer (OEM or Tier-1). Supplier has no SYS.3 architecture responsibility. SYS scope often excluded.
Tier-2 SW component supplier	SWE.1 (subset), SWE.2–SWE.6 for their component	Requirements come from Tier-1 integration specification. SYS processes typically out of scope entirely.
Module/feature supplier	SWE.1–SWE.6 for their feature module	Shares project SYS context with lead supplier but has no SYS ownership.

💡 When SYS.5 Belongs to the OEM

In some programs - especially for body control modules and infotainment ECUs - the OEM runs vehicle-level acceptance testing that formally serves as SYS.5 for the ECU. In this case, the Tier-1 supplier's SYS.5 scope is limited to bench-level system qualification using the OEM-provided test cases. The OEM audit will still check that the supplier has a qualified system ready for vehicle integration - but the final SYS.5 pass/fail authority rests with the OEM. This must be agreed in the development contract and reflected in the Assessment Contract scope definition.

Summary & Key Takeaways

✅ Key Takeaways

SYS.1–SYS.3 are the left leg of the system V-model (define → design); SYS.4–SYS.5 are the right leg (integrate → validate). All five pair bidirectionally: SYS.2↔SYS.5, SYS.3↔SYS.4.
SYS.2 is the single most important process for downstream traceability - every SWE.1 software requirement must trace back to a SYS.2 system requirement. The SYS.2/SWE.1 handoff is the most commonly failed traceability link in supplier assessments.
SYS.3 must include both a static view (architecture block diagram) and a dynamic view (timing/sequence diagrams). Missing dynamic views are a frequent SYS.3 finding.
SYS.4 (system integration) tests HW/SW interfaces at the ECU level; it is distinctly different from SWE.5 (SW-only integration). HIL testing typically serves as SYS.4 evidence.
SYS.5 qualification test cases must be traceable to SYS.2 requirements - and regression test execution must be documented after changes.
Know your supplier role: SW-only suppliers often have no SYS process ownership. Full ECU suppliers own SYS.2–SYS.5. Always confirm scope in the Assessment Contract.

What's Next

Continue to Base Practices & Generic Practices to understand the detailed assessment indicators used by assessors for each process - including the distinction between BP evidence (what you do) and GP evidence (how you manage it), and why Generic Practices are what separates CL1 from CL2.