1.2: SYS.2 System Requirements Analysis

What You'll Learn

Here's what you'll take away from this section:

• Transform stakeholder requirements into system requirements
• Apply AI for requirements quality analysis
• Create verifiable system requirements
• Establish bidirectional traceability

Process Definition

Purpose

SYS.2 Purpose: To transform stakeholder requirements into a set of system requirements.

Outcomes

Base Practices with AI Integration

BP1 Note: ASPICE 4.0 specifies that verification criteria shall be defined as attributes of each system requirement (within 17-08), not as a separate work product. See System Requirement Example below for verification criteria structure.

Requirement Quality Criteria

INCOSE Quality Attributes

References:

• INCOSE Guide for Writing Requirements (INCOSE-TP-2010-006-04)
• ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering

Note: These attributes align with ASPICE 4.0 BP1, which requires system requirements to include verification criteria as requirement attributes.

Common Quality Issues

AI Integration for Requirements Analysis

L1: AI-Assisted Analysis

The following diagram illustrates how AI assists at each stage of requirements analysis, from initial parsing and classification through consistency checking and verification criteria generation.

Note: Diagram uses color indicators (red/yellow/green) that may render differently across viewers.

L2: AI-Generated Verification Criteria

Note: Confidence levels shown are illustrative examples.

Input: SYS-BCM-010: The BCM shall lock all doors within 200ms of lock command

AI Output:
─────────
Verification Criteria (Draft):

1. Test Condition: Lock button pressed at ambient temperature (20°C ± 5°C)
   Expected: All four doors locked within 200ms
   Measurement: Time from button signal to door sensor locked state

2. Test Condition: Lock button pressed at -40°C
   Expected: All four doors locked within 200ms
   Measurement: Time from button signal to door sensor locked state

3. Test Condition: Lock button pressed at +85°C
   Expected: All four doors locked within 200ms
   Measurement: Time from button signal to door sensor locked state

4. Test Condition: Lock command via CAN bus
   Expected: All four doors locked within 200ms
   Measurement: Time from CAN message receipt to door sensor locked state

Human Review: Verify completeness, add edge cases, approve

System Requirement Example

---
ID: SYS-BCM-010
Title: Door Lock Response Time
Type: Performance
Priority: High
Status: Approved
Version: 1.2
---

## Description

The Body Control Module shall command all door lock actuators to the
locked position within 200ms of receiving a valid lock command.

## Definitions

- **Lock command**: CAN message ID 0x301 with data byte 0 = 0x01,
  OR central lock button press (active low signal for >50ms)
- **All door lock actuators**: FL, FR, RL, RR door locks
- **Locked position**: Actuator position sensor indicates locked state

## Rationale

Derived from STK-BCM-001 (stakeholder response time expectation).
200ms provides margin for 150ms actuator response + processing.

## Constraints

- Applicable temperature range: -40°C to +85°C
- Supply voltage range: 9V to 16V
- Concurrent operations: Up to 3 other actuator commands

## Verification Method

Test with timing measurement (see SYS-TEST-010)

## Verification Criteria

- VC1: Lock command to actuator command: < 50ms
- VC2: All actuators commanded in sequence: < 10ms between commands
- VC3: Verified across full temperature and voltage range

## Traceability

- Derived from: STK-BCM-001
- Allocates to: SWE-BCM-101 (software), HWE-BCM-201 (hardware driver)
- Verified by: SYS-TEST-010

## Change History

> **Note**: Dates shown are illustrative examples.

| Version | Date | Author | Change |
|---------|------|--------|--------|
| 1.0 | (initial) | Engineer | Initial version |
| 1.1 | (+2 weeks) | Engineer | Added CAN command definition |
| 1.2 | (+6 weeks) | Engineer | Clarified voltage constraints |

Traceability Matrix

The traceability matrix below maps each stakeholder requirement to its derived system requirements, showing coverage status and verification links.

AI Validation Results:

• [PASS] All stakeholder requirements have system requirements
• [PASS] All system requirements trace to stakeholder requirements
• [WARN] SYS-BCM-035: Missing verification link

Work Products

ASPICE 4.0 Clarification: Work product 17-12 (Verification criteria) is not a separate deliverable for SYS.2. Verification criteria are specified as attributes within each system requirement (17-08) per BP1. Separate test specifications are developed later in SYS.4 (System Integration Test) and SYS.5 (System Qualification Test).

Common Challenges and Mitigations

Summary

SYS.2 System Requirements Analysis:

• AI Level: L1-L2 (significant AI assistance)
• AI Value: Quality analysis, consistency checking, traceability
• Human Essential: Requirement decisions, stakeholder agreement
• Key Outputs: System requirements specification, traceability
• Quality Focus: INCOSE attributes (necessary, unambiguous, complete, etc.)