Requirements Engineering for Autonomous Vehicles: A

Systematic Literature Review

Quelita A. D. S. Ribeiro Moniky Ribeiro Jaelson Castro
Universidade Federal de Pernambuco Universidade Federal de Pernambuco Universidade Federal de Pernambuco
Recife, Pernambuco Recife, Pernambuco Recife, Pernambuco
[email protected] [email protected] [email protected]

ABSTRACT ACM Reference Format:

Context: Autonomous Vehicles (AVs) will transform the way we Quelita A. D. S. Ribeiro, Moniky Ribeiro, and Jaelson Castro. 2022. Re-
quirements Engineering for Autonomous Vehicles: A Systematic Literature
live and work. Several benefits are envisaged, including: reduction
Review. In The 37th ACM/SIGAPP Symposium on Applied Computing (SAC
in traffic deaths, drop in harmful emissions, improvement in fuel ’22), April 25–29, 2022, Virtual Event, . ACM, New York, NY, USA, Article 4,
economy, reduction in travel time, and consumer savings. Indeed, 10 pages. https://doi.org/https://doi.org/10.1145/3477314.3507004
the trend in the automobile industry is the development of AVs
in preparation for the introduction and mass implementation of
driverless vehicles. However, given the complexity and increasing 1 INTRODUCTION
connectivity of the AV, the challenges for effective and efficient Autonomous Vehicle (AV) is a car that makes driving decisions
development are immense. Many problems are related to miscon- without the intervention of a human. As such, autonomy exists
ceptions in the requirements engineering phase for AVs. Hence, a in many aspects of a car today: cruise control and anti-lock brake
Requirements Engineering (RE) process is crucial in the develop- systems are excellent examples of systems that exhibit autonomous
ment of AVs. Objective: The purpose of this work is to identify behavior. Additional systems already exist on some models, includ-
and analyse the current RE approaches used for AVs development. ing advanced cruise control, lane maintenance support, lane change
The analysis is based on answers related to the type of RE problems warning and obstacle prevention systems, all of which expand the
addressed by the study, the RE phases covered by the approach, range of autonomous behavior [27].
requirements modelling styles used, the type of requirements de- The AV consists of orchestration of hardware components with
scribed in the study, the specific AVs considered in the study, and complex software implementations and multiple internal networks
the open problems reported. Method: We conducted a Systematic connecting intelligent sensor nodes with electronic control units
Literature Review (SLR) as the basis for our work. Results: Our and actuators. Therefore, many messages are exchanged within mil-
SLR draws on 31 studies in which we identified the RE problems liseconds [31]. Such connectivity and cooperation enable vehicles
addressed by the studies and the phases of the RE processes con- to connect with other road users and the infrastructure systems
sidered. We also uncovered the languages and description styles [32]. Furthermore, critical data dependencies exist, e.g., compo-
used to describe the requirementes of the AVs. Special attention nents that are mandatory for the core functionality of the vehicle
was paid to the non-functional requirements of interest. Different communicate with noncritical components that provide comfort
types of AVs were identified. Last but not least, several challenges features for the passengers [31].
were revealed. Conclusions: This paper reports the current state According to [39] automated driving will change the future’s
of the art of RE for AVs and identifies some open issues that deserve private transport and is currently the most discussed and disruptive
further investigation. technology in the automotive domain. Indeed, AVs are attracting
more interest with each passing day in the industry, as well as the
CCS CONCEPTS general public.
• Software and its engineering → Requirements analysis; • Given the long development time for an AV, it may take a con-
Applied computing → Transportation; siderable time before a prototype becomes available to experiment
with. Hence, it is important to get the requirements right from the
KEYWORDS beginning, because it contributes to reduce costs, resources, time,
and effort in the other phases of software development, mainly in
Autonomous Vehicles, Requirements Engineering, Systematic Lit-
the software development and testing. However, very few studies
erature Review.
have focused on expressing the requirements of AV at a high level.
Moreover, system building is subject to requirements change ac-
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
cording to the practice tests on the prototype. Therefore, a critical
for profit or commercial advantage and that copies bear this notice and the full citation issue is how to consider those changes and integrate them in the
on the first page. Copyrights for components of this work owned by others than ACM current specification [36].
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a It is well known that inappropriate RE practices may result in
fee. Request permissions from [email protected]. incomplete requirements, incorrect elicitation and specification,
SAC ’22, April 25–29, 2022, Virtual Event, high complexity, and economic or human loss. Hence, it is necessary
© 2022 Association for Computing Machinery.
ACM ISBN 978-1-4503-8713-2/22/04. . . $15.00 to investigate how RE is being adapted to deal Autonomous Vehicles
https://doi.org/https://doi.org/10.1145/3477314.3507004 to avoid inadequate or misunderstood requirements. RE for AV is

1299
SAC ’22, April 25–29, 2022, Virtual Event, Quelita A. D. S. Ribeiro, Moniky Ribeiro, and Jaelson Castro

Table 1: Research questions and motivations

Research Question Description and Motivation

RQ1. What are the problems of the AVs The purpose of this question is to identify problems/situations that are being addressed in the
that were addressed by the studies that RE process in AVs by requirements engineers and researchers. Hence, someone developing an
are related to requirements engineer- autonomous vehicle and facing a similar problem may benefit from the reported results.
ing?
RQ2. What phases of the requirements This question helps to identify the phases of the RE Process that are attracting more attention
engineering process have been sup- from the community and the ones that have been neglected. Hence, it indicates the coverage of
ported? the proposed approach as well which phases deserve more attention. It also may justify the
need to develop a more comprehensive RE Process or to extend a given approach to cover some
missing RE phase. The phases considered are in accordance with the Unified Requirements
Engineering Process Maturity Model (Uni-REPM 1 ).
RQ3. What requirements description Given that there are many ways to describe the requirements (text, goal oriented, scenario-
style are supported by the approaches? based, formal language, UML, logical description, etc.) it is important to find out the styles that
are attracting the most attention, the strengths, and weaknesses of each style in the field of
autonomous vehicles. Hence, it may help to identify popular requirements styles that are used
by the AV community. Descriptions in different styles could be mapped to the most popular
ones, helping to improve the communication among different professional teams.
RQ4. What are the non-functional Autonomous vehicles must meet several Non-Functional Requirements (NFRs) such as safety,
requirements supported by the ap- security, privacy, usability, etc. The purpose of this question is to identify the different types of
proaches? NFRs that are addressed by the studies. The reader will become aware of the several approaches
proposed to deal with the NFRs.
RQ5. What are the types of autonomous Given that there are many types of autonomous vehicles (such platoon, Cycab, AUTOelfe, Ego,
vehiches that were used in the RE etc.) with different levels of autonomy, it may be worth knowing if the approach proposed by
study/work? the study is a generic one or specially tailored for a specific type of autonomous vehicle. It may
be the case that a certain type of AV is more challenging than others.
RQ6. What are the RE challenges related The purpose of this question is to identify the open problems reported by the studies. This
to autonomous vehicles? information is useful for identifying gaps in current research and suggesting areas for future
research.

challenging since it has unique properties that make it complex, retrieval of information about the requirements. Furthermore, the
expensive and error-prone as compared with other categories, such autonomous vehicle is a novelty with several challenges and doubts.
as information systems [20, 30]. For that, we chose to conduct a systematic review in order to
The rising complexity of automated driving functions makes identify and report research that effectively supports the results of
it hard to define all concerning requirements in detail, formulate treatments in a given population, as described in [24]. Moreover,
the development goal in more than an abstract way, as well as the studies had their quality assessed and were evaluated in details
to estimate the development effort [39]. Therefore, requirements and the results synthesized.
engineering problems in the domain of AVs continue to occur de- Hence, this work aims to conduct a Systematic Literature Review
spite the efforts and advances in their understanding. Due to their (SLR), following the guidelines of [22], to identify and analyze the
properties, different approaches, methods, and tools are required RE approaches for AVs. In doing so, we investigate the RE research
to improve their quality. Some studies provide insights into the problems addressed by them. We want to find out which RE phases
practice of RE for AVs [10, 13, 35, 39]. However, to the best of our are attracting more attention to the AVs community. It is also impor-
knowledge there is no systematic attempt to perform an extensive tant to investigate the requirements modeling styles that are used in
identification at all stages of requirements engineering, mapping be- this domain. It is worth discovering whether the RE approaches for
tween functional and non-functional requirements, and constraints AVs have been deployed to manage functional and non-functional
of requirements approach for AVs. requirements and which non-functional requirements deserve spe-
Autonomous vehicles differ from other systems in that they have cial care.
several main concerns and their operation is dynamic, for example In this paper, we report the results of the SLR performed to
they need to comply with federal and state laws in their region. evaluate and synthesize the evidence available in the literature
In case the car leaves your region, any necessary changes must to answer research questions (see Table 1) related to the use of
be determined and integrated into the system as safety require- approaches, methods, techniques, and processes to support the RE
ments, including relevant speed limits, traffic signs and other signs. in the AVs domain.
Therefore, it is necessary to improve security analysis techniques, The results presented in this systematic review can be bene-
ethics, certification, transparency in the process due to a collision ficial to both researchers and practitioners (automotive industry
or other situation, traceability for specifying requirements and fast

1300
Requirements Engineering for Autonomous Vehicles: A Systematic Literature Review SAC ’22, April 25–29, 2022, Virtual Event,

team, requirements engineer, safety requirements engineer, secu- on terms presented in Table 2. We used the descriptive qualitative
rity specialists, designers, and developers) since it gathers evidence research for the qualitative analysis of the data.
from the primary studies included in the review, forming a body of In this paper, we want to collect information about requirements
knowledge regarding requirements engineering for AVs to improve engineering for AVs. Thus, we had focused on terms of the RE area,
the requirements process and reduce the risk of undetected errors autonomous vehicles, and kind of contribution.
and deficiencies. Our procedure for selecting studies consisted of six main steps,
The remainder of this paper is organized as follows: Section 2 as shown in Fig. 1.
presents related work. The research method adopted to conduct
the SLR is outlined in Section 3. The results and the analysis of our 3.1 Inclusion and exclusion criteria
research questions are described in Section 4. Finally, conclusions We are interested only in primary studies that contribute to require-
and future works are shown in Section 5. ments engineering for AVs in the English language, which satisfies
a minimum quality threshold.
2 RELATED WORKS Secondary studies, short papers (≤ 5 pages), studies that are not
related to research questions, non-peer-reviewed studies, duplicated
We did not find any systematic review related to requirements studies (only one copy of each study was included), non-English
engineering targeting autonomous vehicles. written papers, studies that do not discuss requirements engineering
The only systematic review we uncovered was aimed at investi- in AVs development, grey literature, redundant paper of the same
gating test coverage criteria for Verification and Validation (V&V) authorship, and ongoing work were considered exclusion criteria.
and ensuring the safety of AVs in software engineering [40]. The
authors also portray that one of the biggest obstacles for AVs to
reach public roads is the lack of public confidence in the safety Table 2: Terms of the search.
aspect.
We can note that despite the evolution, some features are still # Related words
poorly understood in the automotive industry of conventional vehi- (T1) ("requirements engineering" OR "requirements elicitation" OR "require-
ments analysis" OR "requirements specification" OR "requirements man-
cles. For example, the authors of [28] portray the difficulty in terms
agement" OR "requirements validation" OR "requirements verification"
of usability and the type of information automotive head-up dis- OR "requirements modeling" OR "requirements modelling")
plays (HUDs) should display in different situations to better serve (T2) ("autonomous vehicle" OR "autonomous driving" OR "autonomous fam-
the driver. For this reason, a systematic review was conducted to ily vehicle" OR "self-driving car" OR "automated driving" OR "automated
identify the functional requirements of automotive HUDs from the vehicle" OR "intelligent system" OR "cyber-physical vehicle" )
perspectives of the developer, researcher and user [28].
In contrast to other papers, our goal is to identify and analyse
the current RE approaches used for AVs development. Furthermore,
3.2 Quality assessment
we identify implications for practice and define a research agenda
for the RE community with a view to improve AV development. In order to avoid bias and maximize internal and external validity,
we performed a quality assessment (QA) of the selected studies. All
studies were assessed against a set of 8 quality criteria (See Table
3 RESEARCH METHOD 3). The source of the criteria is also identified, the quality scores for
In order to perform this SLR, we used guidelines and the proto- each criterion of the selected studies are available in Table 4.
col template proposed by Kitchenham, and Charters [24], whose We calculate the quality score of the studies using an arithmetic
𝑆𝑢𝑚𝑂 𝑓 𝑇 ℎ𝑒𝐴𝑛𝑠𝑤𝑒𝑟𝑠
process involves several activities grouped into three main phases: mean: 8 ∗ 100, where the numerator is the sum of
planning, conducting, and reporting of the review. It consists of all answers, and the denominator is the total of questions taken
the following steps: (1) identification of the need for a systematic into account in this quality assessment.
review, (2) development of a review protocol, (3) a comprehensive, We considered 60% as the minimum score for a study to accepted.
exhaustive search for primary studies, (4) quality assessment of in- The overall quality of the selected studies is acceptable since the
cluded studies, (5) data extraction and monitoring, (6) data analysis mean of quality is 72,98%. It is worth noting that all studies were
and synthesis, and (7) report-writing. accepted because their quality score were above 60%.
This SLR aims to identify and analyse the current RE approaches
for AVs. The analysis is based on RQs answers related to the type 3.3 Threats to validity
of RE problems addressed by the study, the RE phases covered We used the four categories of threats presented by [44], which in-
by the approach, requirements modelling styles used, the type of cludes construct, internal, external, and conclusion validity threats.
requirements described in the study, the specific AVs considered in Construct validity: According to [44], bias in the selection of
the RE study, and the open problems reported. studies and inaccuracy in data extraction are the main threats to
An automatic search was conducted in the following electronic the validity of systematic reviews. With the aim to avoid these
databases: ACM Digital Library, IEEE Xplore, Science Direct, Scopus, threats, we followed the guidelines provided by [22] to develop a
and Springer. reliable and auditable research protocol. The protocol was validated
The search period starts in 1970 and finished in December 21st, employing inspection and comparison between already published
2020. The search was executed in title, keywords, and abstract based SLR protocols as well as control papers. The search string of an SLR

1301
SAC ’22, April 25–29, 2022, Virtual Event, Quelita A. D. S. Ribeiro, Moniky Ribeiro, and Jaelson Castro

Figure 1: Systematic literature review steps. Adapted from [23].

Table 3: Quality assessment criteria.

# Questions Possible answer

1 Is there a rationale provided for why the study was undertaken? [15] Y=1, N=0, P=0.5
2 Is the paper based on research (or is it merely a lessons learned report based Y=1, N=0
on expert opinion)? [12]
3 Is there a clear statement of the goals of the research? [12] Y=1, N=0, P=0.5
4 Is the proposed approach clearly described? [3] Y=1, N=0, P=0.5
5 The research context was described at an adequate level (industry, laboratory Y=1, N=0, P=0.5
setting, products used and so on)? [3]
6 Is the study supported by a tool? [11] Y=1, N=0
7 Is there a clear description of the open issues related to the study that was Y=1, N=0, P=0.5
carried out?
8 Does the research also add value to the industrial community? [3] [12] Y=1, P=0.5
N = Not, P = Partial, Y = Yes

was evaluated several times to avoid the risk of omitting relevant decisions may have occurred since some papers did not provide a
studies and we used various synonyms of the search string terms to clear description of their objectives and results.
be able to cover the required papers. We also consider a period that External validity: We are concerned with the generalizability
encompasses all research in AV development, being that from 1970 of the SLR results, which is related to the degree to which the
to the present day. Another important threat was not performing primary studies are representative of the review topic. To mitigate
the snowballing search due to time constraints, which could com- external threats, the search was defined after several trial searches
promise the completeness of the results. Finally, another threat is and validated with the consensus of all authors. By choice of our
that due to resource limitations, not all aspects could be extracted exclusion criteria, we excluded gray literature papers. The analysis
from the data. For instance, variations of the "requirement" term in made by the three authors also improves the external validity by
search string could have been used to better serve non-traditional incrementally improving the quality of the dataset used to draw
development processes such as agile development. general conclusions.
Internal validity: We tried to mitigate threats due to personal bias Conclusion validity: The selection process and the inclusion and
on study understanding. The three authors are experts in require- exclusion criteria were carefully designed and discussed by authors
ments engineering. The first two are PhD students and the third to minimize the risk of exclusion of relevant studies.
one is an experienced reseacher, which increases the reliability of
the results obtained. However, during data extraction, subjective

1302
Requirements Engineering for Autonomous Vehicles: A Systematic Literature Review SAC ’22, April 25–29, 2022, Virtual Event,

Table 4: List of studies and quality scores.

Study Q1. Q2. Q3. Q4. Q5. Q6. Q7. Q8. Total Score Qual %
[2] 1 1 1 1 0.5 1 1 1 0,88 87,50
[10] 1 1 1 0.5 0 0 1 1 0,63 62,50
[13] 1 1 0.5 0.5 1 1 0 1 0,63 62,50
[37] 1 1 1 1 1 1 0 1 0,88 87,50
[39] 1 1 0.5 0.5 0 1 1 1 0,63 62,50
[42] 1 0 1 1 1 0 0 1 0,63 62,50
[21] 1 0 1 1 1 1 0 1 0,75 75,00
[20] 1 1 1 1 1 1 1 1 1,00 100,00
[31] 1 1 1 1 0 1 1 0.5 0,75 75,00
[17] 1 1 1 1 0.5 1 0.5 0.5 0,63 62,50
[26] 1 1 1 1 0 1 0.5 0.5 0,63 62,50
[5] 1 1 1 1 0 1 1 1 0,88 87,50
[30] 1 1 1 1 0 0 0 1 0,63 62,50
[18] 1 1 0.5 1 1 1 1 1 0,88 87,50
[32] 1 1 1 1 0 0 0 1 0,63 62,50
[19] 1 1 1 1 0.5 1 0 1 0,75 75,00
[34] 1 1 1 0.5 0 1 0 1 0,63 62,50
[4] 1 1 1 0 0 0 1 1 0,63 62,50
[1] 1 1 1 1 1 1 1 1 1,00 100,00
[43] 1 1 0 0 0 1 1 1 0,63 62,50
[33] 1 0 1 1 1 0 0 1 0,63 62,50
[35] 1 0 1 1 1 0 0.5 1 0,63 62,50
[14] 1 1 0.5 1 1 1 1 1 0,88 87,50
[25] 1 1 1 1 1 1 0 1 0,88 87,50
[9] 1 1 0 1 1 1 1 1 0,88 87,50
[16] 1 1 0 1 0.5 0 1 1 0,63 62,50
[7] 1 1 0.5 1 0.5 0 1 1 0,63 62,50
[6] 1 1 1 0 0 1 0 1 0,63 62,50
[36] 1 1 1 1 1 0 0.5 1 0,75 75,00
[29] 1 1 1 1 0 1 0.5 1 0,75 75,00
[38] 1 0.5 0.5 1 1 1 1 1 0,75 75,00

4 RESULTS AND ANALYSIS

In this section, we present the results and analysis of the selected
studies. We first provide general information about the studies such
as the year of publication, the context in which it was developed
and the evaluation method used. Then we answer the research
questions.

4.1 Publication year, context, and research

method.
According to Figure 2 the studies were published between 2009 and
December 2020.
The academic and industrial contexts were considered in this
classification. We classified twenty studies (64.5%) as a result of joint
work between academia and industry. Ten studies (32.3%) involved
only the academia and one study (3.2%) was developed exclusively
Figure 2: Temporal view of the studies.
at the industry. Hence, the industry is usually cooperating with the
academia in the investigation of RE for AVs.
We classified the research method of the publications according
to [11]. The majority of the papers are illustrative scenarios (17
4.2 RQ1. What are the requirements engineering
papers, 54.8%), followed by case study (10 papers, 32.3%), not ap- problems addressed by the studies?
plicable (3 papers, 9.7%), and controlled experiment (1 paper, 3.2%). We reviewed the RE problems considered by the studies. The results
We can observe that research in RE for AVs is focused on small of this question are depicted in Table 6. During this literature review,
examples and case studies to evaluate contributions (See Table 5). it was clear that the studies address RE using specific viewpoints,

1303
SAC ’22, April 25–29, 2022, Virtual Event, Quelita A. D. S. Ribeiro, Moniky Ribeiro, and Jaelson Castro

Table 5: Evaluation method. assurance activities within the data management and model learn-
ing phases. Risk assessment to derive security requirements for
Evaluation Method Freq. % automotive systems is addressed in [19]. While [17] focused on
the discovery of the user requirements and the specification of
Illustrative scenario 17 54.8%
the system requirements that will eliminate the problem of driver
Case study 10 32.3%
overload.
Not applicable 3 9.7%
Controlled experiment 1 3.2% Table 6: Problems in the RE process in AVs.

# Problems in the RE process in AVs Studies

[1] [10] [13]
and some papers are classified in more than one category. The [14] [18] [30]
1 Avs Complexity
authors discuss specific problems, and therefore, our classification [33] [35] [36]
included 7 RE problems. [38] [39] [42]
The most important problem addressed by the RE community is Variability, maintenance, reuse,
the complexity of AVs. Indeed, 12 studies (38.70%) mention the need 2 traceability or evolution [1] [2] [21]
for a new process, methodology, method, process, or framework of requirements [30] [34] [35]
(or improvement of an existing one) that can deal with the multi- [36] [37] [43]
faceted nature of AVs. 3 Safety and security alignment [4] [7] [20]
We were able to find few proposals aimed at specific aspects [25] [29] [31]
of RE for AVs. For example, a hybrid-agile process with shorter, [32]
predictable life cycles [13]; a proposal of a method to derive safety 4 Safety concerns [1] [5] [6] [9]
goals for automated driving systems [42]; an approach for scenario- [26] [42]
based systems engineering for automated driving functions [39]; a 5 Security concerns [19]
rigorous requirements engineering approach that integrates adapta- 6 Machine Learning in the RE [16]
tion and tailoring [36]; a proposal that provides a process to specify 7 Human requirements concerns [17]
in a flexible way a Cycab requirement model [35].
Nine studies (29.03%) indicate the need to support variability,
maintenance, reuse, traceability, and evolution of requirements.
For example, [43] helps the developer to define system objectives,
requirements and constraints at an early development phase. They 4.3 RQ2. What phases of the requirements
relied on scenario-based and executable behavior models that can engineering process were supported by the
be analyzed automatically; [2] supports the analysis and verification papers?
of functional and non-functional requirements; while [34] is aimed
The phases taken into account to answer this question are the
at scenario-based testing; [37] introduces variability at the early
following: Organizational Support, Requirements Process Manage-
phase of requirements engineering; and [1] proposes an automated
ment, Requirements Elicitation, Requirements Analysis, Release,
approach to detect undesired feature interactions in self-driving
Planning, Documentation and Requirements Specification, and Re-
systems at an early stage.
quirements Validation. These phases are the ones proposed in Uni-
Another important issue, mentioned in seven studies (22.58%), is
REPM2 (Universal Requirements Engineering Process Maturity
the need to align safety and security. We were able to uncover some
Model). Hence, the process described in each study was carefully
works addressing this issue. For example, [29] illustrates how GORE
checked to identity its coverage. The results of this question are de-
(Goal-Oriented Requirements Engineering) can cope with the co-
picted in Table 7. All requirements engineering phases are covered.
engineering of security and safety properties; while [7] describes
The predominant phase that we identified was Documentation
a Unified Safety and Security analysis method (US2) which uses a
and Requirements Specification (77.4 %), followed by Requirements
simple quantification scheme to assess safety hazards and security
Analysis (61.3%), Requirements Elicitation (51.6%), Requirements Val-
threats simultaneously; and [32] proposes a holistic approach to
idation (41.9%), Requirements Process Management (12.9%),Organi-
identify and analyze safety and security risk.
zational Support (6.5%), and Release Planning (6.5%). It is important
There are six (19.35%) studies only concerned with safety re-
to note that a study could have addressed more than one phase of
quirement. For example, in [6] a methodology is described where
the RE process.
formal models play a crucial role both for supporting the percep-
More than 77% of the studies address the Documentation and
tion of operational situations and for dynamically assessing the
Requirements Specification phase. This result is expected because
safety risks and planning the behaviors of AVs; and [26] proposes a
AVs need to be well documented. In fact, according to RQ3, they
semi-automatic safety analysis and optimization (SASAO) process.
are described in many different styes/languages (feature models,
Several issues are mentioned only by one study. For example,
textual requirements, goal-oriented, scenario-based, etc).
[16] focuses on the elicitation and analysis of Machine Learning
safety requirements and how such requirements should drive the 2 http://www.unirepm.com/publications.php

1304
Requirements Engineering for Autonomous Vehicles: A Systematic Literature Review SAC ’22, April 25–29, 2022, Virtual Event,

Table 7: Phases presents of RE. It is interesting to note in Table 8 that the number of studies on
a specific style exceeds the total number of studies because one
Phases/Stages Presents of RE Freq. % study can use several requirements description styles.
The predominant style identified was feature models followed
Documentation and Requirements Specification 24 77.4%
by textual requirements, goal-oriented, and scenario-based. The au-
Requirements Analysis 19 61.3%
tomotive sector has a well-planned software development process.
Requirements Elicitation 16 51.6%
Many models are developed to address specific safety and security
Requirements Validation 13 41.9%
concerns. Mainly because of auditing and certification. Because
Requirements Process Management 4 12.9%
of the need to express variability in the requirements, the use of
Organizacional Support 2 6.5%
feature models is quite common.
Release Planning 2 6.5%
Many authors considered the use of textual language to describe
the requirements, as it facilitates the communication between stake-
holders. This may be due to multi-disciplinar nature of development
team required to address several concerns of the automotive in-
dustry, such as security, safety, testers, auditors, and certification
The Requirements Analysis phase is also representative (61.3%) experts.
because many papers are concerned with the analysis phase. They Goal-oriented and scenario-based descriptions are also used by
examine how the high-level requirements are decomposed in detail, many studies to define the requirements of AVs.
identifying risks, determining unclear, incomplete, ambiguous, or The development of AVs requires stakeholders from different
contradictory requirements. Mainly analyzing safety requirements. expertise. Thus, a tool should be able to organize the specification in
The percentage of papers addressed in the Elicitation phase is a structured manner to help to cope with the different requirements
51.6%. Several studies investigate the issues and challenges of tra- expressed in different requirements languages.
ditional requirements elicitation techniques when applied to the
context AVs. 4.5 RQ4. What are the non-functional
The Validation phase is also addressed by a considerable num-
requirements supported by the approaches?
ber of studies (more than 40%). The safety critical nature of AVs
demands special care with the validation of the requirements. There- We were able to identify the non-functional requirements addressed
fore, the studies are interested in improving the RE process in order by the studies (See Table 9).
to support tests that are based on model and scenario-based descrip-
tions. Besides that, the review, audit, and inspection of procedures Table 9: Type of non-functional requirements.
are needed to avoid AVs accidents.
However, we can identify that little attention is given to the
requirements process management, organizational support, and Type of Requirements (non-functional) Freq. %
release planning phases. Safety 21 67.7%
Security 11 35.5%
4.4 RQ3. What requirements description style None 7 22.6%
Usability 3 9.7%
was supported by the approaches?
Privacy 2 6.5%
In order to guide our classification, we used seven requirements Law 1 3.2%
styles presented in the work of [11], except for Description logic Performance 1 3.2%
since it was discovered during the classification. The results pre- Reliability 1 3.2%
sented in Table 8 were defined according to the distribution of the Testability 1 3.2%
studies.

Table 8: Style of RE modeling. Safety and security requirements were the most cited among the
studies.
Style of RE Modeling Freq. % Some authors report the use in the AVs development of well-
Feature models 10 32.3% known safety analysis techniques such as FMEA, FTA, STPA, and
Textual requirements 7 22.6% HARA [6, 7, 9, 29]. Other researchers proposed new approaches
Goal-oriented 7 22.6% based on these frameworks and also ISO 26262 [26, 32]. It is inter-
Scenario-based 6 19.4% esting to note that some works are integrating security and safety
Description logic 2 6.5% issues relying on ISO 26262 and SAE J3061 [5, 19, 25].
Non-specific 2 6.5% AVs are also subject to cyber attacks which can expose personal
UML 1 3.2% information on other connected devices. Hence it deserves to be
explored more rigorously. In fact, vehicle security requirements is
already attracting much attention (35.5% of studies).

1305
SAC ’22, April 25–29, 2022, Virtual Event, Quelita A. D. S. Ribeiro, Moniky Ribeiro, and Jaelson Castro

Some papers did not mention non-functional requirements (22.6%)

because they only directed their research to functional require-
ments.
Three papers cited usability because the authors focused on
the requirements for users concerning automated functions, au-
tonomous taxi, and family vehicle (for children, the elderly, or
people with disabilities).
Other three non-functional requirements (performance, relia-
bility, and testability) were mentioned only by a single study. In
section 4.7 we discuss some challenges related to non-functional
requirements.

4.6 RQ5. What are the types of autonomous

vehicles?
The answer to this question may help to recognize which type of AV
attracts more attention concerning requirements engineering. The Figure 3: Autonomous vehicles.
classification was based on the analysis of the vehicles investigated.
Some AV types found in the analyzed papers are defined below:
• A platoon consists of some vehicles, it maintains a constant
speed for all vehicles in the platoon, and can safely reduce the be used to discuss the existing problems with the stakeholders of
distance between vehicles in the platoon. The leader vehicle autonomous vehicle [43].
is driven manually by a human driver to ensure conformance Integrate communication for a multidisciplinary team: The
with laws. AV industry must address several concerns, such as security, safety,
• Cycab is a public vehicle with automated driving capabilities. privacy, usability, legal requirements. Thus, it often relies on a mul-
Automated functions are advanced driver assistance systems. tidisciplinary team, consisting of engineers, designers, developers,
• AUTOelfe is an autonomous taxi, a family car that can be testers, auditors, and certification experts. Hence, it may face many
used independently even by those who cannot drive a con- communication obstacles. As shown in Table 8, different require-
ventional car. ments modelling styles are used. The challenge is to integrate these
• Level-4 AD (defined by SAE J3016 3 ) indicates that the driver different perspectives of the system. For example, it could be worth-
is not required under certain conditions. while to consider the usefulness of scenario descriptions together
• Ego is an autonomous vehicle used for tests, experiments or with goal models to describe the requirements of AVs [38], as well
scenarios. as the definition a coherent set of extensions to foster goal model-
According to Figure 3, we can see that 11 different types were ing of AVs [10] in connection with textual requirements. A future
identified. The most frequent type is Generic (11 papers, 35.5%) concern is related to automated generation of scenarios that could
followed by Ego vehicle (5 papers, 16.1%), Platoon (5 papers, 16.1%), be used in the validation and verification phases [39]. Likewise, in
Cycab vehicle (3 papers, 9.7%), and Automated functions, car of sim- order to facilitate the communication among stakeholder the combi-
ulation, Wheel loaders, Trucks, AUTOelfe, Intelligent Transportation, nation of natural language and model based requirements could be
and Level-4: SAE J3016 (1 paper each, 3.2%). We can note that the considered [14]. However, the mapping from the requirements into
majority of the studies are general purpose. However, if a reader the software design could be facilitated if a formal requirements
is interested in a specific type of AVs (eg. Platoon) some specially language was used [36].
tailored approaches are available. Formulation of safety & security requirements: In relation
to safety concerns, further investigation is required to incorporate
fault injection analysis to add security aspects. It may include formal
4.7 RQ6. What are the RE challenges related to
safety contracts (assumptions & guarantees) to describe dynamic
autonomous vehicles? behavior to support the analysis of functional insufficiencies of
Despite the significant progress reported in the studies, there are AVs [26]. Another challenge is to consider both the formulation of
several weaknesses that still need to be addressed. technical security requirements at the system level, as well as in
Evaluation in real settings: AV is known for its high complex- hardware and software.
ity, the increasing number of functions and the escalating number Evaluation of AV safety & security requirements: A better
of interactions between different functions. However, most research understanding and evaluation of AV safety & security requirements
in RE for AVs was evaluated using simple scenarios. Hence, there is necessary [19]. Current approaches only partially address the
is a need to evaluate them in real settings with real users during security threats and safety hazards present in the AVs. The reuse
complex AVs development. In particular, it is important to uncover of security & safety solution knowledge may help to reduce the
errors or inaccuracies in the requirements as these findings can engineering effort [20]. This may be achieved by the creation of
catalogues of threat and failure modes [32]. Such information will
3 https://www.sae.org/blog/sae-j3016-update improve the understanding of the threats and vulnerabilities of

1306
Requirements Engineering for Autonomous Vehicles: A Systematic Literature Review SAC ’22, April 25–29, 2022, Virtual Event,

existing components and systems and their cyber-physical impli- because [5] is only focused on Safety & Security co-engineering,
cations. It is worth noting that security is also an important con- while [39] aims at driving functions.
sideration for safety of the intended functionality. Therefore the Lack of a specific requirements engineering process for
co-engineering of safety and cybersecurity needs to consider the AVs. We did not find a well-defined, standardized, and known re-
potential adversarial impact on the environment of the AV [5]. It is quirements engineering process to guide companies. Hence, there
necessary to analyze the consequences when a new vulnerability is a need to investigate and develop a specific requirements engi-
or attack vector is identified in the AV domain [32]. It also needs to neering process that consider all aspects of AVs requirements.
consider compliance and certification obligations [29]. It is likely To improve the specification and analysis of the NFRs. De-
that other initiative for RE in safety critical domains, such as [41], spite the current contributions to ameliorate the non-functional
could be applied in the domain of AVs. requirements problem, several open issues are to be solved. Mainly
Use of Machine Learning (ML) for safety requirements: because few studies mention transparency, usability, privacy, law,
Another important line of research is the use of Machine Learning performance, reliability, testability. Besides, for users to trust and
(ML) for safety requirements in the data management and model be willing to buy and use AV, the system must be transparent and
learning phases [16]. However, it is not clear how this approach allow users to ask for information, such as why the AV decided
can be extended to consider machine learning verification and to break instead of turning, informations about accidents, injuries,
deployment, which are two crucial aspects for a compelling safety and death where the police will want to evaluate the guilt [8].
case. To consider RE standards. There are different requirements
Traceability between product and process requirements: engineering standards such as IEEE Std 29148:2011, ISO/IEC 15408,
Given that AVs are safe critical system, if an accident happens and ISO 26262, ISO PAS 21448, ISO/IEC/IEEE 15288, SAE J3061, and
software is to blame, it is of paramount importance for the manu- IEEE Std 830:1998. Nevertheless, most RE approaches for AVs are
facturer or suppliers to quickly identify the problem and implement not compatible with them.
a fix that does not create additional problems. But this requires an Need for industry evaluation. Despite the emerging interest
effective traceability support system [21]. However, with a higher of the community to investigate requirements engineering for AVs,
volume of updates on increasingly complex AVs, traceability is go- there is still a need to implement the new proposals described in
ing to be more difficult to manage and more important to maintain. the studies in real industry projects with real users to improve and
So, the challenge is to support the traceability between product and assess the relevance of the research.
process requirements from standards to the implemented develop- Motivated by the results of this SLR, we propose a research
ment process [37]. agenda for the RE community that is aimed at the AVs domain:
AVs evolution: Last but not least, we must address the issue
(1) How can we develop an RE process tailored for AVs that
of AVs evolution. AVs are developed as product lines and features
address organizational support, process management, elici-
and subsystems reuse common core sets of functionalities. Hence,
tation, analysis, release planning, documentation and speci-
it is important to consider the problem of evolution management
fication, and validation phases?
from a more holistic perspective where consistency among different
(2) What is the core set of information that requirements engi-
heterogeneous models must be verified [30].
neers should consider in AVs development?
(3) What are the main requirements engineering patterns and
how they can be used in an RE process for AVs?
5 CONCLUSIONS (4) What are the requirements and constraints needed to develop
In this work we presented the results of a Systematic Literature a tool capable of dealing with integration with other tools
Review conducted to investigage how Requirements Engineering that support all RE phases for AVs?
is being applied to Autonomous Vehicles. (5) How to measure the feasibility of using requirements engi-
Our SLR draws on 31 studies, selected out of 1068 over 50 years, neering approaches for AVs?
through a multi-stage process. Thus, it gives us more profound in- (6) What are the primary non-functional requirements, and how
sights into the state-of-the-art content of requirements engineering are they related to AVs functions?
for AVs. (7) How to improve the maturity level of requirements engi-
We identified the problems addressed by the studies as well as the neering processes for AVs?
phases of the RE processes that are attracting more attention. We
also revealed the languages and description styles used to specify In future work, we intend to create a methodology that encom-
the requirementes of the AVs. The most frequent non-functional passes the activities included in the RE phases for AV, considering
requirements were also pinpointed, differrent types of AVs were the safety analysis based on STPA. Requirements description style
recognized. Finally, several challenges were disclosed. is still being discussed, but we want to use a language that is easy for
The most relevant findings from this review and their implica- stakeholders to understand. Finally, we will evaluate the methodol-
tions for further research are as follows: ogy in the industry in order to improve the research and receive
Requirements engineering phases. The majority of studies feedback from engineers.
only partially address RE process phases. Only two studies [5]
[39] considered all seven phases, indicating that few approaches 6 ACKNOWLEDGMENTS
consider the whole RE process. However, they are quite limited, This work was partially supported by CNPq, CAPES, and FACEPE.

1307
SAC ’22, April 25–29, 2022, Virtual Event, Quelita A. D. S. Ribeiro, Moniky Ribeiro, and Jaelson Castro

REFERENCES [22] Staffs Keele. 2007. Guidelines for performing systematic literature reviews in
[1] Raja Ben Abdessalem, Annibale Panichella, Shiva Nejati, Lionel C Briand, and software engineering. In Technical report, Ver. 2.3 EBSE Technical Report. EBSE.
Thomas Stifter. 2018. Testing autonomous cars for feature interaction failures [23] Barbara Kitchenham, O Pearl Brereton, David Budgen, Mark Turner, John Bai-
using many-objective search. In 2018 33rd IEEE/ACM International Conference on ley, and Stephen Linkman. 2009. Systematic literature reviews in software
Automated Software Engineering (ASE). IEEE, 143–154. engineering–a systematic literature review. Information and software technology
[2] Dhaminda B Abeywickrama, Nicola Bicocchi, Marco Mamei, and Franco Zam- 51, 1 (2009), 7–15.
bonelli. 2020. The SOTA approach to engineering collective adaptive systems. [24] B. Kitchenham and S Charters. 2007. Guidelines for performing Systematic
International Journal on Software Tools for Technology Transfer 22, 4 (2020), 399– Literature Reviews in Software Engineering.
415. [25] Georg Macher, Alexander Much, Andreas Riel, Richard Messnarz, and Chris-
[3] Philip Achimugu, Ali Selamat, Roliana Ibrahim, and Mohd Naz’ri Mahrin. 2014. tian Kreiner. 2017. Automotive SPICE, safety and cybersecurity integration. In
A systematic literature review of software requirements prioritization research. International Conference on Computer Safety, Reliability, and Security. Springer,
Information and Software Technology 56, 6 (2014), 568–585. 273–285.
[4] Adina Aniculaesei, Jörg Grieser, Andreas Rausch, Karina Rehfeldt, and Tim [26] Peter Munk, Andreas Abele, Eike Thaden, Arne Nordmann, Rakshith Amarnath,
Warnecke. 2018. Toward a holistic software systems engineering approach for Markus Schweizer, and Simon Burton. 2018. Semi-automatic safety analysis and
dependable autonomous systems. In 2018 IEEE/ACM 1st International Workshop optimization. In Proceedings of the 55th Annual Design Automation Conference.
on Software Engineering for AI in Autonomous Systems (SEFAIAS). IEEE, 23–30. 1–6.
[5] Robert Bramberger, Helmut Martin, Barbara Gallina, and Christoph Schmittner. [27] Umit Ozguner, Christoph Stiller, and Keith Redmill. 2007. Systems for safety and
2020. Co-engineering of safety and security life cycles for engineering of auto- autonomous behavior in cars: The DARPA Grand Challenge experience. Proc.
motive systems. ACM SIGAda Ada Letters 39, 2 (2020), 41–48. IEEE 95, 2 (2007), 397–412.
[6] DeJiu Chen, Fredrik Asplund, Kenneth Östberg, Eugene Brezhniev, and Vy- [28] Juhee Park and Woojin Park. 2019. Functional requirements of automotive head-
acheslav Kharchenko. 2015. Towards an ontology-based approach to safety up displays: A systematic review of literature from 1994 to present. Applied
management in cooperative intelligent transportation systems. In International ergonomics 76 (2019), 130–146.
Conference on Dependability and Complex Systems. Springer, 107–115. [29] Christophe Ponsard, Gautier Dallons, and Philippe Massonet. 2016. Goal-oriented
[7] Jin Cui and Giedre Sabaliauskaite. 2018. US2: An Unified Safety and Security co-engineering of security and safety requirements in cyber-physical systems. In
Analysis Method for Autonomous Vehicles. In Future of Information and Commu- International Conference on Computer Safety, Reliability, and Security. Springer,
nication Conference. Springer, 600–611. 334–345.
[8] Luiz Marcio Cysneiros, Majid Raffi, and Julio Cesar Sampaio do Prado Leite. [30] Sudha Ramesh, Birgit Vogel-Heuser, Wanli Chang, Debayan Roy, Licong Zhang,
2018. Software Transparency as a Key Requirement for Self-driving Cars. In 26th and Samarjit Chakraborty. 2017. Specification, verification and design of evolv-
International Requirements Engineering Conference (RE). IEEE, 382–387. ing automotive software. In Proceedings of the 54th Annual Design Automation
[9] Youssef Damak, Marija Jankovic, Yann Leroy, and Bernard Yannou. 2018. Analysis Conference 2017. 1–6.
of safety requirements evolution in the transition of land transportation systems [31] Rhea C Rinaldo and Timo F Horeis. 2020. A Hybrid Model for Safety and Security
toward autonomy. In 15th International Design Conference-DESIGN 2018, Vol. 6. Assessment of Autonomous Vehicles. In Computer Science in Cars Symposium.
2845–2854. 1–10.
[10] Marian Daun, Viktoria Stenkova, Lisa Krajinski, Jennifer Brings, Torsten [32] Christoph Schmittner, Zhendong Ma, Erwin Schoitsch, and Thomas Gruber. 2015.
Bandyszak, and Thorsten Weyer. 2019. Goal modeling for collaborative groups A case study of FMVEA and CHASSIS as safety and security co-analysis method
of cyber-physical systems with GRL: reflections on applicability and limita- for automotive cyber-physical systems. In Proceedings of the 1st ACM Workshop
tions based on two studies conducted in industry. In Proceedings of the 34th on Cyber-Physical System Security. 69–80.
ACM/SIGAPP Symposium on Applied Computing. 1600–1609. [33] Tobias Schräder, Torben Stolte, Inga Jatzkowski, Robert Graubohm, and Markus
[11] Diego Dermeval, Jéssyka Vilela, Ig Ibert Bittencourt, Jaelson Castro, Seiji Isotani, Maurer. 2019. An approach for a requirement analysis for an autonomous family
Patrick Brito, and Alan Silva. 2015. Applications of ontologies in requirements vehicle. In 2019 IEEE Intelligent Vehicles Symposium (IV). IEEE, 1597–1603.
engineering: a systematic review of the literature. Requirements Engineering [34] Barbara Schütt, Thilo Braun, Stefan Otten, and Eric Sax. 2020. SceML: a graph-
(2015), 1–33. ical modeling framework for scenario-based testing of autonomous vehicles.
[12] Tore Dybå and Torgeir Dingsøyr. 2008. Empirical studies of agile software In Proceedings of the 23rd ACM/IEEE International Conference on Model Driven
development: A systematic review. Information and software technology 50, 9 Engineering Languages and Systems. 114–120.
(2008), 833–859. [35] Farida Semmak, Christophe Gnaho, Joêl Brunet, and Régine Laleau. 2009. How
[13] Otto Emmerich, Huaji Wang, Guillermo Garcia, Ilaria Pezzulla, Alexander Dar- to Adapt the KAOS Method to the Requirements Engineering of Cycab Vehicle..
lington, and Bo Gao. 2020. A Systems Engineering Framework and Application to In ENASE. 87–94.
an Open Automated Driving Platform. In IECON 2020 The 46th Annual Conference [36] Farida Semmak, Christophe Gnaho, and Régine Laleau. 2009. Extended kaos
of the IEEE Industrial Electronics Society. IEEE, 2393–2398. method to model variability in requirements. In Evaluation of Novel Approaches
[14] Markus Fockel. 2016. ASIL Tailoring on Functional Safety Requirements. In to Software Engineering. Springer, 193–205.
International Conference on Computer Safety, Reliability, and Security. Springer, [37] Farida Semmak, Régine Laleau, and Christophe Gnaho. 2009. Supporting variabil-
298–310. ity in goal-based requirements. In 2009 Third International Conference on Research
[15] Matthias Galster, Danny Weyns, Dan Tofan, Bjoern Michalik, and Paris Avgeriou. Challenges in Information Science. IEEE, 237–246.
2014. Variability in software systems—a systematic literature review. Software [38] Irish Singh and Seok-Won Lee. 2017. Self-adaptive requirements for intelligent
Engineering, IEEE Transactions on 40, 3 (2014), 282–306. transportation system: A case study. In 2017 International Conference on Informa-
[16] Lydia Gauerhof, Richard Hawkins, Chiara Picardi, Colin Paterson, Yuki Hagiwara, tion and Communication Technology Convergence (ICTC). IEEE, 520–526.
and Ibrahim Habli. 2020. Assuring the safety of machine learning for pedestrian [39] Christoph Sippl, Florian Bock, Christoph Lauer, Aaron Heinz, Thomas Neumayer,
detection at crossings. In International Conference on Computer Safety, Reliability, and Reinhard German. 2019. Scenario-based systems engineering: an approach
and Security. Springer, 197–212. towards automated driving function development. In 2019 IEEE International
[17] Andreas Gregoriades, Jack Hadjicosti, Christos Florides, Maria Pampaka, and Systems Conference (SysCon). IEEE, 1–8.
Harris Michail. 2015. A driving simulator for discovering requirements in complex [40] Zaid Tahir and Rob Alexander. 2020. Coverage based testing for V&V and Safety
systems. In Proceedings of the Conference on Summer Computer Simulation. 1–10. Assurance of Self-driving Autonomous Vehicles: A Systematic Literature Review.
[18] Rong Gu, Eduard Enoiu, and Cristina Seceleanu. 2020. TAMAA: UPPAAL-based In 2020 IEEE International Conference On Artificial Intelligence Testing (AITest).
mission planning for autonomous agents. In Proceedings of the 35th Annual ACM IEEE, 23–30.
Symposium on Applied Computing. 1624–1633. [41] Jéssyka Vilela, Jaelson Castro, Luiz Eduardo G Martins, and Tony Gorschek. 2018.
[19] Mafijul Md Islam, Aljoscha Lautenbach, Christian Sandberg, and Tomas Olovs- Safety Practices in Requirements Engineering: The UNI-REPM Safety Module.
son. 2016. A risk assessment framework for automotive embedded systems. In IEEE Transactions on Software Engineering 46, 3 (2018), 222–250.
Proceedings of the 2nd ACM International Workshop on Cyber-Physical System [42] Fredrik Warg, Martin Skoglund, Anders Thorsén, Rolf Johansson, Mattias
Security. 3–14. Brännström, Magnus Gyllenhammar, and Martin Sanfridson. 2020. The quan-
[20] Sergej Japs. 2020. Security & Safety by Model-based Requirements Engineering. titative risk norm-a proposed tailoring of HARA for ads. In 2020 50th Annual
In 2020 IEEE 28th International Requirements Engineering Conference (RE). IEEE, IEEE/IFIP International Conference on Dependable Systems and Networks Workshops
422–427. (DSN-W). IEEE, 86–93.
[21] Henning Jost, Silke Köhler, and Frank Köster. 2011. Towards a safer development [43] Carsten Wiecher. 2020. A feature-oriented approach: from usage scenarios to
of driver assistance systems by applying requirements-based methods. In 2011 automated system of systems validation in the automotive domain. In Proceed-
14th International IEEE Conference on Intelligent Transportation Systems (ITSC). ings of the 23rd ACM/IEEE International Conference on Model Driven Engineering
IEEE, 1144–1149. Languages and Systems: Companion Proceedings. 1–6.
[44] C Wohlin, P Runeson, M Host, MC Ohlsson, B Regnell, and A Wesslen. 2000.
Experimentation in software engineering: an introduction. 2000.

1308