Why Requirements Engineering?
Why Requirements Engineering?
Requirements engineering is not bureaucracy — it is the foundation that connects a customer's need to the last line of tested code. In safety- and security-critical automotive software this chain must be complete, correct, and auditable. This module explains why, who is involved, and what standards demand.
1.1 The Role of Requirements in Safety-Critical Software
Modern automotive software controls safety-critical actuators — brakes, steering, power management — and runs in open-source collaborative environments where dozens of contributors work across organisational boundaries. Without a structured requirements process two problems become inevitable:
- No agreed specification — contributors implement different interpretations of the same need.
- No audit trail — safety and security auditors cannot verify that every standard requirement is addressed.
ISO 26262 (Part 8, SWE.1), ASPICE PAM 4.0, ISO/SAE 21434, and ISO PAS 8926 all iltiyexplicitly require a documented, traceable requirements hierarchy as a precondition for safety and security releases. Without it, certification is impossible.
The S-CORE Requirements Engineering process provides a single, standardised answer to both problems: a hierarchy of requirement levels with defined attributes, mandatory reviews, and automatic traceability links to code and tests.
1.2 Stakeholders and Their Information Needs
The requirements hierarchy must satisfy the needs of every stakeholder who will either write, review, implement, test, or audit requirements. The S-CORE process identifies the following key stakeholders:
| Stakeholder | Source ID | Role in S-CORE | What they need from requirements |
|---|---|---|---|
| Project Lead | rl__project_lead |
Defines platform specification and content, creates project timeline, tracks project progress | Clear stakeholder requirements as a project description |
| SW Architect | rl__committer |
Breaks down platform specification into features, derives feature/component architecture, allocates requirements to architecture elements, defines AoUs from architecture | Feature requirements and AoUs to drive architecture decisions |
| Tester | rl__committer |
Verifies that the specification is satisfied by the elements under test, considers AoUs for test case specification | Verifiable, testable requirements with traceability to test cases |
| Safety Architect | rl__safety_engineer |
Performs Dependent Failure Analysis, qualitative safety analysis (e.g. FMEA), initiates additional requirements and AoUs to cover failures | Requirements with safety attributes and independence information |
| Security Architect | rl__security_engineer |
Performs Trust Boundary Analysis, Defense in Depth Analysis, qualitative security analysis (TARA) | Requirements with security attributes |
| Module/Tooling SW Developer | rl__delivery_team |
Implements SW according to specification, creates traceability by linking specification to code, considers AoUs of other components, creates AoUs for the component under development | Component requirements with clear acceptance criteria |
| Feature User | (no formal role ID) | Gets detailed information on the specification of a feature, is informed about boundary conditions (AoUs) | AoUs — boundary conditions they must fulfil when using the SW |
| Platform SW Developer of the Reference Integration | rl__platform_team |
Implements requirements for reference integration | Component and feature requirements |
In S-CORE any Contributor may write a requirement, but every requirement must be approved by a Committer or Project Lead before it is merged. Safety and Security Managers provide support when their domain is involved.
1.3 Standard Connections
The S-CORE requirements process implements requirements from multiple standards simultaneously. Understanding these connections helps prioritise engineering effort.
| Standard | Relevant Clause | What it requires |
|---|---|---|
| ISO 26262 | Part 8, SWE.1 | SW requirements specification with safety classification, traceability, and review |
| ASPICE PAM 4.0 | SWE.1 | Elicitation, documentation, agreement, and traceability of SW requirements |
| ISO/SAE 21434 | §10.5.1 | Cybersecurity requirements derived from TARA, traceable through development |
| ISO PAS 8926 | §4.5.2.1 | To Be Defined |
A special requirement type that defines the boundary conditions the user of a software element must fulfil to ensure safe and secure operation. AoUs are exportable to integrators so they can include them in their own requirements management systems.
1.4 Roles and Approval Chains
The S-CORE process defines clear responsibility for each level of the hierarchy:
- Stakeholder requirements and SW-Platform AoU: Written by Contributor (
rl__contributor), approved by Project Lead (rl__project_lead), supported by Safety Manager (rl__safety_manager). - Feature requirements and Feature AoU: Written by Contributor (
rl__contributor), approved by Project Lead (rl__project_lead), supported by Safety Manager (rl__safety_manager) and Security Manager (rl__security_manager). - Component requirements and Component AoU: Written by Contributor (
rl__contributor), approved by Committer (rl__committer), supported by Safety Manager (rl__safety_manager) and Security Manager (rl__security_manager). - Tool/Process requirements: Written by Contributor (
rl__contributor), approved by Committer (rl__committer).
This separation ensures that the level of scrutiny matches the safety and security implications of the requirement.
Feature requirements describe platform-level integration behaviour and are visible to all users of the platform — they require Project Lead approval because they represent agreements between the platform team and its stakeholders.
Component requirements are implementation-specific and concern only the component team — Committer approval is sufficient, as Committers are the technical gatekeepers for their component.
Module Check-In
Answer all questions and click Submit to check your understanding.
Q1. Who is responsible for approving Feature Requirements in S-CORE?
Q2. Which standard requires SW requirements with a safety classification attribute, traceability, and formal review?
Q3. An integrator using an S-CORE platform component needs to know the boundary conditions they must satisfy for safe use. Which requirement type addresses this?