Introduction

In the previous blog posts, we first introduced the ASPICE framework and then explained the SYS.1 process – Requirements Elicitation process and its implementation using easeRequirements for JIRA. Now, we continue with the SYS.2 ASPICE process.

What is ASPICE’s SYS.2 Process?

The System Requirements Analysis (SYS.2) process in ASPICE 4.0 is focused on transforming stakeholder needs and expectations (from SYS.1) into a clear, complete, and testable set of system requirements. These requirements serve as the basis for system architectural design, downstream development, and verification testing.

Main Benefits of the SYS.2 Process

• Requirements are systematically derived and documented,
• Conflicts are resolved and duplicates removed,
• Requirements are validated with stakeholders,
• And all requirements are traceable.

This process is critical for aligning the final product with customer expectations and ensuring successful system development.

Performing this entire process over the Jira platform is possible especially if one utilizes the easeRequirements and easeRequirements Ultimate Jira add-ons as described hereunder.

SYS.2 Base Practices

ASPICE defines six Base Practices for SYS.2. Each represents a specific task that must be performed to achieve the process’ purpose.

SYS.2.BP1 — Derive and Analyze System Requirements

This practice involves identifying and deriving system-level requirements from the higher-level stakeholder requirements and expectations provided in SYS.1. These can include functional, non-functional, safety, regulatory, and legal requirements.

Key aspects:

• Interpret stakeholder needs and convert them into precise technical system requirements. Inserting these needs immediately into Jira has many benefits ranging from organizing and managing the requirements directly in the company’s single point of truth to easily linking them to downstream development activities as well as verification tasks.

Correct issue-type setup in Jira allows for dedicated issue types for both Stakeholder Requirements and Technical System Requirements

• Ensure the derived requirements are feasible and relevant to the system’s intended operational environment.

This step often involves:

• Gap analysis
• Use-case modelling (now also supported by easeRequirements Ultimate see here for further details)
• Scenario analysis

SYS.2.BP2 — Ensure Consistency and Correctness

Here, the focus is on analyzing the system requirements to ensure that they are:

• Complete (no missing necessary requirements),
• Consistent (no contradictions between requirements),
• Unambiguous (clearly defined with no room for multiple interpretations),
• Correct (accurately representing stakeholder needs),
• Feasible (technically and economically possible),
• Verifiable (able to be confirmed by testing, inspection, or analysis).

This practice helps prevent issues during later design, implementation, and validation phases.

A new feature in easeRequirements Ultimate which is about to be released, is an AI-based Requirements Quality Checker which assists in creating Requirements conforming to the this best practice. Check back with easeRequirements Ultimate during Q3, 25 for the release of this exciting feature.

SYS.2.BP3 — Define System External Interfaces

This practice ensures that all interfaces between the system and its external environment (e.g., users, other systems, infrastructure) are defined in terms of:

• Functional behavior,
• Data exchange,
• Timing and performance,
• Protocols and physical characteristics.

Well-defined interfaces are critical for integration and interoperability, especially in automotive systems involving multiple suppliers or subsystems.

SYS.2.BP4 — Establish Bidirectional Traceability

Bidirectional traceability ensures that every system requirement can be traced:

• Back to stakeholder requirements (to verify origin and justification),
• Forward to design, implementation, and test artifacts (to ensure proper realization and verification).

Bidirectional Traceability easily obtained and monitored using easeRequiremernts’ Traceability Matrix

This practice supports:

• Impact analysis during changes,
• Coverage checks,
• Regulatory compliance audits.

Maintaining traceability also helps verify that no requirement is overlooked or misinterpreted. In addition to easeRequirements’ Traceability Matrix, the tool’s Coverage view allows for a multidimensional view spanning from Requirements, through as many layers of derived requirements and development tasks as needed down to Test Cases, Bugs and other late life-cycle artifacts.

SYS.2.BP5 — Validate the System Requirements

In this practice, system requirements are checked to ensure that they correctly and completely express the stakeholder needs.

Validation techniques include:

• Stakeholder reviews,
• Walkthroughs,
• Simulations or prototypes,
• Early model-based analysis.

Validation answers the question: “Are we building the right system?“

easeRequirements Ultimate’s Review Center allows for conducting stakeholder reviews as well as peer reviews in an efficient manner

This best practice ensures that misinterpretations or incomplete understanding of stakeholder requirements are detected early before detailed design begins. Using easeRequirements Ultimate’s dedicated Review Center allows for conducting agile stakeholder reviews as well as peer reviews efficiently and orderly.

SYS.2.BP6 — Manage System Requirements

System requirements must be maintained under controlled conditions. This practice involves:

• Version control,
• Change management,
• Status tracking,
• Configuration management,
• Impact analysis for changes.

All these requirements-controlled conditions are supported inherently in easeRequirements’ revision management module which enables monitoring changes in requirements, rolling back values from previous revisions, comparing revisions as well as highlighting major or minor differences between one revision and the other.

In addition, easeRequirement’s suspect mechanism allows evaluating correctly and promptly the impact of changes

It ensures that as stakeholder needs evolve or clarifications arise, the system requirements remain accurate and traceable, and that all related artifacts are updated accordingly.

This is especially important in projects with multiple iterations or regulatory oversight, where precise documentation and change history are essential.

Typical Work Products

The outputs of SYS.2 include:

• System Requirements Specification (SyRS) – formal document capturing all validated and analyzed system-level requirements.
• Interface Specification Documents – descriptions of external system interfaces.
• Traceability Matrix – showing links between stakeholder requirements and system requirements.
• Change Requests and Status Reports – tracking modifications over time.

Importance of SYS.2 in ASPICE

SYS.2 plays a foundational role in the ASPICE model. Without well-defined and validated system requirements:

• System architecture (SYS.3) may be based on incorrect assumptions,
• Implementation could miss critical functions or fail to comply with safety standards,
• Testing could lack sufficient coverage.

By enforcing discipline in requirement analysis and documentation, SYS.2 helps reduce development risks and improves quality, compliance, and customer satisfaction.

This process plays a crucial role in ensuring that system development meets intended functionality, safety, and quality requirements.

Implementation of this foundational role, is achieved myhc easier using easeRequirements and by having the system requirements in the same system as the development and validation teams it enables easy

🛠️ Coming Up in the Next ASPICE Blog Post

In our next post, we’ll cover the SYS.3 System Architectural Design process and demonstrate how to implement it using Jira, easeRequirements, and easeRequirements Ultimate.

📩 Contact us today to schedule your free consultation and explore how we can support your ASPICE compliance journey.