1.2: Requirements Engineering Practice

Practical Requirements Engineering

The Requirements Lifecycle

The following diagram illustrates the complete requirements lifecycle from elicitation through analysis, specification, validation, and management, showing the iterative nature of requirements engineering in an ASPICE context.

1. Requirements Elicitation

Technique 1: Stakeholder Interviews

Preparation:

• Identify stakeholders (customer, users, safety engineers, regulatory)
• Prepare questions (open-ended: "What are your main concerns?")
• Schedule 1-2 hour sessions

Example Interview Script (ACC ECU):

Interview with: OEM Product Manager (Customer)
Date: 2025-12-17
Purpose: Elicit high-level requirements for ACC ECU development

Q1: What is the primary purpose of the ACC system from your perspective?
A1: "We want to offer Level 2 autonomous driving in our luxury sedan. ACC is
     a key feature for highway driving comfort."

Q2: What are the must-have features vs nice-to-have?
A2: "Must-have: Speed control 30-150 km/h, maintain following distance.
     Nice-to-have: Stop-and-go in traffic, curve speed adaptation."

Q3: What are your main safety concerns?
A3: "False braking (customer dissatisfaction) and missed obstacles (safety risk).
     We need ASIL-B certification, TÜV approval."

Q4: Budget and schedule constraints?
A4: "Budget: €2.5M, Schedule: 18 months to SOP, Cost target: €150 per unit."

Action Items:
- [ ] Define "following distance" (2 seconds? distance in meters?)
- [ ] Clarify "stop-and-go" scope (full stop or minimum 5 km/h?)
- [ ] Obtain ISO 26262 HARA (Hazard Analysis) from customer

Follow-Up Questions for Next Session:
- What are the target markets? (Europe, US, Asia - may affect radar frequencies)
- Are there existing vehicles we can use as reference? (competitor analysis)
- What is the integration timeline with other ADAS features?

Interview Best Practice: Schedule follow-up sessions for clarification. Initial interviews rarely capture everything. Plan for 2-3 iterations with key stakeholders.

Key Questions to Always Ask:

1. Success Criteria: How will you know this is successful?
2. Constraints: Budget, schedule, regulations, existing systems
3. Failure Modes: What must NOT happen? (safety)
4. Priorities: If we had to cut features, which are essential?

Technique 2: Use Case Analysis

Structure:

Use Case: UC-001 Maintain Set Speed on Highway

Primary Actor: Driver
Preconditions: Vehicle speed 30-150 km/h, ACC engaged, no obstacles

Main Flow:
1. Driver sets desired speed (e.g., 120 km/h)
2. System maintains speed ±2 km/h
3. System monitors road ahead (radar/camera)
4. If no obstacles, continue at set speed

Alternative Flow 1: Vehicle Ahead Detected
4a. If vehicle detected <100m ahead
4b. System calculates safe following distance (2 seconds)
4c. System adjusts speed to maintain distance
4d. Return to step 3

Alternative Flow 2: Emergency Braking
4a. If obstacle <5m AND closing speed >10 km/h
4b. System applies emergency brake
4c. System alerts driver (visual + audible)
4d. System logs event

Exception Flow: Sensor Failure
4a. If radar/camera fails (CAN timeout >100ms)
4b. System disables ACC
4c. System alerts driver "ACC UNAVAILABLE"
4d. System logs fault (DTC code)

Postconditions: Vehicle speed controlled per driver setting, or ACC disabled if fault

Derived Requirements:
- [SYS-045-1] Maintain speed ±2 km/h
- [SYS-045-2] Detect vehicles <100m
- [SYS-045-3] Maintain 2-second following distance
- [SYS-045-4] Emergency brake if <5m + closing speed >10 km/h
- [SYS-045-5] Disable ACC on sensor failure

Benefit: Use cases reveal interactions and failure modes that simple feature lists miss.

Iteration Triggers: Requirements lifecycle iterates when: (1) Customer provides new information, (2) Technical feasibility issues discovered, (3) Safety analysis identifies new hazards, (4) Cost/schedule constraints change. Document iteration rationale in requirements history.

2. Requirements Analysis

Technique: Ambiguity Detection

Common Ambiguous Terms:

Checklist for Requirement Quality:

Verdict:

• [PASS] Meets all criteria
• [WARN] Partial: Missing quantification or test criteria
• [FAIL] Fail: Ambiguous or untestable

3. Requirements Specification

IEEE 830 Template (Simplified)

Note: This template follows the IEEE 830 standard. Tool-specific formats (DOORS, Jama) may vary but contain the same content.

Software Requirements Specification (SRS):

# Software Requirements Specification (SRS)
## Project: ACC ECU

### 1. Introduction
**1.1 Purpose**: This SRS specifies software requirements for ACC ECU
**1.2 Scope**: ACC speed control, following distance, emergency braking (ASIL-B)
**1.3 Definitions**: ACC = Adaptive Cruise Control, ASIL = Automotive Safety Integrity Level

### 2. Overall Description
**2.1 Product Perspective**: Part of ADAS suite (Lane Keep Assist, Parking Assist)
**2.2 Product Functions**: Speed control, obstacle detection, emergency braking
**2.3 User Characteristics**: Licensed drivers, no special training required
**2.4 Constraints**: ISO 26262 ASIL-B, MISRA C:2012, TriCore TC397 (2 MB RAM)

### 3. Functional Requirements
**3.1 Speed Control**
[SWE-045-1] Maintain Set Speed
The ACC software shall maintain vehicle speed within ±2 km/h of driver-set speed.
- Input: Set speed (30-150 km/h)
- Output: Throttle/brake command
- Latency: ≤100ms
- Verification: Proving ground test
- Safety Class: ASIL-B
- Implements: [SYS-045]

[SWE-045-2] Detect Obstacles
The ACC software shall detect vehicles ahead within 0-200m range.
- Input: Radar/camera sensor data
- Output: Obstacle distance, speed
- Accuracy: ≥95% detection (objects >0.5m² cross-section)
- Latency: ≤50ms
- Verification: HIL test with simulated sensors
- Safety Class: ASIL-B
- Implements: [SYS-046]

### 4. Non-Functional Requirements
**4.1 Performance**
[SWE-NFR-001] The system shall execute control loop in ≤10ms (worst-case)

**4.2 Safety**
[SWE-NFR-002] On sensor failure, system shall transition to safe state within 100ms

**4.3 Reliability**
[SWE-NFR-003] MTBF ≥10,000 hours (ISO 26262 ASIL-B requirement)

### 5. Interface Requirements
**5.1 CAN Bus**
[SWE-IF-001] Radar Data (Message ID: 0x200, 50 Hz)
- Byte 0-1: Object distance (mm, uint16_t)
- Byte 2-3: Relative speed (cm/s, int16_t)
- Byte 4: Object valid flag (0/1)

### 6. Traceability Matrix
| System Req | Software Req | Rationale |
|------------|--------------|-----------|
| SYS-045 | SWE-045-1 | Speed control |
| SYS-046 | SWE-045-2 | Obstacle detection |

4. Requirements Validation

Technique: Requirements Review Checklist

Review Meeting:

• Attendees: Requirements engineer, systems engineer, software lead, safety engineer, customer (optional)
• Duration: 2–3 hours (for 50–100 requirements)
• Artifacts: Draft SRS, review checklist

Review Checklist:

## Requirements Review Checklist

### Completeness
- ☐ All stakeholder needs addressed?
- ☐ All use cases covered (normal + failure scenarios)?
- ☐ Interfaces defined (CAN, Ethernet, APIs)?

### Correctness
- ☐ Requirements match stakeholder intent?
- ☐ No technical errors (formulas, units)?

### Consistency
- ☐ No contradictions between requirements?
- ☐ Terminology consistent throughout?

### Verifiability
- ☐ All requirements testable (pass/fail criteria)?
- ☐ Verification method defined for each?

### Traceability
- ☐ All software requirements trace to system requirements?
- ☐ Unique IDs assigned (SWE-XXX-Y format)?

### Safety
- ☐ ASIL classification assigned?
- ☐ Fail-safe behavior defined for safety-critical functions?

Issues Found: {List issues, assign owners, due dates}

5. Requirements Management

Tool: IBM DOORS (Industry Standard)

Key Features:

• Unique IDs: Automatic (SWE-001, SWE-002, ...)
• Traceability: Links between requirements (parent/child, implements, verifies)
• Change tracking: History of requirement evolution
• Baselining: Freeze requirements at milestones

Alternative Tools:

• Jama Connect: Modern, web-based (easier collaboration)
• Excel: Small projects (<100 requirements), manual traceability
• Markdown + Git: Very small projects, version control built-in

Change Management Process

When Requirement Changes: The following diagram shows the change management workflow, from change request through impact analysis, approval, implementation, and re-verification.

Example Change Request:

# Change Request: CR-045

**Date**: 2025-12-17
**Requester**: OEM Product Manager
**Priority**: High

## Proposed Change
Modify [SWE-045-1] speed control accuracy from ±2 km/h to ±1 km/h

## Justification
Customer feedback: Competitors offer ±1 km/h, we need to match for market competitiveness

## Impact Analysis
- **Technical**: Requires PID controller tuning, increased CPU load (+5%)
- **Schedule**: +2 weeks (re-tuning, re-testing)
- **Cost**: +€15k (engineering effort)
- **Risk**: Medium (PID tuning may affect stability)

## CCB Decision
[PASS] **APPROVED** - Competitive requirement, acceptable cost/schedule impact

## Action Items
- [ ] Update [SWE-045-1] in DOORS (Assigned: Requirements Engineer)
- [ ] Re-tune PID controller (Assigned: Control Engineer)
- [ ] Re-run proving ground tests (Assigned: Test Engineer)
- [ ] Update traceability matrix

Practical Exercise

Given: Customer statement:

"We need the car to slow down smoothly when approaching another vehicle."

Your Task: Convert to quantified requirements (3-5 requirements)

Solution:

[SWE-045-3] Following Distance Calculation
The ACC software shall calculate safe following distance as: d_safe = v × 2 seconds,
where v = vehicle speed (m/s).
- Input: Vehicle speed (m/s)
- Output: Safe distance (meters)
- Verification: Unit test

[SWE-045-4] Deceleration Control
When slowing to maintain following distance, the system shall limit deceleration
to ≤3 m/s² for driver comfort.
- Input: Target speed, current speed
- Output: Brake command
- Verification: Proving ground test (measure deceleration)

[SWE-045-5] Smooth Speed Transition
Speed changes shall use linear ramp (not step change) over ≥2 seconds.
- Input: Target speed change
- Output: Gradual throttle/brake adjustment
- Verification: Proving ground test (measure jerk ≤2 m/s³)

Summary

Requirements Engineering Process: Elicitation → Analysis → Specification → Validation → Management

Techniques: Stakeholder interviews, use case analysis, ambiguity detection, IEEE 830 template, review checklist, change control

Tools: DOORS (industry standard), Jama (modern), Excel (small projects)

Next: Architecture Decision Making (33.03) — How to make and document architectural trade-offs