Pith. sign in

REVIEW 4 major objections 6 minor 63 references

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

T0 review · 4 major / 6 minor · reviewed 2026-07-11 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Automotive stakeholder-to-product requirement refinement is driven by architectural scope and missing context, not by how long or complex the wording is.

desk verdict Solid industrial RE study with real scale and useful practice findings; the headline “missing context drives complexity” claim is partly mechanically entangled with how missingness is measured, but the rest of the evidence still holds up for ASE-style work. read the letter →

arxiv 2607.05632 v1 pith:KQW5FS53 submitted 2026-07-06 cs.SE

Zixu Wang , Shengcheng Yu , Zhenchang Xing , Tobias Wenzel , Chunyang Chen This is my paper · ORCID
classification cs.SE
keywords EmpiricalStudyRequirementsEngineeringAutomotiveSoftwareRequirementRefinementTraceabilityStakeholderProduct
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper sets out how industrial automotive teams actually intake, judge, and refine high-level stakeholder requirements into implementable product requirements. Using a large industrial corpus of thousands of requirements with acceptance outcomes, deviation rationales, and trace links, it shows clear structural differences across abstraction levels and that acceptance is governed mainly by source and scope alignment with industry specifications. The central claim is that refinement effort tracks architectural breadth and missing operational, conditional, and behavioral context far more than linguistic length or readability. That matters because safety compliance, reuse, defect cost, and development speed all depend on this early bridge, yet most prior quality work judged isolated wording rather than the end-to-end industrial process. The study turns that process into evidence: mapping patterns, rejection and deviation rationales, and a catalogue of the context engineers must reconstruct.

What carries the argument

A mixed-methods analysis of an industrial stakeholder–product requirement corpus with explicit trace links, decision outcomes, and rationales, yielding a taxonomy of mapping patterns (one-to-one, decomposition, consolidation) and a multi-label taxonomy of missing contextual categories that co-occur and predict refinement fragmentation.

What would settle it

A comparable multi-supplier automotive requirements corpus in which textual length strongly predicts both acceptance and the number of derived product requirements, while specification origin and measured missing-context counts do not, would falsify the claimed primary drivers.

Watch

Extended reading notes

Core claim

In industrial automotive practice, the complexity of refining stakeholder requirements into product requirements is driven primarily by architectural scope and missing contextual information—especially operational context, conditional logic, and functional behavior—rather than by textual length or surface linguistic quality. Acceptance and rejection are dominated by origin and scope alignment with industry specifications; approval with deviation is a routine structural mechanism for reconciling intent with hardware, architecture, and integration constraints.

Load-bearing premise

The study assumes one company's industrial requirement corpus, plus expert-guided automated labeling of rationales and missing context, fairly represents how automotive refinement decisions and context reconstruction work in general.

Editorial extensions

If this is right

  • Intake validation should prioritize source, scope, and standard alignment rather than linguistic polish alone.
  • Approval with deviation should be treated as a first-class, auditable refinement outcome, not an informal exception.
  • Traceability support must enable active contextual enrichment from standards and hardware documentation, not only link maintenance.
  • Linguistic quality checks alone are weak predictors of acceptance in safety-critical automotive settings.
  • Automation for refinement should recommend missing context and architectural decomposition rather than relying mainly on text similarity.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If missing-context load predicts decomposition, intake templates that force operational modes, triggers, and error handling could cut many-to-many mappings before review.
  • The same filter-then-reconstruct pattern likely appears in other standards-heavy cyber-physical domains, not only automotive chip development.
  • Any tooling built on these taxonomies inherits the fidelity of automated rationale and context labeling as a hidden dependency.
  • Structured deviation records could support early feasibility predictors for new stakeholder submissions.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. This paper reports a large-scale mixed-methods empirical study of how stakeholder requirements (SHRQs) are evaluated and refined into product requirements (PRQs) in industrial automotive chip development at Infineon. Using 8,082 SHRQs and 5,870 PRQs with traceability, acceptance/rejection outcomes, deviation rationales, and domain references, the authors characterize linguistic/structural differences across abstraction levels (RQ1), factors associated with acceptance vs. rejection (RQ2–RQ3), SHRQ–PRQ mapping structure and complexity (RQ4), and missing contextual information reconstructed during refinement (RQ5). The central claim is that refinement complexity is driven primarily by architectural scope and missing contextual information rather than linguistic verbosity, and that acceptance is dominated by specification origin and scope alignment rather than surface textual quality. The paper further claims a taxonomy of mapping patterns linked to refinement effort and derives practice implications for intake validation, deviation management, and context-aware tooling.

Significance. If the results hold under cleaner identification and clearer external-validity bounds, this is a substantial contribution to empirical requirements engineering. Industrial-scale joint analysis of stakeholder- and product-level requirements with real review decisions and traceability is rare; the dataset size, decision rationales, and mapping statistics go well beyond typical RE quality studies that treat requirements as isolated NL artifacts. The descriptive findings on specification-origin acceptance gaps (≈83% vs. ≈10%), rejection/deviation rationale distributions, and weak length–mapping correlation (Spearman ρ≈0.27) are already useful for automotive RE practice and for calibrating NLP quality tools that currently over-weight linguistic smells. Explicit credit is due for the industrial collaboration, the dual quantitative/qualitative design, and the concrete practice implications (intake as scope filter; deviation as first-class artifact). The load-bearing causal claim about missing context, however, needs tighter measurement and wording before the paper can fully support the abstract’s strongest assertion.

major comments (4)
  1. [§5.4.1 / Finding 5 / Fig. 7] §5.4.1, Finding 5, Fig. 7, and the abstract: the independent variable “number of missing contextual categories” is constructed from SHRQ–PRQ pairs by labeling categories absent in the SHRQ but introduced in linked PRQs, then taking the union over all PRQs of that SHRQ. The dependent variable is the number of those same PRQs. Under this operationalization, more PRQs mechanically enlarge the opportunity set for distinct categories to appear, so a positive association (Pearson r=0.44, Spearman ρ=0.57) is expected even under a null of no causal drive from incompleteness to decomposition. The “not verbosity” half is independently supported by the weak length correlation in §5.3 (ρ≈0.27), but the positive claim that missing context drives refinement complexity is not cleanly identified. Please (i) reframe as a descriptive co-occurrence/association rather than a driver, and/or (ii) re-measure m
  2. [§5.2.2 and §5.4.1] §5.2.2 (RQ3) and §5.4.1 (RQ5): rejection/deviation rationales and the 13-category missing-context taxonomy are labeled at scale with GPT-4o after expert seed taxonomies, with only stratified human-in-the-loop consensus on a sample. No sample size, agreement statistics (e.g., Cohen’s/Fleiss’ κ or percent agreement), or estimated label error rates are reported. These labels underpin Finding 3, Finding 5, and the practice implications on intake and contextual enrichment. Please report validation protocol numbers and sensitivity of the main distributions/correlations to labeling error; if agreement is modest, temper claims accordingly.
  3. [Abstract / §5.3 (RQ4) / Contributions] Abstract and contribution bullet on “a taxonomy of SHRQ–PRQ mapping patterns … related to differing refinement effort” overstates what §5.3 delivers. The results mainly report cardinality statistics (SHRQ→PRQ mean 1.93; PRQ→SHRQ mean 1.32; long tails; one-to-one vs. decomposition/consolidation) and source differences (spec mean ≈1.74 vs. non-spec ≈3.40), plus qualitative examples of architectural scope. There is no named pattern taxonomy with explicit effort measures beyond PRQ count. Either present a concrete taxonomy (named patterns, decision rules, effort proxies) or revise the abstract/contributions to match the structural mapping analysis actually performed.
  4. [Study Design / Discussion / missing Threats section] The manuscript lacks a dedicated Threats to Validity section, which is load-bearing for an industrial single-company study whose strongest claims are framed as general automotive RE insights. §4 and §6 note Infineon provenance and proprietary limits, but do not systematically treat construct validity of the missing-context and rationale taxonomies, internal validity of the complexity associations, or external validity beyond one semiconductor supplier’s tool workflow and documentation style. Please add a threats section and align causal language in the abstract, Findings 4–5, and §6.1 with what the design can support (observational associations within one organization).
minor comments (6)
  1. [Table 2 / §5.1.1] Table 2 readability: Flesch–Kincaid grade levels of 21–26 for SHRQs are extreme; briefly note domain jargon/formula effects so readers do not over-interpret absolute grade scores.
  2. [§5.2.2 / Figs. 2–5] Fig. 2–5 examples are helpful but some figure captions and in-text percentages (e.g., “over 72% of rejections with rationale”) should state denominators explicitly (all rejected vs. rejected-with-rationale).
  3. [Table 1 / §4.2] §4.1–4.2: clarify how “approved with deviation” is represented in the status counts (Table 1 lists Approved/Rejected for SHRQs only) and whether deviation cases are a subset of the 3,688 approved.
  4. [§7 / Contributions] Related Work §7 is solid but could more sharply contrast this study with REMsES and prior automotive RE industrial reports when claiming “first” industrial-scale joint SHRQ–PRQ analysis.
  5. [Title / §2.2 / §6.1] Minor prose issues: “Requirement Engineering” in the title vs. “Requirements Engineering” elsewhere; a few long sentences in §2.2 and §6.1 could be tightened for ASE readability.
  6. [§9 Data Availability] Data availability points to a website for prompts/taxonomies; for reviewability, include the expert category definitions (even if anonymized) in an appendix or supplemental PDF, not only an external site.

Circularity Check

1 steps flagged · score 3.0 of 10

Mild self-definitional circularity: missing-context count is the union of categories introduced by the PRQs whose cardinality is the dependent variable for refinement complexity.

  1. self definitional [§5.4.1 (RQ5), Finding 5, Fig. 7; also abstract & §6.1]
    "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. ... 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 ... SHRQs missing more contextual dimensions are much more likely to be decomposed into multiple PRQs."

    The IV (count of missing categories per SHRQ) is defined as the size of the union of categories that the linked PRQs themselves introduce. Larger |PRQs| therefore enlarges the opportunity set for distinct categories, inducing a positive association with the DV (number of mapped PRQs) partly by construction of the measure rather than as independent evidence that missing context drives refinement complexity. The causal wording “driven by” / “strongly influence” in the abstract, Finding 5 and Discussion therefore rests on a quantity that is not an a-priori property of the SHRQ alone.

full rationale

This is an observational industrial empirical study (mixed-methods analysis of Infineon SHRQ/PRQ data, decisions, and links), not a first-principles derivation or parameter-fitted prediction of a target quantity. Most findings (linguistic differences RQ1, acceptance by source RQ2, rejection/deviation rationales RQ3, weak length–mapping correlation and mapping taxonomy RQ4) rest on independent measurements of text, status, and explicit traceability links; they do not reduce to their inputs by construction. The sole load-bearing circular step is in RQ5/Finding 5: the independent variable “number of missing contextual categories” is obtained by multi-label classification of each SHRQ–PRQ pair for categories “absent from the SHRQ but explicitly introduced in the corresponding PRQ,” then taking the union over all PRQs linked to that SHRQ. That count is therefore constructed from the content (and, via opportunity set, the cardinality) of the very refinement outcomes whose number is correlated (Spearman ρ=0.57). The positive association is therefore partly mechanical rather than cleanly identified evidence that incompleteness drives decomposition. Architectural-scope arguments remain qualitative/example-based and the “not verbosity” half is independently supported by the weak length correlation; hence only partial circularity and a low score. No self-citation uniqueness theorems, fitted-parameter-as-prediction, or ansatz-smuggling appear.

Assumptions & free parameters 0 free parameters · 4 assumptions · 3 invented entities

As an empirical SE study, the load-bearing content is not free mathematical parameters but domain assumptions about process fidelity, data completeness, and labeling validity. The main invented constructs are the expert/LLM taxonomies used to interpret rationales and missing context. No physical constants or fitted scientific scales appear; the quantitative claims rest on corpus statistics and correlation coefficients computed on proprietary labeled data.

assumptions (4)
  • domain assumption Infineon's exported SHRQ/PRQ texts, acceptance statuses, rationales, and trace links are complete and faithful records of industrial refinement decisions rather than incomplete or post-hoc documentation.
    Study Design §4.1–4.2 treats tool exports as a reliable basis for analyzing acceptance and refinement behavior.
  • domain assumption Patterns observed at Infineon (semiconductor supplier in automotive chip projects under ISO 26262/AUTOSAR-like constraints) are informative for broader automotive RE practice.
    Implications and conclusion generalize from one industrial partner without multi-site replication.
  • ad hoc to paper Expert-defined taxonomies plus GPT-4o multi-label classification with stratified human consensus validation sufficiently recover true rejection/deviation reasons and missing contextual categories.
    RQ3 and RQ5 methods; accuracy of bulk labels is not fully quantified beyond sampled review.
  • domain assumption Standard linguistic metrics (token length, clauses, Flesch–Kincaid, lexical density) and mapping fan-out are valid proxies for structural complexity and refinement effort.
    RQ1/RQ4 analyses following prior RE linguistic tooling [22,24].
invented entities (3)
  • 12-category rejection rationale taxonomy and 10-category approval-with-deviation taxonomy
    purpose: Structure industrial review comments to explain acceptance outcomes (RQ3).
    Jointly defined by domain experts then applied via LLM; not an external standard taxonomy.
  • 13-category missing-context taxonomy (operational context, conditional logic, functional behavior, error handling, etc.)
    purpose: Label what SHRQs omit and PRQs introduce to explain refinement complexity (RQ5).
    Domain-engineer-defined multi-label scheme used for SHRQ–PRQ pair classification.
  • Taxonomy of SHRQ–PRQ mapping patterns linked to refinement effort
    purpose: Characterize one-to-one, decomposition, and consolidation structures and their drivers (RQ4/contributions).
    Derived from industrial mapping distributions and qualitative interpretation of architectural scope.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry." pith.science (2026). https://pith.science/paper/KQW5FS53

@misc{pith2026260705632,
  author       = {Pith},
  title        = {Pith review of: Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KQW5FS53}},
  note         = {Machine review of arXiv:2607.05632}
}
read the original abstract

The automotive industry's shift toward software-driven systems has increased system complexity and raised the importance of effective requirement intake and refinement for correctness, compliance, development speed, and systematic reuse. Although prior research has proposed techniques for improving requirement quality, limited empirical evidence exists on how stakeholder-level requirements are evaluated, refined, and transformed into product-level requirements in industrial automotive practice. This paper presents a large-scale empirical study 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, we combine quantitative analyses of requirement structures, decision distributions, and mapping patterns with qualitative analyses of rationales, 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 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 mapping patterns and relate these patterns to differing refinement effort. The findings provide concrete insight into industrial requirements intake and refinement practices and identify actionable opportunities for improving intake validation, deviation management, and tool-supported contextual enrichment to support faster and more reusable automotive product development.

Figures

Figures reproduced from arXiv: 2607.05632 by the authors.

Figure 1
Figure 1. Transformation Process from Stakeholder to Prod [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Distribution and Percentage of Rejection Rationale [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Examples of Rejection Approved with Deviation. Beyond binary acceptance and rejec￾tion, industrial practice also includes a third outcome: approved with deviation. Requirements in this category are formally accepted but require modification, clarification, or constraint during refine￾ment. As shown in [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Distribution and Percentage of Approved with De [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Examples of Approved with Deviation ranges or supported modes that exceed the capabilities of the hard￾ware (the first SHRQ in [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Mapping Complexity vs SHRQ Length: Overall and [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Missing Categories vs Number of Mapped PRQs [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

63 extracted references · 62 canonical work pages

  1. [1]

    ISO 26262-6:2018: Road vehicles – Functional safety – Part 6: Product development at the software level

    2018. ISO 26262-6:2018: Road vehicles – Functional safety – Part 6: Product development at the software level

    work page 2018

  2. [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

    work page 2022

  3. [3]

    2023.AUTOSAR Standard: Automotive Open System Architecture

    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

    work page 2023

  4. [4]

    Peter Bergmiller. 2013. Design and safety analysis of a drive-by-wire vehicle. In Automotive Systems Engineering. Springer, 147–202

    work page 2013

  5. [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. In2023 IEEE 31st International Requirements Engineering Conference (RE). IEEE, 212–222

    work page 2023

  6. [6]

    Papaccio

    Barry W Boehm and Philip N. Papaccio. 1988. Understanding and controlling software costs.IEEE transactions on software engineering14, 10 (1988), 1462–1477

    work page 1988

  7. [7]

    Maria Bonner, Marc Zeller, Gabor Schulz, Dagmar Beyer, and Mihaela Olteanu

    work page

  8. [8]

    InREFSQ Workshops

    Automated Traceability between Requirements and Model-Based Design.. InREFSQ Workshops

    work page

Show all 63 references
  1. [9]

    Markus Borg, Per Runeson, and Anders Ardö. 2014. Recovering from a decade: a systematic mapping of information retrieval approaches to software traceability. Empirical Software Engineering19, 6 (2014), 1565–1616

    2014

  2. [10]

    Peter Braun, Manfred Broy, Frank Houdek, Matthias Kirchmayr, Mark Müller, Birgit Penzenstadler, Klaus Pohl, and Thorsten Weyer. 2014. Guiding require- ments engineering for software-intensive embedded systems in the automotive industry: The REMsES approach.Computer Science-Res...

    2014

  3. [11]

    Manfred Broy. 2006. Challenges in automotive software engineering. InProceed- ings of the 28th international conference on Software engineering. 33–42

    2006

  4. [12]

    2012.Software and systems traceability

    Jane Cleland-Huang, Orlena Gotel, Andrea Zisman, et al . 2012.Software and systems traceability. Vol. 2. Springer

    2012

  5. [13]

    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

    2014

  6. [14]

    Yanja Dajsuren and Mark van den Brand. 2019. Automotive software engineering: Past, present, and future. InAutomotive Systems and Software Engineering: State of the Art and Future Trends. Springer, 3–8

    2019

  7. [15]

    Fabiano Dalpiaz, Alessio Ferrari, Xavier Franch, and Cristina Palomares. [n. d.]. Natural Language Processing for Requirements Engineering. ([n. d.])

  8. [16]

    Daniela Damian, James Chisan, Lakshminarayanan Vaidyanathasamy, and Yogen- dra Pal. 2005. Requirements engineering and downstream software development: Findings from a case study.Empirical Software Engineering10, 3 (2005), 255

    2005

  9. [17]

    Davide Falessi, Giovanni Cantone, and Gerardo Canfora. 2011. Empirical princi- ples and an industrial case study in retrieving equivalent requirements via natural language processing techniques.IEEE Transactions on Software Engineering39, 1 (2011), 18–44

    2011

  10. [18]

    Alessandro Fantechi, Alessio Ferrari, Stefania Gnesi, and Laura Semini. 2018. Requirement engineering of software product lines: Extracting variability using NLP. In2018 IEEE 26th international Requirements Engineering conference (RE). IEEE, 418–423

    2018

  11. [19]

    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. In14th IEEE international symposium on design and diagnostics of e...

    2011

  12. [20]

    2017.Requirements engineering artifact quality: definition and control

    Henning Femmer. 2017.Requirements engineering artifact quality: definition and control. Ph. D. Dissertation. Technische Universität München

    2017

  13. [21]

    Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer. 2014. Rapid requirements checks with require- ments smells: two case studies. InProceedings of the 1st International Workshop on Rapid Continuous Software Engineering. 10–19

    2014

  14. [22]

    Henning Femmer, Daniel Méndez Fernández, Stefan Wagner, and Sebastian Eder

  15. [23]

    Rapid quality assurance with requirements smells.Journal of Systems and Software123 (2017), 190–213

    2017

  16. [24]

    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)

    2025 arXiv

  17. [25]

    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 practi...

    2017

  18. [26]

    Alessio Ferrari, Giorgio Oronzo Spagnolo, and Stefania Gnesi. 2017. Pure: A dataset of public requirements documents. In2017 IEEE 25th international require- ments engineering conference (RE). IEEE, 502–505

    2017

  19. [27]

    International Organization for Standardization. 2018. ISO 26262:2018 — Road vehicles — Functional safety. Standard

    2018

  20. [28]

    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. InProceedings of the IEEE/ACM 47th International Conference on Software Engineering. ...

    2025

  21. [29]

    2005.Competitive engineering: a handbook for systems engineering, requirements engineering, and software engineering using Planguage

    Tom Gilb. 2005.Competitive engineering: a handbook for systems engineering, requirements engineering, and software engineering using Planguage. Elsevier

    2005

  22. [30]

    Joseph A Goguen and Charlotte Linde. 1993. Techniques for requirements elici- tation. In[1993] Proceedings of the IEEE International Symposium on Requirements Engineering. IEEE, 152–164

    1993

  23. [31]

    Samuel Greengard. 2015. Automotive systems get smarter.Commun. ACM58, 10 (2015), 18–20

    2015

  24. [32]

    Alireza Haghighatkhah, Ahmad Banijamali, Olli-Pekka Pakanen, Markku Oivo, and Pasi Kuvaja. 2017. Automotive software engineering: A systematic mapping study.Journal of Systems and Software128 (2017), 25–55

    2017

  25. [33]

    Alireza Haghighatkhah, Markku Oivo, Ahmad Banijamali, and Pasi Kuvaja. 2017. Improving the state of automotive software engineering.IEEE Software34, 5 (2017), 82–86

    2017

  26. [34]

    A Handbook. 2003. From contract drafting to software specification: Linguistic sources of ambiguity. (2003)

    2003

  27. [35]

    1998.IEEE Recommended Practice for Software Require- ments Specifications

    IEEE Computer Society. 1998.IEEE Recommended Practice for Software Require- ments Specifications. Technical Report IEEE Std 830-1998. Institute of Electrical and Electronics Engineers (IEEE), New York, USA

    1998

  28. [36]

    Elmar Juergens, Florian Deissenboeck, Martin Feilkas, Benjamin Hummel, Bern- hard Schaetz, Stefan Wagner, Christoph Domann, and Jonathan Streit. 2010. Can clone detection support quality assessments of requirements specifica- tions?. InProceedings of the 32nd ACM/IEEE Internat...

    2010

  29. [37]

    Leonid Kof. 2007. Treatment of passive voice and conjunctions in use case documents. InInternational Conference on Application of Natural Language to Information Systems. Springer, 181–192

    2007

  30. [38]

    Giuseppe Lami, Stefania Gnesi, Fabrizio Fabbrini, Mario Fusani, and Gianluca Trentanni. 2004. An automatic tool for the analysis of natural language require- ments.Informe técnico, CNR Information Science and Technology Institute, Pisa, Italia, Setiembre(2004)

    2004

  31. [39]

    Feng-Lin Li, Jennifer Horkoff, Alexander Borgida, Giancarlo Guizzardi, Lin Liu, and John Mylopoulos. 2015. From stakeholder requirements to formal specifica- tions through refinement. InInternational Working Conference on Requirements Engineering: Foundation for Software Quali...

    2015

  32. [40]

    Silverio Martínez-Fernández, Claudia P Ayala, Xavier Franch, and Elisa Y Naka- gawa. 2015. A Survey on the Benefits and Drawbacks of AUTOSAR. InProceedings of the first international workshop on automotive software architecture. 19–26

    2015

  33. [41]

    Tundiya Mayur Kalubhai. 2025. Advancing Automotive Innovation: Addressing Software and Technology Failures for Enhanced Reliability and Safety.American Journal of Business Practice2, 1 (2025), 42–50

    2025

  34. [42]

    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. InProceedings of the 63rd An- nual Meeting of the Association for Computational...

    2025

  35. [43]

    2021.Robotic Vehicles: Systems and Technology

    Tian Seng Ng. 2021.Robotic Vehicles: Systems and Technology. Springer

    2021

  36. [44]

    Feifei Niu, Rongqi Pan, Lionel C Briand, and Hanyang Hu. 2025. Tvr: Automo- tive system requirement traceability validation and recovery through retrieval- augmented generation.arXiv preprint arXiv:2504.15427(2025)

    2025 arXiv

  37. [45]

    Bashar Nuseibeh and Steve Easterbrook. 2000. Requirements engineering: a roadmap. InProceedings of the Conference on the Future of Software Engineering. 35–46

    2000

  38. [46]

    Daniel Ott. 2012. Defects in natural language requirement specifications at mercedes-benz: An investigation using a combination of legacy data and expert opinion. In2012 20th IEEE International Requirements Engineering Conference (RE). IEEE, 291–296

    2012

  39. [47]

    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 Systems5, 17 (2018)

    2018

  40. [48]

    1996.Requirements engineering: An overview

    Klaus Pohl. 1996.Requirements engineering: An overview. RWTH, Fachgruppe Informatik Aachen

    1996

  41. [49]

    2016.Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level-IREB compliant

    Klaus Pohl. 2016.Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level-IREB compliant. Rocky Nook, Inc

    2016

  42. [50]

    Klaus Pohl. 2024. Fundamentals, Principles, and Techniques.Requirements Engineering(2024)

    2024

  43. [51]

    Klaus Pohl, Manfred Broy, Heinrich Daembkes, and Harald Hönninger. 2016. Advanced model-based engineering of embedded systems. InAdvanced Model- Based Engineering of Embedded Systems: Extensions of the SPES 2020 Methodology. Springer, 3–9

    2016

  44. [52]

    K Venkatesh Prasad, Thomas J Giuli, and David Watson. 2006. The case for mod- eling security, privacy, usability and reliability (SPUR) in automotive software. InAutomotive Software Workshop. Springer, 1–14

    2006

  45. [53]

    Alexander Pretschner, Manfred Broy, Ingolf H Kruger, and Thomas Stauner. 2007. Software engineering for automotive systems: A roadmap. InFuture of Software Engineering (FOSE’07). IEEE, 55–71

    2007

  46. [54]

    Balasubramaniam Ramesh and Matthias Jarke. 2002. Toward reference models for requirements traceability.IEEE transactions on software engineering27, 1 (2002), 58–93

    2002

  47. [55]

    Aaron Schlutter and Andreas Vogelsang. 2018. Knowledge representation of requirements documents using natural language processing. InREFSQ Workshops

    2018

  48. [56]

    Aaron Schlutter and Andreas Vogelsang. 2020. Knowledge extraction from natural language requirements into a semantic relation graph. InProceedings of ASE ’26, October 12–16, 2026, Munich, Germany Zixu Wang, Shengcheng Yu, Zhenchang Xing, Tobias Wenzel, and Chunyang Chen the IE...

    2020

  49. [57]

    Florian Schneider and Brian Berenbach. 2013. A literature survey on international standards for systems requirements engineering.Procedia Computer Science16 (2013), 796–805

    2013

  50. [58]

    2021.Automotive software architectures

    Miroslaw Staron. 2021.Automotive software architectures. Springer

    2021

  51. [59]

    2017.Automotive SPICE: Process Assessment Model (PAM), Version 3.1

    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

    2017

  52. [60]

    2015.Model-based requirements engineering for multifunc- tional systems

    Andreas Vogelsang. 2015.Model-based requirements engineering for multifunc- tional systems. Ph. D. Dissertation. Technische Universität München

    2015

  53. [61]

    Matthias Weber and Joachim Weisbrod. 2002. Requirements engineering in automotive development-experiences and challenges. InProceedings IEEE Joint International Conference on Requirements Engineering. IEEE, 331–340

    2002

  54. [62]

    Stefan Winkler and Jens von Pilgrim. 2010. A survey of traceability in require- ments engineering and model-driven development.Software & Systems Modeling 9, 4 (2010), 529–565

    2010

  55. [63]

    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

    1997

Pith tools

Reviewed July 11, 2026 · model on record in the stance chip above.