#  Requirements Strategy for Managing Human Factors in Automated Vehicle
Development

Amna Pir Muhammad12 *  —, Alessia Knauss3 *  —, Eric Knauss12 *  —, and Jonas
Bärgmann1 *  —
1Chalmers University of Technology 2 University of Gothenburg, 3Zenseact AB
Gothenburg, Sweden

###### Abstract

The integration of human factors (HF) knowledge is crucial when developing
safety-critical systems, such as automated vehicles (AVs). Ensuring that HF
knowledge is considered continuously throughout the AV development process is
essential for several reasons, including efficacy, safety, and acceptance of
these advanced systems. However, it is challenging to include HF as
requirements in agile development. Recently, Requirements Strategies have been
suggested to address requirements engineering challenges in agile development.

By applying the concept of Requirements Strategies as a lens to the
investigation of HF requirements in agile development of AVs, this paper
arrives at three areas for investigation: a) ownership and responsibility for
HF requirements, b) structure of HF requirements and information models, and
c) definition of work and feature flows related to HF requirements. Based on
13 semi-structured interviews with professionals from the global automotive
industry, we provide qualitative insights in these three areas. The diverse
perspectives and experiences shared by the interviewees provide insightful
views and helped to reason about the potential solution spaces in each area
for integrating HF within the industry, highlighting the real-world practices
and strategies used.

###### Index Terms:

Requirements Engineering, Automated Vehicles, Human Factors, Agile
Development, Requirements Strategy

##  I Introduction

Human factors (HF), a multidisciplinary field focusing on understanding the
interactions between humans and other system elements, plays a pivotal role in
the design and development of user-centric, safe, and effective automated
vehicle (AV) technology [1], including supervised and unsupervised automation.
User-centric here means, for example, that the AV technology is predictable,
comfortable, acceptable, and trustworthy.

_Human factors requirements_ refer to those requirements that are primarily
introduced due to HF and are essential in this context. A HF requirement could
be that an AV should move to the lane’s edge when detecting an oncoming truck,
addressing human comfort aspects.

Despite the recognized importance of HF in system development, its integration
into the complex and multidimensional environment of AV development [2, 3, 4],
especially within agile frameworks [5], remains challenging. For example, it
has been reported that tech leaders and project managers might underestimate
the impact of human-related factors, focusing instead solely on technical
challenges [6]. In our experience, this oversight is partially due to the
technology driven nature of AV development, where the driving task is
increasingly perceived as disconnected from humans, focusing instead on
computer based automation. Thus, companies tend to embrace data-driven
approaches while also adopting more agile and iterative development paradigms.
However, this may lead to underestimating the role of humans and their
capabilities and limitations as constraints for the overall system. This
underestimation and the inherent complexities of agile methodologies, which
emphasize speed and flexibility, often lead to insufficient considerations of
HF in the development process and threatens the safety and success of AV
Systems. Recognizing this gap, there arises a critical need for a structured
approach to ensure that HF requirements are consistently and effectively
integrated. This is where the concept of Requirements Strategies comes into
play, providing a systematic framework for aligning requirements integration
with the dynamic and iterative nature of agile development [7].

The Requirements Strategy provides a guideline to integrate requirements
engineering practices effectively within agile workflows [7]. The core purpose
of this framework is to bridge the gap between high-level organizational
objectives and the specific requirements engineering activities needed to
achieve these objectives. This framework facilitates building a shared
understanding of the problem space and requirements among all stakeholders
involved and to integrate it into a development workflow. The Requirements
Strategy framework consists of three main building blocks: an organizational
perspective, a structural perspective, and a work and feature flow
perspective. Each of these perspectives contributes to creating a holistic
understanding and effective management of requirements.

In this qualitative study, we examine the integration of HF requirements
through the lens of Requirements Strategies. Our objective is to evaluate the
effectiveness of Requirements Strategies in facilitating this integration. For
this purpose, we formulated three research questions, each focusing on a main
building block of the Requirements Strategy.

  * RQ1

Organizational perspective: How do ownership and responsibility for HF
requirements impact their integration in product development?

  * RQ2

Structural perspective: How does the structure of requirements and information
models impact the integration of HF requirements in product development?

  * RQ3

Feature and workflow perspective: How does defining a work and feature flow
related to HF requirements influence their integration in product development?

For each question, we propose propositions based on common believes in
existing literature. These propositions serve as fundamental hypotheses that
guide our analysis, shaping the way we approach and interpret our findings.
This method helps us to thoroughly examine and apply different aspects of HF
within the lens of Requirements Strategy. Using this theoretical framework, we
conducted 13 semi-structured interviews with professionals from the global
automotive industry.

Our findings reveal diverse perspectives on the proposed propositions. While
some cases lend support to our propositions, others suggest that these methods
(e.g., requirements decomposition, traceability, assigning HF expertise to
critical roles) may not be as effective as anticipated. The universal
acceptance of these requirements practices as described in the literature and
within the framework of Requirements Strategy, is inconclusive in our context.
These mixed views highlight the necessity for additional research to further
explore these findings, but also the need for organizations to define a
consistent Requirements Strategy within the identified solution spaces.

The remaining paper is organized as follows: Section II depicts the background
and anchors our propositions in prior related research. Section III outlines
the research methodology, also addressing potential threats to the validity of
the results. The findings are presented in Section IV. Section V engages in a
discussion of these findings. Finally, the paper concludes with Section VI.

##  II Background

###  II-A Human Factors in Automotive Industry

The concept of HF is pivotal in AV development. According to Muhammad et al.,
“the field of _Human Factors in AV Development_ aims to inform AV development
by providing fundamental knowledge about human capabilities and limitations
throughout the design cycle so the product will meet specific quality
objectives” [8].

HF experts concentrate on understanding the full spectrum of human attributes,
including cognitive, physical, behavioral, psychological, social, emotional,
and motivational aspects [1]. This understanding is vital for designing AVs
that are trustworthy, comfortable, effective, and safe as well as deliver a
satisfying and aesthetically pleasing experience for all stakeholders, as
noted in [3]. The insights into human capabilities and the objectives of AV
design are disseminated through various means including design principles,
training programs, selection processes, and effective communication
strategies. This dissemination is an ongoing necessity, integral to the
comprehensive development and refinement of AV systems, throughout the AV
design cycle.

In Table I, we provide specific examples of functionality of (conditionally)
automated vehicles together with some important HF aspects for which HF
requirements are crucial. Note that these are examples relating to AV features
of different levels of automation that are typically engineering and
technology driven, and not to human machine interface (HMI) design. While the
design of the latter typically includes HF experts, the former are usually
designed and developed in agile teams without integrated HF experts. Also,
note that studies have shown a misalignment between engineers’ judgments and
users’ trust in automation [9].

TABLE I: Examples on Human Factors and its impact on AV Design Lane-Keeping:
Designing and developing a lane-keeping feature presents substantial HF
challenges. For instance, automated lane keeping should be designed to
minimize the risk of motion sickness [10], while avoiding making interactions
with other road-users uncomfortable - for the AV users as well as for other
road-users. An example related to user discomfort is that the AV can position
itself in the lane in a way that minimizes perceived risk [11]. Further, the
implemented lane-keeping strategy (e.g., the level of lane-centering) affects
the user’s acceptance and trust in the system [12]. That is, HF requirements
include ensuring the lane-keeping algorithm facilitates smooth and predictable
movements [13] while incorporating algorithms to maintain safety during close
encounters with other vehicles.
---
Lane change: Lane changes must be made in a safe, predictable, comfortable,
and acceptable way, for both the users of the AV and for surrounding traffic
[14]. Based on user studies, HF requirements may here be operationalized
through functional requirements. That is, there may, for example, be specific
timings of turn-signal initiations and trajectory shapes that make users (and
surrounding traffic) feel that a lane change is predictable and feels
comfortable, which in turn facilitates acceptance.
Collision Avoidance System Interaction: In scenarios where the collision
avoidance system intervenes to prevent crashes, the timing and nature of the
intervention are crucial. For example, nuisance interventions (i.e., when a
user does not feel an intervention is warranted) should be kept to a minimum
[15], while the intervention should be made early enough to avoid crashing.
Considering driver comfort zone boundaries [16] in collision avoidance design
can improve performance while keeping the nuisance intervention rate low.
Therefore, the collision avoidance algorithm should strike a balance between
early intervention (i.e., optimal crash avoidance) and minimizing driver
nuisance (e.g., based on driver comfort zone boundaries). Examples of HF
requirements in this case include seamless interventions to maintain passenger
trust in the vehicle’s safety capabilities, avoiding behaviors that may induce
discomfort or distrust.
Driver Monitoring System: Driver monitoring systems can be used both to
mitigate inattention and distraction in lower levels of automation [17], and
to assess if the driver is ready to take over when an AV issues a take-over
request (ToR) in higher levels of automation [18]. Both uses are intended to
improve safety. For the former, designing warning or intervention strategies
that minimize driver nuisance is crucial for acceptance, while it for both is
important to consider driver variability and human capabilities. HF
requirements on driver monitoring systems may therefore relate to how and when
to provide information to drivers (e.g., warnings or ToRs).

Note that this study focuses on HF relevant to the product design and users,
not the developers of these systems.

#### HF Integration in AV Development

The integration of HF in the automotive industry has emerged as a critical
area of focus. Research, as highlighted in studies such as Lee et al. [3] and
Hancock [19], underlines the vital role of HF in automated system design. This
is especially relevant given the increasing complexity of technology and the
imperative need for enhanced user safety. Researchers have studied various key
aspects, including the interaction between AVs and human drivers [20], how
humans engage with and disengage from these systems [21], the design of HMI
[22], and the maintenance of situational awareness [23]. These studies are
foundational in comprehending HF’s role in elevating the user experience (UX),
ensuring safety, and fostering trust and acceptance of AVs.

Despite this, the practical application of HF knowledge often remains limited
to specific scenarios or design solutions, usually integrated into the design
process or the requirements specification. A gap persists in understanding how
HF research insights are effectively translated into the agile development
processes of AVs, signaling an area ripe for further exploration and
application.

#### Agile Methodologies and HF Integration

The challenge of integrating HF into agile development processes in the
automotive sector remains a relatively under-explored area, with limited
studies specifically addressing this context. Saghafian et al. [24] describe
the conflict between the swift and adaptable nature of agile methodologies and
the comprehensive, often time-intensive demands of HF practices in immersive
visual technologies field. Steinberg and Grumman’s study [25] offers valuable
perspectives on modifying agile frameworks to better incorporate HF
considerations. Muhammad et al. emphasize the role of cross-functional
collaboration in successfully integrating HF [8, 5].

These research works highlight the challenges arising from inadequate
collaboration and communication among engineering, design, and HF teams, which
can hinder the effective integration of HF in development processes. They
stress the necessity of establishing robust communication channels and
collaborative structures within organizations to facilitate this integration.
However, specific discussions on integrating HF in agile contexts, as outlined
in our research, are relatively less explored and represent a contribution to
the field.

###  II-B Requirements Strategy and Proposition Formulation

The concept of a Requirements Strategy allows to reason on a high level of
abstraction about how requirements engineering is covered in agile and hybrid
software and systems development [7]. This is particularly applicable since
all case companies are agile to some degree; thus, traditional processes do
not suffice to express the concepts we need. Its primary purpose is to
establish a clear and shared understanding of both the problem space and the
corresponding requirements. A Requirements Strategy comprises three core
building blocks: an organizational, a structural, and a work and feature flow
perspective.

#### Organizational Perspective

This perspective in requirements management concentrates on defining teams’
roles, responsibilities, and the ownership of different types of requirements.
This aspect is critical for the effective integration and management of
requirements in product development [7].

A crucial element of requirements management is the clear definition of roles
and responsibilities. Wiegers and Beatty [26] emphasize the importance of
clearly defining roles and responsibilities in the requirements management
process. The significance of assigning clear ownership to each requirement is
highlighted by Cagan [27], who argues that this clarity fosters accountability
and greatly influences project success. Cockburn [28] discusses the importance
of ownership in agile environments, arguing for a more collaborative and less
‘siloed’ approach. The literature vividly highlights the importance of role
clarity and responsibility in requirements management. This understanding
leads to the formulation of our first proposition, emphasizing the impact of
clear ownership on HF requirements integration in product development:

  * •

_Proposition 1:_ Clear ownership and responsibility for HF requirements
positively impact the integration of HF in product development

Paasivaara and Lassenius [29] discuss the integration of clear roles and
responsibilities within agile methodologies, showing how agile practices can
be adapted to improve the management of requirements in dynamic environments.
Rubin [30] provides insights into the role of product owners in guiding agile
teams, hinting to the importance of critical roles in clear ownership in
product development. Aurum and Wohlin [31] contend that such assignments
facilitate better decision-making and accountability, leading to more
effective management of requirements and resource allocation, thereby
contributing to the overall quality and success of the product. Thus, our
literature review indicates that if organizations aim to support managing HF
knowledge in a Requirements Strategy from an organizational perspective, HF
expertise should be assigned to roles that are critical for the agile
development workflow, such as product owners. We formulate our Proposition 2
as follows:

  * •

_Proposition 2:_ Clear ownership and responsibility for HF requirements
requires to assign HF expertise to critical roles

#### Structural Perspective

This perspective focuses on defining requirements levels, types, and
traceability demands, ensuring clarity and structure in how requirements are
approached and documented [7].

Hull et al.[32] emphasize the pivotal role of clear and structured
requirements for successful project outcomes. This approach was further
refined by Davis [33], who differentiated user and system requirements, thus
initiating a nuanced understanding of requirements levels. Wiegers and Beatty
[26] expanded on this by categorizing requirements into business, user, and
software types, offering a comprehensive framework for large-scale project
management. The emphasis on traceability in the structural perspective aligns
with the principles outlined by Gotel and Finkelstein [34] and Rupp et al.
[35]. They advocate for bi-directional traceability, ensuring that each
requirement is linked to its origin as well as the implementation. Literature
underscores the importance of well-structured requirements, emphasises
traceability, and requirements decomposition. This need for clarity and
structure in managing requirements structurally informs our next set of
propositions:

  * •

_Proposition 3:_ Clear HF requirements structure positively impacts the
integration of HF in product development

  * •

_Proposition 4:_ Clear HF requirements traceability positively impacts the
integration of HF in product development

  * •

_Proposition 5:_ Clear decomposition of HF requirements with respect to
organizational levels positively impacts the integration of HF in product
development

#### Work and Feature Flow Perspective

This perspective focuses on defining the lifecycle of requirement types and
mapping them to the workflow, ensuring that requirements are effectively
integrated into the agile development process [7].

The significance of adaptability and iterative development in managing complex
requirements is a cornerstone in this context. Authors such as Van Der Vyver
et al. [36] and Schwaber and Beedle [37] highlight the importance of being
responsive to changing requirements. Cohn and Ford [38] further elaborate on
this by discussing the dynamics of incorporating requirements into agile
processes, setting a foundation for understanding the adaptability of agile
frameworks to these changes. Schwaber and Beedle emphasize the importance of
well-defined requirements for the success of agile projects, highlighting the
need for a common understanding among stakeholders and interdisciplinary
collaboration [37, 39]. Rubin further elaborates on this by presenting a model
for managing requirements’ lifecycle in agile environments, stressing
continuous integration and iterative development as central to agile
methodologies [30]. Moreover, research on project management practices
highlights that a clear definition of work streams improves project outcomes
[40]. The role of review and reflection is highlighted as a critical element
in agile development. Sutherland and Schwaber [41] emphasize the importance of
regular review meetings, such as Sprint Reviews, for assessing progress and
integrating evolving requirements. These reviews are evaluative and play a
crucial role in adapting and refining requirements based on ongoing feedback.
Leffingwell [42] extends this notion by advocating for a systematic review
strategy to enhance requirements quality and maintain team engagement with
evolving changes, reinforcing Schwaber and Beedle’s focus on continuous
improvement [37].

In summary, literature underscores the dynamic nature and lifecycle in agile
development. Additionally, the importance of defining clear work streams and
the need for regular reviews and reflections are emphasized. These insights
inform our final propositions:

  * •

_Proposition 6:_ A strong lifecycle model of HF requirements positively
impacts the integration of HF requirements in product development

  * •

_Proposition 7:_ A clear definition of a HF work stream in relation to other
work streams positively impacts the integration of HF requirements in product
development

  * •

_Proposition 8:_ A clear plan for review and reflection of HF requirements
positively impacts the integration of HF requirements in product development

##  III Methodology

This study adopts a qualitative research design, utilizing a priori coding to
analyze semi-structured interview data. The approach was chosen to
systematically categorize and interpret the experiences and insights of
professionals in the automotive industry. Central to our method was the
formulation and examination of propositions (Section II-B) for each of our
research questions, which guided our data collection and analysis process.

###  III-A Data Collection

TABLE II: Interviewees’ roles and work experience (Experience level: Low= 0–5 years, Medium=5–10 years, High= More than 10 years) ID |  Role |  Experience Level |  Supplier/OEM |  Agile Methodologies Usage
---|---|---|---|---
01 |  Senior Manager |  High |  OEM |  Some projects adopt agile methodologies, while others follow traditional approaches
02 |  Technology Leader HF & Automation |  High |  Supplier & OEM |  Some projects adopt agile methodologies, while others follow traditional approaches
03 |  Senior HF Specialist |  High |  Supplier & OEM |  Using SAFe methodology
04 |  Engineering Manager |  High |  OEM |  Using agile practices
05 |  HF expert |  Medium |  Supplier |  Agile methodologies are employed for software aspects, while hardware components follow a more traditional approach
06 |  Chief Expert HMI |  High |  Supplier |  Utilizes agile methodologies variably across projects and business units
07 |  HF Expert |  High |  Supplier |  Using agile practices
08 |  Software Developer |  High |  OEM |  Fully committed to SAFe methodology
09 |  Requirements Engineering Researcher & Tester |  High |  OEM |  Operates in a hybrid manner
10 |  HF Specialist & Automation and control engineer |  Low |  OEM |  Embraces agile approaches in their tasks, although the organizational structure remains non-agile
11 |  AD Safety Specialist |  High |  Supplier |  Engages in partial agility, incorporating agile practices, particularly in project execution, but not fully aligned with agile principles in strategic aspects
12 |  Senior Technical Specialist |  High |  OEM |  Majority of projects are developed using agile methodologies
13 |  Global Agile Process Lead |  High |  Supplier |  Adopted a framework based on SAFe principles

#### Semi-Structured interviews

Data were collected through 13 semi-structured interviews. This format was
specifically chosen to probe the propositions related to each research
question. Each interview lasted approximately 50-60 minutes. Given our intent
to include companies from various global locations, virtual interviews were
the most feasible approach. Consequently, 11 interviews were conducted using
Microsoft Teams or Zoom video calls, while 2 interviews were conducted in
person. The interviews were recorded with the participants’ consent and later
transcribed verbatim for analysis.

Prior to the interviews, we provided details about the current study
objectives, mutual expectations and high-level questions. Each interview began
with an introduction to the authors and an overview of the project, outlining
the study’s purpose and objectives. We then started with demographic
questions, followed by more targeted questions about the integration of HF in
automotive development, directly relating to our propositions. Interview
questions were grouped in relation to the building blocks of Requirements
Strategies, and in each block we asked for an assessment on how well the
interviewee experiences their context to perform with respect to these
aspects. The interview questions used can be found here. All participants have
experience working within agile methodologies to varying degrees. While some
have fully embraced agile practices, others have incorporated agile
methodologies to a lesser extent.

#### Sampling Strategy

Our selection criteria included respondents with expertise in HF who are
employed in the automotive industry. Specifically, we focused on those experts
who have a close working relationship with requirements or process design.
Consequently, all our participants had knowledge of HF. Given our broader
focus on investigating the integration of HF expertise in development
processes in general, we did not delve into detailed discussions about
specific types of HF. Instead, we relied on participants’ overall
understanding of HF and their involvement in key aspects such as requirements
and design. This approach enabled us to capture a broad perspective on the
role of HF across various domains within the automotive industry.

The sampling included individuals who could provide in-depth and specialized
knowledge pertinent to our research objectives - based on the author contacts
and by using LinkedIn to screen for potential candidates. We reached out to
professionals from various automotive companies, selecting those who met our
criteria and were willing to participate. This approach ensured rich,
qualitative data from a diverse range of experts in the field.

In total, we conducted 13 interviews with professionals from 12 different
companies, including industry leaders like Mercedes-Benz, and Volvo. Each
participant was assigned a unique identifier (ID01 through ID13) to maintain
confidentiality. In order to recruit these 13 participants, we contacted 39
suitable candidates, often with several reminders. We believe that the low
response rate may indicate a particularly high workload among the population
of suitable candidates. We would have preferred more participants to ensure
that theoretical saturation was reached but had to stop our recruiting
efforts. From the analysis of our results, we do not believe that additional
interviews would significantly change our results (later interviews tend to
bring up sentiments that were similarly mentioned before) and report our
findings now to enable future research in this important field. An overview of
these participants, highlighting their roles and levels of experience, can be
found in Table II.

###  III-B Data Analysis

The data analysis was structured around our a priori coding framework, with
three codes per proposition (supports, neutral, rejects). These codes were
applied to the interview transcripts through line-by-line reading, assigning
relevant codes to specific statements. The initial codes were identified
before data collection and were refined as the analysis progressed. We adopted
Saldana’s guidelines for coding as outlined in [43]. The analysis process
involved:

  1. 1.

Familiarization with the data through repeated reading of the transcripts

  2. 2.

Applying the a priori codes to the data

  3. 3.

Ensuring consistency across transcripts and refining the coding
framework/guidelines as necessary

  4. 4.

Interpretation of the data in the light of our propositions and the broader
study context

The use of a priori coding facilitated a structured and theory-driven
analysis. This approach not only ensured a systematic examination aligned with
the study’s goals but also accommodated the emergence of new insights.

To ensure uniform understanding and application of the codes, two of the
authors were involved in coding. While the first author coded all data, a
second author coded a subset until we were satisfied with the inter-rater
agreement. For this purpose, we relied on Cohen’s Kappa [44] and iterative
coding, evaluation, and improvement of coding guidelines until we reached
substantial consensus (Kappa above 0.6).

###  III-C Research Validity

To ensure the validity of the study, careful consideration was given to four
key aspects: credibility, transferability, dependability, and confirmability.

Credibility, which pertains to the truthfulness and believability of the
findings, faced potential threats due to the possibility of participant bias
in semi-structured interviews. Participants might tailor their responses based
on what they perceive the researcher wants to hear, which could lead to skewed
data. To mitigate this threat, we ensured to have sufficient time to reach an
understanding with interviewees and by asking similar questions from different
perspectives.

Transferability, or the extent to which the study’s findings can be applied to
other contexts, was challenged by the unique and specific contexts of the
professionals interviewed. Since these individuals might not represent the
entire automotive industry, there was a risk of limited generalizability. To
mitigate this threat, we collected demographics and additional information
about each interviewee’s context. We use this information in our
interpretation of the results and discussion of their implications.

Dependability, which concerns the stability of the data over time, was
threatened by the rapidly evolving nature of the automotive industry. As the
industry changes, the study’s findings might lose relevance. To ensure
dependability, a detailed documentation of the research process and the
decision-making in coding and theme development was maintained. This approach
not only enhances transparency but also allows the research process to be
replicated and critiqued by others. Additionally, consistency in data
collection and analysis methods was rigorously maintained.

Finally, confirmability, the degree to which the findings are shaped by the
respondents and not researcher bias, was a concern. The subjective
interpretation of data by researchers could potentially lead to biased
conclusions. This was addressed by maintaining a reflexive journal throughout
the research process, documenting our thoughts, reflections, and potential
biases. We also ensured reliability of coding, by leveraging inter-rater
agreement for iterative improvement of coding guidelines. Furthermore, there
is a threat that interviewees and researchers have different understandings of
critical aspects, such as HF. We tried to mitigate this threat through careful
sampling and by adopting a dialogue-based interview style rather than a strict
question-answer style. This allowed us to identify potential misunderstandings
early and to recover during the interview. These practices helped in
maintaining objectivity and transparency in the research.

##  IV Findings

The summary of the interviewees’ stances on our propositions, along with a
representative quote, can be found here. Figure 1 offers a visual overview of
the findings. In the figure, we derive the solution space from our findings
below.

Figure 1: Overview of findings: Propositions P1 to P8 in relation to RQs (in
different colours: RQ1 - purple, RQ2 - red, RQ3 - blue); propositions for
which interviewees expressed a mix of positive and neutral sentiments have
green summary boxes, while propositions that also received negative sentiments
have yellow boxes.

###  IV-A RQ 1: How do ownership and responsibility for HF requirements impact
the integration of HF requirements in product development?

The first research question addresses the organizational aspect of the
Requirements Strategy and investigates propositions related to the impact of
clearly defined ownership and responsibility on the integration of HF in AV
development.

#### Proposition 1: Clear ownership and responsibility for HF requirements
positively impact the integration of HF in product development

The findings support the proposition, with mostly positive, but also neutral
sentiments among interviewees.

Many interviewees highlighted defined roles and responsibilities that
positively impact the integration of HF in product development, such as the
role of a product owner, specialized HF expert or HF team. These roles, as
described by interviewees, foster clarity in communication, responsibility
allocation, and overall integration of HF into the development cycle.

For instance, the beneficial influence of assigning HF responsibility to a
product owner is illustrated by ID01’s experience, where a product owner with
UX expertise was able to effectively integrate HF into the development
process:

> _“We hired a product owner who is also a UX person, so she is halftime
> product owner, half-time UX… So they’re pulling it…the team is basically
> specifying those requirements.”_ — ID01

Similarly, ID04 described a situation where the product owner sets general
priorities, while specialists like designers handle detailed aspects of HF.
This clear division of responsibility and ownership is exemplified by direct
communication between designers and engineers about specific details:

> _“So the priorities, the overall topics were decided by the product owner,
> but when it came to the nitty-gritty details, it was directly the designer
> coming to the engineers…”_ — ID04

However, several interviewees maintained a neutral stance, discussing various
aspects of HF integration and role responsibilities without explicitly
supporting or rejecting the proposition. For example, ID05 commented on the
integration of HF optimization into developers’ responsibilities, indicating a
more distributed approach to HF management.

> _“Optimization with respect to HF is a task that becomes integrated into the
> developer’s responsibilities.”_ — ID05

Overall, the data supports Proposition 1, showing that clear ownership and
responsibility for HF requirements positively influence the integration of HF
in product development. However, the effectiveness of this integration may
vary depending on the organizational structure and specific approaches adopted
by different teams or departments.

#### Proposition 2: Clear ownership and responsibility for HF requirements
requires to assign HF expertise to critical roles

Complementary to Proposition 1, we investigate here whether ownership and
responsibility should be assigned to critical roles in the development
lifecycle, by making sure that these roles possess HF expertise. In this
context, ‘critical roles’ refer to key positions that significantly influence
the direction and success of a project. These roles typically include
positions like product owners, portfolio owners, or other decision-making
positions.

The interview data provides a nuanced view on the proposition that assigning
HF expertise to critical roles is pivotal for clear ownership and effective
management of HF requirements in product development. Most interviewees are
positive or neutral, but there are two interviewees that take a rejecting
stance.

The support to this proposition is evidenced by numerous instances where
integrating HF expertise into critical roles enhanced the management and
implementation of HF requirements. The interviewees reveal a trend of merging
HF expertise with critical roles such as product owners. For instance, ID13
emphasizes the importance of product owners possessing HF knowledge to
effectively guide development teams:

> _“That product owner… should then also consider… human factors and the human
> behaviors.”_ — ID13

Similarly, ID08 discusses the responsibilities of portfolio owners:

> _“The portfolio owner, overseeing a range of products, plays a crucial role
> at a very high level. Their responsibility is not just to ensure that we
> meet customer requirements, but also to define and offer products that
> deliver value to customers.”_ — ID08

While designers and engineers can also be considered to be critical roles, we
did not count such sentiments as clear support, since the need to have HF
expertise covered so broadly shows that, depending on the context, it is more
complicated than to just centralize it at selected critical positions. This
interpretation is also supported by other responses that hint towards a
distributed approach to HF responsibility, challenging the notion that clear
ownership and responsibilities for HF requirements should be confined to
specific critical roles. As for example, mentioned by ID12 and ID05, which
contradicts the proposition’s focus on assigning HF expertise to specific
critical roles.

> _“The human factors team… they are responsible for all of those elements…
> including in some cases the design of the actual system itself.”_ — ID12

> _“You cannot really form a group of people, only doing this… Everybody could
> have some opinion on HF issues.”_ — ID05

In summary, our data presents a nuanced perspective. While there is
substantial support for the proposition that assigning HF expertise to
critical roles enhances the management of HF requirements, evidence also
points to the effectiveness of a distributed or collaborative approach in
certain contexts. This suggests that while assigning HF expertise to critical
roles can be beneficial, it may not be the only effective approach for
managing HF requirements across different organizational settings.

###  IV-B RQ 2: How does requirements structure and requirements information
model impact the integration of HF requirements in product development?

The second research question examines how the structuring of HF requirements
and the development of information models influence the integration of HF in
AV development, assessing the structural part of the Requirements Strategy.

#### Proposition 3: Clear HF requirements structure positively impacts the
integration of HF in product development

We find this proposition rather supported, with four positive and eight
neutral sentiments among interviewees, but no rejections (one skipped this
topic).

Several interviewees highlighted the beneficial impact of a well-defined
requirements system on integrating HF in product development. The frequent
mention of tools that are used to document requirements and tasks related to
requirements for HF such as JIRA, Doors, and Code Beamer underscores their
essential role in organizing HF requirements. These tools are key in
establishing a structured environment conducive to HF integration. For
example, ID04 emphasizes the effectiveness of a requirements tool for
documenting HF aspects, indicating its importance in integrating these factors
into product workflows. This highlights the crucial role of structured
documentation systems in embedding HF considerations into product development
processes.

> _“In this tool, we documented all the requirements [including design and
> HF]. We used this as a documentation tool. I’m not sure if that’s good or
> bad, but that’s how it was used… I think that the requirements structure
> worked really well.”_ — ID04

Similarly, ID07 described a structured documentation practice for HF studies,
indicating a systematic approach that could enhance HF integration in
development processes.

> _“We communicate through these channels, and then we maintain comprehensive
> documentation of all work that has transpired, including detailed accounts
> of how studies were conducted and their findings and results.”_ — ID07

ID12’s shift towards a human-centered design philosophy, with centrally
managed requirements, aligns with the proposition, indicating the benefits of
a clear, organized structure.

> _“We have implemented a requirements management system for storing all
> requirements… [This system is part of] centralizing our design philosophy
> around being human-centered… everything now stems from this centralized
> approach…”_ — ID12

In contrast to those who highlight explicit consideration of HF and human-
centric considerations when designing the requirements documentation
structure, other interviewees indicate that a generic requirements structure
and tool environment can be sufficient or even preferred. This suggests that
specific support for HF considerations is not needed or not beneficial in
certain contexts.

> _“Partly they are part of the overall documentation environment…there should
> not be any specific other kind of documentation.”_ — ID06

Moreover, ID13 speaks to the inclusion of HF within a unified requirements
database, lending support to the proposition through a comprehensive approach.

> _“I would say that it is a part of all other requirements in the requirement
> database.”_ — ID13

Conversely, some responses highlight challenges in the current documentation
systems, suggesting that clear requirements structures are not universally
effective or consistently utilized. ID09, for instance, points out a
deficiency in HF documentation:

> _“Human factors requirements are typically not documented explicitly
> upfront.”_ — ID09

ID05 addresses challenges concerning the flexibility and practicality of
detailed requirements structuring and documentation systems, emphasizing the
extra workload for developers and the difficulty of adapting them in rapidly
evolving, innovative settings.

> _“Documentation is seen as extra work for the developers… everyone deems it
> as an added task, leading to a general reluctance towards anything
> additional.”_ — ID05

The data presents a composite view. Evidence supports the proposition that a
clear requirements structure facilitates the integration of HF into product
development, as evidenced by the formal and centralized approaches of some
interviewees. This is also indirectly supported by quotes that indicate
difficulties when a clear requirements structure is missing. It is however
unclear whether this structure must explicitly accommodate HF considerations
or should be generic in nature. The diversity in practices among interviewees
suggests that the impact of a clear requirements structure might be influenced
by other variables, such as organizational culture or the unique nature of the
project.

#### Proposition 4: Clear HF requirements traceability positively impacts the
integration of HF in product development

The findings indicate a diverse range of practices regarding HF requirements
traceability across various organizations. This variability reflects
differences in both the implementation and the perception of the importance of
traceability in integrating HF into product development.

For example, ID01 notes the use of traditional documentation and linking with
testing activities, which implies a level of traceability that could support
HF integration.

> _“That describes HF requirements and then from those documents there’s some
> testing… So there’s a process for that.”_ — ID01

ID06 describes a careful documentation process for high-complexity systems,
indicating that in certain contexts, there is clear traceability of
requirements, including HF aspects:

> _“If we are looking at a, let’s say a part with the compnay’s responsibility
> and higher complexity….. It [traceability] is extremely carefully taken on
> all steps of the requirements, it’s in the setting…[this includes] clear
> documentation of possible issues, records of test outcomes, software version
> histories, and all these things.”_ — ID06

A notable number of interviewees remained neutral. Their responses ranged from
acknowledging the use of tools like JIRA for managing requirements to
expressing indifference towards the specific traceability of HF requirements.
As, for example, ID08 reflects on their organizational structures, which,
while not specific to HF, are applied to all requirements. This approach
suggests an integration of HF requirements into existing models, but the
effectiveness and clarity of these traceability methods are not specified:

> _“SAFe gives that structure in general, it’s not specific for HF, but we
> applied the same structure for all requirements.”_ — ID08

Moreover, ID10 noted the absence of specific traceability models or processes
for HF requirements. This lack of specialized traceability mechanisms could
imply a gap in effectively integrating HF in product development.

> _“ We don’t have any traceability whatsoever.”_ — ID10

In contrast to the indicators above, some interviewees suggest that
traceability does not directly impact the integration of HF in product
development. For example, ID05 and ID07 argue that traceability is used for
system level reporting and not directly useful for product developers,
effectively rejecting our proposition.

> _“…traceability…more or less only for reporting, not useful for
> developing.”_ — ID05

> _“The levels, how you define this is more or less useless for the
> development.”_ — ID07

In summary, the mixed responses from the interviewees illustrate the varied
perspectives on the role of traceability in HF requirements integration. While
some see clear benefits in traceability for ensuring thorough documentation
and process adherence, others view it as having limited practical value in the
actual development process. This diversity in opinions suggests that the
effectiveness of HF traceability may be highly contextual and dependent on the
organizational practices and the nature of the product development processes.

#### Proposition 5: Clear decomposition of HF requirements with respect to
organizational levels positively impacts the integration of HF in product
development

The interview data presents a mixed perspective on the Proposition.

Several interviewees expressed support for the proposition, indicating that
decomposing HF requirements across different organizational levels is crucial
for their effective integration into product development.

For example, ID12’s insights shed light on the decomposition of various
requirements under a human-centered design philosophy, which reinforces this
proposition. Their approach suggests that systematically addressing HF
requirements substantially enhances their integration into product
development.

> _“At the highest, we go quite deep into the human and understand the
> requirements of the human and whether they be physical or cognitive and then
> they are used to guide specific requirements which are then decomposed into
> the engineering requirements that are used to deliver the car….So the
> typical and hierarchical level approach”_ — ID12

Similarly, ID13’s emphasis on iterative design and user stories further aligns
with this perspective, indicating that decomposing HF requirements into
manageable parts facilitates improved understanding and implementation:

> _“Then we can quickly move forward and break that down into the different
> level of requirements. Implement, test, and validate and come back to you in
> two or three weeks.”_ — ID13

ID09 details a clear multi-level decomposition process, reinforcing the
proposition:

> _“We treat our initial requirements as level one. These are then further
> decomposed into level two, or system requirements, which may differ from the
> conventional use of the term. Sometimes, there’s even a third or fourth
> level for specific needs like FPGA. Generally, we operate with these three
> levels”_ — ID09

However, ID05 and ID08 take a rejecting stance and noted challenges or
alternative perspectives. ID05, for example, points out the complexities of
decomposing HF requirements in innovative fields like autonomous driving:

> _“In at least in the new area, in the autonomous driving area… You cannot
> really decompose the requirement at the beginning because you don’t know
> what the technique can do, what the sensor can see, what the system is
> capable of.”_ — ID05

ID08’s observations suggest variability in the application of structured
decomposition across different organizations:

> _“I would say we don’t have the structure as you would probably want to see
> it…At the moment we don’t have a standardized taxonomy or something like
> that.”_ — ID08

Some interviewees remained neutral, neither supporting nor rejecting the
proposition outright. As, for example, ID07’s comment implies a more adaptive
rather than structured approach to HF integration.

> _“We sort of adapt to it and then we try to decompose according to the
> order”_ — ID07

In summary, the mixed responses highlight the complexity and contextual nature
of integrating HF requirements in product development. While a structured
decomposition approach is favored by some, the diversity in organizational
practices and the abstract nature of HF requirements pose challenges to its
universal application. These findings suggest that while the proposition may
hold value, its applicability and effectiveness are likely contingent on the
specific context of the organization and the nature of the product development
process.

###  IV-C RQ 3: How does defining a work and feature flow related to HF
requirements influence their integration in product development?

This question evaluates the third aspect of requirement strategy, i.e., the
work and feature flow perspective.

#### Proposition 6: A strong lifecycle model of HF requirements positively
impact the integration of HF requirements in product development

Our findings support Proposition 6 (7 positive, 5 neutral stances among
interviewees), particularly highlighting the benefits of integrating agile
practices. Our analysis reveals a trend towards the integration of HF
requirements within agile and iterative development processes, reinforcing the
notion that a robust lifecycle model of HF requirements is instrumental in
enhancing product development. For example, ID01 provided insight into their
organization’s structured approach, illustrating the systematic adoption of
agile methodologies:

> _“We’re doing we have the set of meetings, there’s the
> planning…understanding requirements, implementing, testing, and
> integration., get feedback and iterate based on that.”_ — ID01

This approach underscores the efficacy of agile methodologies as integral
components of the lifecycle model, particularly in their role in facilitating
the integration of HF requirements. The iterative nature of agile
methodologies, as pointed out by our interviewees, enables the seamless
incorporation of various specialties, including HF. ID13 elaborates on this
process:

> _“In an agile way of working, you’re working incrementally and iteratively.
> So we’re doing one functional feature at a time, we use different modeling
> and simulation before we have the hardware available to us…you’re doing some
> of the HF requirements depending on what you’re developing next. […] Well,
> it works very well with incrementally in an iterative approach.”_ — ID13

The emphasis on early decision-making and continuous feedback loops, as
observed by ID12, further corroborates the value of a well-structured
lifecycle model for HF integration:

> _“Lifecycle model involves early-stage requirements capture, evaluation, and
> iterative feedback… Separates design and delivery aspects….Significant
> architectural decisions, some of the big decisions that really have to be
> defined early on and not changed and made with always people being involved
> from this part of the process.”_ — ID12

However, some interviewees expressed neutral stances, indicating variability
in the application of lifecycle models or the complexity of the project. For
instance, ID10 noted:

> _“The process isn’t as intuitive or straight- forward. It often requires a
> significant amount of repeated effort, depending on the complexity of the
> issue this iterative process involves a few steps for simpler problems but
> becomes more detailed when tackling complex issues.”_ — ID10

In summary, the data support the proposition that a robust lifecycle model for
HF requirements positively influences their integration in product
development, as evidenced by the majority of interviewees. However, the
neutral responses indicate variability and complexity in the application of
these models, suggesting that while a strong lifecycle model is generally
beneficial, its implementation and effects may vary depending on specific
project contexts and methodologies.

#### Proposition 7: A clear definition of a HF work stream in relation to
other work streams positively impacts the integration of HF requirements in
product development

Our findings provide partial support for Proposition 7, as three interviewees
supported the proposition while eight others maintained a neutral stance.

Some interviewees suggest that when HF is clearly integrated into the
workflow, particularly in agile environments, it is more effectively
considered in product development. For instance, ID02 emphasizes that agile
methodologies facilitate the integration of various specialists, including HF
specialists. This is evident from the observation,

> _“Human factors specialist and HF requirements should be part of the regular
> work, together with everything else, we should not keep it separate because
> that’s what we have today. Today we are in separate, we have this, these
> silos. We want to break silos with agile way of working.”_ — ID02

This statement supports the proposition, as it demonstrates that clear and
integrated work streams, such as those found in agile environments, are
conducive to incorporating HF requirements effectively. Similarly, ID13’s
perspective reinforces this view by advocating for a unified approach where HF
is integrated along with other critical functions:

> _“There are no separate work streams for HF. The aspects are all the same,
> we don’t have separate works streams for functional safety or for cyber
> security or anything else like that.”_ — ID13

However, some interviewees expressed a neutral stance, indicating a diverse
implementation of HF integration in their processes. For instance, ID04’s
comment reveals a gap between intention and execution:

> _“The developers implementing the code always wanted to have the human
> factor requirements… the designers did not work with our PI planning.”_ —
> ID04

ID03’s experience further illustrates the challenges of integrating HF into
other workstreams, hinting at possible technical complexities:

> _“It’s integrated, but sometimes I feel it’s very technical.”_ — ID03

Moreover, we learned that the impact of clearly defined HF work streams on
their integration appears to be context-dependent, varying across different
organizational structures and project types. ID12’s experience illustrates
this variability:

> _“In some cases, separate teams for HF run their own sprints, typically
> delivering specifications because we don’t need external resources.
> Alternatively, people work with joint teams to develop requirements that
> consider all aspects, including mechanical, electrical, and others.”_ — ID12

In summary, while the data provides evidence that clear definitions and
structured work streams in agile methodologies can improve the integration of
HF in product development, there is also an understanding that its
effectiveness can vary based on project dynamics and organizational
frameworks. Notably, none of the interviewees explicitly rejected the
proposition.

#### Proposition 8: A clear plan for review and reflection of HF requirements
positively impacts the integration of HF requirements in product development

Our findings support Proposition 8, with seven interviewees taking a
supporting stance and five others taking neutral stances. Our interviewees
highlighted practices and perspectives that align with the importance of a
structured approach to reviewing and reflecting on HF requirements. This
support is evidenced by the emphasis on agile flexibility, the importance of
planning and communication, and the iterative improvement processes discussed
by various interviewees. Iterative processes and continuous improvement,
central to agile methodologies, are also highlighted as beneficial for
integrating HF. For instance, ID12’s emphasis on retrospectives underscores
this point:

> _“We’ll conduct retrospectives and discuss the process, people, and output.
> The main feedback, however, is whether what we’ve created works, is usable,
> and if people like it. Does it feel intuitive?… Continuous improvement is
> key. At the end of the day, it’s about spending time, doing the work,
> reviewing, reflecting, and improving for the next time.”_ — ID12

Similarly, ID13’s mention of sprint reviews and the role of retrospectives as
a platform for stakeholder engagement to reflect on HF requirements indicates
a structured approach:

> _“The Sprint review is the time and place for the team to invite
> stakeholders to review and reflect on the human factor requirements. As I
> said, this should preferably be done with the stakeholders. The team should
> work as closely as possible with them, regardless of who the stakeholders
> are.”_ — ID13

These insights illustrate the positive impact of regular review and reflection
in aligning product development with HF requirements. ID07’s comments further
support this, illustrating a formalized review process:

> _“When you complete a study or project, you usually create an HF
> requirements report deliverable. It’s reviewed by the authors or peer-
> reviewed, and then you receive feedback, addressing minor or major comments.
> We also typically have lessons learned, discussing improvements for future
> projects.”_ — ID07

Some interviewees did not explicitly support or reject the proposition. As for
example, ID09 highlights the importance of the review and reflection processes
but does not directly link these to the positive integration of HF
requirements.

> _“We review and reflect overall for the workflow and testing.”_ — ID09

In summary, the data predominantly supports the proposition that a clear plan
for review and reflection of HF requirements is beneficial for their
integration in product development. The emphasis on iterative feedback,
stakeholder involvement, and retrospective analyses by several interviewees
underscores the value of reflective practices in effective product
development. However, the presence of neutral stances suggests that the impact
of such practices may vary depending on other factors, such as team dynamics,
project nature, or organizational contexts.

##  V Discussion

Our findings have been obtained from a qualitative analysis of semi-structured
interview data based on the lens of Requirements Strategies. In this section,
we discuss how these findings are contextualized within existing literature,
drawing parallels and contrasts with strategies in related fields. Our
findings indicate that while every company adopts agility to varying extents,
they do so in distinct ways tailored to their specific contexts. Consequently,
these results may have implications for organizations that go beyond
‘traditional’ processes at both system and organizational levels.

#### Impact of Ownership and Responsibility on HF Integration

The results indicate general support confirming that clear ownership and
responsibility (Proposition 1) benefit HF integration in product development,
resonating with Smith and Reinertsen’s [45] observations on role clarity.
However, the neutral stances suggest a nuanced application, dependent on
organizational context and project nature. This aligns with the findings of
Cockburn [28], who highlight the impact of organizational culture on the
adoption of agile practices. For Proposition 2, the opinions on assigning HF
expertise to critical roles were divergent. Hence, we conclude that this is
not the sole effective approach. The diversity in responses implies that
either a distributed approach to managing HF expertise or that a combined
approach that distributes HF expertise generally over the development
organization, and at the same time ensures that critical roles can utilize it
in their decision making can be effective.

#### Impact of Requirement Structuring and Information Models on HF
Integration in AV Development

The mixed perspectives on the impact of clear requirements structure on HF
integration (Proposition 3) echo the broader discourse in software engineering
[46], where structured approaches, while valuable, must be flexible enough to
accommodate the dynamic nature of product development, as noted by Cooper et
al. [47]. This also reflects the tension in software development expressed by
the controversial agile value of working software over comprehensive
documentation [48, 49]. Our findings contradict literature such as Hull et al.
that describes the clarity and structure of requirements as pivotal for
successful project outcomes [32], at least in the context of our
investigation. We believe that due to the disruptive nature of AV technology,
some of our interviewees are suspicious about a structure that may prevent
them to explore emergent HF properties. The fact that not all areas of
automotive development are equally disrupted may explain why our interviewees
come to different assessments.

For Proposition 4, regarding traceability of HF requirements, the diversity of
viewpoints underscores the practical challenges of maintaining traceability in
various organizational contexts. This reveals that the effectiveness of
traceability in HF integration may not be universally recognized, suggesting a
gap between theoretical expectations [35, 34]and practical realizations. The
findings on the decomposition of HF requirements in Proposition 5 show varied
support. The iterative approaches to requirement decomposition discussed by
interviewees reflect systems engineering best practices for breaking down
complex requirements into manageable parts for efficient implementation.
However, other interviewees felt that requirements decomposition does not work
well in innovative domains, where traditional decomposition schemes may not
fit well. Similar effects have also been reported in literature, e.g. by Hoda
et al. [50].

#### Impact of Work and Feature Flow on HF Integration in AV Development

The findings regarding the lifecycle model of HF requirements (Proposition 6)
support the positive impact of the integration of HF in product development.
This aligns with agile methodologies which emphasize adaptability and
iterative development for complex requirements, as discussed in Van Der
Vyver’s et al. [36] and Schwaber and Beedle’s [37] work. Our study shows both
positive and neutral sentiments among interviewees, which suggests diverse
approaches to integrate HF into the development, influenced by factors like
project size, nature, organizational culture, and scope [51].

The feedback on Proposition 7 highlight the debate on integrating versus
separating HF activities in agile processes, echoing Cockburn and Highsmith’s
view on agile methodologies’ adaptability across organizational contexts [52].
Integrating HF with other workstreams may improve recognition and integration,
but might also limit its scope to specific areas. Conversely, external HF
expertise may have a broader reach across teams, but have less influence on
decision-making. This balance between specialized knowledge and cross-
functional collaboration is also discussed by Highsmith [39].

Lastly, the emphasis of Proposition 8 on the importance of a clear plan for
review and reflection of HF requirements is supported by Sutherland and
Schwaber’s insights [41] into continuous improvement and iterative evaluation
in agile development. The mix of positive and neutral responses indicates
differences in how organizations implement these processes, ranging from
specialized review approaches to relying on generic reviews schemes. This
divergence likely stems from their distinct cultural foundations. For example,
in firms where a human-centric design is deeply embedded, additional reporting
may be viewed as redundant. However, we believe that in companies still
developing this culture, detailed reports could be crucial for increasing
awareness and driving cultural change.

Overall, the lens of Requirements Strategies allowed for meaningful
discussions with experts, particularly benefiting companies transitioning away
from purely process-driven approaches. The fact that we find a wide spectrum
of different approaches for each proposition, and even a certain level of
disagreements with the structural propositions, shows that a suitable
Requirements Strategy would have to be defined for each specific context. For
this reason, we derive different solutions from our interviews, to indicate
the solution space for organizations that aim to integrate HF requirements
into AV development. We believe that our findings will help organizations to
explore this solution space and make good, consistent decisions. We are
certain that this will help to systematically cover HF concerns in AV
development.

##  VI Conclusion

In conclusion, this study contributes to the understanding of how HF
requirements can be effectively integrated into AV development, examined
through the lens of Requirements Strategies. Adopting agile methodologies has
proven promising in addressing complex HF requirements through iterations and
feedback loops, yet it becomes unclear how HF requirements can be
systematically managed in agile scopes. This tension highlights the crucial
role of a consistent Requirements Strategy in the successful integration of HF
knowledge into the agile development of AVs. Our findings underscore the
necessity for organizations to adapt their strategies to the unique demands of
the development environments. In particular, they indicate that clear
ownership and responsibility for HF requirements enhance their integration
into product development, resulting in more streamlined and cohesive
workflows. While foundational, the structuring and traceability of HF
requirements also necessitate a balance between rigidity and flexibility.
Both, organizational matters and structuring of requirements are fundamental
to integrate activities related to HF requirements into agile workflows. Along
these three components (organization, structure, workflow), our study
identifies various solution spaces indicated in the findings, reflecting the
diverse approaches employed within the industry to integrate HF requirements.
We observed that while certain practices are effective, the effectiveness of
others may vary, highlighting the need for future research and the development
of tailored approaches that consider the unique organizational contexts.

## Acknowledgments

The authors extend their sincere gratitude to all interviewees for their time
and valuable insights. This work was supported by funding from the European
Union’s Horizon 2020 research and innovation programme, through the Marie
Skłodowska-Curie grant, agreement number 860410. For additional information
about this project, please visit https://www.shape-it.eu.

## References

  * [1] The Journal of the Human Factors and Ergonomics Society, online (assessed: 2020-Nov-16) (2020).  [link].
URL https://journals.sagepub.com/description/hfs

  * [2] K. R. Ohnemus, Incorporating human factors in the system development life cycle: marketing and management approaches, in: IPCC 96: Communication on the Fast Track. IPCC 96 Proceedings, IEEE, 1996, pp. 46–53.
  * [3] J. Lee, C. Wickens, Y. Liu, L. Boyle, Designing for people, ShangHai (2017) 173\.
  * [4] D. Norman, Things that make us smart: Defending human attributes in the age of the machine, Diversion Books, 2014.
  * [5] A. P. Muhammad, E. Knauss, J. Bärgman, A. Knauss, Managing human factors in automated vehicle development: Towards challenges and practices, in: 2023 IEEE 31st International Requirements Engineering Conference (RE), IEEE, 2023, pp. 347–352.
  * [6] S. V. Zykov, A. Singh, Agile Enterprise Engineering: Smart Application of Human Factors, Vol. 175, Springer, 2020.
  * [7] A. P. Muhammad, E. Knauss, O. Batsaikhan, N. E. Haskouri, Y.-C. Lin, A. Knauss, Defining requirements strategies in agile: a design science research study, in: International Conference on Product-Focused Software Process Improvement, Springer, 2022, pp. 73–89.
  * [8] A. P. Muhammad, E. Knauss, J. Bärgman, Human factors in developing automated vehicles: A requirements engineering perspective, Journal of Systems and Software 205 (2023) 111810.
  * [9] F. Walker, J. Steinke, M. Martens, W. Verwey, Do engineer perceptions about automated vehicles match user trust? consequences for design, Transportation research interdisciplinary perspectives 8 (2020) 100251.
  * [10] M. R. Siddiqi, S. Milani, R. N. Jazar, H. Marzbani, Ergonomic path planning for autonomous vehicles-an investigation on the effect of transition curves on motion sickness, IEEE transactions on intelligent transportation systems 23 (7) (2021) 7258–7269.
  * [11] S. Kolekar, B. Petermeijer, E. Boer, J. de Winter, D. Abbink, A risk field-based metric correlates with driver’s perceived risk in manual and automated driving: A test-track study, Transportation research part C: emerging technologies 133 (2021) 103428.
  * [12] I. J. Reagan, D. G. Kidd, J. B. Cicchino, Driver acceptance of adaptive cruise control and active lane keeping in five production vehicles, in: Proceedings of the Human Factors and Ergonomics Society Annual Meeting, Vol. 61, SAGE Publications Sage CA: Los Angeles, CA, 2017, pp. 1949–1953.
  * [13] A. S. Tomar, M. S. Gull, S. R. Penmetsa, F. Tillema, Towards a human-centric design solution for automated systems to enhance driver’s comfort and acceptance, in: 2021 International Conference on Electrical, Computer, Communications and Mechatronics Engineering (ICECCME), IEEE, 2021, pp. 1–6.
  * [14] S. Jokhio, P. Olleja, J. Bärgman, F. Yan, M. Baumann, Analysis of time-to-lane-change-initiation using realistic driving data, IEEE Transactions on Intelligent Transportation Systems (2023).
  * [15] U. Sander, Opportunities and limitations for intersection collision intervention—a study of real world ‘left turn across path’accidents, Accident Analysis & Prevention 99 (2017) 342–355.
  * [16] J. Bärgman, K. Smith, J. Werneke, Quantifying drivers’ comfort-zone and dread-zone boundaries in left turn across path/opposite direction (ltap/od) scenarios, Transportation Research Part F: Traffic Psychology and Behaviour 35 (2015) 170–184.
  * [17] C. A. Hobbs, P. J. McDonough, Development of the european new car assessment programme (euro ncap), Regulation 44 (3) (1998) 2439–2453.
  * [18] R. Cirino Goncalves, C. M. Goodridge, J. Kuo, M. G. Lenne, N. Merat, Using driver monitoring to estimate readiness in automation: A conceptual model based on simulator experimental data, Available at SSRN 4640135.
  * [19] P. A. Hancock, Some pitfalls in the promises of automated and autonomous vehicles, Ergonomics 62 (4) (2019) 479–495.
  * [20] M. Kyriakidis, J. C. de Winter, N. Stanton, T. Bellet, B. van Arem, K. Brookhuis, M. H. Martens, K. Bengler, J. Andersson, N. Merat, et al., A human factors perspective on automated driving, Theoretical issues in ergonomics science 20 (3) (2019) 223–249.
  * [21] A. S. Mueller, I. J. Reagan, J. B. Cicchino, Addressing driver disengagement and proper system use: human factors recommendations for level 2 driving automation design, Journal of cognitive engineering and decision making 15 (1) (2021) 3–27.
  * [22] F. Ekman, M. Johansson, J. Sochor, Creating appropriate trust in automated vehicle systems: A framework for hmi design, IEEE Transactions on Human-Machine Systems 48 (1) (2017) 95–101.
  * [23] M. R. Endsley, Designing for situation awareness in complex systems, in: Proceedings of the Second International Workshop on symbiosis of humans, artifacts and environment, 2001, pp. 1–14.
  * [24] M. Saghafian, T. A. Sitompul, K. Laumann, K. Sundnes, R. Lindell, Application of human factors in the development process of immersive visual technologies: challenges and future improvements, Frontiers in psychology 12 (2021) 634352.
  * [25] R. Steinberg, N. Grumman, Human factors at the speed of relevance for agile engineering, in: Proceedings of the Human Factors and Ergonomics Society Annual Meeting, Vol. 66, SAGE Publications Sage CA: Los Angeles, CA, 2022, pp. 1897–1901.
  * [26] K. E. Wiegers, J. Beatty, Software requirements, Pearson Education, 2013.
  * [27] M. Cagan, Inspired: How to create products customers love, SVPG Press Sunnyvale, CA, USA, 2008.
  * [28] A. Cockburn, Agile software development: the cooperative game, Pearson Education, 2006.
  * [29] M. Paasivaara, C. Lassenius, Collaboration practices in global inter-organizational software development projects, Software Process: Improvement and Practice 8 (4) (2003) 183–199.
  * [30] K. S. Rubin, Essential Scrum: A practical guide to the most popular Agile process, Addison-Wesley, 2012.
  * [31] A. Aurum, C. Wohlin, The fundamental nature of requirements engineering activities as a decision-making process, Information and Software Technology 45 (14) (2003) 945–954.
  * [32] E. Hull, K. Jackson, J. Dick, Requirements engineering in the solution domain, Springer, 2005.
  * [33] A. M. Davis, Software requirements: objects, functions, and states, Prentice-Hall, Inc., 1993.
  * [34] O. C. Gotel, C. Finkelstein, An analysis of the requirements traceability problem, in: Proceedings of ieee international conference on requirements engineering, IEEE, 1994, pp. 94–101.
  * [35] C. Rupp, M. Simon, F. Hocker, Requirements engineering und management, HMD Praxis der Wirtschaftsinformatik 46 (3) (2009) 94–103.
  * [36] G. Van Der Vyver, A. Koronios, M. S. Lane, Agile methodologies and the emergence of the agile organisation: a software development approach waiting for its time?, in: Proceedings of the 7th Pacific Asia Conference on Information Systems (PACIS 2003), University of South Australia, 2003, pp. 1344–1358.
  * [37] K. Schwaber, M. Beedle, Agile software development with Scrum, Prentice Hall PTR, 2001.
  * [38] M. Cohn, D. Ford, Introducing an agile process to an organization [software development], Computer 36 (6) (2003) 74–78.
  * [39] J. A. Highsmith, Agile software development ecosystems, Addison-Wesley Professional, 2002.
  * [40] P. Guide, A guide to the project management body of knowledge, 2008.
  * [41] J. Sutherland, K. Schwaber, The scrum guide, The definitive guide to scrum: The rules of the game. Scrum. org 268 (2013) 19.
  * [42] D. Leffingwell, Agile software requirements: lean requirements practices for teams, programs, and the enterprise, Addison-Wesley Professional, 2010.
  * [43] J. Saldaña, The coding manual for qualitative researchers, sage, 2021.
  * [44] S. Kılıç, Kappa testi, Journal of mood disorders 5 (3) (2015) 142–144.
  * [45] P. G. Smith, D. G. Reinertsen, Developing products in half the time: new rules, new tools, John Wiley & Sons, 1997.
  * [46] I. Sommerville, Software engineering (ed.), America: Pearson Education Inc (2011).
  * [47] A. Cooper, R. Reimann, D. Cronin, C. Noessel, About face: the essentials of interaction design, John Wiley & Sons, 2014.
  * [48] A. Davis, Just enough requirements management: where software development meets marketing, Addison-Wesley, 2013.
  * [49] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, et al., Manifesto for agile software development (2001).
  * [50] R. Hoda, N. Salleh, J. Grundy, The rise and evolution of agile software development, IEEE software 35 (5) (2018) 58–63.
  * [51] J. Sutherland, K. Schwaber, The scrum papers, Nuts, bolts and origins of an Agile process (2007).
  * [52] A. Cockburn, J. Highsmith, Agile software development, the people factor, Computer 34 (11) (2001) 131–133.