Pith. sign in

REVIEW 3 major objections 6 minor 41 references

Automatic Generation of Explainability Requirements and Software Explanations From User Reviews

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read A prompt-based ChatGPT pipeline derives explainability requirements and explanations from app reviews, but requirements engineers still significantly prefer human-written requirements.

desk verdict Useful new pipeline and benchmark for explainability requirements, but the headline significance tests ignore repeated-measures clustering and the abstract overstates the explanation-preference result. read the letter →

arxiv 2507.07344 v1 pith:6V7BQYJY submitted 2025-07-10 cs.SE

Martin Obaidi , Jannik Fischbach , Jakob Droste , Hannah Deters , Marc Herrmann , Jil Klünder , Steffen Krätzig , Hugo Villamizar
show 1 more author
Kurt Schneider
This is my paper · ORCID
classification cs.SE
keywords explainabilityrequirementsengineeringuserreviewsapplargelanguagemodelsChatGPTnon-functionalhuman-in-the-loop
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

User reviews express explanation needs in informal language, and turning those needs into structured explainability requirements is largely unautomated. This paper tries to close that gap with a tool-supported ChatGPT pipeline that summarizes a review, derives a requirement in a fixed “The system must explain...” form, and generates a matching user-facing explanation. In a comparative study, requirements engineers significantly preferred manually written requirements (296 vs 168 votes; $\chi^2 = 35.31$, $p = 2.81 \times 10^{-9}$), while end users only slightly preferred manual explanations (447 vs 365; $\chi^2 = 8.28$, $p = 0.004$). The paper concludes that the pipeline is a useful drafting aid but that human validation is essential, especially for the correctness and relevance of requirements.

What carries the argument

The mechanism is a three-stage prompt-based pipeline built on a general-purpose pretrained language model: a pre-processing prompt summarizes the review and removes emotional content; a derivation prompt forces the output into the objective sentence pattern “The system must explain...”; and a generation prompt writes a short UI explanation from the derived requirement rather than from the raw review. The fixed requirement pattern is load-bearing because it makes outputs comparable, checkable, and traceable from need to requirement to explanation. The evaluation machinery is a blind paired-preference survey using six criteria (tone, style, clarity, correctness, relevance, and level of detail), with chi-square tests against a 50:50 baseline and an inter-rater agreement measure.

What would settle it

Repeat the two preference studies with an analysis that accounts for repeated voting by the same participants, for example a mixed-effects model with participant random intercepts; if the explanation preference no longer differs from chance and the requirement preference shrinks toward the margin, the paper's claim of statistically significant preferences is not supported.

Watch

Extended reading notes

Core claim

The central claim is that a prompt-based generative language model can perform the whole arc from a raw user review to a structured explainability requirement and then to a user-facing explanation, and that the result is useful but not yet reliable enough to replace a human reviewer. The evidence is a paired, blinded comparison on 58 app reviews: eight requirements engineers voted on requirements and 14 end users voted on explanations. The paper reports a significant overall preference for manual requirements, a weaker but still significant preference for manual explanations, moderate inter-rater agreement for requirements ($\kappa = 0.49$) and only slight agreement for explanations ($\kappa = 0.16$). The authors read this as evidence that automation is feasible, that AI explanations can compete on clarity and style, and that correctness and relevance remain the decisive weaknesses for AI-generated artifacts.

Load-bearing premise

The quantitative conclusion rests on the manual artifacts created in a workshop with four requirements engineers from one industrial partner being a valid gold standard, and on the chi-square tests' assumption that all votes are independent even though each participant voted on all 58 items.

Editorial extensions

If this is right

  • A development team can feed a backlog of app reviews into the pipeline and receive first-draft explainability requirements plus UI explanation texts, cutting per-task formulation time by roughly 44–52% in the tool trial.
  • Because engineers favored manual requirements mainly on relevance and correctness, AI-generated requirements should be routed through human review before entering a formal requirements document.
  • AI-generated explanations are competitive with human-written ones on clarity and style, so their most defensible near-term use is user-facing draft text that is verified before release.
  • The 58-review paired dataset of manual and AI artifacts gives later work a benchmark for measuring progress on automatic explainability requirement generation.

Reading between the lines

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

  • Because every participant voted on all 58 items, the reported chi-square tests treat repeated measurements as independent; re-analyzing with per-participant random effects would likely widen the intervals, leaving the requirement preference intact but making the explanation preference fragile.
  • A direct next experiment would swap the application domain and the participant pool: if the manual-requirement preference persists among reviewers unfamiliar with the product, it reflects requirement quality; if it shrinks, part of the gap is product familiarity.
  • The correctness weakness suggests a concrete remedy the paper leaves untested: grounding the explanation step in system-specific documentation or feature specifications, which should eliminate plausible-but-wrong statements before users see them.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper introduces a tool-supported pipeline that uses ChatGPT to automatically derive explainability requirements from user reviews and generate corresponding UI explanations. The authors evaluate the pipeline on 58 Spotify user reviews by comparing its outputs against manually crafted artifacts produced by four requirements engineers in a workshop. Two online surveys are reported: eight requirements engineers voted on which requirement they preferred per review (RQ1), and fourteen end users voted on which explanation they preferred per review (RQ2). The paper reports a statistically significant preference for manual requirements (296 vs. 168 votes; chi-square = 35.31, p = 2.81e-09) and a statistically significant but weaker preference for manual explanations (447 vs. 365 votes; chi-square = 8.28, p = 0.004), along with per-criterion reason analyses and an evaluation of the tool's efficiency and acceptance.

Significance. If the results hold, the paper makes a useful contribution to requirements engineering: it provides an open dataset of 58 reviews with paired manual and AI-generated artifacts, a reproducible prompt-based tool, and empirical evidence that human validation remains essential in AI-assisted requirements derivation. The transparent reporting of raw vote counts and the public release of data and code are notable strengths. However, the central quantitative claims rest on chi-square tests that ignore the repeated-measures structure of the data, and some interpretive claims in the abstract overstate what the data show. The underlying direction of the RQ1 finding is plausible, but the strength of the evidence for both the requirements and explanation preferences is not established by the reported analysis. The paper's value would be substantially improved by a correct statistical analysis.

major comments (3)
  1. [V-A and V-B] The chi-square tests reported in Sections V-A and V-B treat all 464 requirement votes and 812 explanation votes as independent observations. This assumption is violated because each of the 8 engineers and 14 users voted on all 58 reviews, so votes are clustered by both participant and review. The authors' own Fleiss' kappa values (0.49 for requirements, 0.16 for explanations) confirm substantial rater dependence. The reported p-values (2.81e-09 and 0.004) are therefore inflated and cannot support the 'statistically significant' preference claims. For RQ2, the 447 vs. 365 split is weak enough that a clustered reanalysis could eliminate significance entirely, which matters because the abstract and Section VI-A rely on the explanation-preference result. Please reanalyze using a method that accounts for clustering, such as a mixed-effects logistic regression with random intercepts for participant and review, or at minimum a paired within-participant analysis (e.g., a sign test on per-review outcomes or a Wilcoxon signed-rank test on per-participant preference counts), and report effect sizes with confidence intervals.
  2. [Abstract and VI-A] The abstract and Section VI-A state that 'AI-generated explanations are frequently preferred for their clarity and style.' This claim is not directly supported by the reported data. Table III shows Clarity and Style were cited as decisive reasons in a minority of votes (56 and 53 of the main-reason counts, respectively, versus 58 each for Correctness and Relevance), and the paper does not provide a per-source breakdown of votes by criterion. Given the overall preference for manual explanations and the non-significant per-criterion tests in Table IV, the evidence supports only a claim that AI explanations were sometimes preferred for stylistic reasons. Please either provide the missing breakdown or temper the wording.
  3. [V-C and VII] The tool evaluation claims 'significant efficiency gains' in the conclusion (Section VII), but Section V-C reports only descriptive percentage reductions in formulation time (44.2% in Group A, 52.5% in Group B) with no inferential test, confidence intervals, or accounting for the crossover design. With n=8 participants, these differences should be tested with a paired analysis (e.g., Wilcoxon signed-rank test) or the wording should be softened to 'descriptive reductions in time' rather than 'significant efficiency gains.'
minor comments (6)
  1. [III-A and IV] The language of the artifacts presented to participants is not stated. The pre-processing prompt in Section III-A instructs 'Use German,' while the requirement prompt uses the English sentence structure 'The system must explain...' and the reviews are described in Section VI-C as English-language Spotify reviews. Please clarify whether the manual and AI-generated requirements and explanations were in English or German when shown to the German participants, since a language mismatch could confound the preference results.
  2. [IV-C] The six quality criteria (tone, style, clarity, correctness, relevance, level of detail) are described as 'based on established standards in RE and explainability research,' but no specific reference is provided for this selection. Please cite the source(s) for these criteria.
  3. [V-A, Table II] The per-criterion chi-square tests in Tables II and IV also ignore that participants could select multiple reasons for a single vote, so the counts are not independent. Since these results are not used to support a positive claim, a brief caveat would suffice.
  4. [II] The name 'Vogelsang' is rendered as 'V ogelsang' in multiple places in the text and reference [29]; please correct the typographical spacing.
  5. [IV-B] The phrase 'randomly selected 58 reviews, ensuring that all types and categories of explanation needs were represented' is ambiguous; if the selection was stratified random, please state that explicitly.
  6. [V-B] The statement 'The overall agreement rate was low (5%)' is unclear; please specify that this means 3 out of 58 reviews received unanimous agreement (approximately 5%).

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the evaluation compares AI-generated artifacts against independently crafted manual ones, so the result is not preordained by the approach's inputs.

full rationale

The paper's central claim is empirical: a ChatGPT pipeline can draft explainability requirements and explanations, but human validation remains necessary. This claim is supported by a blinded comparison against manually crafted artifacts produced by four industrial requirements engineers in a workshop (Section IV-B). Nothing in the pipeline's construction predetermines the participants' preferences: the ChatGPT outputs are generated from review summaries via fixed prompts (Section III), while the manual artifacts are authored independently and evaluated by different engineers and end users who were blinded to origin (Section IV-C). The author-derived taxonomy of Droste et al. [12] is used only to stratify the sample of 58 reviews, not to define the outcome measure, so it does not make the evaluation circular. The quality criteria (tone, style, clarity, correctness, relevance, level of detail) are author-defined, but the actual votes are collected from participants and are not derivable from those definitions. The reported chi-square tests in Sections V-A and V-B may be statistically questionable because each participant voted on all 58 items, making the vote counts non-independent; however, that is a validity concern about inflated p-values, not a circularity concern, and the paper itself flags the limited sample size and statistical power in Section VI-C. No equation, fitted parameter, uniqueness theorem, or self-citation is reused as its own conclusion. The prior publications cited by the authors provide background taxonomies, review datasets, and related methods, but the evaluation outcome is new, empirically collected, and externally observable. Therefore no circular step is present; the appropriate circularity score is 0.

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

The paper contains no mathematical derivation, so the ledger has no fitted constants in the usual sense. The only hand-chosen numbers are the LLM temperature settings, which are procedural rather than fitted to outcomes. The empirical claim depends on imported assumptions: the validity of the authors' taxonomy and source dataset, the author-defined quality criteria, and the statistical premise that votes are independent. No new theoretical entities are introduced.

free parameters (1)
  • LLM temperature settings = 0.5 (summarization), 0.3 (requirement derivation), 0.8 (explanation generation)
    Set by hand for the three pipeline stages in Section III to balance structure and creativity; procedural, not fitted to the preference data.
assumptions (4)
  • domain assumption The explanation-need taxonomy of Droste et al. [12] is valid for selecting representative reviews and interpreting explanation needs.
    Used in Section IV-B to ensure the 58 sampled reviews cover all types and categories from the taxonomy; this comes from prior work by the same research group and is not independently revalidated here.
  • domain assumption The gold-standard dataset [39] correctly identifies explanation needs in Spotify reviews.
    The 58 reviews were sampled from this self-authored dataset (Section IV-B); if the source labels are wrong, both manual and AI artifacts are built on faulty input.
  • ad hoc to paper The six quality criteria (tone, style, clarity, correctness, relevance, level of detail) adequately capture the quality of explainability requirements and explanations.
    Defined by the authors in Section IV-C and not validated as a measurement instrument; participants could also give free-text reasons, but the fixed criteria guide the comparisons.
  • domain assumption Votes from the same participant across different reviews are independent observations.
    The chi-square tests in Sections V-A and V-B require independence, but each participant voted repeatedly on all 58 items; this assumption is unstated and likely violated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automatic Generation of Explainability Requirements and Software Explanations From User Reviews." pith.science (2026). https://pith.science/paper/6V7BQYJY

@misc{pith2026250707344,
  author       = {Pith},
  title        = {Pith review of: Automatic Generation of Explainability Requirements and Software Explanations From User Reviews},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6V7BQYJY}},
  note         = {Machine review of arXiv:2507.07344}
}
read the original abstract

Explainability has become a crucial non-functional requirement to enhance transparency, build user trust, and ensure regulatory compliance. However, translating explanation needs expressed in user feedback into structured requirements and corresponding explanations remains challenging. While existing methods can identify explanation-related concerns in user reviews, there is no established approach for systematically deriving requirements and generating aligned explanations. To contribute toward addressing this gap, we introduce a tool-supported approach that automates this process. To evaluate its effectiveness, we collaborated with an industrial automation manufacturer to create a dataset of 58 user reviews, each annotated with manually crafted explainability requirements and explanations. Our evaluation shows that while AI-generated requirements often lack relevance and correctness compared to human-created ones, the AI-generated explanations are frequently preferred for their clarity and style. Nonetheless, correctness remains an issue, highlighting the importance of human validation. This work contributes to the advancement of explainability requirements in software systems by (1) introducing an automated approach to derive requirements from user reviews and generate corresponding explanations, (2) providing empirical insights into the strengths and limitations of automatically generated artifacts, and (3) releasing a curated dataset to support future research on the automatic generation of explainability requirements.

Figures

Figures reproduced from arXiv: 2507.07344 by the authors.

Figure 1
Figure 1. Overview of our tool-supported approach for automated creation of explainability requirements and explanations. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Distribution of decisions by eight requirements engineers for preferred [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Distribution of decision ratios by 14 users on their preferred expla [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

41 extracted references · 32 canonical work pages

  1. [1]

    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

  2. [2]

    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,” in 2019 IEEE 27th International Requirements Engineering Conference (RE) , 2019, pp. 363–368

    work page 2019

  3. [3]

    Quo vadis, ex- plainability? – a research roadmap for explainability engineering,

    W. Brunotte, L. Chazette, V . Kl ¨os, and T. Speith, “Quo vadis, ex- plainability? – a research roadmap for explainability engineering,” in Requirements Engineering: F oundation for Software Quality . Cham: Springer International Publishing, 2022, pp. 26–32

    2022

  4. [4]

    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,” in Require- ments Engineering: F oundation for Software Quality . Cham: Springer Nature Switzerland, 2024, pp. 3–19

    work page 2024

  5. [5]

    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

    work page 2025

  6. [6]

    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,” in 2025 IEEE 33rd International Requirements Engineering Conference (RE), Valencia, Spain, Sep. 2025

    2025

  7. [7]

    A live extensible ontology of quality factors for textual requirements,

    J. Frattini, L. Montgomery, J. Fischbach, M. Unterkalmsteiner, D. Mendez, and D. Fucci, “A live extensible ontology of quality factors for textual requirements,” in 2022 IEEE 30th International Requirements Engineering Conference (RE) , 2022, pp. 274–280

    2022

  8. [8]

    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, Dec 2020

    work page 2020

Show all 41 references
  1. [9]

    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,” in 2023 IEEE 31st International Requirements Engineering Conference Workshops (REW), 2023, pp. 102–111

    2023

  2. [10]

    What can be concluded from user feedback? - an empirical study,

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

    2023

  3. [11]

    A study on the men- tal models of users concerning existing software,

    M. Anders, M. Obaidi, B. Paech, and K. Schneider, “A study on the men- tal models of users concerning existing software,” in Requirements Engi- neering: F oundation for Software Quality, V . Gervasi and A. V ogelsang, Eds. Cham: Springer International Publishing, 2022, pp. 235–250

    2022

  4. [12]

    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,” in 2024 IEEE 32nd International Requirements Engineering Conference (RE), 2024, pp. 55–66

    2024

  5. [13]

    Transfer learning for mining feature requests and bug reports from tweets and app store reviews,

    P. R. Henao, J. Fischbach, D. Spies, J. Frattini, and A. V ogelsang, “Transfer learning for mining feature requests and bug reports from tweets and app store reviews,” in 2021 IEEE 29th International Require- ments Engineering Conference Workshops (REW) , 2021, pp. 80–86

    2021

  6. [14]

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

    M. Obaidi, J. Fischbach, J. Droste, H. Deters, M. Herrmann, J. Kl ¨under, and K. Schneider, “Dataset: Automatic generation of explainability requirements and software explanations from user reviews,” Jul. 2025. [Online]. Available: https://doi.org/10.5281/zenodo.15839752

    2025 doi

  7. [15]

    The role of a mental model in learning to operate a device,

    D. E. Kieras and S. Bovair, “The role of a mental model in learning to operate a device,” Cognitive science , vol. 8, no. 3, pp. 255–273, 1984

    1984

  8. [16]

    Mental models: concepts for human- computer interaction research,

    N. Staggers and A. F. Norcio, “Mental models: concepts for human- computer interaction research,” International Journal of Man-machine studies, vol. 38, no. 4, pp. 587–605, 1993

    1993

  9. [17]

    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,” in 2025 IEEE 33rd International Requirements Engineering Conference (RE) , Valencia, ...

    2025

  10. [18]

    One explanation does not fit all: The promise of interactive explanations for machine learning transparency,

    K. Sokol and P. Flach, “One explanation does not fit all: The promise of interactive explanations for machine learning transparency,” KI- K¨unstliche Intelligenz, vol. 34, no. 2, pp. 235–250, 2020

    2020

  11. [19]

    The metacognitive demands and opportunities of generative ai,

    L. Tankelevitch, V . Kewenig, A. Simkute, A. E. Scott, A. Sarkar, A. Sellen, and S. Rintel, “The metacognitive demands and opportunities of generative ai,” in Proceedings of the CHI Conference on Human Factors in Computing Systems , 2024, pp. 1–24

    2024

  12. [20]

    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?” in REFSQ’25, 2025

    2025

  13. [21]

    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

  14. [22]

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

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

    2025

  15. [23]

    Peeking outside the black-box: Ai explainability requirements beyond interpretability

    J. Droste, H. Deters, R. Fuchs, and K. Schneider, “Peeking outside the black-box: Ai explainability requirements beyond interpretability.” in REFSQ’24 Workshops, 2024

    2024

  16. [24]

    On the relation of trust and explainability: Why to engineer for trust- worthiness,

    L. K ¨astner, M. Langer, V . Lazar, A. Schom¨acker, T. Speith, and S. Sterz, “On the relation of trust and explainability: Why to engineer for trust- worthiness,” in 2021 IEEE 29th International Requirements Engineering Conference Workshops (REW) . IEEE, 2021, pp. 169–175

    2021

  17. [25]

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

    L. Chazette and K. Schneider, “Explainability as a non-functional requirement: Challenges and recommendations,” Requirements Engi- neering, vol. 25, no. 4, pp. 493–514, 2020

    2020

  18. [26]

    The x factor: On the relationship between user experi- ence and explainability,

    H. Deters, J. Droste, A. Hess, V . Kl ¨os, K. Schneider, T. Speith, and A. V ogelsang, “The x factor: On the relationship between user experi- ence and explainability,” in Proceedings of the 13th Nordic Conference on Human-Computer Interaction , 2024, pp. 1–12

    2024

  19. [27]

    A systematic review and taxonomy of expla- nations in decision support and recommender systems,

    I. Nunes and D. Jannach, “A systematic review and taxonomy of expla- nations in decision support and recommender systems,” User Modeling and User-Adapted Interaction , vol. 27, pp. 393–444, 2017

    2017

  20. [28]

    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,” in ICSE- SEIP’25, 2025

    2025

  21. [29]

    Using large language models for natural language processing tasks in requirements engineering: A systematic guideline,

    A. V ogelsang and J. Fischbach, “Using large language models for natural language processing tasks in requirements engineering: A systematic guideline,” arXiv preprint arXiv:2402.13823 , 2024

    2024 arXiv

  22. [30]

    Norbert: Transfer learn- ing for requirements classification,

    T. Hey, J. Keim, A. Koziolek, and W. F. Tichy, “Norbert: Transfer learn- ing for requirements classification,” in 2020 IEEE 28th international requirements engineering conference (RE) . IEEE, 2020, pp. 169–179

    2020

  23. [31]

    How do users like this feature? a fine grained sentiment analysis of app reviews,

    E. Guzman and W. Maalej, “How do users like this feature? a fine grained sentiment analysis of app reviews,” in 2014 IEEE 22nd inter- national requirements engineering conference (RE) . IEEE, 2014, pp. 153–162

    2014

  24. [32]

    Towards trustworthy sentiment analysis in software engineering: Dataset characteristics and tool selection,

    M. Obaidi, M. Herrmann, J. Kl ¨under, and K. Schneider, “Towards trustworthy sentiment analysis in software engineering: Dataset characteristics and tool selection,” in 2025 IEEE 33rd International Requirements Engineering Conference Workshops (REW) , 2025. [Online]. Available...

    2025 arXiv

  25. [33]

    A german gold-standard dataset for sentiment analysis in software engineering,

    M. Obaidi, M. Herrmann, E. Schmid, R. Ochsner, K. Schneider, and J. Kl ¨under, “A german gold-standard dataset for sentiment analysis in software engineering,” in 2025 IEEE 33rd International Requirements Engineering Conference Workshops (REW) , 2025

    2025

  26. [34]

    Sentiment analysis tools in software engineering: A systematic mapping study,

    M. Obaidi, L. Nagel, A. Specht, and J. Kl ¨under, “Sentiment analysis tools in software engineering: A systematic mapping study,” Information and Software Technology , vol. 151, p. 107018, 2022

    2022

  27. [35]

    Development and application of sentiment analysis tools in software engineering: A systematic literature review,

    M. Obaidi and J. Kl ¨under, “Development and application of sentiment analysis tools in software engineering: A systematic literature review,” in International Conference on Evaluation and Assessment in Software Engineering. ACM, 2021

    2021

  28. [36]

    On the lim- itations of combining sentiment analysis tools in a cross-platform setting,

    M. Obaidi, H. Holm, K. Schneider, and J. Kl ¨under, “On the lim- itations of combining sentiment analysis tools in a cross-platform setting,” in Product-F ocused Software Process Improvement , D. Taibi, M. Kuhrmann, T. Mikkonen, J. Kl ¨under, and P. Abrahamsson, Eds. Cham: Spr...

    2022

  29. [37]

    Automatic creation of acceptance tests by extracting conditionals from requirements: Nlp approach and case study,

    J. Fischbach, J. Frattini, A. V ogelsang, D. Mendez, M. Unterkalmsteiner, A. Wehrle, P. R. Henao, P. Yousefi, T. Juricic, J. Radduenz et al. , “Automatic creation of acceptance tests by extracting conditionals from requirements: Nlp approach and case study,” Journal of Systems...

    2023

  30. [38]

    On-demand security requirements synthesis with relational generative adversarial networks,

    V . Koscinski, S. Hashemi, and M. Mirakhorli, “On-demand security requirements synthesis with relational generative adversarial networks,” in 2023 IEEE/ACM 45th International Conference on Software Engi- neering (ICSE) . IEEE, 2023, pp. 1609–1621

    2023

  31. [39]

    Dataset: Gold standard dataset for explainability need detection in app reviews

    M. Obaidi, “Dataset: Gold standard dataset for explainability need detection in app reviews.” Sep. 2024

    2024

  32. [40]

    The tame project: Towards improvement-oriented software environments,

    V . R. Basili and H. D. Rombach, “The tame project: Towards improvement-oriented software environments,” IEEE Transactions on software engineering, vol. 14, no. 6, pp. 758–773, 2002

    2002

  33. [41]

    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

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.