arXiv CSopen access

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry Zixu Wang

Shengcheng Yu∗

Zhenchang Xing

[email protected] Technical University of Munich, Infineon Technologies AG Munich, Germany

[email protected] Technical University of Munich Heilbronn, Germany

[email protected] CSIRO’s Data61 Australia

Tobias Wenzel

Chunyang Chen

[email protected] Infineon Technologies AG Munich, Germany

[email protected] Technical University of Munich Heilbronn, Germany

arXiv:2607.05632v1 [cs.SE] 6 Jul 2026

Abstract The automotive industry’s shift toward software-driven systems has increased complexity while raising the stakes for requirement intake and refinement—critical not only for correctness and compliance, but also for development speed and systematic reuse. While prior research has proposed techniques for improving requirement quality, there is limited empirical understanding of how stakeholderlevel requirements are evaluated, refined, and transformed into product-level requirements in industrial automotive practice. This paper presents a large-scale empirical study of requirements engineering based on an industrial dataset from Infineon comprising 8,082 stakeholder requirements and 5,870 product requirements, enriched with traceability links, decision outcomes, deviation rationales, and domain references. Using a mixed-methods approach that combines quantitative analyses of requirement structures, decision distributions, and mapping patterns with qualitative analysis of rationales and referenced specifications, and software- and hardware-related artifacts, we investigate structural and contextual differences between stakeholder and product requirements, factors influencing acceptance, rejection, and approval with deviation, and the nature of stakeholder-to-product requirement refinement. The results reveal systematic differences across abstraction levels and show that refinement complexity is driven primarily by architectural scope and missing contextual information rather than linguistic verbosity. We further derive a taxonomy of stakeholder–product requirement mapping patterns and relate them to differing refinement effort. These findings provide concrete insights into industrial requirements intake and refinement practices and highlight actionable opportunities for improving intake validation, deviation ∗ Shengcheng Yu is the corresponding author.

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 for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) 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 fee. Request permissions from [email protected]. ASE ’26, Munich, Germany © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM https://doi.org/XXXXXXX.XXXXXXX

management, and tool-supported contextual enrichment to support faster and more reusable automotive product development.

CCS Concepts • Software and its engineering → Requirements analysis.

Keywords Empirical Study, Requirements Engineering, Automotive Software ACM Reference Format: Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen. 2026. Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry. In Proceedings of 41st IEEE/ACM International Conference on Automated Software Engineering (ASE ’26). ACM, New York, NY, USA, 12 pages. https://doi.org/XXXXXXX.XXXXXXX

1

Introduction

The automotive industry is undergoing a profound transformation from mechanically centered products toward software-driven and cyber-physical systems [10]. Modern vehicles increasingly rely on highly integrated software and hardware platforms that coordinate functionality across hundreds of electronic control units interconnected through complex in-vehicle networks [29, 41, 45]. Software now governs not only infotainment and comfort features but also powertrain control, advanced driver assistance systems, and safetycritical functions [4, 50]. As a result, automotive systems exhibit unprecedented scale, heterogeneity, and interdependence across software, hardware, and communication layers [10, 13]. This shift has led to a substantial escalation in system complexity and integration effort [30, 51]. The growing volume of software and its tight coupling with hardware have increased the likelihood of integration defects, late discovery of inconsistencies, and unexpected emergent behavior [39]. In recent years, a significant proportion of vehicle recalls and field failures have been attributed to software-related issues, including safety-critical defects [45]. These developments have led to growing concerns in industry regarding the need for rigorous, lifecycle-wide quality assurance. Quality assurance in the automotive industry is strongly shaped by a constellation of standards and frameworks. Functional safety in road vehicles is governed by ISO 26262 [25], which mandates

ASE ’26, October 12–16, 2026, Munich, Germany

Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen

safety-driven refinement and traceable justification of safety requirements. AUTOSAR [3] standardizes software architecture, component interfaces, and integration mechanisms, thereby influencing how requirements are decomposed and allocated. Automotive SPICE [57] defines process requirements and assessment models for system and software development, including explicit processes for requirements engineering alongside many other process areas. Together, these standards and specifications demand not only technically correct implementations but also auditable, well-structured, and standards-compliant requirements throughout refinement and realization. Within this context, requirements engineering (RE) plays a fundamental role in quality assurance [25, 49, 57]. Requirements define intended system behavior, constraints, and operating conditions prior to implementation. Decisions made during early requirements elicitation and refinement have a lasting impact on defect rates, downstream rework, compliance with standards, and ultimately certification success [2, 6, 15, 43]. Deficiencies at the requirements level often propagate across development phases, becoming increasingly costly and difficult to correct once embedded in architectures and implementations [15]. RE is not only a means of assuring quality and compliance, but also a prerequisite for efficient product-line engineering, faster requirement intake, and systematic reuse across product variants [9, 59]. Despite its importance, requirements engineering in the automotive industry faces persistent challenges [13, 31]. Requirements are predominantly specified in natural language, which makes them susceptible to ambiguity, underspecification, and implicit assumptions [32, 43]. Furthermore, requirements can be managed across multiple abstraction levels, ranging from high-level stakeholder requirements to detailed product and component specifications [48]. This process spans organizational boundaries among original equipment manufacturers, tier-1 suppliers, and semiconductor vendors. Coordinating these actors while preserving intent, context, and traceability is inherently complex and error-prone [60]. Prior research on general RE has proposed a variety of approaches to mitigate these challenges. Existing work includes quality models [19, 21] and defect taxonomies for natural-language requirements [44], knowledge extraction and representation [53, 54], test specification techniques [40], automated linguistic checks [5, 18], and traceability recovery methods [26, 42]. Tool support has been developed to establish and analyze links among requirements and related artifacts [7, 42, 53]. However, most of these approaches focus on assessing the quality of isolated requirement sets or on recovering missing links after the fact. They rarely address the endto-end refinement process from stakeholder-level requirements to product-level specifications as it unfolds in industrial practice. Consequently, several critical gaps remain. There is limited industrial-scale evidence on how and why stakeholder requirements are actually evaluated and transformed. The structural forms of stakeholder-to-product requirement mappings, the emergence of complex refinement structures, and the contextual information engineers must reconstruct during refinement are not well understood. In particular, there is a lack of empirical insight into how stakeholder-level and product-level requirements differ structurally and how they are related in real automotive projects.

This paper addresses these gaps through an empirical study based on an industrial dataset from Infineon. The dataset comprises 8,082 stakeholder requirements and 5,870 product requirements. It includes explicit traceability between product requirements and their source stakeholder requirements, documented approval/rejection decisions (with rationales), and references to specifications and auxiliary domain artifacts. To the best of our knowledge, this constitutes one of the most comprehensive datasets available for studying requirements refinement in an industrial automotive setting. With this dataset, the study investigates several interrelated questions. It examines how stakeholder and product requirements differ in structure and contextual richness, which factors influence acceptance, rejection, and approval with deviation decisions, and how stakeholder-to-product requirement mappings are organized. It further analyzes what drives refinement complexity and which types of contextual information engineers reconstruct during the elaboration of product requirements. This study adopts a mixed-methods approach. Quantitative analyses are used to characterize requirement structures, decision distributions, and mapping patterns through descriptive statistics and structural comparisons. Pattern mining is applied to identify recurring forms of stakeholder-to-product requirement relationships. In parallel, qualitative analyses examine decision rationales, deviation justifications, and references to industry specifications and hardware documentation using thematic coding. The results reveal systematic structural differences between stakeholder and product requirements and provide empirical evidence on how missing context and specification-driven constraints influence decision outcomes. The study derives a taxonomy of stakeholder-to-product requirement mapping patterns and associates these patterns with differing levels of refinement effort. Importantly, the findings indicate that refinement complexity is driven less by linguistic verbosity and more by architectural scope and implicit domain assumptions. Engineers frequently need to reconstruct context from specifications and hardware documentation to make stakeholder requirements implementable. These insights highlight concrete opportunities to improve requirement intake validation, deviation management, and tool-supported contextual enrichment in industrial automotive requirements engineering. This paper conducts the first empirical study to jointly analyze stakeholder-level and product-level requirements at an industrial scale. In summary, this paper makes the following noteworthy contributions:

• A first large-scale empirical characterization of stakeholder-level and product-level requirements (SHRQs and PRQs) in an industrial automotive setting, revealing systematic differences in structure, granularity, and contextual completeness across abstraction levels. • An analysis of acceptance and deviation decisions, showing how industry specifications, feasibility constraints, and missing context influence requirement outcomes. • A taxonomy of SHRQ–PRQ mapping relationships and refinement complexity, demonstrating that complexity is driven primarily by architectural scope and missing contextual information rather than textual verbosity.

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry ASE ’26, October 12–16, 2026, Munich, Germany

• Implications for practice, including improved intake validation, systematic deviation management, and tool support for contextual enrichment, and opportunities for future automation in requirement assessment and refinement.

2 Background and Motivation 2.1 Requirements in the Automotive Domain Requirements Engineering (RE) structures how system behavior is specified, refined, and verified throughout the automotive development process [1, 25, 43, 46, 59, 61]. Within this process, requirements are organized across multiple abstraction levels to accommodate the separation of responsibilities among OEMs, tier-1 suppliers, and semiconductor providers, as well as the technical constraints imposed by safety standards and architectural specifications. Understanding these abstraction levels is essential for analyzing how high-level intents are ultimately realized in component-level software behavior [47, 59]. Stakeholder requirements (SHRQs) express vehicle-level goals, functional expectations, safety intents, and regulatory constraints. They are typically written in natural language and vary widely in granularity, scope, and completeness. SHRQs capture what the system should achieve from an end-user or safety perspective but often omit timing assumptions, operational modes, and hardware dependencies. Product requirements (PRQs) refine high-level intents into implementable specifications for specific hardware or software components. They must comply with architectural constraints such as component interfaces, signal models, and timing behavior, as well as platform capabilities and safety requirements derived from ISO 26262. Accordingly, PRQs use controlled syntax and semantics, follow naming conventions, and are organized into functional, interface, performance, and design-constraint categories. To support compliance, PRQs must be atomic, unambiguous, and traceable to both upstream SHRQs and downstream validation artifacts. The refinement from SHRQs to PRQs is a core part of the automotive requirements lifecycle. SHRQs are analyzed, decomposed, and operationalized into increasingly detailed specifications (Fig. 1) that reflect architectural and hardware constraints. SHRQ–PRQ relationships are often heterogeneous: a single SHRQ may decompose into multiple PRQs covering different components or operational contexts, while multiple SHRQs may converge into one PRQ representing shared functionality. These patterns show that automotive requirements differ not only in abstraction level but also in structure, semantics, contextual completeness, and architectural grounding. This layered organization motivates our subsequent analysis of the challenges and decision mechanisms involved in SHRQ-to-PRQ refinement.

2.2

Challenges and Motivation

Although automotive requirements are organized across abstraction levels, refining SHRQs into PRQs remains difficult to perform consistently in practice. Several factors hinder engineers’ ability to operationalize high-level intents while maintaining alignment with safety, architectural, and implementation constraints. First, SHRQs often lack critical contextual information needed for precise refinement. They frequently omit timing assumptions,

Figure 1: Transformation Process from Stakeholder to Product Requirements in Automotive RE

operational modes, hardware dependencies, and environmental conditions. For example, a requirement such as “The system shall support dynamic power-mode transitions” does not specify transition timing, ECU involvement, or hardware limits. In practice, this led to more than a dozen PRQs across multiple components, including conflicting timing constraints. Engineers must reconstruct missing context from standards, hardware documentation, or internal guidelines, making refinement dependent on tacit knowledge and prone to inconsistency. Second, SHRQs show substantial heterogeneity in structure, scope, and clarity. Originating from OEMs, regulatory bodies, and diverse internal stakeholders, they vary widely in format and level of detail. This variability complicates the identification of refinement boundaries and increases the risk of ambiguous or conflicting interpretations, directly affecting the derivation of precise PRQs. Third, refinement relationships are complex. Mappings between SHRQs and PRQs are often many-to-many. A single SHRQ may decompose into multiple PRQs reflecting different architectural roles, timing behaviors, or safety constraints, while several SHRQs may converge into a single PRQ capturing shared functionality. This increases cognitive load and complicates traceability, making it harder to ensure that system-level intent is faithfully realized. Fourth, acceptance and rejection decisions depend on more than linguistic quality. Engineers frequently approve SHRQs with deviation, reinterpret them to fit architectural constraints, or reject them due to feasibility or safety concerns. However, the rationale behind these decisions is rarely analyzed systematically, limiting insight into current refinement practices. These challenges call for a deeper empirical understanding of differences between SHRQs and PRQs, refinement decision-making, and the contextual knowledge engineers rely on. This study addresses these gaps through an empirical analysis of industrial automotive projects, characterizing requirement properties, acceptance decisions, refinement structures, and contextual dependencies to ground current practice in evidence and identify opportunities to improve requirement intake, refinement workflows, and future automation.

3

Research Questions

These challenges reveal gaps in our empirical understanding of how SHRQs and PRQs differ, how engineers evaluate and refine them, and what contextual knowledge is required during refinement. To address these gaps, we investigate five research questions. Stakeholder Heterogeneity and Requirement Characteristics

ASE ’26, October 12–16, 2026, Munich, Germany

RQ1: How does stakeholder heterogeneity in the automotive ecosystem manifest in systematic linguistic and structural differences in requirements across abstraction levels? Understanding these differences provides essential context for interpreting subsequent acceptance decisions and refinement behavior across abstraction levels. Requirement Acceptance and Review Rationales RQ2: Which characteristics distinguish SHRQs that are accepted from those that are rejected during industrial review? RQ3: What review rationales most frequently underlie rejection or approval with deviation in industrial practice? Together, these questions examine both the outcomes of acceptance decisions and the underlying issues that shape these decisions. Mapping Complexity RQ4: How are SHRQ–PRQ mappings structured in industrial practice, and what factors drive refinement complexity reflected in these mapping patterns? These questions explore the cognitive and structural aspects of refinement, including architectural decomposition, many-to-many relationships, and cross-component interactions. Contextual Knowledge in Refinement RQ5: What contextual information is typically missing in SHRQs, how do these gaps co-occur, and how do they shape refinement into PRQs? This question focuses on identifying which types of contextual information are systematically absent from SHRQs and must be made explicit during product-level refinement.

4

Study Design

To address the RQs, we conducted an empirical study of real-world automotive requirements in collaboration with Infineon. This section describes the design of the study, including the approach, data, and analysis procedures.

4.1

Data Source and Collection

The data comes from Infineon’s automotive chip development projects, which are safety-critical and involve multiple stakeholder groups, like OEM customers, standardization bodies, and internal roles such as system engineering, architecture, safety, and quality. As a result, the requirements reflect the heterogeneity and domain constraints typical of large-scale automotive chip development. The repository contains requirements at multiple abstraction levels, along with ISO 26262-mandated [25] review decisions and traceability information. For this study, we extracted SHRQs, PRQs, their metadata, including acceptance status and reviewer rationale, and the SHRQ–PRQ traceability links created during refinement. All artifacts were exported directly from the tool and reviewed to remove direct product identifiers and proprietary technical details. Domain-relevant terminology from public standards such as AUTOSAR and ISO 26262 was retained in representative examples to preserve ecological validity. Because the data originates from real industrial projects and captures actual review outcomes and traceability practices, it provides a reliable basis for analyzing requirement characteristics, acceptance decisions, and refinement behavior in practice.

Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen

Table 1: Overview of the requirement datasets Attribute Total count Source

Status Safety vance

4.2

SHRQs 8,082 Derived from specifications (3,939) and non-spec (4,143) Approved: 3,688; Rejected: 4,394 rele- Not applicable

Requirement type

Not applicable

Textual form

Natural language or tables; often informal/semistructured

PRQs 5,870 Derived from SHRQs (5,392) and auxiliary sources (478) All approved Annotated with ASIL (A–D, QM, N/A; per ISO 26262) Functional, Performance, Interface, Design Constraint, Process, Quality, Application, Testing Natural language; formalized and structured; atomic

Dataset Overview & Characteristics

The dataset comprises two requirement abstraction levels used in automotive chip development: stakeholder requirements (SHRQs) and product requirements (PRQs). The dataset (see Table 1) includes 8,082 SHRQs from diverse sources, consisting of 3,939 specificationderived inputs such as AUTOSAR and 4,143 non-specification SHRQs. Each SHRQ includes a short name, textual description, acceptance status, and review rationales. Of these, 3,688 SHRQs were approved for refinement into PRQs, while 4,394 were rejected, typically with reviewer comments explaining the decision. The dataset also contains 5,870 PRQs, representing implementable requirements organized into functional blocks aligned with the software architecture. Among them, 5,392 PRQs trace back to approved SHRQs, while the remaining PRQs capture auxiliary or internal requirements. PRQs further include structured attributes such as requirement type and are annotated with an Automotive Safety Integrity Level (ASIL), ranging from QM to A–D, enabling analysis of safety relevance. The dataset records explicit traceability links between SHRQs and PRQs, enabling analysis of refinement relationships across abstraction levels. These mappings form the basis for analyzing refinement structure and complexity in subsequent sections.

5 Results 5.1 Stakeholder Heterogeneity & Requirement Characteristics 5.1.1 RQ1: Stakeholder Heterogeneity & Requirement Characteristics. To answer RQ1, we analyze how differences in stakeholder roles and responsibilities are reflected in systematic linguistic and structural characteristics of SHRQs and PRQs, further distinguishing SHRQs from different sources. Length, structural complexity, and readability SHRQs exhibit substantially greater variation in length than PRQs. On average, SHRQs contain 43 words (std: 70), whereas PRQs are significantly shorter and more uniform (mean: 19 words, std: 15). Within SHRQs, specification-derived requirements show relatively consistent lengths with moderate variance (mean: 41 words, std: 36), while non-spec SHRQs are highly heterogeneous (mean: 44 words, std: 91), ranging from very short placeholders to lengthy, multi-clause descriptions

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry ASE ’26, October 12–16, 2026, Munich, Germany

Table 2: Linguistic characteristics of SHRQs and PRQs SHRQs

Metrics

PRQs

Spec.

Non-Spec.

Accepted

Rejected

Overall

General Number of Rows Unique Sentences

3,939 3,800

4,143 2,812

3,688 3,603

4,394 3,015

8,082 6,612

5,870 5,797

Lexical Complexity Total Tokens Lexical Words Vocab (Tok.) Vocab (Lex.) Vocab (Stem) Lexical Diversity Lexical Density

170,405 120,413 6,515 6,255 5,252 0.04 0.71

162,909 105,322 6,272 6,039 4,604 0.04 0.65

162,175 113,992 6,940 6,658 5,561 0.05 0.70

171,267 111,819 6,758 6,531 5,052 0.05 0.65

333,314 225,735 10,786 10,457 8,612 0.04 0.68

112,417 74,384 5,045 4,836 4,008 0.05 0.66

Syntactic Complexity Avg. Sent. Len. (Tok.) Avg. Sent. Len. (Lex.) Avg. # Clauses Avg. Parse Tree Depth

44.90 31.69 3.70 6.30

57.93 37.45 6.00 5.64

45.01 31.64 3.82 6.22

56.80 37.09 5.71 5.78

50.41 34.14 4.69 6.02

19.39 12.83 2.14 4.74

Readability Flesch–Kincaid (Grade)

21.68

26.08

21.55

25.92

23.56

13.40

(max: 2,103 words vs. 755 words). This pronounced variability reflects the heterogeneous origins of SHRQs, which stem from industry specifications (spec-SHRQs), internal engineering teams, OEM inputs, and requirements inherited from previous product generations (non-spec SHRQs). In contrast, PRQs exhibit a constrained and standardized structure, consistent with their role in supporting implementation and integration. Length alone, however, does not fully capture how stakeholder heterogeneity translates into linguistic complexity. Following established approaches for automated linguistic analysis of requirements, and using the tooling provided by prior work [22, 24], we examine syntactic and readability metrics to reveal deeper structural differences between requirement types. In Table 2, SHRQs contain substantially longer sentences and nearly twice as many clauses per sentence as PRQs (50.41 vs. 19.39 tokens per sentence; 4.69 vs. 2.14 clauses). Non-spec SHRQs are consistently the most syntactically demanding, with longer sentences (57.93 vs. 44.90 tokens) and more clauses (6.00 vs. 3.70) than specification-derived SHRQs. Readability metrics follow the same pattern: SHRQs reach substantially higher Flesch–Kincaid Grade Levels than PRQs (23.56 vs. 13.40), with non-spec SHRQs again exhibiting the highest values (26.08 vs. 21.68). Together, these results show that stakeholder heterogeneity manifests not only in the scale and variability of requirements but also in their syntactic structure and cognitive complexity. Semantic contrasts. Vocabulary analysis reveals two layers of difference between spec- and non-spec SHRQs. At the foundational level, both groups share common software engineering terminology such as function, configuration, and module, though specification requirement uses these terms more frequently, reflecting its emphasis on modular architecture. At the domain-specific level, clear divergence emerges: spec-SHRQs are characterized by configuration management vocabulary (variant, build, multiplicity, scope) and error detection (error, raise), whereas non-spec requirements center on runtime safety mechanisms (safety, reset, mechanism), hardware-level interactions (register, hardware), and fault response strategies (reaction, alarm). Semantic clustering confirms this pattern: 65% of requirements share a common vocabulary core, while domain-specific concerns form distinct, near-pure clusters. At the product level, our analysis reveals a hierarchical refinement pattern

with moderate semantic overlap between SHRQs and PRQs. The SHRQ-PRQ relationship thus reflects a refinement hierarchy where lower-level requirements elaborate on higher-level specifications using overlapping vocabulary, while maintaining distinct concerns for safety assurance (SHRQ) versus implementation details (PRQ). Taken together, these results show that stakeholder heterogeneity in the automotive ecosystem manifests in clear and consistent linguistic and structural differences across sources and abstraction levels. SHRQs are longer, more variable, and linguistically more complex, with non-spec SHRQs exhibiting the greatest heterogeneity. PRQs are substantially shorter, more uniform, and focused on technical and implementation-oriented content.

Finding 1: Stakeholder heterogeneity in the automotive ecosystem manifests in systematic linguistic and structural differences across sources and abstraction levels. SHRQs are longer, more variable, and linguistically more complex—especially those originating from non-spec sources, whereas PRQs are shorter, more uniform, and focused on implementation and integration concerns.

5.2

Requirement Acceptance & Review Rationales

5.2.1 RQ2: Features of Approved vs. Rejected SHRQs. To address RQ2, we analyze the acceptance outcomes of SHRQs and examine how they relate to requirement sources and linguistic characteristics. Acceptance outcomes differ markedly between specificationderived and non-specification-derived requirements. Among the 3,939 spec-SHRQs, 83% were approved, and 17% were rejected, whereas non-spec SHRQs exhibit a substantially lower acceptance rate, with approximately 10% approved and 90% rejected. This contrast indicates that requirement source and standardization play a dominant role in industrial acceptance decisions. In contrast, textual characteristics alone are insufficient to explain acceptance outcomes. In Table 2, while accepted SHRQs tend to exhibit higher lexical density, shorter sentences, and fewer clauses on average, rejected SHRQs display greater variability across these metrics. However, none of these linguistic properties decisively distinguishes accepted from rejected requirements in isolation. Taken together, these results suggest that acceptance decisions are not primarily driven by surface linguistic characteristics. Overall, these findings show that requirement sources dominate acceptance outcomes, while linguistic characteristics alone are insufficient to explain review decisions. To understand why requirements are rejected or conditionally approved, we next examine the explicit review rationales documented by engineers.

Finding 2: Acceptance outcomes are primarily driven by alignment with industry specifications and requirement origin, whereas linguistic characteristics alone do not reliably distinguish approved from rejected SHRQs in industrial review.

ASE ’26, October 12–16, 2026, Munich, Germany

Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen

5.2.2 RQ3: Rationales for Rejected or Deviation-Approved SHRQs. To address RQ3, we analyzed the documented rationales associated with rejected SHRQs and those approved with deviation. Due to the industrial context of the dataset, rationale documentation follows project-specific practices. The available annotations provide sufficient coverage to identify recurring decision patterns, as confirmed through expert validation. Since the dataset lacks predefined rationale categories, several domain experts with experience in automotive RE independently reviewed a sample of rationale comments and jointly defined a taxonomy of rationale types, resulting in 12 categories for rejection and 10 categories for approval with deviation. Using this taxonomy, the remaining rationale comments were automatically categorized using a large language model (GPT-4o) guided by the expert-defined taxonomy, as illustrated by the prompts on our website. We conducted humanin-the-loop validation, where domain experts reviewed a stratified random sample across categories to assess labeling accuracy. Disagreements were resolved by consensus. This mixed approach of expert-driven taxonomy and automated classification allowed us to capture the distribution of rationale types at scale while grounding the analysis in domain expertise. Rejection Rationales. The analysis of rejection rationales (Fig. 2) shows that many SHRQs fail because they misalign with the structural and organizational realities of automotive software development. The most frequent causes of rejection are scope- and relevance-related. As shown in Fig. 2, among the rejected SHRQs, 726 were marked as Not Applicable, 633 as Not a Requirement, and 363 as the responsibility of higher-level system integrators. Together, these account for over 72% of rejections with rationale, indicating that a large proportion of stakeholder submissions are not actionable requirements but rather contextual notes, organizational statements, or system-level responsibilities. For example, in Fig. 3, one requirement specified that unavailable configuration parameters should be “greyed out” rather than trigger an error, but this was dismissed as Not Applicable since it described tooling usability rather than product functionality. Similarly, the second statement was categorized as Not a Requirement, because it represented a design suggestion or explanatory note rather than enforceable system requirements. Another common rejection concerned scoping responsibilities: for instance, the third SHRQ in Fig. 3 was classified as Integrator Responsibility, since such functionality belongs to partner systems outside our project’s scope. Feasibility constraints represent another recurring rejection factor. Hardware Limitations alone account for 12.9%. The last example in Fig. 3 shows that one SHRQ demanded an error if a memory configuration parameter was not set to a specific byte alignment, but this was infeasible because the underlying sector boundaries did not support the prescribed alignment constraint. Additional cases were dismissed as Design Decisions or Process-Related issues, reflecting the frequent mismatch between stakeholder expectations and the realities of embedded hardware and architectures in safety-critical systems. Specification Compliance also plays a decisive role. Requirements conflicting with specifications or duplicating existing functionality are typically dismissed, underlining the centrality of alignment with standardized frameworks in automotive software engineering. Finally, intrinsic requirement quality defects, though fewer

in number, contribute meaningfully to rejections. Ambiguity, Unclear phrasing, obsolete statements, or Empty Functionality with no actionable semantics undermine engineers’ ability to formalize, implement, or test requirements. While less frequent than scoping issues, these linguistic and semantic defects directly impact the quality of downstream specifications.

Figure 2: Distribution and Percentage of Rejection Rationale

Figure 3: Examples of Rejection Approved with Deviation. Beyond binary acceptance and rejection, industrial practice also includes a third outcome: approved with deviation. Requirements in this category are formally accepted but require modification, clarification, or constraint during refinement. As shown in Fig. 4, Hardware Limitations dominate this category, followed by Tool or Standardization Issues, Redundancy and Partitioning, and Integration and Interoperability challenges. Additional factors include API Compliance, Configuration Variants, Error Handling, and Functional Safety or ASIL Compliance. In contrast to rejected SHRQs, which often fail due to scope, deviation cases expose the practical challenges of reconciling even well-specified requirements with hardware, toolchains, and integration realities. A closer inspection of the rationales reveals several recurring patterns that illustrate the unique character of automotive RE (Examples in Fig. 5). Unlike enterprise or consumer software, automotive requirements are deeply shaped by hardware capabilities, the evolution of specifications, and the need to integrate with tightly coupled execution environments. For example, deviations frequently arise from hardware limitations. Some SHRQs prescribe parameter

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry ASE ’26, October 12–16, 2026, Munich, Germany

Figure 4: Distribution and Percentage of Approved with Deviation Rationale

shaped primarily by customers and development teams, automotive requirements emerge from negotiation across multiple actors—standards bodies, OEMs, hardware constraints, and suppliers—making acceptance with deviation an inherent feature of the domain rather than an exception. Overall, SHRQs fail to achieve full approval for two main reasons. First, many are rejected due to mis-scoping, irrelevance, or intrinsic quality defects. Second, even approved requirements may conceal limitations when feasibility or architectural constraints force deviations. Both outcomes underscore the dual challenge of requirements validation in the automotive industry: early scoping and alignment with industry specifications are necessary to filter out irrelevant or defective inputs, while technical feasibility assessments are essential. Finding 3: Rejections are primarily driven by scope mismatches, hardware limitations, and conflicts with standards or specifications. Requirements approved with deviation reflect systematic adaptations in which stakeholder intent is preserved but reorganized to align with architectural partitioning, hardware capabilities, and integration constraints in automotive software systems.

5.3

Figure 5: Examples of Approved with Deviation ranges or supported modes that exceed the capabilities of the hardware (the first SHRQ in Fig. 5). In other cases, deviations arise from Tool and Standardization Issues, such as overly broad or outdated standard. The second SHRQ from specification shows that unrealistic standard requirement, where in EEPROM emulation were replaced with alternative formulations more aligned with current hardware. The third example (Redundancy and Partitioning) shows the corresponding responsibility reassigned to a replacement module. API behavior also drives deviations. The fourth SHRQ prescribes the use of API (e.g., CanIf controller), which could not be implemented directly at the driver level, where only hardware IDs were available, leading to re-scoped PRQs. Finally, Functional Safety and ASIL Compliance imposes selective application of standards. While SHRQs often demanded uniform ASIL D compliance, PRQs implemented ASIL levels selectively, depending on module criticality and hardware support. The prevalence of this outcome indicates that many SHRQs are neither outright acceptable nor wholly unsuitable, but require negotiation to reconcile intent with feasibility. Taken together, these cases reveal that deviation is not simply a sign of requirement quality but a structural mechanism through which automotive software negotiates between specifications, hardware feasibility, safety certification, and supplier differentiation. Unlike in general software engineering, where requirements are

Mapping Complexity

5.3.1 RQ4: Factors Influencing the Complexity of SHRQ–PRQ Mappings. To investigate how SHRQs are refined into PRQs and what drives the resulting complexity, we analyze both the structural distribution of SHRQ–PRQ mappings and the factors associated with more complex refinement patterns. Mapping Distributions and Structural Forms Overall, SHRQ–PRQ mappings are dominated by simple one-to-one relationships, but also include substantial cases of decomposition and consolidation (Table 3). From the stakeholder perspective (SHRQ → PRQ (decomposition)), each approved SHRQ maps to 1.93 PRQs on average, with a median of one. At least half of the SHRQs are realized through a single PRQ, while a quarter map to two or more PRQs. The distribution is long-tailed, with a maximum of 67 PRQs derived from a single SHRQ. From the product perspective (PRQ → SHRQ (consolidation)), each PRQ traces back to 1.32 SHRQs on average. Although one-to-one mappings are most common, rare many-to-one relationships occur, with some PRQs consolidating inputs from more than 20 SHRQs. These cases reflect the consolidation of overlapping or partially redundant stakeholder inputs to ensure consistency and avoid duplication at the product level. Together, these results show that while simple mappings dominate, many-to-many relationships are a fundamental aspect of industrial requirements refinement. One-to-many mappings (such as Fig. 1) reflect the decomposition of SHRQs that span multiple functional responsibilities, whereas many-to-one mappings reflect consolidation across heterogeneous stakeholder inputs. Length To assess whether mapping complexity can be explained by requirement length, we analyze the relationship between SHRQ length and the number of mapped PRQs. Textual length shows a weak positive association with mapping complexity. Using Spearman’s 𝜌, the token count (𝜌 =0.27) exhibits a statistically significant

ASE ’26, October 12–16, 2026, Munich, Germany

Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen

Table 3: Mapping Statistics between SHRQs and PRQs Mapping Direction

Count

Mean

Std

Min

25%

50%

75%

Max

SHRQ → PRQ Spec-derived Non-spec

3,688 3,270 418

1.93 1.74 3.40

2.91 2.30 5.58

1 1 1

1 1 1

1 1 2

2 2 3

67 67 46

PRQ → SHRQ

5,392

1.32

0.80

1

1

1

1

23

but weak correlation with the number of mapped PRQs, indicating that while longer SHRQs tend to map to slightly more PRQs, the weak correlation suggests that textual length plays a minor role in mapping complexity. Notably, this pattern remains consistent across requirement sources: spec-SHRQs and non-spec SHRQs exhibit nearly identical weak correlations (𝜌=0.30 and 𝜌=0.30, respectively). This consistency indicates that specification does not alter the relationship between textual length and mapping complexity. Fig. 6 shows substantial dispersion around the regression trend. SHRQs with similar token counts exhibit vastly different mapping patterns, ranging from simple one-to-one relationships to decompositions involving more than twenty PRQs. A short requirement such as “A safety management driver shall be provided” expands into 13 PRQs because it anchors a safety-critical mechanism spanning multiple modules, whereas a much longer SHRQ describing diagnostic faults across ASC/LIN/SPI channels results in few mappings through a single PRQ due to its localized architectural scope. These observations indicate that mapping complexity is driven less by textual properties than by the number of distinct functional and architectural concerns implicated by a requirement. Requirements spanning multiple subsystems, interfaces, or safety mechanisms require extensive decomposition, regardless of their textual brevity.

Figure 6: Mapping Complexity vs SHRQ Length: Overall and by Source Role of Specification in Mapping Complexity. Requirement source further shapes mapping complexity. Specification-derived SHRQs map to fewer PRQs on average (mean ≈ 1.74), reflecting their stable scope and alignment with established architectural and specification practices. In contrast, accepted non-spec SHRQs map to a larger number of PRQs on average (mean ≈ 3.40), indicating that such requirements often require substantial decomposition, re-scoping, or clarification before implementation. Notably, the most extreme decomposition cases occur among specification-derived SHRQs (maximum of 67 PRQs). These cases typically arise when reusable specification requirements serve as reference points that must be instantiated and adapted across multiple product contexts. Thus, specification constrains refinement into predictable clusters in most cases, while also enabling highly complex decompositions when reuse and instantiation are required.

These findings show that SHRQ–PRQ mapping complexity is primarily driven by architectural scope, functional dispersion, and contextual assumptions rather than by surface textual characteristics. Structural mapping patterns—ranging from one-to-one to many-to-many relationships—provide concrete evidence of how these drivers manifest during industrial requirements refinement.

Finding 4: SHRQ–PRQ mapping complexity is only weakly related to textual length and is driven mainly by architectural scope and specification context. Most mappings are one-to-one, but many-to-many structures emerge when requirements span multiple components or safety mechanisms. While specifications generally stabilize refinement, they can increase complexity when reused across different product contexts.

5.4

Contextual Knowledge in Refinement

5.4.1 RQ5: Missing Contextual information in Refinement. To address RQ5, we analyze what contextual information is missing in SHRQs and must be reconstructed during PRQ elaboration. Because a single requirement may lack multiple types of contextual information, we formulate this analysis as a multi-label classification problem. Domain engineers with experience in automotive requirements refinement defined a taxonomy of contextual information categories that reflect recurring information gaps observed in industrial practice. The final taxonomy comprises 13 categories, including operational context, conditional logic, functional behavior, error handling, configuration, interface specification, and safety and compliance, among others. Using this domain-defined taxonomy, we employ a large language model (GPT-4o) to classify each SHRQ–PRQ pair by identifying which contextual information categories are absent from the SHRQ but explicitly introduced in the corresponding PRQ. Consistent with the approach used in RQ3, we conduct human-in-the-loop validation, in which domain experts review a stratified sample of the classifications and resolve disagreements by consensus. Distribution of Missing Contextual Information Our SHRQ-level analysis shows that missing contextual information is both widespread and systematic. When aggregating missing categories across all PRQs linked to each SHRQ, operational context emerges as the most frequently absent category, missing in 81.5% of SHRQs. This indicates that most SHRQs do not specify the system states, operating modes, or conditions under which they apply. Several other categories are also commonly missing. Conditional logic is absent in 51.5% of SHRQs, and functional behavior in 45.0%, suggesting that requirements often express desired outcomes without defining triggering conditions or detailed system responses. Error handling (36.5%) and configuration information (29.5%) are also frequently missing, highlighting the gap between stakeholder intent and implementation-level precision. Fig. 1 shows a representative SHRQ–PRQ pair where multiple contextual dimensions, including implementation details, functional behavior, operational context, and conditional logic, are absent from the SHRQ and introduced during product-level elaboration. Overall, the five most common

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry ASE ’26, October 12–16, 2026, Munich, Germany

categories, each missing in more than a quarter of SHRQs, indicate that refinement typically involves enriching a recurring set of contextual dimensions rather than addressing isolated gaps. Extent of Contextual Incompleteness per SHRQ At the individual requirement level, missing context is common. Among 3,688 unique SHRQs, each requirement is missing an average of 3.65 contextual categories, with a median of 3. Only 0.2% are fully specified, while over 70% are missing three or more types of context. The most common case is three missing categories, and more than a quarter lack five or more, showing that refinement usually requires reconstructing a large amount of implicit knowledge. Co-occurrence of Missing Contextual Categories Missing contextual information usually appears in clusters rather than alone. Cooccurrence analysis shows that operational context is the most central missing category, frequently appearing alongside others. The most common pairings combine operational context with conditional logic, functional behavior, and error handling. This suggests that refinement typically requires coordinated additions across several interdependent dimensions. Engineers often must reconstruct execution conditions, system behavior, and failure handling together rather than filling a single gap. Relationship Between Missing Context and Refinement Complexity To quantify this effect, we examine the relationship between the number of missing contextual categories in an SHRQ and the number of PRQs derived from it. Both Pearson (r=0.44, p<0.001) and Spearman (𝜌=0.57, p<0.001) correlations show a moderate positive association, indicating that greater contextual incompleteness corresponds to higher refinement complexity. As shown in Fig. 7, the relationship is monotonic with a stepwise pattern. SHRQs missing zero or one category almost always map to a single PRQ, while those missing four to five categories typically require two PRQs. When eight or more categories are missing, a single SHRQ expands into nearly seven PRQs on average, with some cases exceeding ten. SHRQs missing only one or two categories never result in highly fragmented mappings, indicating that extensive decomposition occurs only when substantial contextual information is absent.

Figure 7: Missing Categories vs Number of Mapped PRQs Finding 5: SHRQs omit several interdependent types of contextual information, like operational context, conditional logic, and functional behavior, which must be reconstructed during product-level elaboration. These gaps rarely appear in isolation and strongly influence refinement effort, as SHRQs missing more contextual dimensions are much more likely to be decomposed into multiple PRQs.

6 Discussion 6.1 Synthesis: From Intake Filtering to Context Reconstruction Taken together, our findings suggest a two-stage picture of industrial requirements refinement. Intake acts as a scope filter: whether an SHRQ enters refinement is decided largely by its origin and responsibility boundaries, rarely by how well it is written (Findings 2 and 3). Refinement itself is knowledge reconstruction: effort is governed not by requirement length but by missing context and architectural scope (Findings 4 and 5). Industry specifications link the two stages: specification-derived SHRQs pass the filter more often (83% vs. 10%) and decompose less (1.74 vs. 3.40 PRQs), plausibly because standards pre-answer the context that engineers must otherwise reconstruct—and where a specification is reused across products, the same mechanism produces the most extreme decompositions (up to 67 PRQs).

6.2

Implications for Practice

First, early intake validation should explicitly consider the requirement source, scope, and standard alignment. Findings 2 and 3 show that non-specification SHRQs are often rejected or approved with deviation because they fall outside project scope, lack sufficient context, or conflict with architectural constraints. This extends prior work [17, 18, 20, 21] on requirement quality and smells, which focuses primarily on linguistic clarity and completeness, by showing that in automotive settings, acceptance depends more on scope and standard conformance than on surface-level textual quality. Lightweight intake checks that prioritize applicability, scope, and standards alignment, rather than linguistic polish alone, could substantially reduce downstream rework. Second, deviation should be treated as a first-class artifact rather than an exception. Finding 3 shows that “approved with deviation” is not an edge case but a systematic result of aligning standardized requirements with hardware feasibility and integration constraints. However, current tools often capture deviations informally or not at all. Explicit deviation modeling that records rationale, constraints, and downstream impact would improve transparency, traceability, and auditability in safety-critical development. Third, traceability management must move beyond link maintenance to actively support contextual enrichment. Findings 4 and 5 show that mapping complexity is only weakly associated with textual characteristics but strongly driven by missing contextual information and architectural scope. Tool support should therefore integrate standards references, hardware specifications, and module-level documentation directly into the refinement workflow. This would enable engineers to capture contextual knowledge when it is introduced, rather than reconstructing it later in an ad hoc way.

6.3

Implications for Research and Future Work

Beyond linguistic quality models. Findings 1 and 2 indicate that linguistic clarity alone is a poor predictor of acceptance. This contrasts with a large body of prior work on requirement smells and NLP-based quality assessment, which primarily targets ambiguity, verbosity, and syntactic defects (e.g., [18, 20, 21]). Our results suggest that such approaches, while valuable, are insufficient in

ASE ’26, October 12–16, 2026, Munich, Germany

Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen

isolation for safety-critical automotive systems, where feasibility, architectural scope, and standard compliance play a decisive role. Future research should combine NLP-based quality assessment with domain-aware checks that consider architectural scope, standard compliance, and feasibility constraints. Modeling deviation and feasibility explicitly. The prevalence of approval with deviation (Finding 3) suggests the need for formal models that treat deviation as a structured refinement outcome rather than a binary failure. This opens opportunities to study deviation patterns, predict feasibility issues early, and support tradeoff analysis in safety-critical RE. Context-aware automation for requirement refinement. Findings 4 and 5 show that refinement is a knowledge-intensive process, relying on external artifacts like industry specifications and hardware documentation. Future work can explore techniques that recommend contextual sources, suggest missing requirement elements, or support decomposition based on architectural knowledge—moving beyond text similarity toward context-aware assistance.

examined traceability practices in industry, highlighting challenges related to scalability and maintenance effort [12, 60]. Other work proposes modeling languages or refinement frameworks to support the transformation of informal stakeholder requirements into more formal specifications [37, 61]. Current work emphasizes creating or recovering traceability links rather than analyzing them as evidence of refinement decisions. As a result, little is known about why stakeholder requirements are accepted, rejected, consolidated, or approved with deviation, how mapping structures arise, or what drives refinement complexity in large-scale settings. This study treats stakeholder-toproduct refinement as an empirical decision-making process and analyzes acceptance, rejection, and deviation.

7

Related Work

Prior work has highlighted the challenges posed by heterogeneous functions [10], large-scale reuse [31, 51], and distributed development contexts [31, 51]. Architectural frameworks such as AUTOSAR [3] promote modularity and reuse through standardized interfaces, which in turn shape how requirements are formulated in practice to remain compatible with established services, data types, and communication mechanisms [30, 38, 56]. Also, functional safety standards such as ISO 26262 [25] mandate rigorous requirements processes, including completeness, consistency, and bidirectional traceability across abstraction levels [25, 55]. Empirical studies [9, 58] report that industrial automotive requirements frequently exhibit inconsistencies, ambiguity, and limited verifiability despite these standards. While these works establish the importance of requirements engineering in automotive systems, they focus on processes and compliance, offering limited insight into how requirements evolve across abstraction levels in practice. Against this domain background, a substantial body of research has examined the quality of natural-language requirements more broadly. Early frameworks such as IEEE 830 [33] and subsequent quality models emphasize properties including completeness, consistency, defects, and unambiguity [16, 34, 35, 43, 46]. Studies on requirement smells, controlled vocabularies, and structured templates demonstrate that linguistic regularization can reduce ambiguity and improve readability [17, 20, 21, 23, 27, 36]. More recent work [14, 22, 24] applies natural language processing and computational linguistics techniques to analyze sentence structure, lexical density, and domain terminology at scale. These approaches provide valuable methods for identifying quality defects, but they typically treat requirements as isolated textual artifacts, without considering their role within a larger refinement and acceptance process or the constraints imposed by safety-critical domains. Beyond individual requirement statements, traceability has long been recognized as essential for managing complexity in large software systems [28, 52]. Extensive research has explored automated traceability recovery using information retrieval, machine learning, and deep learning techniques [8, 11, 12]. Empirical studies have also

8

Conclusion

This paper examines how stakeholder-level requirements are refined into product-level requirements in industrial automotive software development and highlights the practical challenges of this transition. Using a large industrial dataset from Infineon, the study analyzes how requirements are evaluated, transformed, and contextualized in settings shaped by safety standards, architectural constraints, and hardware dependencies. The results reveal clear and systematic differences between stakeholder and product requirements in structure, granularity, and contextual completeness. The analysis further shows that decisions to accept, reject, or approve requirements with deviation are driven mainly by architectural scope, technical feasibility, and missing domain context, rather than by surface-level linguistic features. The observed stakeholder–product requirement mappings indicate that refinement complexity often arises from implicit assumptions that engineers must reconstruct from standards, specifications, and hardware documentation. This explains why even concise stakeholder requirements can require substantial elaboration and why deviations are a routine part of industrial requirements intake. Overall, the study provides the first industrial-scale empirical characterization of the structural relationship between stakeholder and product requirements and the decision-making processes involved in refinement within the automotive industry. By linking RE theory with standards-driven industrial practice, the findings offer practical guidance for improving requirement refinement. Future work can build on these results by enabling earlier estimation of refinement and risk and by developing tool support for context-aware requirement elaboration.

9

Data Availability Statement

The industrial dataset used in this study is proprietary and subject to confidentiality restrictions that preclude public release. More information, including detailed results and taxonomy prompts, can be found on our website: https://sites.google.com/view/shrq2prq.

References [1] 2018. ISO 26262-6:2018: Road vehicles – Functional safety – Part 6: Product development at the software level. [2] David Arthur, Christopher Becker, Alex Epstein, Bill Uhl, Scott Ranville, et al. 2022. Foundations of automotive software. Technical Report. United States. Department of Transportation. National Highway Traffic Safety . . . . [3] AUTOSAR Consortium. 2023. AUTOSAR Standard: Automotive Open System Architecture. AUTOSAR Development Partnership. https://www.autosar.org

Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry ASE ’26, October 12–16, 2026, Munich, Germany

[4] Peter Bergmiller. 2013. Design and safety analysis of a drive-by-wire vehicle. In Automotive Systems Engineering. Springer, 147–202. [5] Vincent Bertram, Hendrik Kausch, Evgeny Kusmenko, Haron Nqiri, Bernhard Rumpe, and Constantin Venhoff. 2023. Leveraging natural language processing for a consistency checking toolchain of automotive requirements. In 2023 IEEE 31st International Requirements Engineering Conference (RE). IEEE, 212–222. [6] Barry W Boehm and Philip N. Papaccio. 1988. Understanding and controlling software costs. IEEE transactions on software engineering 14, 10 (1988), 1462–1477. [7] Maria Bonner, Marc Zeller, Gabor Schulz, Dagmar Beyer, and Mihaela Olteanu. 2023. Automated Traceability between Requirements and Model-Based Design.. In REFSQ Workshops. [8] Markus Borg, Per Runeson, and Anders Ardö. 2014. Recovering from a decade: a systematic mapping of information retrieval approaches to software traceability. Empirical Software Engineering 19, 6 (2014), 1565–1616. [9] Peter Braun, Manfred Broy, Frank Houdek, Matthias Kirchmayr, Mark Müller, Birgit Penzenstadler, Klaus Pohl, and Thorsten Weyer. 2014. Guiding requirements engineering for software-intensive embedded systems in the automotive industry: The REMsES approach. Computer Science-Research and Development 29, 1 (2014), 21–43. [10] Manfred Broy. 2006. Challenges in automotive software engineering. In Proceedings of the 28th international conference on Software engineering. 33–42. [11] Jane Cleland-Huang, Orlena Gotel, Andrea Zisman, et al. 2012. Software and systems traceability. Vol. 2. Springer. [12] Jane Cleland-Huang, Orlena CZ Gotel, Jane Huffman Hayes, Patrick Mäder, and Andrea Zisman. 2014. Software traceability: trends and future directions. In Future of software engineering proceedings. 55–69. [13] Yanja Dajsuren and Mark van den Brand. 2019. Automotive software engineering: Past, present, and future. In Automotive Systems and Software Engineering: State of the Art and Future Trends. Springer, 3–8. [14] Fabiano Dalpiaz, Alessio Ferrari, Xavier Franch, and Cristina Palomares. [n. d.]. Natural Language Processing for Requirements Engineering. ([n. d.]). [15] Daniela Damian, James Chisan, Lakshminarayanan Vaidyanathasamy, and Yogendra Pal. 2005. Requirements engineering and downstream software development: Findings from a case study. Empirical Software Engineering 10, 3 (2005), 255. [16] Davide Falessi, Giovanni Cantone, and Gerardo Canfora. 2011. Empirical principles and an industrial case study in retrieving equivalent requirements via natural language processing techniques. IEEE Transactions on Software Engineering 39, 1 (2011), 18–44. [17] Alessandro Fantechi, Alessio Ferrari, Stefania Gnesi, and Laura Semini. 2018. Requirement engineering of software product lines: Extracting variability using NLP. In 2018 IEEE 26th international Requirements Engineering conference (RE). IEEE, 418–423. [18] Stefan Farfeleder, Thomas Moser, Andreas Krall, Tor Stålhane, Herbert Zojer, and Christian Panis. 2011. DODT: Increasing requirements formalism using domain ontologies for improved embedded systems development. In 14th IEEE international symposium on design and diagnostics of electronic circuits and systems. IEEE, 271–274. [19] Henning Femmer. 2017. Requirements engineering artifact quality: definition and control. Ph. D. Dissertation. Technische Universität München. [20] Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer. 2014. Rapid requirements checks with requirements smells: two case studies. In Proceedings of the 1st International Workshop on Rapid Continuous Software Engineering. 10–19. [21] Henning Femmer, Daniel Méndez Fernández, Stefan Wagner, and Sebastian Eder. 2017. Rapid quality assurance with requirements smells. Journal of Systems and Software 123 (2017), 190–213. [22] Henning Femmer, Frank Houdek, Max Unterbusch, and Andreas Vogelsang. 2025. Description and Comparative Analysis of QuRE: A New Industrial Requirements Quality Dataset. arXiv preprint arXiv:2508.08868 (2025). [23] D Méndez Fernández, Stefan Wagner, Marcos Kalinowski, Michael Felderer, Priscilla Mafra, Antonio Vetrò, Tayana Conte, M-T Christiansson, Des Greer, Casper Lassenius, et al. 2017. Naming the pain in requirements engineering: Contemporary problems, causes, and effects in practice. Empirical software engineering 22, 5 (2017), 2298–2338. [24] Alessio Ferrari, Giorgio Oronzo Spagnolo, and Stefania Gnesi. 2017. Pure: A dataset of public requirements documents. In 2017 IEEE 25th international requirements engineering conference (RE). IEEE, 502–505. [25] International Organization for Standardization. 2018. ISO 26262:2018 — Road vehicles — Functional safety. Standard. [26] Dominik Fuchß, Tobias Hey, Jan Keim, Haoyu Liu, Niklas Ewald, Tobias Thirolf, and Anne Koziolek. 2025. LiSSA: toward generic traceability link recovery through retrieval-augmented generation. In Proceedings of the IEEE/ACM 47th International Conference on Software Engineering. ICSE, Vol. 25. [27] Tom Gilb. 2005. Competitive engineering: a handbook for systems engineering, requirements engineering, and software engineering using Planguage. Elsevier. [28] Joseph A Goguen and Charlotte Linde. 1993. Techniques for requirements elicitation. In [1993] Proceedings of the IEEE International Symposium on Requirements Engineering. IEEE, 152–164.

[29] Samuel Greengard. 2015. Automotive systems get smarter. Commun. ACM 58, 10 (2015), 18–20. [30] Alireza Haghighatkhah, Ahmad Banijamali, Olli-Pekka Pakanen, Markku Oivo, and Pasi Kuvaja. 2017. Automotive software engineering: A systematic mapping study. Journal of Systems and Software 128 (2017), 25–55. [31] Alireza Haghighatkhah, Markku Oivo, Ahmad Banijamali, and Pasi Kuvaja. 2017. Improving the state of automotive software engineering. IEEE Software 34, 5 (2017), 82–86. [32] A Handbook. 2003. From contract drafting to software specification: Linguistic sources of ambiguity. (2003). [33] IEEE Computer Society. 1998. IEEE Recommended Practice for Software Requirements Specifications. Technical Report IEEE Std 830-1998. Institute of Electrical and Electronics Engineers (IEEE), New York, USA. [34] Elmar Juergens, Florian Deissenboeck, Martin Feilkas, Benjamin Hummel, Bernhard Schaetz, Stefan Wagner, Christoph Domann, and Jonathan Streit. 2010. Can clone detection support quality assessments of requirements specifications?. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 2. 79–88. [35] Leonid Kof. 2007. Treatment of passive voice and conjunctions in use case documents. In International Conference on Application of Natural Language to Information Systems. Springer, 181–192. [36] Giuseppe Lami, Stefania Gnesi, Fabrizio Fabbrini, Mario Fusani, and Gianluca Trentanni. 2004. An automatic tool for the analysis of natural language requirements. Informe técnico, CNR Information Science and Technology Institute, Pisa, Italia, Setiembre (2004). [37] Feng-Lin Li, Jennifer Horkoff, Alexander Borgida, Giancarlo Guizzardi, Lin Liu, and John Mylopoulos. 2015. From stakeholder requirements to formal specifications through refinement. In International Working Conference on Requirements Engineering: Foundation for Software Quality. Springer, 164–180. [38] Silverio Martínez-Fernández, Claudia P Ayala, Xavier Franch, and Elisa Y Nakagawa. 2015. A Survey on the Benefits and Drawbacks of AUTOSAR. In Proceedings of the first international workshop on automotive software architecture. 19–26. [39] Tundiya Mayur Kalubhai. 2025. Advancing Automotive Innovation: Addressing Software and Technology Failures for Enhanced Reliability and Safety. American Journal of Business Practice 2, 1 (2025), 42–50. [40] Dragan Milchevski, Gordon Frank, Anna Hätty, Bingqing Wang, Xiaowei Zhou, and Zhe Feng. 2025. Multi-Step Generation of Test Specifications using Large Language Models for System-Level Requirements. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 6: Industry Track). 132–146. [41] Tian Seng Ng. 2021. Robotic Vehicles: Systems and Technology. Springer. [42] Feifei Niu, Rongqi Pan, Lionel C Briand, and Hanyang Hu. 2025. Tvr: Automotive system requirement traceability validation and recovery through retrievalaugmented generation. arXiv preprint arXiv:2504.15427 (2025). [43] Bashar Nuseibeh and Steve Easterbrook. 2000. Requirements engineering: a roadmap. In Proceedings of the Conference on the Future of Software Engineering. 35–46. [44] Daniel Ott. 2012. Defects in natural language requirement specifications at mercedes-benz: An investigation using a combination of legacy data and expert opinion. In 2012 20th IEEE International Requirements Engineering Conference (RE). IEEE, 291–296. [45] Juraj Pancik, Aleš Vemola, Robert Kledus, Marek Semela, and A Bradac. 2018. Auto recalls and software quality in the automotive sector. EAI Endorsed Transactions on Scalable Information Systems 5, 17 (2018). [46] Klaus Pohl. 1996. Requirements engineering: An overview. RWTH, Fachgruppe Informatik Aachen. [47] Klaus Pohl. 2016. Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level-IREB compliant. Rocky Nook, Inc. [48] Klaus Pohl. 2024. Fundamentals, Principles, and Techniques. Requirements Engineering (2024). [49] Klaus Pohl, Manfred Broy, Heinrich Daembkes, and Harald Hönninger. 2016. Advanced model-based engineering of embedded systems. In Advanced ModelBased Engineering of Embedded Systems: Extensions of the SPES 2020 Methodology. Springer, 3–9. [50] K Venkatesh Prasad, Thomas J Giuli, and David Watson. 2006. The case for modeling security, privacy, usability and reliability (SPUR) in automotive software. In Automotive Software Workshop. Springer, 1–14. [51] Alexander Pretschner, Manfred Broy, Ingolf H Kruger, and Thomas Stauner. 2007. Software engineering for automotive systems: A roadmap. In Future of Software Engineering (FOSE’07). IEEE, 55–71. [52] Balasubramaniam Ramesh and Matthias Jarke. 2002. Toward reference models for requirements traceability. IEEE transactions on software engineering 27, 1 (2002), 58–93. [53] Aaron Schlutter and Andreas Vogelsang. 2018. Knowledge representation of requirements documents using natural language processing. In REFSQ Workshops. [54] Aaron Schlutter and Andreas Vogelsang. 2020. Knowledge extraction from natural language requirements into a semantic relation graph. In Proceedings of

ASE ’26, October 12–16, 2026, Munich, Germany

Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen

the IEEE/ACM 42nd International Conference on Software Engineering Workshops. 373–379. [55] Florian Schneider and Brian Berenbach. 2013. A literature survey on international standards for systems requirements engineering. Procedia Computer Science 16 (2013), 796–805. [56] Miroslaw Staron. 2021. Automotive software architectures. Springer. [57] VDA QMC and intacs. 2017. Automotive SPICE: Process Assessment Model (PAM), Version 3.1. Technical Report. Quality Management Center (QMC), German Association of the Automotive Industry (VDA) and intacs. [58] Andreas Vogelsang. 2015. Model-based requirements engineering for multifunctional systems. Ph. D. Dissertation. Technische Universität München.

[59] Matthias Weber and Joachim Weisbrod. 2002. Requirements engineering in automotive development-experiences and challenges. In Proceedings IEEE Joint International Conference on Requirements Engineering. IEEE, 331–340. [60] Stefan Winkler and Jens von Pilgrim. 2010. A survey of traceability in requirements engineering and model-driven development. Software & Systems Modeling 9, 4 (2010), 529–565. [61] Pamela Zave and Michael Jackson. 1997. Four dark corners of requirements engineering. ACM transactions on Software Engineering and Methodology (TOSEM) 6, 1 (1997), 1–30.