Automotive Software Requirements Engineering: Core Concepts, V-Model & Traceability

How to Obtain User Requirements

Requirements engineering typically falls to product managers. The first step is customer interviews, but two caveats apply: customers may not know their true needs or cannot articulate them accurately, and they may hide or mislead due to vested interests. Therefore, we must work like business analysts: record stated requests, dig behind proposed solutions to uncover real needs, and iterate communication to clarify. Analysts need keen observation, thinking, and understanding — using eyes, ears, and brain. They should guide stakeholders to reframe problems via models and questions.

Ford example: Customers initially asked for a faster horse. By asking "why" repeatedly — why a faster horse? To arrive sooner. Why arrive sooner? To reach destinations in less time. The real need was faster travel, leading to the automobile.

What Is a Real Requirement

Teams often jump from vehicle feature definitions straight to solution design, or adopt agile iterations without writing requirements. The author argues all R&D must start from the problem, not the perceived solution. The task is to interpret stakeholder statements and extract the essential problem; the problem's essence remains invariant regardless of technical implementation.

ATM cash withdrawal: The essence is "securely obtaining payment capability." Security can be achieved without an ATM, enabling Alipay, palm-print payment, etc., which add convenience while preserving security.

What Is a System

Software requirements derive from system requirements. A system is a set of elements (machines, software, people) organized to achieve expected results (requirements). Components must interact via interfaces: human-machine, software-hardware, and software-software interfaces.

Systems exhibit emergence : effectiveness arises from interactions among elements, not from any single part. Emergence can be desired (planned) or undesired (unexpected side effects, e.g., dangerous vehicle behavior). Systems also have a system-of-systems property: each system is part of a larger outer system and depends on it. For example, a car needs roads with proper gradient and friction. The article prompts readers to consider a vehicle communication interface: its function is data transfer, its interfaces are various communication ports, its parent system is the vehicle EE architecture, and asks what its emergence is.

Exercise: Cup Requirements

A cup's utility depends on:

Functional properties emerging from component interactions.

Suitable interfaces with external components.

Correct embedding in the outer system — graspable by hand, liftable by arm.

Suitable environment; in weightlessness, alternative solutions are needed.

What Is Requirements Engineering

A requirement is a verifiable, measurable statement of a product's or process's operational, functional, design, or constraint characteristics. The key is discovering the real problem and delivering value.

Stakeholders are individuals, groups, or entities with direct or indirect interest in the system. They are legitimate sources of requirements; the most important is the purchaser (who pays for benefits). Knowing stakeholders helps in daily work and life.

US DoD 1991 definition: Requirements engineering encompasses all lifecycle activities aimed at identifying user needs, deriving additional needs through analysis, forming a requirements specification, and validating that specification against customer needs, plus the processes supporting these activities.

Requirements and Lifecycle

Because systems are systems-of-systems, traceability is essential. High-level stakeholder needs must be transformed down through system, subsystem, and component requirements. Every stakeholder requirement must have corresponding child requirements at lower levels; gaps or mismatches mean unmet needs.

Requirements engineering influences the entire development process end-to-end and top-down. The V-model views development by hierarchy; each level has its own concerns. For instance, customer needs relate to people, while system needs relate to electronic control systems and component connections. When design changes occur, requirements must be updated to reflect them; otherwise, downstream risks emerge. If a component's technology cannot meet its requirement, impact on upper-level requirements and ultimately customer needs must be analyzed.

Requirements Traceability

Traceability relationships can be one-to-one, one-to-many, or many-to-many. Tools like DOORS can manage these links. Two analysis activities are enabled:

Impact analysis : what happens if a requirement changes?

Source analysis : why does this requirement exist?

Because automotive development follows the V-process (requirements on the left, testing on the right), verification coverage analysis is also needed: check whether all requirements are covered and satisfied.

Requirements and Modeling

Misunderstandings across stakeholder levels are common. Modeling solves this by:

Helping stakeholders understand requirements.

Enabling most creative work during model construction.

Requirements development is like a sandwich, cycling between requirements, design, and requirements again. Each phase should model thoroughly to help engineers grasp the system and decompose current-level requirements to the next level. Activity diagrams, state diagrams, etc., act as snapshots showing increasing detail at each level.

Models help engineers:

Communicate with customers to build mutual understanding of the system-to-be.

Analyze the system to ensure desired emergence and avoid undesired emergence.

Derive next-level requirements and determine how to satisfy them.

Requirements and Testing

Verification is all activities aimed at detecting or preventing system defects , where defects are deviations from requirements. Verification includes reviews, inspections, analysis, component testing, and system testing. Correctness is not ensured by testing alone; early quality control (reviews, analysis) is crucial. The classic "test early, test often" applies to verification as well. The same functional issue can be caught in early design, design review, unit test, or system test. Early verification aligns with the V-model left side; later verification aligns with the right side.

Many companies focus only on requirements testing. A serious problem: if requirements are wrong or inconsistent, can testing find the issues? Even if found, the cost is far higher than catching them during early requirements analysis.

Requirements Process

Most requirements engineers work on system design and software requirements design. The ASPICE standard defines the requirements process, which follows the V-model: left side for requirements design, right side for testing. Beyond technical aspects, management concerns are vital: supplier interaction, project management, basic quality assurance. Thus requirements engineering demands both technical skill and organizational management capability.

Types of Requirements

To ensure completeness, requirements are categorized into three types:

Functional requirements : what the system must do — specific functions or behaviors. Externally seen as user needs; internally involve architecture, multi-level requirements design, load, power consumption, etc.

Quality requirements : how well the system performs — performance, reliability, safety, availability during faults, etc.

Constraints : external conditions or rules limiting design or implementation, usually non-negotiable. Mainly cost, regulatory, and process restrictions that must not be violated.

The article concludes with a preview of next week's topic: system context.