pith. sign in

arxiv: 2604.27825 · v1 · submitted 2026-04-30 · 💻 cs.SE

Requirements Debt in AI-Enabled Perception Systems Development: An Industrial RE4AI Perspective

Hina Saeeda , Soniya Abraham This is my paper

Pith reviewed 2026-05-07 07:34 UTC · model grok-4.3

classification 💻 cs.SE
keywords requirements debttechnical debtAI-enabled systemsautomotive perceptionrequirements engineeringRE4AIsafety-critical systemsperception systems
0
0 comments X

The pith

Evolving requirements accumulate as Requirements Debt that spreads through AI automotive perception systems and blocks certification.

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

The paper shows how requirements in AI-enabled automotive perception systems shift continuously because of new data, model updates, and changing operating conditions. When these shifts are not documented, validated, or traced, they build up as Requirements Debt. Functional changes such as algorithm or sensor updates create semantic drift and validation backlogs when verification lags. Non-functional changes around safety, reliability, and transparency create assurance lags and compliance gaps as standards move. The authors reached these conclusions by analyzing interviews with experts from thirteen automotive companies and three research institutes. A reader would care because these systems must be certifiable for road safety, and the debt directly threatens auditability and reliable operation.

Core claim

Evolving functional requirements drive semantic drift, validation backlogs, and integration debt when verification cannot keep pace with iteration; evolving non-functional requirements create assurance lag, compliance misalignment, and transparency and reliability debt as standards and ethical expectations shift. These mechanisms interact and propagate Requirements Debt across data, models, and system artefacts, undermining auditability, reliability, and certification readiness in safety-critical perception systems.

What carries the argument

Requirements Debt (ReD), a subtype of technical debt that forms when changes to functional and non-functional requirements in AI perception systems are not consistently documented, validated, and traced across the development lifecycle.

If this is right

  • Verification activities must track rapid functional changes such as sensor fusion updates to avoid integration debt.
  • Continuous alignment with shifting safety and transparency standards is required to prevent assurance lag and compliance misalignment.
  • Unmanaged debt propagates into data pipelines, trained models, and final system artefacts, reducing traceability for audits.
  • Certification readiness for safety-critical automotive AI depends on explicit tracking of requirement evolution throughout the lifecycle.
  • Better documentation and tracing practices for changing requirements can limit the spread of Requirements Debt to downstream artefacts.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same debt mechanisms may appear in other data-driven AI domains such as medical imaging or industrial robotics where requirements also evolve with new data and models.
  • Automated tools that flag semantic drift between successive requirement versions could reduce the manual validation burden identified in the interviews.
  • Embedding Requirements Debt metrics into AI development pipelines would give project teams early signals before certification delays occur.
  • The findings point toward the need for adaptive requirements processes that treat data and model artefacts as first-class requirement carriers rather than afterthoughts.

Load-bearing premise

The assumption that thematic analysis of sixteen interviews with experts from thirteen international automotive companies and three European research institutes gives a representative picture of how Requirements Debt forms and spreads across the whole industry.

What would settle it

A review of requirement change logs, verification records, and certification documents from several completed AI perception projects that shows no measurable accumulation of semantic drift, validation backlogs, or compliance gaps despite rapid requirement evolution would falsify the propagation claim.

Figures

Figures reproduced from arXiv: 2604.27825 by Hina Saeeda, Soniya Abraham.

Figure 1
Figure 1. Figure 1: Overview of the research process. TABLE I INTERVIEWEE DETAILS ID Role Company Exp. (yrs) ID1 CEO Zion Tech AB 17+ ID2 Software Engineer Univrses 4 ID3 Senior Engineer Polestar 13 ID4 Engineer Kognic 5 ID5 Solution Architect Volvo 13 ID6 Researcher Gothenburg University 2+ ID7 Architect Zenseact 4 ID8 ML Engineer Cruise 5+ ID9 Engineer Wabtec 6 ID10 Researcher RISE 2+ ID11 Associate Professor Halmstad Unive… view at source ↗
Figure 2
Figure 2. Figure 2: Identified Evolving Functional Requirements Leading to ReD view at source ↗
Figure 3
Figure 3. Figure 3: Identified Evolving Non-Functional Requirements Leading to ReD view at source ↗
read the original abstract

AI integration in automotive perception systems shifts requirements from static specifications to continuously evolving entities shaped by data, models, and operating contexts. When such changes are not consistently documented, validated, and traced, they accumulate as Requirements Debt (ReD), an underexplored but critical subtype of technical debt. This study conceptualises and empirically investigates how evolving functional and non-functional requirements create and propagate ReD across the AI-enabled automotive perception system lifecycle. We conducted 16 semi-structured interviews with experts from 13 international automotive companies and 3 European research institutes, and analysed the data using thematic analysis. As one of the first empirical studies connecting technical debt theory with RE4AI, the work identifies key ReD mechanisms. Evolving functional requirements (e.g., algorithm updates, sensor fusion, architectural changes, real-time constraints) drive semantic drift, validation backlogs, and integration debt when verification lags behind rapid iteration. In parallel, evolving non-functional requirements (e.g., safety, cybersecurity, reliability, scalability, transparency, trustworthiness) create assurance lag, compliance misalignment, and transparency and reliability debt as standards and ethical expectations shift. These interacting mechanisms propagate ReD across data, models, and system artefacts, undermining auditability, reliability, and certification readiness in safety-critical perception systems.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The manuscript conceptualizes Requirements Debt (ReD) as an underexplored subtype of technical debt arising in AI-enabled automotive perception systems when evolving functional and non-functional requirements are not adequately documented, validated, or traced. Drawing on thematic analysis of 16 semi-structured interviews with experts from 13 international automotive companies and 3 European research institutes, the authors identify specific mechanisms: evolving functional requirements (e.g., algorithm updates, sensor fusion, real-time constraints) drive semantic drift, validation backlogs, and integration debt; evolving non-functional requirements (e.g., safety, cybersecurity, transparency) drive assurance lag, compliance misalignment, and transparency/reliability debt. These mechanisms are claimed to propagate ReD across data, models, and system artefacts, undermining auditability, reliability, and certification readiness.

Significance. If the empirical mechanisms hold under scrutiny, the work is significant as one of the first studies to empirically link technical debt theory with RE4AI in a safety-critical domain. It offers concrete, industry-derived categories of ReD that could guide practitioners in managing requirement evolution during AI perception system development and inform future standards for traceability and assurance in automotive AI.

major comments (3)
  1. [Methodology] Methodology section: The thematic analysis is described only at a high level (semi-structured interviews followed by thematic analysis) with no reporting of saturation assessment, inter-rater reliability, coding process details, or steps taken to mitigate researcher bias. Because the central claim—that specific ReD mechanisms propagate across the lifecycle—rests entirely on patterns extracted from these 16 interviews, the absence of these standard qualitative safeguards makes it impossible to evaluate whether the identified mechanisms are robust or idiosyncratic to the sample.
  2. [Findings] Findings / Results section (around the description of functional and non-functional requirement evolution): The propagation claim ('propagate ReD across data, models, and system artefacts') is asserted as a key outcome but is supported only by thematic summaries and selected quotes. No mapping table, cross-case analysis, or explicit evidence is provided showing how individual interview excerpts demonstrate propagation through the three artefact types; this gap directly weakens the lifecycle-wide scope of the contribution.
  3. [Discussion] Sampling and generalizability discussion: The paper states the sample covers '13 international automotive companies' yet provides no breakdown by company size, geographic region, or process maturity. Without such variation data or explicit discussion of convenience sampling limitations, the general claim that the mechanisms apply 'across the AI-enabled automotive perception system lifecycle' cannot be substantiated beyond the specific 16 experts interviewed.
minor comments (2)
  1. [Introduction] The definition of ReD in the introduction would benefit from a short explicit contrast with related concepts such as 'data debt' or 'model debt' already discussed in the technical debt literature, to sharpen the novel contribution.
  2. If a figure or table summarizing the ReD mechanisms exists, ensure each mechanism is directly anchored to at least one interview theme or quote for traceability.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback on our manuscript. The comments have prompted us to enhance the transparency of our methods, strengthen the empirical grounding of our propagation claims, and better contextualize the scope of our findings. We address each major comment below and indicate the revisions made to the manuscript.

read point-by-point responses

  1. Referee: [Methodology] Methodology section: The thematic analysis is described only at a high level (semi-structured interviews followed by thematic analysis) with no reporting of saturation assessment, inter-rater reliability, coding process details, or steps taken to mitigate researcher bias. Because the central claim—that specific ReD mechanisms propagate across the lifecycle—rests entirely on patterns extracted from these 16 interviews, the absence of these standard qualitative safeguards makes it impossible to evaluate whether the identified mechanisms are robust or idiosyncratic to the sample.

    Authors: We agree that the original Methodology section provided only a high-level overview and omitted key details necessary for evaluating rigor. In the revised manuscript we have substantially expanded this section to describe the thematic analysis process in full. We now outline the inductive approach (following Braun and Clarke), the step-by-step coding procedure from initial open coding through theme refinement, how saturation was monitored by tracking the emergence of new codes and themes across successive interviews, and the measures taken to address researcher bias (including independent dual coding of a subset of transcripts with subsequent consensus discussions and maintenance of a reflexivity journal). These additions directly respond to the concern and allow readers to assess the robustness of the identified ReD mechanisms. revision: yes

  2. Referee: [Findings] Findings / Results section (around the description of functional and non-functional requirement evolution): The propagation claim ('propagate ReD across data, models, and system artefacts') is asserted as a key outcome but is supported only by thematic summaries and selected quotes. No mapping table, cross-case analysis, or explicit evidence is provided showing how individual interview excerpts demonstrate propagation through the three artefact types; this gap directly weakens the lifecycle-wide scope of the contribution.

    Authors: We accept that the propagation claim across data, models, and system artefacts was previously conveyed primarily through narrative summaries and illustrative quotes rather than systematic evidence. To remedy this, we have inserted a new mapping table in the Findings section. The table explicitly links representative interview excerpts to each ReD mechanism and traces the propagation pathway through the three artefact types. This addition supplies the concrete, traceable evidence requested and reinforces the lifecycle-wide scope of the contribution without altering the original thematic findings. revision: yes

  3. Referee: [Discussion] Sampling and generalizability discussion: The paper states the sample covers '13 international automotive companies' yet provides no breakdown by company size, geographic region, or process maturity. Without such variation data or explicit discussion of convenience sampling limitations, the general claim that the mechanisms apply 'across the AI-enabled automotive perception system lifecycle' cannot be substantiated beyond the specific 16 experts interviewed.

    Authors: We acknowledge the validity of this observation. While we cannot retroactively collect additional variation data that was not systematically recorded during the study, we have revised the manuscript in two ways: (1) we now provide an anonymized summary of organizational characteristics (e.g., OEM vs. Tier-1 supplier, primary geographic base) drawn from the information that was available under confidentiality constraints; and (2) we have added an explicit limitations paragraph in the Discussion that addresses the convenience-sampling nature of the study and cautions against over-generalization beyond the sampled industrial contexts. These changes temper the scope of our claims while preserving the value of the empirically derived mechanisms. revision: partial

Circularity Check

0 steps flagged

No circularity: empirical claims rest on external interview data with no derivations or self-referential reductions

full rationale

The paper contains no mathematical derivations, equations, fitted parameters, or self-definitional constructs. Its central claims about ReD mechanisms are presented as outcomes of thematic analysis performed on 16 semi-structured interviews with external industry experts. No load-bearing steps reduce by construction to the paper's own inputs, no self-citation chains justify uniqueness or ansatzes, and no renaming of known results occurs. The derivation chain is self-contained against the collected data rather than circular.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the domain assumption that qualitative interview data can reliably surface general mechanisms of requirements debt, and introduces ReD as a conceptual entity grounded in the empirical findings.

axioms (1)
  • domain assumption Thematic analysis of expert interviews can accurately identify general mechanisms of requirements debt in AI systems.
    This underpins the empirical investigation and mechanism identification described in the abstract.
invented entities (1)
  • Requirements Debt (ReD) independent evidence
    purpose: To name and frame the accumulation of issues from undocumented or unvalidated changes in evolving requirements for AI perception systems.
    Introduced as a subtype of technical debt specific to RE4AI contexts and supported by the interview data.

pith-pipeline@v0.9.0 · 5524 in / 1397 out tokens · 71716 ms · 2026-05-07T07:34:04.296860+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

45 extracted references · 45 canonical work pages

  1. [1]

    L.,& Ozkaya, I

    Kruchten, P., Nord, R. L.,& Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), 18-21

    work page 2012

  2. [2]

    Tom, E., Aurum, A.,& Vidgen, R. (2013). An exploration of technical debt. Journal of Systems and Software, 86(6), 1498-1516

    work page 2013

  3. [3]

    Melo, A., Fagundes, R., Lenarduzzi, V ., & Santos, W. B. (2022). Iden- tification and measurement of requirements technical debt in software development: A systematic literature review

    work page 2022

  4. [4]

    & Sp´ınola, R

    Barbosa, L., Freire, S., Rios, N., Ramac, R., Tau ˇsan, N., P ´erez, B., ... & Sp´ınola, R. (2022, August). Organizing the TD management landscape for requirements and requirements documentation debt. In Workshop on Requirements Engineering (WER)

    work page 2022

  5. [5]

    Wang, Q., & Huang, Y . (2020). Identification and management of requirements debt: Systematic mapping study and survey

    work page 2020

  6. [6]

    (2019, September)

    Lenarduzzi, V ., & Fucci, D. (2019, September). Towards a holistic defini- tion of requirements debt. In 2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) (pp. 1-5). IEEE

    work page 2019

  7. [7]

    M., Knauss, E., Knauss, A., & Horkoff, J

    Saeeda, H., Rohacova, Z., Jakobsson, O., Heyn, H. M., Knauss, E., Knauss, A., & Horkoff, J. (2025, April). Requirements Representations in Machine Learning-Based Automotive Perception Systems Develop- ment for Multi-party Collaboration. In International Working Conference on Requirements Engineering: Foundation for Software Quality (pp. 197-213). Cham: Sp...

    work page 2025

  8. [8]

    M.,& Horkoff, J

    Peng, Y ., Saeeda, H., Heyn, H. M.,& Horkoff, J. (2025, September). Data Annotation: A Requirements Engineering for Machine Learning Systems Perspective. In 2025 IEEE 33rd International Requirements Engineering Conference (RE) (pp. 572-575). IEEE

    work page 2025

  9. [9]

    (2021, September)

    Ahmad, K., Bano, M., Abdelrazek, M., Arora, C., & Grundy, J. (2021, September). What’s up with requirements engineering for artificial intelligence systems?. In 2021 IEEE 29th International Requirements Engineering Conference (RE) (pp. 1-12). IEEE

    work page 2021

  10. [10]

    ”Automotive perception software development: An empirical investigation into data, annotation, and ecosystem challenges.” arXiv preprint arXiv:2303.05947 (2023)

    Heyn, Hans-Martin, Khan Mohammad Habibullah, Eric Knauss, Jennifer Horkoff, Markus Borg, Alessia Knauss, and Polly Jing Li. ”Automotive perception software development: An empirical investigation into data, annotation, and ecosystem challenges.” arXiv preprint arXiv:2303.05947 (2023)

    work page arXiv 2023

  11. [11]

    Organisation and communication problems in auto- motive requirements engineering

    Liebel, Grischa, Matthias Tichy, Eric Knauss, Oscar Ljungkrantz, and Gerald Stieglbauer. “Organisation and communication problems in auto- motive requirements engineering.”Requirements Engineering23, no. 1 (2018): 145–167

    work page 2018

  12. [12]

    Require- ments are slipping through the gaps A case study on causes & effects of communication gaps in large-scale software development

    Bjarnason, Elizabeth, Krzysztof Wnuk, and Bj ¨orn Regnell. “Require- ments are slipping through the gaps A case study on causes & effects of communication gaps in large-scale software development.”Proc. IEEE 19th Int. Requirements Engineering Conference (RE), 2011, pp. 37–46. doi:10.1109/RE.2011.6051639

    work page doi:10.1109/re.2011.6051639 2011

  13. [13]

    Requirement Engineering Challenges for AI-intensive Systems Development

    Heyn, Hans-Martin, Eric Knauss, Amna Pir Muhammad, Olof Eriksson, Jennifer Linder, Padmini Subbiah, Shameer Kumar Pradhan, and Sagar Tungal. “Requirement Engineering Challenges for AI-intensive Systems Development.”2021 IEEE/ACM 1st Workshop on AI Engineering – Software Engineering for AI (WAIN), 2021, pp. 89–96

    work page 2021

  14. [14]

    Requirements en- gineering for safety-critical systems: A systematic literature review

    Martins, Luiz Eduardo G., and Tony Gorschek. “Requirements en- gineering for safety-critical systems: A systematic literature review.” Information and Software Technology75 (2016): 71–89

    work page 2016

  15. [15]

    Requirements Engineering for Automotive Perception Systems: An Interview Study

    Habibullah, Khan Mohammad, Hans-Martin Heyn, Gregory Gay, Jen- nifer Horkoff, Eric Knauss, Markus Borg, Alessia Knauss, H ˚akan Sivencrona, and Jing Li. “Requirements Engineering for Automotive Perception Systems: An Interview Study.”REFSQ, 2023, pp. 189–205

    work page 2023

  16. [16]

    Safety of Perception Systems in Vehicles of High-Level Motion Au- tomation

    Skruch, Pawel, Marcin Szelest, Marek Dlugosz, and Dariusz Cieslar. “Safety of Perception Systems in Vehicles of High-Level Motion Au- tomation.”ICETA 2022, pp. 561–566

    work page 2022

  17. [17]

    Springer, 2022

    Szeliski, Richard.Computer Vision: Algorithms and Applications(2nd ed.). Springer, 2022

    work page 2022

  18. [18]

    Autonomous Driving Systems: An Overview of Challenges in Safety, Reliability and Privacy

    Memon, Ruqaiyah, Keyvan Arezoo, Khalil Alipour, and Mohammad Ghamari. “Autonomous Driving Systems: An Overview of Challenges in Safety, Reliability and Privacy.”HSI 2022, pp. 1–7

    work page 2022

  19. [19]

    A comparative review on multi- modal sensors fusion based on deep learning

    Tang, Qin, Jing Liang, and Fangqi Zhu. “A comparative review on multi- modal sensors fusion based on deep learning.”Signal Processing213 (2023): 109165

    work page 2023

  20. [20]

    Safety assurance for automated driving systems that can adapt using machine learning: A qualitative interview study

    Ballingall, Stuart, Majid Sarvi, and Peter Sweatman. “Safety assurance for automated driving systems that can adapt using machine learning: A qualitative interview study.”Journal of Safety Research84 (2023): 243–250

    work page 2023

  21. [21]

    International Organization for Standardization.ISO 26262-1:2018, Road vehicles Functional safety.Geneva, 2018

    work page 2018

  22. [22]

    Myklebust, Thor, and Tor St ˚alhane.Functional Safety and Proof of Compliance.Springer, 2021

    work page 2021

  23. [23]

    Automotive Safety and Machine Learning: Initial Results on Adapting ISO 26262

    Henriksson, Jens, Markus Borg, and Cristofer Englund. “Automotive Safety and Machine Learning: Initial Results on Adapting ISO 26262.” SEFAIAS 2018, pp. 47–49

    work page 2018

  24. [24]

    Non-functional requirements for machine learning: understanding cur- rent use and challenges among practitioners

    Habibullah, Khan Mohammad, Gregory Gay, and Jennifer Horkoff. “Non-functional requirements for machine learning: understanding cur- rent use and challenges among practitioners.”Requirements Engineering 28, no. 2 (2023): 283–316

    work page 2023

  25. [25]

    A survey on bias and fairness in machine learning

    Mehrabi, Ninareh, Fred Morstatter, Nripsuta Saxena, Kristina Lerman, and Aram Galstyan. “A survey on bias and fairness in machine learning.” ACM Computing Surveys54, no. 6 (2021): 1–35

    work page 2021

  26. [26]

    Requirements Engineering for Machine Learning: Perspectives from Data Scientists

    V ogelsang, Andreas, and Markus Borg. “Requirements Engineering for Machine Learning: Perspectives from Data Scientists.”REW 2019, pp. 245–251. doi:10.1109/REW.2019.00050

    work page doi:10.1109/rew.2019.00050 2019

  27. [27]

    Artificial Intelligence Act

    European Parliament. “Artificial Intelligence Act.” Regulamento da Uni˜ao Europeia (UE) 1689 (2024)

    work page 2024

  28. [28]

    Status Quo and Problems of Requirements Engineering for Machine Learning: Results from an International Survey

    Alves, Antonio Pedro Santos, et al. “Status Quo and Problems of Requirements Engineering for Machine Learning: Results from an International Survey.” arXiv preprint (2023)

    work page 2023

  29. [29]

    Certifiably safe software-dependent systems: challenges and directions

    Hatcliff, John, Alan Wassyng, Tim Kelly, Cyrille Comar, and Paul Jones. “Certifiably safe software-dependent systems: challenges and directions.”FOSE, 2014, pp. 182–200

    work page 2014

  30. [30]

    Geneva, 2022

    International Organization for Standardization.ISO/IEC 23053:2022, Framework for AI Systems Using Machine Learning. Geneva, 2022

    work page 2022

  31. [31]

    Guidelines for conducting and report- ing case study research in software engineering

    Runeson, Per, and Martin H ¨ost. “Guidelines for conducting and report- ing case study research in software engineering.”Empirical Software Engineering14 (2009): 131–164

    work page 2009

  32. [32]

    Yin, Robert K.Case Study Research and Applications.6th ed., Sage, 2018

    work page 2018

  33. [33]

    Autonomous Vehicle Safety: An Interdisciplinary Challenge

    Koopman, Philip, and Michael Wagner. “Autonomous Vehicle Safety: An Interdisciplinary Challenge.”IEEE ITS Magazine9, no. 1 (2017): 90–96

    work page 2017

  34. [34]

    Trustworthy Machine Learning: Fairness and Robust- ness

    Liu, Haochen. “Trustworthy Machine Learning: Fairness and Robust- ness.”WSDM, 2022, pp. 1553–1554

    work page 2022

  35. [35]

    Re- quirements engineering for autonomous vehicles: a systematic literature review

    Ribeiro, Quelita A. D. S., Moniky Ribeiro, and Jaelson Castro. “Re- quirements engineering for autonomous vehicles: a systematic literature review.”SAC, 2022, pp. 1299–1308

    work page 2022

  36. [36]

    General guidelines for conducting research inter- views

    McNamara, Carter. “General guidelines for conducting research inter- views.”Retrieved(2009)

    work page 2009

  37. [37]

    The ABC of software engineering research

    Stol, Klaas-Jan, and Brian Fitzgerald. “The ABC of software engineering research.”ACM TOSEM27, no. 3 (2018): 1–51

    work page 2018

  38. [38]

    Challenges of scaled agile for safety-critical systems

    Stegh ¨ofer, Jan-Philipp, Eric Knauss, Jennifer Horkoff, and Rebekka Wohlrab. “Challenges of scaled agile for safety-critical systems.”PRO- FES, 2019, pp. 350–366

    work page 2019

  39. [39]

    Challenges and success factors for large-scale agile transformations: A systematic literature review

    Dikert, Kim, Maria Paasivaara, and Casper Lassenius. “Challenges and success factors for large-scale agile transformations: A systematic literature review.”Journal of Systems and Software119 (2016): 87–108

    work page 2016

  40. [40]

    Safety of Perception Systems for Automated Driving: A Case Study on Apollo

    Kochanthara, Sangeeth, Tajinder Singh, Alexandru Forrai, and Loek Cleophas. “Safety of Perception Systems for Automated Driving: A Case Study on Apollo.”ACM Transactions on Software Engineering and Methodology33, no. 3 (2024): 1–28

    work page 2024

  41. [41]

    Setting AI in context: a case study on defining the context and operational design domain for automated driving

    Heyn, Hans-Martin, Padmini Subbiah, Jennifer Linder, Eric Knauss, and Olof Eriksson. “Setting AI in context: a case study on defining the context and operational design domain for automated driving.”REFSQ, 2022, pp. 199–215

    work page 2022

  42. [42]

    Braun, V ., & Clarke, V . (2023). Toward good practice in thematic analysis: Avoiding common problems and be (com) ing a knowing researcher. International journal of transgender health, 24(1), 1-6

    work page 2023

  43. [43]

    Salda ˜na, J., & Omasta, M. (2016). Qualitative research: Analyzing life. Sage Publications

    work page 2016

  44. [44]

    ”Job satisfaction at risk: Measuring the role of process debt in agile software development.” Journal of Systems and Software 222 (2025): 112350

    Gustavsson, Tomas, Muhammad Ovais Ahmad, and Hina Saeeda. ”Job satisfaction at risk: Measuring the role of process debt in agile software development.” Journal of Systems and Software 222 (2025): 112350

    work page 2025

  45. [45]

    ”Identifying and categorizing challenges in large-scale agile software development projects: Insights from two Swedish companies.” ACM SIGAPP Applied Computing Review 23, no

    Saeeda, Hina, Muhammad Ovais Ahmad, and Tomas Gustavsson. ”Identifying and categorizing challenges in large-scale agile software development projects: Insights from two Swedish companies.” ACM SIGAPP Applied Computing Review 23, no. 2 (2023): 23-43

    work page 2023