Requirements Engineering
for Automotive Embedded Systems
Miroslaw Staron
Abstract Requirements engineering is both a phase of software development
lifecycle and a subdomain of software engineering. In general, “requirements" is
defined as the description of the functionality of software under design and its
properties (functional and nonfunctional requirements). Requirements are often
perceived as textual documentation. However, in automotive software engineering,
requirements can have multiple forms—starting from the short textual descriptions
of functionality to fully executable model-based specifications.
In this chapter, we overview the notion of a requirement in general, and describe
the types of requirements used when designing automotive software systems. We
use the V-model, prescribed by the ISO 26262 safety standard, which describes
the way in which software is designed in the automotive domain. We consider the
different types of requirements used in these phases.
1 Introduction
Contemporary cars, trucks, buses, and even bikes have software—some as much
as 1 GB of onboard binary code excluding maps, music, and other downloadable
data. As the history of software dates back to the 1970s with the first onboard
Electronic Control Units (ECUs) in an engine, we could observe an enormous
growth of software. Up until the end of the 1990s, the amount of onboard code was
measured in megabytes, and only a few ECUs were present in the car. However, in
the last decade, this amount has grown to over 130 ECUs per car and as much as the
aforementioned 1 GB of code.
Moreover, software is included in more safety-critical areas, such as collision
avoidance by breaking, automatic parking, or autonomous driving. Therefore, we
need to enhance our expertise in working with software as one of the primary
M. Staron ()
Computer Science and Engineering, University of Gothenburg, Gothenburg, Sweden
e-mail: [email protected]
© Springer Nature Switzerland AG 2019 11
Y. Dajsuren, M. van den Brand (eds.), Automotive Systems and Software
Engineering, https://doi.org/10.1007/978-3-030-12157-0_2
12 M. Staron
development entities alongside mechanics and electronics. In this chapter, we focus
on one of these areas—requirements engineering. We contribute by providing prac-
tical examples of how to efficiently utilize requirements engineering for automotive
systems.
The area of requirements engineering is one of the disciplines in vehicle
development on the one hand, and, on the other hand, it is a subdomain of software
engineering and one of the initial phases of software development lifecycle. It
deals with the methods, tools, and techniques for eliciting, specifying, documenting,
prioritizing, and quality assuring the requirements. The requirements themselves
are very important in enhancing the quality of software in various ways as quality
is defined as “The degree to which software fulfills the user requirements, implicit
expectations and professional standards.” [16].
Requirements is often defined as (1) a condition or capability needed by a
user to solve a problem or achieve an objective; (2) a condition or capability
that must be met or possessed by a system or system component to satisfy a
contract, standard, specification, or other formally imposed documents; and (3) a
documented representation of a condition or capability as in (1) or (2) [16]. This
definition stresses the link between the user of the system and the system itself,
which is important for a number of reasons:
• Testability of the system—it should be clear how a requirement should be tested,
for example, what is the usage scenario realized by the requirement.
• Traceability of the functionality to design—it should be possible to trace which
parts of the software construction realize the requirement in order to provide
safety argumentation and enable impact/change management.
• Traceability of the project progress—it should be possible to get an overview
of which requirements have already been implemented and which are still to be
implemented in the project.
It is a very technical definition for something that is intuitively well known—a
requirement is a way of communicating what we, the users, want in our dream car.
In this sense, it seems that the discipline of requirements engineering is simple. In
practice, working with requirements is very complex as the ideas that we, users,
have need to be translated to one of the millions of components of the car and its
software. So, let us see how the automotive companies work with our requirements
or dreams.
We discuss software requirements engineering because the automotive industry
has recognized the need to shift its innovation from the mechanical parts of the
car to its electronics and software. The majority of us, the customers, buy cars
today because they are fast (sporty), safe, or comfortable. In many cases, these
properties are realized by adjusting the software that steers parts of the modern
cars. For example, we can have the same car with a software package that makes it
extremely sporty—look at the Tesla’s “Insane” acceleration package or the Volvo’s
Polestar performance package. These are just the two challenges which lead to two
very important trends in automotive software requirements engineering:
