3.1: Requirements Templates

What You'll Learn

By the end of this chapter, you'll have:

• Complete SRS and SWRS templates ready to use on your project
• A structured requirement format that assessors love
• Built-in traceability that makes matrices generate themselves
• YAML schemas for requirement management tools

Introduction

"Show me your requirements." That's usually the first thing an ASPICE assessor says. And within 5 minutes, they know whether you're sailing toward CL2 or drowning in CL0.

Requirements are the foundation of everything—architecture traces to them, code implements them, tests verify them. Mess up your requirements, and the ripple effects touch every other process.

The good news? Well-structured templates make requirements almost impossible to mess up. This section gives you production-ready templates for System (SYS.2) and Software (SWE.1) requirements—the same ones I've used on dozens of successful assessments.

System Requirements Specification (SRS) Template

Complete SRS Template

---
title: "System Requirements Specification"
document_id: "SRS"
project: "{{PROJECT_NAME}}"
component: "{{COMPONENT_NAME}}"
version: "{{VERSION}}"
date: {{DATE}}
status: "Draft | Review | Approved"
asil_level: "QM | ASIL-A | ASIL-B | ASIL-C | ASIL-D"
authors: ["{{AUTHOR_NAME}}"]
reviewers: ["{{REVIEWER_NAME}}"]
approvers: ["{{APPROVER_NAME}}"]
---

# System Requirements Specification
## {{COMPONENT_NAME}}

## 1. Introduction

### 1.1 Purpose

This document specifies the system requirements for the {{COMPONENT_NAME}} system.
It serves as the basis for:
- System architecture design (SYS.3)
- Software requirements derivation (SWE.1)
- System verification and validation (SYS.5)

**ASPICE Process**: SYS.2 System Requirements Analysis

### 1.2 Scope

**In Scope**:
- {{LIST_INCLUDED_FUNCTIONALITY}}

**Out of Scope**:
- {{LIST_EXCLUDED_FUNCTIONALITY}}

### 1.3 Definitions and Acronyms

| Term | Definition |
|------|------------|
| ECU | Electronic Control Unit |
| CAN | Controller Area Network |
| UDS | Unified Diagnostic Services |
| {{TERM}} | {{DEFINITION}} |

### 1.4 Reference Documents

| Document ID | Title | Version |
|-------------|-------|---------|
| STKH-DOC-001 | Stakeholder Requirements | v1.2 |
| SYS-ARCH-001 | System Architecture | v2.0 |
| {{DOC_ID}} | {{TITLE}} | {{VERSION}} |

---

## 2. Stakeholder Requirements Traceability

This section traces system requirements back to stakeholder needs (SYS.2 BP5).

| System Req ID | Stakeholder Requirement | Rationale |
|---------------|-------------------------|-----------|
| SYS-REQ-001 | [STKH-005] Convenience Features | Enable remote door access |
| SYS-REQ-002 | [STKH-008] Safety Features | Prevent operation during motion |
| {{SYS_ID}} | {{STKH_ID}} | {{RATIONALE}} |

---

## 3. Functional Requirements

### 3.1 {{FEATURE_CATEGORY_1}}

#### SYS-REQ-001: Remote Door Unlock

**Description**:
The system shall unlock the door lock mechanism when a valid unlock command is
received via the CAN bus from the Body Control Module (BCM).

**Rationale**:
Enables keyless entry feature requested by stakeholders ([STKH-005]).

**Preconditions**:
- Vehicle electrical system is active (KL15 ON or KL30 active)
- Door lock actuator is in a known state (locked or unlocked)

**Inputs**:
- CAN Message: `DoorCmd_BCM` (ID: 0x320)
  - Signal: `DoorUnlockReq` = 0x01
  - Signal: `DoorID` = 0x02 (Front Left)

**Outputs**:
- Actuator Control: PWM signal to door lock motor (unlock direction)
- CAN Message: `DoorStatus_ECU` (ID: 0x321)
  - Signal: `DoorState` = 0x01 (Unlocked)

**Processing**:
1. Receive and validate `DoorCmd_BCM` message
2. Check preconditions (voltage range, actuator status)
3. Activate door lock motor in unlock direction
4. Monitor position sensor for unlock confirmation
5. Send status confirmation via CAN

**Acceptance Criteria**:
- Door unlocks within 500ms of command reception
- Status message sent within 100ms of unlock completion
- No unlock if vehicle speed > 5 km/h (safety interlock)

**Safety Relevance**:
ASIL-B (prevents unintended unlock during vehicle operation)

**Traceability**:
- ↑ Parent: [STKH-005] Keyless Entry Feature
- → Related: [SYS-REQ-008] CAN Communication
- ↓ Derived To: [SWE-042] Software Remote Unlock Function

**Priority**: Must Have

**Verification Method**: System Integration Test [TC-SYS-001]

---

#### SYS-REQ-002: Speed-Based Lock Interlock

**Description**:
The system shall automatically lock all doors when the vehicle speed exceeds 10 km/h.

**Rationale**:
Safety feature to prevent accidental door opening during vehicle motion ([STKH-008]).

**Preconditions**:
- Vehicle ignition is ON (KL15 active)
- At least one door is currently unlocked

**Inputs**:
- CAN Message: `VehicleSpeed_BCM` (ID: 0x310)
  - Signal: `VehSpd` (uint16, 0.01 km/h resolution)

**Outputs**:
- Actuator Control: PWM signal to all door lock motors (lock direction)
- CAN Message: `DoorStatus_ECU` (ID: 0x321)
  - Signal: `AutoLockActive` = 0x01

**Processing**:
1. Monitor `VehSpd` signal continuously (100ms cycle)
2. If `VehSpd` > 10.0 km/h AND any door unlocked:
   - Activate all door lock motors in lock direction
   - Set `AutoLockActive` flag
3. Confirm lock status via position sensors
4. Broadcast status update

**Acceptance Criteria**:
- Auto-lock triggers within 200ms of speed threshold crossing
- All doors locked within 1 second of trigger
- Function inhibited if manual unlock pressed during operation

**Safety Relevance**:
ASIL-B (critical safety function)

**Traceability**:
- ↑ Parent: [STKH-008] Safety Features
- → Related: [SYS-REQ-009] Speed Signal Processing
- ↓ Derived To: [SWE-043] Auto-Lock Logic

**Priority**: Must Have

**Verification Method**: System Qualification Test [TC-SYS-002]

---

### 3.2 {{FEATURE_CATEGORY_2}}

*[Repeat structure for additional requirements]*

---

## 4. Non-Functional Requirements

### 4.1 Performance Requirements

#### SYS-REQ-020: Response Time

**Description**:
The system shall respond to CAN commands within 100ms (95th percentile).

**Measurement**:
Time from CAN message reception to actuator activation start.

**Verification**: Performance profiling + HIL testing

---

#### SYS-REQ-021: CAN Bus Load

**Description**:
The system shall not exceed 30% CAN bus utilization under normal operation.

**Measurement**:
CANalyzer measurement during integration testing.

**Verification**: System integration test with full vehicle network

---

### 4.2 Reliability Requirements

#### SYS-REQ-030: Fault Detection Coverage

**Description**:
The system shall detect and report 95% of single-point faults within 100ms.

**Rationale**:
ASIL-B requirement for diagnostic coverage (ISO 26262-5).

**Verification**: FMEA analysis + fault injection testing

---

### 4.3 Safety Requirements

#### SYS-REQ-040: Safe State Definition

**Description**:
In case of critical failure, the system shall transition to safe state:
all doors locked, fault code stored, warning lamp activated.

**Safety Mechanism**:
Watchdog monitoring + voltage supervision + CAN timeout detection

**Verification**: Fault injection testing (FIT)

---

## 5. Interface Requirements

### 5.1 CAN Bus Interface

| Message Name | ID (Hex) | Cycle Time | Signals | Direction |
|--------------|----------|------------|---------|-----------|
| DoorCmd_BCM | 0x320 | Event | DoorUnlockReq, DoorID | RX |
| VehicleSpeed_BCM | 0x310 | 100ms | VehSpd | RX |
| DoorStatus_ECU | 0x321 | 200ms | DoorState, AutoLockActive | TX |

**Detailed Specification**: See [ICD-CAN-001] CAN Interface Control Document

---

### 5.2 Hardware Interface

| Signal Name | Type | Voltage Range | Connector Pin |
|-------------|------|---------------|---------------|
| DoorMotor_PWM | Output | 0-12V PWM | J1-5 |
| PositionSensor | Input | 0-5V Analog | J1-8 |
| KL15_Ignition | Input | 0/12V Digital | J1-1 |

**Detailed Specification**: See [HW-IF-001] Hardware Interface Specification

---

## 6. Requirements Traceability Matrix

### Forward Traceability (System → Software)

| System Req | Software Req(s) | Architecture Component |
|------------|-----------------|------------------------|
| SYS-REQ-001 | SWE-042, SWE-043 | DoorLockController SWC |
| SYS-REQ-002 | SWE-044, SWE-045 | SpeedMonitor SWC |
| {{SYS_ID}} | {{SWE_IDS}} | {{COMPONENT}} |

### Backward Traceability (System → Stakeholder)

| System Req | Stakeholder Req | Customer Feature |
|------------|-----------------|------------------|
| SYS-REQ-001 | STKH-005 | Keyless Entry |
| SYS-REQ-002 | STKH-008 | Auto-Lock on Drive |
| {{SYS_ID}} | {{STKH_ID}} | {{FEATURE}} |

---

## 7. Requirements Verification Matrix

| Requirement ID | Verification Method | Test Case(s) | Status |
|----------------|---------------------|--------------|--------|
| SYS-REQ-001 | Integration Test | TC-SYS-001 | [PASS] Pass |
| SYS-REQ-002 | Qualification Test | TC-SYS-002 | [PASS] Pass |
| SYS-REQ-020 | Performance Test | TC-PERF-001 | ⏳ Planned |
| {{REQ_ID}} | {{METHOD}} | {{TEST_ID}} | {{STATUS}} |

---

## 8. Open Issues and Assumptions

### 8.1 Open Issues

| Issue ID | Description | Impact | Owner | Target Date |
|----------|-------------|--------|-------|-------------|
| ISS-001 | CAN message timing not finalized | Medium | BCM Team | 2025-01-15 |
| {{ID}} | {{DESCRIPTION}} | {{IMPACT}} | {{OWNER}} | {{DATE}} |

### 8.2 Assumptions

1. BCM will implement CAN message authentication (ISO 11898-1)
2. Door lock actuator response time < 400ms (vendor specification)
3. CAN bus operates at 500 kbit/s (vehicle standard)

---

## 9. Document History

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2025-11-01 | A. Stepien | Initial draft |
| 1.1 | 2025-11-15 | A. Stepien | Added safety requirements |
| 2.0 | 2025-12-01 | A. Stepien | Customer review incorporated |
| {{VER}} | {{DATE}} | {{AUTHOR}} | {{CHANGES}} |

---

## 10. Approval

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Technical Lead | {{NAME}} | __________ | ______ |
| Safety Manager | {{NAME}} | __________ | ______ |
| Quality Manager | {{NAME}} | __________ | ______ |
| Customer Representative | {{NAME}} | __________ | ______ |

Software Requirements Specification (SWRS) Template

Complete SWRS Template (SWE.1)

---
title: "Software Requirements Specification"
document_id: "SWRS"
project: "{{PROJECT_NAME}}"
software_component: "{{COMPONENT_NAME}}"
version: "{{VERSION}}"
date: {{DATE}}
status: "Draft | Review | Approved"
asil_level: "QM | ASIL-A | ASIL-B | ASIL-C | ASIL-D"
aspice_process: "SWE.1 Software Requirements Analysis"
---

# Software Requirements Specification
## {{SOFTWARE_COMPONENT_NAME}}

## 1. Introduction

### 1.1 Purpose

This document specifies the software requirements for the {{COMPONENT_NAME}}
software component, derived from the System Requirements Specification [SRS].

**ASPICE Compliance**:
- SWE.1 BP1: Specify software requirements
- SWE.1 BP2: Structure software requirements
- SWE.1 BP5: Establish bidirectional traceability
- SWE.1 BP6: Ensure consistency and feasibility
- SWE.1 BP7: Communicate software requirements

### 1.2 Scope

This SWRS covers the software implementation of:
- {{LIST_SOFTWARE_FUNCTIONS}}

### 1.3 Reference Documents

| Document ID | Title | Version |
|-------------|-------|---------|
| SRS-001 | System Requirements Specification | v2.0 |
| SAD-001 | Software Architecture Document | v1.5 |
| AUTOSAR-SWC | DoorLockCtrl SWC Description | v1.0 |

---

## 2. Software Requirements

### 2.1 Functional Software Requirements

#### SWE-042: CAN Message Reception and Validation

**Description**:
The software shall receive CAN message `DoorCmd_BCM` (ID: 0x320), validate the
message checksum and sequence counter, and extract the `DoorUnlockReq` signal.

**Rationale**:
Implements the communication interface defined in [SYS-REQ-001].

**Inputs**:
- CAN RX buffer: `DoorCmd_BCM` (8 bytes)
  - Byte 0: `DoorUnlockReq` (bit 0-1)
  - Byte 1: `DoorID` (bit 0-3)
  - Byte 7: Checksum (CRC-8)

**Outputs**:
- Internal variable: `doorUnlockRequest` (boolean)
- Internal variable: `targetDoorID` (uint8)
- Error flag: `canMessageInvalid` (boolean)

**Processing**:
```c
// Pseudocode
function onCANMessageReceived(msg: DoorCmd_BCM):
    1. Verify message length == 8 bytes
    2. Calculate CRC-8 checksum on bytes 0-6
    3. Compare calculated checksum with msg.byte[7]
    4. If checksum valid:
        - Extract doorUnlockReq from byte[0] bits 0-1
        - Extract targetDoorID from byte[1] bits 0-3
        - Set canMessageInvalid = false
    5. Else:
        - Set canMessageInvalid = true
        - Increment diagnostic counter: CANChecksumErrors

Acceptance Criteria:

• Valid messages: canMessageInvalid == false, signals extracted correctly
• Invalid checksum: canMessageInvalid == true, error counter incremented
• Processing time: < 50μs (measured on target ECU)

Traceability:

• ↑ Derived From: [SYS-REQ-001] Remote Door Unlock
• → Related: [SWE-043] Door Unlock Command Processing
• ↓ Implemented In: src/comm/can_handler.c:handleDoorCommand()
• [OK] Verified By: [TC-042] Unit Test CAN Reception

Priority: Must Have

Safety Relevance: ASIL-B (invalid commands could cause safety hazard)

SWE-043: Door Unlock Command Processing

Description: The software shall process validated door unlock requests by activating the door lock actuator PWM output in the unlock direction for the specified door.

Rationale: Core function implementing [SYS-REQ-001] at software level.

Preconditions:

• canMessageInvalid == false (SWE-042 passed)
• vehicleSpeed <= 5.0 km/h (safety interlock from SWE-045)
• systemState == OPERATIONAL (not in fault state)

Inputs:

• doorUnlockRequest: true
• targetDoorID: 0x02 (Front Left Door)
• currentDoorState[FRONT_LEFT]: LOCKED | UNLOCKED | MOVING | FAULT

Outputs:

• PWM output: DoorMotorPWM[FRONT_LEFT] = 80% duty cycle, unlock direction
• Status variable: doorOperationInProgress = true
• CAN TX: DoorStatus_ECU.DoorState = MOVING (0x02)

Processing:

// Pseudocode
function processDoorUnlockRequest(doorID: uint8):
    1. Check preconditions:
        - IF vehicleSpeed > 5.0 km/h: RETURN error
        - IF systemState != OPERATIONAL: RETURN error
        - IF currentDoorState[doorID] == UNLOCKED: RETURN (already unlocked)

    2. Activate actuator:
        - Set GPIO direction pin: UNLOCK_DIR
        - Set PWM duty cycle: 80%
        - Enable PWM output

    3. Start timeout timer: 1000ms

    4. Update state:
        - currentDoorState[doorID] = MOVING
        - doorOperationInProgress = true

    5. Send CAN status update:
        - DoorStatus_ECU.DoorState = MOVING
        - DoorStatus_ECU.DoorID = doorID

Completion Criteria:

• Position sensor indicates UNLOCKED position: Stop PWM, set state = UNLOCKED
• Timeout (1000ms) expires: Stop PWM, set fault code, state = FAULT
• Overcurrent detected: Stop PWM immediately, set fault code

Acceptance Criteria:

• Successful unlock: Door reaches UNLOCKED position within 500ms
• Safety interlock: No activation if speed > 5 km/h
• Fault handling: Timeout detection within ±10ms

Traceability:

• ↑ Derived From: [SYS-REQ-001] Remote Door Unlock
• → Uses: [SWE-042] CAN Message Reception
• → Uses: [SWE-045] Speed Safety Interlock
• ↓ Implemented In: src/app/door_lock/door_ctrl.c:unlockDoor()
• [OK] Verified By: [TC-043] Unit Test Door Unlock Logic

Priority: Must Have

Safety Relevance: ASIL-B

SWE-044: Speed Monitoring for Auto-Lock

Description: The software shall continuously monitor vehicle speed from CAN and trigger auto-lock function when speed exceeds 10.0 km/h threshold.

Derived From: [SYS-REQ-002] Speed-Based Lock Interlock

Inputs:

• CAN RX: VehicleSpeed_BCM.VehSpd (uint16, 0.01 km/h resolution, 100ms cycle)

Outputs:

• Internal event: AutoLockTrigger (boolean)
• Diagnostic: speedSignalTimeout (boolean, if CAN message missing > 300ms)

Processing:

// Cyclic task: 100ms period
function monitorSpeedForAutoLock():
    1. Read latest VehSpd from CAN buffer

    2. Check signal validity:
        - IF CAN message age > 300ms:
            - Set speedSignalTimeout = true
            - Use last valid speed (fail-safe)
        - ELSE:
            - Set speedSignalTimeout = false

    3. Convert to km/h: speed_kmh = VehSpd * 0.01

    4. Auto-lock trigger logic:
        - IF (speed_kmh > 10.0) AND (previousSpeed <= 10.0):
            - Set AutoLockTrigger = true  (rising edge detection)
        - ELSE:
            - Set AutoLockTrigger = false

    5. Store current speed: previousSpeed = speed_kmh

Acceptance Criteria:

• Trigger fires within 200ms of speed crossing 10.0 km/h threshold
• No false triggers due to signal noise (hysteresis: 9.5-10.5 km/h)
• Timeout detection: 300ms ± 20ms

Traceability:

• ↑ Derived From: [SYS-REQ-002] Speed-Based Lock Interlock
• → Triggers: [SWE-046] Auto-Lock Execution
• ↓ Implemented In: src/app/speed_monitor/speed_mon.c:checkAutoLock()
• [OK] Verified By: [TC-044] Unit Test Speed Monitoring

2.2 Non-Functional Software Requirements

SWE-060: Cyclic Task Execution Timing

Description: The software shall execute the main control loop as a cyclic task with 10ms period and worst-case execution time (WCET) < 5ms.

Measurement:

• Instrumentation: Toggle GPIO at task entry/exit
• Analysis: Logic analyzer measurement on target hardware

Acceptance Criteria:

• Measured WCET < 5ms in 10,000 consecutive cycles
• Jitter < 500μs (95th percentile)

Verification: Timing analysis + HIL testing

SWE-061: RAM Usage

Description: The software component shall not exceed 8 KB of RAM usage (static + dynamic).

Measurement:

• Linker map file analysis: Static allocation
• Runtime profiling: Stack watermark

Acceptance Criteria:

• Total RAM: < 8192 bytes
• Stack usage: < 2048 bytes (measured worst-case)

Verification: Memory profiling tools (ARM GCC size, RTOS stack checker)

SWE-062: MISRA C:2012 Compliance

Description: All source code shall comply with MISRA C:2012 with the following deviations:

• Rule 8.7: Functions declared at file scope (required for AUTOSAR RTE)

Verification:

• Static analysis: Cppcheck with MISRA addon
• Manual review: Deviation justifications documented

Acceptance Criteria:

• Zero mandatory rule violations
• Documented deviations for all required/advisory violations

2.3 Interface Requirements (Software Level)

SWE-070: AUTOSAR RTE Interface

Description: The software component shall interface with other SWCs via AUTOSAR Runtime Environment (RTE) using the following ports:

Sender-Receiver Ports:

// Provided Interface (outgoing)
Rte_Write_DoorLockCtrl_DoorStatus(DoorStateType status);

// Required Interface (incoming)
Rte_Read_DoorLockCtrl_VehicleSpeed(SpeedType* speed);
Rte_Read_DoorLockCtrl_DoorCommand(DoorCmdType* cmd);

Client-Server Ports:

// Provided Operation (server)
Std_ReturnType SWC_DoorLock_Unlock(DoorIDType doorID);

// Required Operation (client)
Std_ReturnType Dem_SetEventStatus(EventIDType eventID, EventStatusType status);

Verification: Interface contract testing + AUTOSAR compliance check

3. Requirements Traceability Matrix

3.1 Forward Traceability (Software → Code → Tests)

3.2 Backward Traceability (Software → System → Stakeholder)

4. Requirements Verification Plan

5. Approval

---

## Individual Requirement Template (YAML Schema)

For requirement management tools or databases:

```yaml
# requirement_schema.yaml
# Single software requirement in structured format

requirement:
  id: "SWE-042"
  type: "functional"  # functional | non-functional | interface
  title: "CAN Message Reception and Validation"

  description: >
    The software shall receive CAN message DoorCmd_BCM (ID: 0x320),
    validate the message checksum and sequence counter, and extract
    the DoorUnlockReq signal.

  rationale: >
    Implements the communication interface defined in SYS-REQ-001.

  asil_level: "ASIL-B"
  priority: "must_have"  # must_have | should_have | could_have

  traceability:
    derived_from:
      - "SYS-REQ-001"
    related_to:
      - "SWE-043"
    implemented_in:
      - file: "src/comm/can_handler.c"
        function: "handleDoorCommand"
        lines: [87, 142]
    verified_by:
      - "TC-042"
      - "TC-INT-012"

  inputs:
    - name: "CAN RX buffer"
      description: "DoorCmd_BCM message (8 bytes)"
      source: "AUTOSAR COM module"

  outputs:
    - name: "doorUnlockRequest"
      type: "boolean"
      description: "Extracted unlock request flag"
    - name: "canMessageInvalid"
      type: "boolean"
      description: "Message validation result"

  acceptance_criteria:
    - "Valid messages: canMessageInvalid == false"
    - "Invalid checksum: canMessageInvalid == true, error counter incremented"
    - "Processing time < 50μs on target ECU"

  verification:
    method: "unit_test"
    test_cases: ["TC-042"]
    coverage_target: 100  # percent MC/DC

  metadata:
    author: "A. Stepien"
    created_date: "2025-11-15"
    last_modified: "2025-12-10"
    status: "approved"  # draft | review | approved
    version: "1.2"

Summary

Requirements Templates for ASPICE Compliance:

• SRS Template: System-level requirements (SYS.2) with stakeholder traceability
• SWRS Template: Software requirements (SWE.1) derived from system requirements
• Structured Format: Markdown + YAML for human readability and AI processing
• Built-in Traceability: Every requirement links to parents, children, code, tests
• Verification Ready: Acceptance criteria and verification methods embedded

Key Features:

1. Unique IDs: All requirements have traceable identifiers
2. Safety Integration: ASIL levels and safety relevance documented
3. Testability: Clear acceptance criteria for every requirement
4. AI-Compatible: Structured format enables AI-powered generation and validation
5. ASPICE Aligned: Templates cover all SYS.2 and SWE.1 base practices