From App Features to Explanation Needs: Analyzing Correlations and Predictive Potential

Elisa Schmid; Hannah Deters; Jakob Droste; Jil Kl\"under; Kurt Schneider; Kushtrim Qengaj; Marc Herrmann; Martin Obaidi

REVIEW 4 major objections 3 minor 48 references

From App Features to Explanation Needs: Analyzing Correlations and Predictive Potential

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

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

Pith's one-line read This paper shows that explanation needs expressed in app reviews cannot be reliably predicted from app metadata alone: linear regression models produce negative $R^2$ values on validation, so hypotheses linking app properties to…

desk verdict App-metadata prediction of explanation needs: plausible negative result, but the regression evidence is a majority-class baseline, not a real test. read the letter →

arxiv 2508.03881 v2 pith:E7FJOIRT submitted 2025-08-05 cs.SE

Martin Obaidi , Kushtrim Qengaj , Jakob Droste , Hannah Deters , Marc Herrmann , Jil Klünder , Elisa Schmid , Kurt Schneider This is my paper · ORCID

classification cs.SE

keywords explanationneedsappreviewsrequirementsengineeringmetadatacorrelationanalysislinearregressionexplainabilitycrowd-based

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper tries to establish a negative result: users' explanation needs, as expressed in app reviews, cannot be reliably predicted from app metadata such as category, price, version, star rating, and review count. Analyzing a gold standard dataset of 4,495 annotated reviews and validating on 495 more, the authors find that most app properties show only weak correlations with explanation needs, with moderate correlations limited to app version, star rating, and review volume. Linear regression models trained on these properties fail to generalize, yielding negative $R^2$ values on the validation set. The paper concludes that explanation needs are context-dependent and that requirements engineers should combine metadata with direct user feedback rather than rely on automated prediction from app features.

What carries the argument

The central machinery is the explanation-need taxonomy applied to app reviews: each review is labeled as carrying an explicit, implicit, or no explanation need, and needs are assigned to categories such as Interaction, System Behavior, Security & Privacy, User Interface, Business, Domain Knowledge, and Meta Information. The study then maps these labels to metadata variables—company-defined properties like app category, price, version, age restriction, and in-app purchases, plus user feedback-derived properties like star rating, review count, and download count—and tests associations with Cramer's V, Eta, Spearman, and Pearson correlations. The final step is linear regression with $R^2$ as the measure of predictive power; the failure of $R^2$ to stay positive in validation is what carries the paper's negative conclusion.

What would settle it

Train linear regression models on a new, independently labeled dataset of app reviews using the same metadata variables and evaluate $R^2$ on a held-out set; positive $R^2$ for the explicit/implicit/none classification would contradict the paper's central claim.

Watch

Extended reading notes

Core claim

The central claim is that app properties are insufficient to predict explanation needs. On the gold standard dataset of 4,495 reviews, correlation analyses found only weak associations for most company-defined properties (app category, purchase type, price, minimum age) and feedback-derived properties, with moderate effects only for app version, number of reviews, and star rating. Linear regression models predicting explanation needs from metadata achieved negative $R^2$ values for the overall explicit/implicit/none classification, and on the 495-review validation set the negative $R^2$ values persisted, indicating the models do not generalize. Some categories—Business, Domain Knowledge, Security & Privacy—showed moderate in-sample $R^2$ values around 0.70, but validation produced near-zero or negative values for nearly all categories. The authors interpret this as evidence that explanation needs reflect latent, context-rich user expectations that are not encoded in static app properties.

Load-bearing premise

The analysis assumes that the manual labels of explanation needs in the gold standard and validation datasets correctly capture what users actually need explained; if those labels do not reflect real user needs, the weak correlations and negative $R^2$ values describe the annotation scheme rather than the actual phenomenon.

Editorial extensions

If this is right

App-store metadata should be treated as a weak screening signal, not a predictor: teams that rely on it alone will miss most explanation needs.
App version and star rating are the most informative metadata signals, so major updates and rating shifts are the moments when explanation needs are most likely to change.
Security & Privacy and System Behavior categories showed slightly higher predictive potential, suggesting metadata may be more useful for those aspects than for Interaction or User Interface.
Requirements-mining pipelines should combine metadata with review-text analysis or direct user engagement rather than attempting fully automated explanation-need detection from app features.
The negative validation $R^2$ implies that metadata-only models trained on one set of apps will not transfer to another set of apps.

Reading between the lines

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

An untested implication is that nonlinear models such as random forests or gradient boosting might extract more signal from the same metadata, though the consistently weak correlations suggest the ceiling is low.
Because the validation labels were produced by the same research group using the same taxonomy, an independent replication with external annotators would clarify whether the negative result describes the construct or the annotation scheme.
A natural extension is to feed review-text features (embeddings, topic models) into the same regression setup; the paper's own discussion suggests this direction but does not test it.
The prominence of version and star rating hints at a longitudinal design: tracking explanation needs across releases of the same app could test whether update events causally trigger needs.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

First thing you should know: the paper asks a good, previously untested question—can app-store metadata alone predict explanation needs in reviews?—and reports a negative answer. That answer may be correct, but the regression analysis as presented does not support it. The validation R² values are essentially what a trivial majority-class predictor produces, and 'linear regression' on a nominal outcome is the wrong tool.

What's actually new and useful: the paper extends a labeled dataset with metadata, builds a fresh 495-review validation set with high inter-rater agreement (κ≈0.89), and runs a broad battery of correlations. The weak-to-moderate correlations for version, star rating, and review count are plausible and worth knowing. The authors are also candid about threats to validity.

The soft spots are real. Section III says multiple logistic regression, but Section IV and Tables V–VI report 'Linear Regression' with R² and RMSE for a categorical target (explicit/implicit/none). R² is not meaningful for a nominal outcome, and the negative values don't demonstrate poor predictive performance in the way the paper implies. With 429/495 reviews in the majority class, predicting 'none' for everyone gives R²≈−0.13 on a 0/1/2 encoding—right on top of the reported −0.137. Their 'Score' of 0.86 is likewise the majority-class accuracy. So the headline 'metadata alone cannot predict explanation needs' is not established by the table; it's just the baseline. A proper multinomial logistic regression with accuracy/balanced accuracy or AUC, and comparison to a majority-class baseline, is required.

Two more issues: app-level metadata is repeated across reviews from the same app, so the independence assumption is violated; cluster-robust or mixed-effects models are needed. And 'Score' is never defined. On the construct side, labels come from the authors' own taxonomy with no external benchmark; they acknowledge this, and it's not circular, but it limits what the negative result tells us about real user needs.

Who should read it: CrowdRE and app-review mining folks. The dataset and correlation findings have some value. As a peer-reviewed paper, I'd want a major revision: define the model, use proper classifiers, report baselines, and handle clustering. If they do that, the negative result—if it survives—is a useful contribution. But in its current form, the central statistical claim doesn't hold up.

Referee Report

4 major / 3 minor

Summary. The paper investigates whether app-store metadata can predict explanation needs expressed in user reviews. Using a gold-standard dataset of 4,495 annotated reviews enriched with app metadata, plus a newly annotated validation set of 495 reviews, the authors report mostly weak correlations between app properties and explanation needs, and linear-regression models with low or negative R² values. They conclude that app metadata alone is insufficient to reliably predict explanation needs and recommend supplementing metadata analysis with direct user feedback.

Significance. A rigorously established negative result would be useful for CrowdRE and requirements-mining practice, because it would steer researchers away from metadata-only prediction and toward richer signals. The paper has concrete strengths: it makes its data publicly available, it contributes a freshly labeled validation set with high inter-rater agreement (κ = 0.89 for type, κ = 0.88 for categories), and its headline claim is falsifiable. However, the current analysis pipeline has unresolved validity issues that bear directly on the headline negative R² values: the outcome is categorical but modeled with linear regression, the 'Score' metric is never defined, and app-level predictors are applied to review-level outcomes without accounting for non-independence. These issues must be fixed before the central claim can be accepted.

major comments (4)

[III.C, IV.B, Tables V-VI] The study design states that validation is performed 'via multiple logistic regression' (Section III), but all reported predictive results in Section IV.B and Tables V and VI are labeled 'Linear Regression' with R² and RMSE. The target Etype is nominal (explicit/implicit/none), and the Ecat targets are binary category indicators. Fitting ordinary least squares to an arbitrary numeric encoding of a nominal outcome is a misspecified model, and the resulting negative R² values do not establish the paper's conclusion. For example, in the validation set 429/495 reviews have no explanation need, so a trivial majority-class predictor that ignores all app properties yields R² ≈ 1 − 132/116.4 ≈ −0.135, essentially matching the reported Etype value of −0.137 in Table VI. Please re-analyze with a proper multinomial logistic regression (or a comparable classifier), report metrics with the majority-class/no-information baseline, and specify the feature encoding, training procedure, and whether the Table V values are in-sample or cross-validated.
[Tables V and VI] The column 'Score' is used throughout Tables V and VI but is never defined in Section III.C or anywhere else. Without a definition, the reader cannot interpret values such as 0.86 for Etype. If Score is accuracy, then 0.86 is at or below the majority-class accuracy of 0.867 (429/495), which would not indicate predictive value. Please define the metric explicitly, state its range and interpretation, and, where relevant, include confidence intervals or a statistical comparison with the baseline.
[III.B, III.C, Table III] App-level metadata (app category, version, star rating, number of reviews, etc.) is attached to every review from the same app and then treated as independent observations in both the correlation analyses and the regression models. This pseudoreplication inflates the effective sample size and can bias p-values and predictive-performance estimates. The regression and correlation results should be re-examined with standard errors clustered by app, or with a mixed-effects model that includes app as a random effect, so that the conclusion about 'app properties alone' is not an artifact of treating 4,495 review rows as 4,495 independent pieces of app-level information.
[V.C, Abstract, Conclusion] The construct validity of the target variable is a load-bearing assumption that is acknowledged only as a threat. All explanation-need labels, the taxonomy, and the validation annotations come from the same research group, and no external benchmark is used. Section V.C notes that 'our taxonomy choice also constrains possible results,' but the abstract and conclusion state the negative result in general terms ('explanation needs ... cannot be precisely inferred from app metadata alone'). Please either add an external validation of the label construct or explicitly scope the conclusion to the adopted taxonomy and annotation scheme throughout the paper.

minor comments (3)

[IV.A and Table IV] The opening summary of Section IV.A says hypotheses H1^0–H4^0, H6^0, H7^0–H14^0, H19^0, H20^0, H23^0–H24^0, and H26^0 were rejected, but Table IV lists H2.10 and H6.10 as 'Do not reject' and H5^0 as 'Do not reject.' Please align the narrative with the table or clarify which sub-hypotheses are being referred to.
[Table III and Tables V-VI] The abbreviation 'Ecat' is used in Tables V and VI but is not defined in Table III; please introduce it explicitly (e.g., 'Ecategory') before first use. Also, the symbol 'r2' should be typeset as R² consistently.
[III.C] The heading 'V ariables' contains a spacing artifact and should read 'Variables.'

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the negative predictive result is an out-of-sample empirical finding, not a construction.

full rationale

No step in the derivation equates a prediction with its input by construction. The target variables (Etype, Ecategory) are manually annotated labels from the gold standard dataset [26] and the validation set, while the predictors are crawled app metadata. The regression models are fit on the gold standard and applied to the independently labeled validation set, so the reported negative R2 values are out-of-sample results, not fitted parameters renamed as predictions. The self-citations that define the taxonomy and dataset ([23], [24], [26]) are prior, externally falsifiable artifacts; they do not encode the metadata predictors or the regression outputs. Using the same group's taxonomy for validation is a legitimate construct-validity concern but not a circular reduction, because the labels are not computed from the metadata. The inconsistency between 'multiple logistic regression' in Section III and 'Linear Regression' in Section IV is an internal-validity issue, not circularity. Therefore, the central claim that app metadata alone has limited predictive power for explanation needs is an empirical finding independent of its inputs.

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

The result rests on the validity of the explanation-need labels, accurate metadata matching, review-level independence, and representativeness of the validation apps. These are domain assumptions rather than free parameters; no new entities are introduced.

free parameters (1)

Linear/logistic regression coefficients = Not reported
Models in Table V are fitted to the gold standard data; coefficients are never listed, so the fitted equations cannot be inspected and the reported R2 values cannot be recomputed externally.

assumptions (5)

domain assumption Manual explanation-need labels from the authors' taxonomy are a valid ground truth.
Section III-B; both datasets use labels from the same research group's taxonomy. If invalid, all correlations and regressions target an artifact.
domain assumption Metadata crawled from app stores was matched to the correct reviews.
Section III-B; errors add noise and could create or mask correlations.
domain assumption Reviews can be treated as independent observations although app-level metadata repeats within apps.
Section IV-A; no clustering or mixed-effects correction is reported, so significance and effect sizes may be overestimated.
domain assumption The validation set of ten hand-picked apps is representative enough to test generalizability.
Section III-B1; if not, the confirmation of the negative result does not generalize.
standard math Standard effect-size conventions for correlation coefficients apply.
Section III-C3; labels like weak and moderate rely on Cohen's conventions, which may not be appropriate for all categorical data.

how reviews work

0 comments

Cite this review

Pith. "Pith review of From App Features to Explanation Needs: Analyzing Correlations and Predictive Potential." pith.science (2026). https://pith.science/paper/E7FJOIRT

@misc{pith2026250803881,
  author       = {Pith},
  title        = {Pith review of: From App Features to Explanation Needs: Analyzing Correlations and Predictive Potential},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/E7FJOIRT}},
  note         = {Machine review of arXiv:2508.03881}
}

read the original abstract

In today's digitized world, software systems must support users in understanding both how to interact with a system and why certain behaviors occur. This study investigates whether explanation needs, classified from user reviews, can be predicted based on app properties, enabling early consideration during development and large-scale requirements mining. We analyzed a gold standard dataset of 4,495 app reviews enriched with metadata (e.g., app version, ratings, age restriction, in-app purchases). Correlation analyses identified mostly weak associations between app properties and explanation needs, with moderate correlations only for specific features such as app version, number of reviews, and star ratings. Linear regression models showed limited predictive power, with no reliable forecasts across configurations. Validation on a manually labeled dataset of 495 reviews confirmed these findings. Categories such as Security & Privacy and System Behavior showed slightly higher predictive potential, while Interaction and User Interface remained most difficult to predict. Overall, our results highlight that explanation needs are highly context-dependent and cannot be precisely inferred from app metadata alone. Developers and requirements engineers should therefore supplement metadata analysis with direct user feedback to effectively design explainable and user-centered software systems.

Figures

Figures reproduced from arXiv: 2508.03881 by the authors.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 47 canonical work pages

[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

work page 2018
[2]

Revealing the complexity of automotive software,

V . Antinyan, “Revealing the complexity of automotive software,” in ESEC/FSE’20. Association for Computing Machinery, 2020

work page 2020
[3]

Understanding large-scale software systems – structure and flows,

O. Levy and D. Feitelson, “Understanding large-scale software systems – structure and flows,” Empirical Software Engineering , vol. 26, no. 1, 2021

work page 2021
[4]

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 RE’19, 2019

work page 2019
[5]

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,” in RE. IEEE, 2021

work page 2021
[6]

Exploring the means to measure explainability: Metrics, heuristics and questionnaires,

H. Deters, J. Droste, M. Obaidi, and K. Schneider, “Exploring the means to measure explainability: Metrics, heuristics and questionnaires,” Information and Software Technology , vol. 181, p. 107682, 2025

work page 2025
[7]

How explainable is your system? towards a quality model for ex- plainability,

——, “How explainable is your system? towards a quality model for ex- plainability,” in Requirements Engineering: F oundation for Software Quality, D. Mendez and A. Moreira, Eds. Springer Nature Switzerland, 2024, pp. 3–19

work page 2024
[8]

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

work page 2025

Show all 48 references

[9]

Accu3rate: A mobile health application rating scale based on user reviews,

M. Biswas, M. H. Tania, M. S. Kaiser, R. Kabir, M. Mahmud, and A. A. Kemal, “Accu3rate: A mobile health application rating scale based on user reviews,” PloS one , vol. 16, no. 12, p. e0258050, 2021

2021
[10]

Privacy explanations–a means to end-user trust,

W. Brunotte, A. Specht, L. Chazette, and K. Schneider, “Privacy explanations–a means to end-user trust,” JSS, vol. 195, 2023

2023
[11]

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
[12]

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
[13]

How can we develop explainable systems? insights from a literature review and an interview study,

L. Chazette, J. Kl ¨under, M. Balci, and K. Schneider, “How can we develop explainable systems? insights from a literature review and an interview study,” in Proceedings of the International Conference on Software and System Processes and International Conference on Global Sof...

2022
[14]

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 Requirements Engineering: F oundation for Software Quality: 31st In- tern...

2025
[15]

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
[16]

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
[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
[18]

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). IEEE, 2023

2023
[19]

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 Proceedings of the 47th International Conference on Software Engineering: Software ...

2025
[20]

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,” in REW. IEEE, 2023

2023
[21]

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,” in HCI-COLLAB’21. Springer, 2021

2021
[22]

Revealing the role of user moods in struggling search tasks,

L. Xu, X. Zhou, and U. Gadiraju, “Revealing the role of user moods in struggling search tasks,” in SIGIR’19. Association for Computing Machinery, 2019

2019
[23]

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
[24]

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. [Online]. Available: https://doi.org/10.1007/s00766-025-00440-x

2025 doi
[25]

Prado: Predicting app adoption by learning the correlation between developer-controllable properties and user behaviors,

X. Lu, Z. Chen, X. Liu, H. Li, T. Xie, and Q. Mei, “Prado: Predicting app adoption by learning the correlation between developer-controllable properties and user behaviors,” Proc. ACM Interact. Mob. Wearable Ubiquitous Technol., vol. 1, no. 3, sep 2017

2017
[26]

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. [Online]. Available: https://doi.org/10.5281/zenodo.11522828

2024 doi
[27]

Towards public understanding of software through mod- eling,

R. Jongeling, “Towards public understanding of software through mod- eling,” in Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems , 2024, pp. 665– 669

2024
[28]

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).” in SEKE, 2023, pp. 86–89

2023
[29]

Explanations on demand-a technique for eliciting the actual need for explanations,

H. Deters, J. Droste, M. Fechner, and J. Kl ¨under, “Explanations on demand-a technique for eliciting the actual need for explanations,” in REW. IEEE, 2023

2023
[30]

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 NordiCHI’24. Association for Computing Machinery, 2024

2024
[31]

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, 2017

2017
[32]

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
[33]

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 Requirements Engineering: F oundation for Software Quality: 31st International Working Conference . Springer Nature Switzerland, 2025

2025
[34]

Cases for explainable software systems: Characteristics and examples,

M. Sadeghi, V . Kl ¨os, and A. V ogelsang, “Cases for explainable software systems: Characteristics and examples,” in 2021 IEEE 29th International Requirements Engineering Conference Workshops (REW) . IEEE, 2021, pp. 181–187

2021
[35]

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,” in 2025 IEEE 33rd International Requirements Engineering ...

2025
[36]

Investigating the criticality of user-reported issues through their relations with app rating,

A. D. Sorbo, G. Grano, C. A. Visaggio, and S. Panichella, “Investigating the criticality of user-reported issues through their relations with app rating,” Journal of Software: Evolution and Process , 2020

2020
[37]

The app sampling problem for app store mining,

W. Martin, M. Harman, Y . Jia, F. Sarro, and Y . Zhang, “The app sampling problem for app store mining,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories , 2015, pp. 123– 133

2015
[38]

Evaluating pre-trained models for user feedback analysis in software engineering: a study on classification of app-reviews,

M. A. Hadi and F. H. Fard, “Evaluating pre-trained models for user feedback analysis in software engineering: a study on classification of app-reviews,” Empirical Software Engineering , vol. 28, no. 4, p. 88, May 2023

2023
[39]

A coefficient of agreement for nominal scales,

J. Cohen, “A coefficient of agreement for nominal scales,” Educational and Psychological Measurement , vol. 20, no. 1, 1960

1960
[40]

The measurement of observer agreement for categorical data

J. Landis and G. Koch, “The measurement of observer agreement for categorical data.” Biometrics, vol. 33 1, 1977

1977
[41]

Bonferroni correction,

E. W. Weisstein, “Bonferroni correction,” Wolfram Research, Inc., 2004, accessed on 03.27.2024, 03:50 AM

2004
[42]

Cram ´er, Mathematical Methods of Statistics

H. Cram ´er, Mathematical Methods of Statistics . Princeton, NJ: Prince- ton University Press, 1946

1946
[43]

Das fehlergesetz und seine verallgemeinerungen durch fechner und pearson: A rejoinder,

K. Pearson, “Das fehlergesetz und seine verallgemeinerungen durch fechner und pearson: A rejoinder,” Biometrika, vol. 4, no. 1-2, pp. 169– 212, June 1905

1905
[44]

The proof and measurement of association between two things,

C. Spearman, “The proof and measurement of association between two things,” The American Journal of Psychology , vol. 15, no. 1, pp. 72–101, 1904

1904
[45]

Note on regression and inheritance in the case of two parents,

K. Pearson, “Note on regression and inheritance in the case of two parents,” Proceedings of the Royal Society of London , vol. 58, pp. 240– 242, 1895
[46]

Cohen, Statistical Power Analysis for the Behavioral Sciences , 2nd ed

J. Cohen, Statistical Power Analysis for the Behavioral Sciences , 2nd ed. Routledge, 1988

1988
[47]

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

M. Obaidi, Q. Kushtrim, J. Droste, H. Deters, M. Herrmann, J. Kl ¨under, E. Schmid, and K. Schneider, “Dataset: From app features to explanation needs: Analyzing correlations and predictive potential,” Jul. 2025. [Online]. Available: https://doi.org/10.5281/zenodo.15851593

2025 doi
[48]

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.

[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

work page 2018

[2] [2]

Revealing the complexity of automotive software,

V . Antinyan, “Revealing the complexity of automotive software,” in ESEC/FSE’20. Association for Computing Machinery, 2020

work page 2020

[3] [3]

Understanding large-scale software systems – structure and flows,

O. Levy and D. Feitelson, “Understanding large-scale software systems – structure and flows,” Empirical Software Engineering , vol. 26, no. 1, 2021

work page 2021

[4] [4]

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 RE’19, 2019

work page 2019

[5] [5]

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,” in RE. IEEE, 2021

work page 2021

[6] [6]

Exploring the means to measure explainability: Metrics, heuristics and questionnaires,

H. Deters, J. Droste, M. Obaidi, and K. Schneider, “Exploring the means to measure explainability: Metrics, heuristics and questionnaires,” Information and Software Technology , vol. 181, p. 107682, 2025

work page 2025

[7] [7]

How explainable is your system? towards a quality model for ex- plainability,

——, “How explainable is your system? towards a quality model for ex- plainability,” in Requirements Engineering: F oundation for Software Quality, D. Mendez and A. Moreira, Eds. Springer Nature Switzerland, 2024, pp. 3–19

work page 2024

[8] [8]

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

work page 2025