Pith. sign in

REVIEW 3 major objections 2 minor 56 references

From Quality Properties to Practice: A Guideline and Workflow for Explainability Requirements

T0 review · 3 major / 2 minor · reviewed 2026-06-27 · grok-4.3

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

Pith's one-line read A ten-property guideline with tool support reduces time writing explainability requirements by nearly a quarter while matching manual quality.

desk verdict A ten-property guideline plus web tool for explainability requirements, with small studies showing time savings and comparable quality ratings. read the letter →

arxiv 2606.10882 v1 pith:YYTPGKRD submitted 2026-06-09 cs.SE

Martin Obaidi , Jakob Droste , Hannah Deters , Marc Herrmann , Michel Krahl , Kurt Schneider This is my paper · ORCID
classification cs.SE
keywords explainabilityrequirementsqualitypropertiesengineeringAIsystemsworkflowtoolLLMsupportformulationeffort
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

The paper establishes a workflow for writing explainability requirements by distilling literature and interviews into ten prioritized quality properties via a practitioner survey, then encoding those properties into a web tool for iterative drafting, checking, and revision with lightweight LLM help. Two evaluations show the tool shortens average formulation time by 23.5 percent and yields requirements that developers rate as comparably implementable and well-formed to fully manual versions. Readers care because AI systems increasingly need clear explainability statements for trust and compliance, yet current practice is ad hoc and prone to vagueness. The approach supplies a concrete, repeatable method to make the task faster without apparent loss in outcome quality.

What carries the argument

The ten core quality properties prioritized from a survey of twenty practitioners, together with the iterative workflow of drafting, property-based checks, and revision supported by a web tool and lightweight LLM assistance.

What would settle it

A follow-up study in which tool-supported requirements receive markedly lower average ratings for implementability or formulation quality than manually written ones, using a larger or more diverse developer sample, would falsify the central result.

Watch

Extended reading notes

Core claim

A sequential guideline-driven workflow operationalized in a web-based tool that applies ten core quality properties through drafting, property checks, and revision produces explainability requirements with 23.5 percent less formulation time on average and with implementability and formulation quality ratings comparable to those written manually.

Load-bearing premise

The ten core properties selected and ranked through the survey of twenty practitioners form a sufficient and appropriate basis for guiding explainability requirements across varied AI domains and contexts.

Editorial extensions

If this is right

  • Requirements engineers can complete the task in less time on average.
  • The resulting statements remain suitable for downstream implementation.
  • The same workflow performs consistently in both facilitated workshops and independent online use.
  • Lightweight LLM assistance guided by the properties avoids the vagueness seen in unguided model use.

Reading between the lines

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

  • The same prioritization process could be repeated for other quality attributes such as security or fairness requirements.
  • Embedding the checks inside existing requirements management platforms would reduce context switching for teams.
  • Repeated application across projects might produce more uniform compliance documentation for regulators.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 2 minor

Summary. The paper claims that a sequential workflow for formulating explainability requirements—derived from a literature review and interviews to elicit candidates, prioritized via an online survey of 20 practitioners into a guideline of ten core properties with formulation instructions, and operationalized in a web-based tool with iterative LLM-supported drafting and checks—reduces formulation time by 23.5% (Wilcoxon p=0.021) in a workshop (n=6) while yielding requirements rated comparably in implementability and quality to manual versions in an online study (n=18).

Significance. If the ten-property guideline proves robust, the work offers a concrete, practitioner-derived bridge from regulatory demands for explainability to actionable requirements engineering practice, with empirical evidence that lightweight tool support can lower effort without sacrificing perceived quality. The dual-study design (controlled workshop plus independent online validation) and use of external literature plus new survey data for guideline construction are strengths that could support adoption in AI-enabled systems development.

major comments (3)
  1. [§3] §3 (Guideline Derivation, prioritization survey): The ten core properties central to the workflow and both evaluations are selected by ranking candidates from a survey of only n=20 practitioners. This small, non-stratified sample risks missing domain-specific properties or over-weighting others, directly undermining the claim that the resulting guideline produces high-quality requirements across varied AI contexts.
  2. [§5.1] §5.1 (Workshop study): The reported 23.5% average time reduction rests on n=6 participants with a statistically significant Wilcoxon result, but the manuscript provides only high-level reporting of the manual baseline procedure and participant tasks; without power analysis or detailed task logs, the efficiency claim remains only moderately supported and may not generalize.
  3. [§5.2] §5.2 (Online study): Comparable ratings for implementability and formulation quality are shown with n=18 developers, yet the paper gives limited detail on the exact rating scales, inter-rater agreement, or the distribution of AI application domains represented; this weakens the evidence that tool-supported outputs are perceived as equivalent beyond the studied cohort.
minor comments (2)
  1. [§4] The tool description could include the precise LLM prompting templates or few-shot examples used for property-based checks to improve reproducibility.
  2. [§6] A limitations subsection should explicitly discuss the generalizability risks arising from the small survey and evaluation samples and the single-institution or single-domain focus, if any.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for their constructive feedback on our manuscript. We address each of the major comments point by point below, proposing revisions to improve clarity and transparency where appropriate.

read point-by-point responses

  1. Referee: [§3] §3 (Guideline Derivation, prioritization survey): The ten core properties central to the workflow and both evaluations are selected by ranking candidates from a survey of only n=20 practitioners. This small, non-stratified sample risks missing domain-specific properties or over-weighting others, directly undermining the claim that the resulting guideline produces high-quality requirements across varied AI contexts.

    Authors: The candidate properties were initially derived from a structured literature review and semi-structured interviews with developers, as detailed in §3. The survey (n=20) was used solely for prioritization and ranking to arrive at the ten core properties. We agree that the sample size is modest and non-stratified, which is a limitation. In revision, we will clarify the multi-stage derivation process, provide additional details on the literature sources and interview participants, and add an explicit discussion of limitations regarding generalizability across AI domains. This addresses the concern without overstating the survey's role. revision: partial

  2. Referee: [§5.1] §5.1 (Workshop study): The reported 23.5% average time reduction rests on n=6 participants with a statistically significant Wilcoxon result, but the manuscript provides only high-level reporting of the manual baseline procedure and participant tasks; without power analysis or detailed task logs, the efficiency claim remains only moderately supported and may not generalize.

    Authors: We will revise the manuscript to include a more detailed description of the manual baseline procedure, the specific tasks assigned to participants, and any available task logs. Regarding power analysis, we can include a post-hoc calculation based on the observed effect size. While n=6 is small, the controlled workshop design and significant result (p=0.021) provide initial evidence for the time reduction; we will emphasize the need for larger studies in the limitations section. revision: yes

  3. Referee: [§5.2] §5.2 (Online study): Comparable ratings for implementability and formulation quality are shown with n=18 developers, yet the paper gives limited detail on the exact rating scales, inter-rater agreement, or the distribution of AI application domains represented; this weakens the evidence that tool-supported outputs are perceived as equivalent beyond the studied cohort.

    Authors: We agree and will expand §5.2 to specify the exact rating scales (e.g., Likert items), report inter-rater agreement (such as percentage agreement or appropriate statistical measures), and describe the AI application domains of the n=18 participants. These additions will provide a more complete picture of the study and support the comparability findings. revision: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: guideline from external sources and new survey; evaluations independent

full rationale

The derivation chain starts with a literature review and developer interviews to elicit candidates, followed by an independent online survey (n=20) for prioritization into the ten-property guideline. The workflow is then tested in two separate empirical studies (workshop n=6 and online n=18) whose participants and tasks are distinct from the survey. No equations, fitted parameters, or self-citations appear in the provided text, and no step reduces by construction to its own inputs. The central claims rest on externally collected data and separate validation rather than definitional loops or renamed fits.

Assumptions & free parameters 0 free parameters · 1 assumptions · 0 invented entities

The work rests on standard empirical methods rather than new mathematical derivations or postulated entities; no free parameters or invented entities are introduced.

assumptions (1)
  • domain assumption Practitioner surveys and structured literature reviews reliably identify and prioritize quality properties for requirements engineering.
    Invoked to justify the elicitation and prioritization steps leading to the ten core properties.

how reviews work

0 comments
Cite this review

Pith. "Pith review of From Quality Properties to Practice: A Guideline and Workflow for Explainability Requirements." pith.science (2026). https://pith.science/paper/YYTPGKRD

@misc{pith2026260610882,
  author       = {Pith},
  title        = {Pith review of: From Quality Properties to Practice: A Guideline and Workflow for Explainability Requirements},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YYTPGKRD}},
  note         = {Machine review of arXiv:2606.10882}
}
read the original abstract

Explainability is increasingly required in AI-enabled software systems to support transparency, user trust, and compliance. Yet, explainability requirements are often written ad hoc, and unguided large language model support can yield vague, inconsistent, or incomplete statements. This paper presents a sequential, guideline-driven workflow for formulating explainability requirements and evaluates its tool-based operationalization. We first elicited candidate quality properties through a structured literature review and developer interviews. We then prioritized these properties in an online survey with practitioners (n=20) and derived a concise guideline of ten core properties with actionable formulation instructions. Next, we operationalized the guideline in a web-based tool that supports an iterative workflow of drafting, property-based checks, and revision. We evaluated the workflow in two complementary studies. In a workshop with requirements engineers (n=6), tool support reduced formulation time by 23.5% on average (Wilcoxon p=0.021). In an independent online study with software developers (n=18), tool-supported and manually written requirements received comparable ratings for implementability and formulation quality, with a descriptive slight preference tendency toward the tool-supported versions. Overall, our results suggest that combining a prioritized quality guideline with lightweight LLM support can reduce formulation effort while producing requirements that are perceived comparably to manually written ones.

Figures

Figures reproduced from arXiv: 2606.10882 by the authors.

Figure 1
Figure 1. Overview of our research design in FLOW notation [45]. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Most frequently selected Top properties (selected at least four times). [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Screenshot of the guideline-driven formulation tool for explainability [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Developers’ ratings of the helpfulness of app reviews as additional [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

56 extracted references · 3 canonical work pages

  1. [1]

    Healthcare professionals’ use of mobile phones and the internet in clinical practice,

    N. Koehler, O. Vujovic, and C. McMenamin, “Healthcare professionals’ use of mobile phones and the internet in clinical practice,”Journal of Mobile Technology in Medicine, vol. 2, pp. 3–13, Mar. 2013

    2013

  2. [2]

    Leakiness and creepiness in app space: perceptions of privacy and mobile app use,

    I. Shklovski, S. D. Mainwaring, H. H. Sk ´ulad´ottir, and H. Borgthorsson, “Leakiness and creepiness in app space: perceptions of privacy and mobile app use,” inCHI ’14, 2014, p. 2347–2356

    2014

  3. [3]

    Artificial intelligence in dermatology image analysis: Current develop- ments and future trends,

    Z. Li, K. C. Koban, T. L. Schenck, R. E. Giunta, Q. Li, and Y . Sun, “Artificial intelligence in dermatology image analysis: Current develop- ments and future trends,”Journal of Clinical Medicine, vol. 11, no. 22, 2022

    2022

  4. [4]

    Peeking inside the black-box: a survey on explainable artificial intelligence (xai),

    A. Adadi and M. Berrada, “Peeking inside the black-box: a survey on explainable artificial intelligence (xai),”IEEE access, vol. 6, pp. 52 138– 52 160, 2018

    2018

  5. [5]

    A study on the mental models of users concerning existing software,

    M. Anders, M. Obaidi, B. Paech, and K. Schneider, “A study on the mental models of users concerning existing software,” inRequirements Engineering: Foundation for Software Quality, V . Gervasi and A. V ogel- sang, Eds. Cham: Springer International Publishing, 2022, pp. 235–250

    2022

  6. [6]

    Explanations in everyday software systems: Towards a taxonomy for explainability needs,

    J. Droste, H. Deters, M. Obaidi, and K. Schneider, “Explanations in everyday software systems: Towards a taxonomy for explainability needs,” in2024 IEEE 32nd International Requirements Engineering Conference (RE), 2024, pp. 55–66

    2024

  7. [7]

    Framing what can be explained – an operational taxonomy for explainability needs,

    J. Droste, H. Deters, M. Obaidi, J. Kl ¨under, and K. Schneider, “Framing what can be explained – an operational taxonomy for explainability needs,”Requirements Engineering, 2025

    2025

  8. [8]

    Context, content, consent- how to design user-centered privacy explanations (s)

    W. Brunotte, J. Droste, and K. Schneider, “Context, content, consent- how to design user-centered privacy explanations (s).” inSEKE, 2023, pp. 86–89

    2023

Show all 56 references
  1. [9]

    Exploring explainability: a definition, a model, and a knowledge catalogue,

    L. Chazette, W. Brunotte, and T. Speith, “Exploring explainability: a definition, a model, and a knowledge catalogue,” inRE. IEEE, 2021

    2021

  2. [10]

    Automatic generation of explainability requirements and software explanations from user reviews,

    M. Obaidi, J. Fischbach, J. Droste, H. Deters, M. Herrmann, J. Kl ¨under, S. Kr ¨atzig, H. Villamizar, and K. Schneider, “Automatic generation of explainability requirements and software explanations from user reviews,” in2025 IEEE 33rd International Requirements Engineering C...

    2025

  3. [11]

    XAI for all: Can large language models simplify explainable AI?

    P. Mavrepis, G. Makridis, G. Fatouros, V . Koukos, M. M. Separdani, and D. Kyriazis, “XAI for all: Can large language models simplify explainable AI?”arXiv, vol. abs/2401.13110, Jan. 2024

    2024

  4. [12]

    A survey of contrastive and counterfactual explanation generation methods for explainable artificial intelligence,

    I. Stepin, J. M. Alonso, A. Catala, and M. Pereira-Fari ˜na, “A survey of contrastive and counterfactual explanation generation methods for explainable artificial intelligence,”IEEE Access, vol. 9, pp. 11 974– 12 001, 2021

    2021

  5. [13]

    Llm-generated explanations for recommender systems,

    S. Lubos, T. N. T. Tran, A. Felfernig, S. Polat Erdeniz, and V .-M. Le, “Llm-generated explanations for recommender systems,” inUMAP Adjunct ’24, 2024, p. 276–285

    2024

  6. [14]

    Is Stack Overflow obsolete? an empirical study of the characteristics of ChatGPT answers to Stack Overflow questions,

    S. Kabir, D. N. Udo-Imeh, B. Kou, and T. Zhang, “Is Stack Overflow obsolete? an empirical study of the characteristics of ChatGPT answers to Stack Overflow questions,” inCHI ’24, 2024, pp. 1–17

    2024

  7. [15]

    Replication Package: From Quality Properties to Practice: A Guideline and Workflow for Explainability Requirements,

    M. Obaidi, J. Droste, H. Deters, M. Herrmann, M. Krahl, and K. Schneider, “Replication Package: From Quality Properties to Practice: A Guideline and Workflow for Explainability Requirements,” May

  8. [16]

    Available: https://doi.org/10.5281/zenodo.20396663

    [Online]. Available: https://doi.org/10.5281/zenodo.20396663

    doi

  9. [17]

    Explainability as a non-functional requirement: challenges and recommendations,

    L. Chazette and K. Schneider, “Explainability as a non-functional requirement: challenges and recommendations,”REJ, vol. 25, no. 4, 2020

    2020

  10. [18]

    Explainability as a non-functional requirement,

    M. A. K ¨ohl, K. Baum, M. Langer, D. Oster, T. Speith, and D. Bohlender, “Explainability as a non-functional requirement,” in2019 IEEE 27th International Requirements Engineering Conference (RE). IEEE, 2019, pp. 363–368

    2019

  11. [19]

    From app features to explanation needs: Analyzing correlations and predictive potential,

    M. Obaidi, K. Qengaj, J. Droste, H. Deters, M. Herrmann, J. Kl ¨under, E. Schmid, and K. Schneider, “From app features to explanation needs: Analyzing correlations and predictive potential,” in2025 IEEE 33rd International Requirements Engineering Conference Workshops (REW), 20...

    2025

  12. [20]

    Immersive and enjoyable explanations - on distinct explainability requirements in games,

    J. Droste, R. Fuchs, H. Deters, M. Obaidi, A. Dockhorn, and K. Schnei- der, “Immersive and enjoyable explanations - on distinct explainability requirements in games,” inRequirements Engineering: Foundation for Software Quality. Springer, 2026

    2026

  13. [21]

    Misunderstandings by design: Using erroneous tutorials to induce mental model conflicts and the need for explanations,

    J. Droste, H. Deters, C. Kirchhoff, L. Nagel, M. Obaidi, and K. Schnei- der, “Misunderstandings by design: Using erroneous tutorials to induce mental model conflicts and the need for explanations,” inRequirements Engineering: Foundation for Software Quality. Springer, 2026

    2026

  14. [22]

    Writing better software explanations: A guideline-based approach,

    M. Obaidi, J.-C. Kremser, H. Deters, J. Droste, M. Herrmann, and K. Schneider, “Writing better software explanations: A guideline-based approach,” in2026 IEEE 34th International Requirements Engineering Conference (RE). IEEE, 2026

    2026

  15. [23]

    Understanding usefulness in developer explanations on stack overflow,

    M. Obaidi, K. Qengaj, H. Deters, J. Droste, M. Herrmann, K. Schneider, and J. Kl ¨under, “Understanding usefulness in developer explanations on stack overflow,” inRequirements Engineering: Foundation for Software Quality. Springer, 2026

    2026

  16. [24]

    Iden- tifying explanation needs: Towards a catalog of user-based indicators,

    H. Deters, L. Reinhardt, J. Droste, M. Obaidi, and K. Schneider, “Iden- tifying explanation needs: Towards a catalog of user-based indicators,” inRE, 2025, pp. 31–42

    2025

  17. [25]

    Modeling and evaluating per- sonas with software explainability requirements,

    H. Ramos, M. Fonseca, and L. Ponciano, “Modeling and evaluating per- sonas with software explainability requirements,” inHuman-Computer Interaction: 7th Iberoamerican Workshop, HCI-COLLAB 2021, Sao Paulo, Brazil, September 8–10, 2021, Proceedings 7, 2021, pp. 136– 149

    2021

  18. [26]

    Explanation needs in app reviews: Taxonomy and automated detection,

    M. Unterbusch, M. Sadeghi, J. Fischbach, M. Obaidi, and A. V ogelsang, “Explanation needs in app reviews: Taxonomy and automated detection,” inREW. IEEE, 2023

    2023

  19. [27]

    A review of taxonomies of explainable artificial intelligence (xai) methods,

    T. Speith, “A review of taxonomies of explainable artificial intelligence (xai) methods,” inProceedings of the 2022 ACM Conference on Fair- ness, Accountability, and Transparency, ser. FAccT ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 2239–2250

    2022

  20. [28]

    Requirements elicitation tech- niques: a systematic literature review based on the maturity of the techniques,

    C. Pacheco, I. Garc ´ıa, and M. Reyes, “Requirements elicitation tech- niques: a systematic literature review based on the maturity of the techniques,”IET Software, vol. 12, no. 4, pp. 365–378, 2018

    2018

  21. [29]

    Successful requirement elicita- tion by combining requirement engineering techniques,

    D. Mishra, A. Mishra, and A. Yazici, “Successful requirement elicita- tion by combining requirement engineering techniques,” in2008 First International Conference on the Applications of Digital Information and Web Technologies (ICADIWT). IEEE, 2008, pp. 258–263

    2008

  22. [30]

    How to elicit explainability requirements? a com- parison of interviews, focus groups, and surveys,

    M. Obaidi, J. Droste, H. Deters, M. Herrmann, R. Ochsner, J. Kl ¨under, and K. Schneider, “How to elicit explainability requirements? a com- parison of interviews, focus groups, and surveys,” in2025 IEEE 33rd International Requirements Engineering Conference (RE), 2025, pp. 167–178

    2025

  23. [31]

    Non-functional re- quirements elicitation guideline for agile methods,

    M. Younas, D. Jawawi, I. Ghani, and R. Kazmi, “Non-functional re- quirements elicitation guideline for agile methods,”Journal of Telecom- munication, Electronic and Computer Engineering (JTEC), vol. 9, no. 3-4, pp. 137–142, 2017

    2017

  24. [32]

    A model for evaluating requirements elicitation techniques in software development projects

    N. C. Alflen, E. P. Prado, and A. Grotta, “A model for evaluating requirements elicitation techniques in software development projects.” inICEIS (2), 2020, pp. 242–249

    2020

  25. [33]

    The role of domain knowledge in requirements elicitation via interviews: an exploratory study,

    I. Hadar, P. Soffer, and K. Kenzi, “The role of domain knowledge in requirements elicitation via interviews: an exploratory study,”Require- ments Engineering, vol. 19, pp. 143–159, 2014

    2014

  26. [34]

    How does users’ app knowledge influence the preferred level of detail and format of software explanations?

    M. Obaidi, J. Fischbach, M. Herrmann, H. Deters, J. Droste, J. Kl ¨under, and K. Schneider, “How does users’ app knowledge influence the preferred level of detail and format of software explanations?” in REFSQ’25, 2025

    2025

  27. [35]

    Do users’ explainability needs in software change with mood?

    M. Obaidi, J. Droste, H. Deters, M. Herrmann, J. Kl ¨under, and K. Schneider, “Do users’ explainability needs in software change with mood?” inREFSQ’25, 2025

    2025

  28. [36]

    Automating explanation need management in app reviews: A case study from the navigation app industry,

    M. Obaidi, N. V oß, J. Droste, H. Deters, M. Herrmann, J. Fischbach, and K. Schneider, “Automating explanation need management in app reviews: A case study from the navigation app industry,” inICSE- SEIP’25, 2025

    2025

  29. [37]

    How explainable is your system? towards a quality model for explainability,

    H. Deters, J. Droste, M. Obaidi, and K. Schneider, “How explainable is your system? towards a quality model for explainability,” inRequire- ments Engineering: Foundation for Software Quality. Cham: Springer Nature Switzerland, 2024, pp. 3–19

    2024

  30. [38]

    Exploring the means to measure explainability: Metrics, heuris- tics and questionnaires,

    ——, “Exploring the means to measure explainability: Metrics, heuris- tics and questionnaires,”Information and Software Technology, vol. 181, p. 107682, 2025

    2025

  31. [39]

    Chapter 81 experimental evidence on the existence of hypothetical bias in value elicitation methods,

    G. W. Harrison and E. E. Rutstr ¨om, “Chapter 81 experimental evidence on the existence of hypothetical bias in value elicitation methods,” in Handbook of Experimental Economics Results, C. R. Plott and V . L. Smith, Eds. Amsterdam: Elsevier, 2008, vol. 1, pp. 752–767

    2008

  32. [40]

    Designing end-user personas for explainability requirements using mixed methods research,

    J. Droste, H. Deters, J. Puglisi, and J. Kl ¨under, “Designing end-user personas for explainability requirements using mixed methods research,” inREW. IEEE, 2023

    2023

  33. [41]

    On the pulse of requirements elicitation: Physiological triggers and explainability needs,

    H. Deters, J. Droste, and K. Schneider, “On the pulse of requirements elicitation: Physiological triggers and explainability needs,” inREFSQ Workshops. CEUR Workshop Proceedings, 2024

    2024

  34. [42]

    Requirements on explanations: A quality framework for explainability,

    L. Chazette, V . Kl ¨os, F. Herzog, and K. Schneider, “Requirements on explanations: A quality framework for explainability,” inRE, 2022

    2022

  35. [43]

    Advancing requirements engineering through generative ai: Assessing the role of llms,

    C. Arora, J. Grundy, and M. Abdelrazek, “Advancing requirements engineering through generative ai: Assessing the role of llms,” in Generative AI for Effective Software Development, A. Nguyen-Duc, P. Abrahamsson, and F. Khomh, Eds. Springer, 2024, pp. 129–148

    2024

  36. [44]

    Challenges in applying large language models to requirements engineering tasks,

    J. J. Norheim, E. Rebentisch, D. Xiao, L. Draeger, A. Kerbrat, and O. L. de Weck, “Challenges in applying large language models to requirements engineering tasks,”Design Science, vol. 10, 2024

    2024

  37. [45]

    Unleashing the potential of prompt engineering for large language models,

    B. Chen, Z. Zhang, N. Langren ´e, and S. Zhu, “Unleashing the potential of prompt engineering for large language models,”Patterns, vol. 6, no. 6, p. 101260, 2025

    2025

  38. [46]

    Using flow to improve com- munication of requirements in globally distributed software projects,

    K. Stapel, E. Knauss, and K. Schneider, “Using flow to improve com- munication of requirements in globally distributed software projects,” in 2009 Collaboration and Intercultural Issues on Requirements: Commu- nication, Understanding and Softskills, 2009, pp. 5–14

    2009

  39. [47]

    Wohlin, P

    C. Wohlin, P. Runeson, M. H ¨ost, M. C. Ohlsson, B. Regnell, and A. Wessl´en,Experimentation in software engineering. Springer, 2012

    2012

  40. [48]

    Multidimensional Gold-Standard Dataset for Explanation Needs in App Reviews,

    M. Obaidi, “Multidimensional Gold-Standard Dataset for Explanation Needs in App Reviews,” May 2026. [Online]. Available: https: //doi.org/10.5281/zenodo.20359756

    2026 doi

  41. [49]

    Systems and software engineering — life cycle processes — requirements engineering,

    ISO/IEC/IEEE, “Systems and software engineering — life cycle processes — requirements engineering,” Geneva, 2018. [Online]. Available: https://www.iso.org/standard/72026.html

    2018

  42. [50]

    Requirements engineering und management,

    C. Rupp, M. Simon, and F. Hocker, “Requirements engineering und management,”HMD Praxis der Wirtschaftsinformatik, vol. 46, no. 3, pp. 94–103, 2009

    2009

  43. [51]

    K. Pohl, G. B ¨ockle, and F. van der Linden,Software product line engineering: Foundations, principles, and techniques ; with 10 tables. Berlin and Heidelberg: Springer, 2005

    2005

  44. [52]

    Empirical research on requirements quality: a systematic mapping study,

    L. Montgomery, D. Fucci, A. Bouraffa, L. Scholz, and W. Maalej, “Empirical research on requirements quality: a systematic mapping study,”Requirements Engineering, vol. 27, no. 2, pp. 183–209, 2022

    2022

  45. [53]

    A systematic literature review on quality criteria for agile requirements specifications,

    P. Heck and A. Zaidman, “A systematic literature review on quality criteria for agile requirements specifications,”Software Quality Journal, vol. 26, no. 1, pp. 127–160, 2018

    2018

  46. [54]

    Explainable software systems: from requirements analysis to system evaluation,

    L. Chazette, W. Brunotte, and T. Speith, “Explainable software systems: from requirements analysis to system evaluation,”REJ, vol. 27, no. 4, 2022

    2022

  47. [55]

    The impact of readability on trust in infor- mation,

    A. Withall and E. Sagi, “The impact of readability on trust in infor- mation,” inProceedings of the 43rd Annual Meeting of the Cognitive Science Society, T. Fitch, C. Lamm, H. Leder, and K. Teßmar-Raible, Eds., vol. 43. Vienna, Austria: Cognitive Science Society, 2021, pp. 2370–2376

    2021

  48. [56]

    What can be con- cluded from user feedback? — an empirical study,

    M. Anders, M. Obaidi, A. Specht, and B. Paech, “What can be con- cluded from user feedback? — an empirical study,” in2023 IEEE 31st International Requirements Engineering Conference Workshops (REW), 2023, pp. 122–128

    2023

Pith tools

Reviewed June 27, 2026 · model on record in the stance chip above.