Pith. sign in

REVIEW 4 major objections 5 minor 48 references

Requirements rank better when user feedback is pooled by topic clusters, outperforming a state-of-the-art independent-ranking method.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-04 05:36 UTC pith:3JNTCD2T

load-bearing objection The clustering idea and the shared artifacts are solid, but the claim that iReFeed consistently outperforms ReFeed rests on a re-implemented baseline with different settings, so the head-to-head comparison needs to be redone or justified before the headline holds. the 4 major comments →

arxiv 2603.28677 v2 pith:3JNTCD2T submitted 2026-03-30 cs.SE

Enhancing User-Feedback Driven Requirements Prioritization

Aurek Chattopadhyay , Nan Niu , Hui Liu , Jianzhang Zhang This is my paper
classification cs.SE
keywords requirements prioritizationuser feedbackCrowdRErequirements clusteringtopic modelingrequires relationsNSGA-IInext release problem
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper tries to show that requirements prioritization improves when requirements are treated as interconnected rather than independent. It proposes iReFeed, which uses topic modeling over user app reviews to cluster candidate requirements, associates feedback at the cluster level, and ranks requirements within that context. On 94 prioritization instances from four real-world apps, iReFeed outperforms ReFeed across recall, precision, F1, and F2. The paper also shows that feeding topically clustered requirements to ChatGPT surfaces additional 'requires' pairs, and adding a dependency value as a third NSGA-II objective increases the share of solutions on the reference Pareto front, improving search-based release planning.

Core claim

The central claim is that interconnectedness itself, as derived from user feedback topics, is a source of prioritization signal. iReFeed first runs topic modeling (LDA or BERTopic) over large sets of Google Play reviews, groups the candidate requirements of a release into topically coherent clusters, then associates each cluster with the union of feedback messages from its member requirements. Priorities are computed from sentiment, intention, and similarity scores at the cluster level rather than per requirement. On 94 instances from Discord, Microsoft 365 Word, Webex, and Zoom, iReFeed consistently outperforms ReFeed, with the coherence-weighted LDA-C variant recommended. The paper further

What carries the argument

The central mechanism is the topic cluster: user feedback is topic-modeled, candidate requirements are grouped by the resulting topics, and all feedback associated with a cluster's requirements is pooled before priority scoring. Equations (2) and (3) replace ReFeed's per-requirement feedback mapping with a cluster-level mapping; a coherence factor α(FC) weights clusters by internal pairwise similarity. The second mechanism is the D-value, a count of how often a requirement appears as the right-hand side of a ChatGPT-discovered 'requires' pair, added as a third NSGA-II objective to bias release planning toward requirements that are prerequisites for others.

Load-bearing premise

The evaluation treats vendor release timestamps as authoritative ground truth for which requirements were correctly prioritized; if release timing is driven by marketing windows, contracts, dependencies, or resource constraints rather than user-feedback-aligned priority, the comparison may not measure prioritization quality at all.

What would settle it

Compare iReFeed against ReFeed on prioritization instances where ground truth is set by explicit expert judgment of priority rather than release timestamps. Concretely, take the Discord, Word, Webex, and Zoom release notes, have independent practitioners rank each instance's top-k requirements, and recompute F2 at top-k; if iReFeed's advantage disappears or reverses, the claim that interconnectedness improves prioritization is not supported.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • Prioritization systems that treat requirements as independent leave usable signal on the table; cluster-level feedback pooling captures this signal and improves ranking quality.
  • Topic modeling over user reviews can double as a dependency-discovery aid: cluster-wise LLM prompting finds 'requires' pairs that whole-set prompting misses.
  • Adding dependency counts as an objective in search-based release planning shifts the Pareto front toward solutions that respect prerequisite structure.
  • The coherence-weighting variant suggests not all clusters are equal; more internally coherent clusters deserve stronger priority influence.
  • The method is fully automated from reviews to ranked requirements, so it scales to settings where manual AHP-style prioritization breaks down.

Where Pith is reading between the lines

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

  • If release timing itself encodes customer priorities imperfectly, the reported margin over ReFeed may shrink under ground truth derived from explicit stakeholder ranking; the release-timestamp assumption deserves direct testing.
  • The same topic-cluster step could be reused as a feature in other LLM-based requirements engineering tasks, such as traceability or inconsistency detection, not just prioritization.
  • The inverse D-value variant's poor performance suggests dependency-aware search is not a random perturbation; the direction of the dependency objective matters and could be tested on other search-based planning algorithms.
  • The 'requires' pairs from ChatGPT are noisy, so treating them as a soft objective rather than hard constraints may be why NSGA-II still helps; this soft-versus-hard design choice is testable.

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

4 major / 5 minor

Summary. The paper proposes iReFeed, an extension of ReFeed (Kifetew et al., 2021) for user-feedback-driven requirements prioritization. Instead of associating each user message with a single requirement, iReFeed first clusters requirements topically using LDA or BERTopic over user reviews, then associates feedback at the cluster level, and finally computes per-requirement priorities using a modified ReFeed formula with cluster-coherence weighting. The paper evaluates four iReFeed variants against a reimplemented ReFeed on 94 prioritization instances from Discord, Microsoft 365 Word, Webex, and Zoom, using release-note timestamps as ground truth. A second experiment (RQ2) uses ChatGPT to extract asymmetric 'requires' pairs from the Word Processor benchmark, comparing whole-set prompting against cluster-wise prompting. A third experiment (RQ3) adds a dependency value derived from these pairs as a third NSGA-II objective and reports that iReFeed solutions occupy a larger share of the reference Pareto front than the baseline. The paper concludes that interconnectedness improves prioritization, enables automated dependency discovery, and strengthens search-based release planning.

Significance. The work is potentially valuable: it operationalizes requirements interconnectedness in a feedback-driven prioritization pipeline, and it makes a credible attempt to connect CrowdRE with SBSE. The authors provide publicly available datasets and implementations, which is exemplary for reproducibility. The RQ2 use of modern LLMs for dependency extraction is timely. However, the headline claims are weakened by evaluation choices: the ReFeed comparison is against a reimplemented baseline, the release-timestamp ground truth is a proxy whose validity is not established, the RQ3 comparison uses different objective spaces, and the leakage discussion in RQ2 is logically incorrect. If these concerns are addressed with additional experiments and re-analysis, the core idea could become a solid contribution.

major comments (4)
  1. [§3, Steps 2–3 and §4.2] The comparison against ReFeed is not against the original method. The paper reimplements ReFeed with cosine similarity threshold 0.1 instead of the Jaccard threshold 0 used in [13], and replaces the ontology-based intention score with a random forest classifier trained on [31]. These changes are applied to both ReFeed and iReFeed, so the experiment isolates cluster-level association, but the claim 'iReFeed consistently outperforms ReFeed' (Abstract, §4.2) is unsupported for the original ReFeed. Please compare against the original configuration or provide evidence that the modified baseline is equivalent or stronger.
  2. [§4.1, ground truth definition] The evaluation labels requirements released in the earlier of two consecutive periods as the true top-k set. The statement 'The release timestamps give rise to the prioritization’s ground truth in an authoritative way' is not justified: release timing is often determined by marketing windows, dependencies, contracts, or other factors unrelated to feedback-driven priority. Because both methods are evaluated on this proxy, the measured recall/precision may reflect release-order prediction rather than prioritization quality. This threatens the principal RQ1 conclusion. Please validate the ground truth against explicit priority indicators or discuss and mitigate this confound.
  3. [§6, Table 6 and Fig. 5] The RQ3 comparison is not methodologically fair. The baseline NSGA-II optimizes two objectives (value, cost), while iReFeed NSGA-II optimizes three (value, cost, D-value). The reference Pareto front is then constructed using only value and cost, and performance is measured by the fraction of each algorithm's solutions on that 2-D front. The third objective is ignored in the evaluation, so a 3-objective search can produce different 2-D projections for reasons unrelated to solution quality. Please either solve the same bi-objective problem with D-value as a constraint, evaluate in the 3-objective space (e.g., hypervolume), or otherwise make the comparison comparable.
  4. [§5, discussion of data leakage] The data-leakage reasoning is backwards. Because the Word Processor benchmark was published in 2016 and ChatGPT 4.5/4o were trained on web data up to their release dates, the dataset is more likely, not less, to have been memorized. The low precision (≤0.30) of the extracted pairs also means the D-value fed to NSGA-II in RQ3 is largely noise. The paper should test for leakage (e.g., pre-registered prompts, random splits) and validate the 'requires' pairs before using them as an objective.
minor comments (5)
  1. [Fig. 3] The figure reports averages without error bars or confidence intervals, and the text mentions combined Wilcoxon p-values without giving the actual p-values or effect sizes. Please include per-instance distributions or at least standard deviations.
  2. [Table 4] For ChatGPT 4o, iReFeed finds 32 pairs, the same count as baseline; the claim that 'iReFeed does help uncover additional pairs' needs an overlap analysis to show the pairs are different and not simply a reordering.
  3. [Eq. (3)] α(FC) is defined as min(1, average pairwise similarity); the notation makes it look like a per-summation weight. Clarify that α(FC) is constant for a cluster and should be moved outside the sum.
  4. [§3, Step 2] The change from Jaccard threshold 0 to cosine threshold 0.1 is described as 'slightly increased'; these thresholds operate on different similarity scales and are not directly comparable. Please justify the equivalence.
  5. [References] Reference [50] is a Substack blog post; replace with a peer-reviewed model comparison.

Circularity Check

0 steps flagged

No circular derivation: iReFeed is an empirical pipeline evaluated against external ground truth, not a claim whose output is equivalent to its inputs.

full rationale

The paper's central claims are empirical comparisons, not derived predictions. RQ1 uses release-note timestamps as an external, authoritative ground truth (Sec. 4.1) and compares ReFeed (Eq. 1) against iReFeed (Eqs. 2-3); priority scores are computed from feedback similarity and sentiment/intention, not from the ground-truth labels, so there is no Eq.-to-Eq. reduction. The topic count of 20 and the coherence weight alpha are design choices, and alpha=1 reduces Eq. 3 to Eq. 2, but neither is fitted to the RQ1 outcome in a way that makes the comparison forced. RQ2 evaluates ChatGPT cluster-wise prompting against the 65 manually defined 'requires' pairs of the Word Processor benchmark [17]; clusters are produced by the method itself, but the ground truth is external, so the evaluation is not self-definitional. RQ3 uses the LLM-generated pairs as a third NSGA-II objective and measures the share of solutions on a reference Pareto front defined by Finkelstein et al. [8]; adding an objective and observing a changed front is an empirical pipeline, not a tautology. The re-implemented ReFeed baseline (cosine threshold 0.1, random-forest intention classifier) and the release-note ground truth are validity threats, not circularity. The paper explicitly acknowledges external-validity limits (Secs. 4.3, 6). No load-bearing self-citation or imported uniqueness theorem is present. A low baseline/ground-truth fidelity concern therefore does not raise the circularity score.

Axiom & Free-Parameter Ledger

5 free parameters · 6 axioms · 1 invented entities

The approach rests on several domain assumptions about what user feedback topics mean, what release timing means, and what LLM output can be trusted for. These are not derived from first principles and are the main source of the soundness risk.

free parameters (5)
  • Number of topics K = 20
    Selected after experimenting with several topic counts, not by a data-driven criterion (Section 3, Step 1).
  • Feedback-requirement association threshold = cosine similarity 0.1
    Chosen by hand as a 'slight increase' from ReFeed's Jaccard 0 threshold; directly affects which reviews are linked to requirements (Section 3, Step 2).
  • Coherence weight alpha(FC) = min(1, average pairwise similarity of requirements in cluster)
    Introduced ad hoc in Eq. 3 to boost priorities of internally coherent clusters; not derived from a fitted model.
  • Review lookback window = one release cycle buffer; at most two years of reviews
    Chosen to ensure time sensitivity; the optimal amount of feedback data is left to future work (Section 4.1).
  • LDA/BERTopic hyperparameters = LDA passes=15; UMAP components=5, neighbors=15, min_dist=0; HDBSCAN min_samples=10
    Fixed without sensitivity analysis; the paper notes the literature has no common recommendation for topic count (Section 3, Step 1).
axioms (6)
  • domain assumption Release timestamps are an authoritative ground truth for prioritization.
    Section 4.1 states this; release decisions can be influenced by marketing, contracts, and dependencies rather than user-feedback priority.
  • domain assumption Requirements that share a feedback topic are 'interconnected' and should pool their feedback.
    Core premise of iReFeed in Section 3 Step 2; not independently validated against true requirements dependencies.
  • domain assumption Asymmetric 'requires' relations constrain valid release plans.
    Section 2.2 defines 'ra requires rb' to mean rb must not be prioritized lower or later; this is used as ground truth in RQ2/RQ3.
  • domain assumption The 65 manually labeled 'requires' pairs in the Word Processor benchmark are correct.
    Used as ground truth in Section 5; no independent verification is reported.
  • ad hoc to paper LLM-generated 'requires' pairs can serve as useful search objectives even at low recall.
    Section 6 feeds ChatGPT-4.5 combined pairs into NSGA-II as D-value; the paper provides no evidence that low-precision pairs improve rather than distort planning.
  • standard math Standard Pareto optimality and NSGA-II are suitable for the next release problem.
    Section 2.1; established in prior work, not derived here.
invented entities (1)
  • Dependency value (D-value) and its five transformations no independent evidence
    purpose: Third objective in NSGA-II to encode 'requires' relation counts
    D-value is constructed from LLM-generated pairs with no external validation; the paper shows its effect only via the reference-front metric.

pith-pipeline@v1.3.0-alltime-deepseek · 17731 in / 14418 out tokens · 151529 ms · 2026-08-04T05:36:22.604003+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of Enhancing User-Feedback Driven Requirements Prioritization." pith.science (2026). https://pith.science/paper/3JNTCD2T

@misc{pith2026260328677,
  author       = {Pith},
  title        = {Pith review of: Enhancing User-Feedback Driven Requirements Prioritization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3JNTCD2T}},
  note         = {Machine review of arXiv:2603.28677}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Context: Requirements prioritization is a challenging problem that is aimed to deliver the most suitable subset from a pool of candidate requirements. The problem is NP-hard when formulated as an optimization problem. Feedback from end users can offer valuable support for software evolution, and ReFeed represents a state-of-the-art in automatically inferring a requirement's priority via quantifiable properties of the feedback messages associated with a candidate requirement. Objectives: In this paper, we enhance ReFeed by shifting the focus of prioritization from treating requirements as independent entities toward interconnecting them. Additionally, we explore if interconnecting requirements provide additional value for search-based solutions. Methods: We leverage user feedback from mobile app stores to group requirements into topically coherent clusters. Such interconnectedness, in turn, helps to auto-generate additional "requires" relations in candidate requirements. These "requires" pairs are then integrated into a search-based software engineering solution. Results: The experiments on 94 requirements prioritization instances from four real-world software applications show that our enhancement outperforms ReFeed. In addition, we illustrate how incorporating interconnectedness among requirements improves search-based solutions. Conclusion: Our findings show that requirements interconnectedness improves user feedback driven requirements prioritization, helps uncover additional "requires" relations in candidate requirements, and also strengthens search-based release planning.

Figures

Figures reproduced from arXiv: 2603.28677 by Aurek Chattopadhyay, Hui Liu, Jianzhang Zhang, Nan Niu.

Figure 1
Figure 1. Figure 1: Compared with ReFeed [13] that associates user-feedback messages to a single [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of iReFeed processing pipeline. [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Answering RQ1 with average performances of ReFeed and the four variants of iReFeed: LDA, LDA-C, BERTopic, and BERTopic-C. the availability of the user reviews up till Jan 2025 was sensible to us. Given the ground truth, we measure the qualities of ReFeed and iReFeed prioritization results by computing recall (R), precision (P), F1-score (F1), and F2-score (F2). These metrics quantify how much a prioritizat… view at source ↗
Figure 4
Figure 4. Figure 4: Examples from a Microsoft 365 Word instance illustrating the differences between [PITH_FULL_IMAGE:figures/full_fig_p017_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: One run of RQ3 with search results from the baseline NSGA-II and the iReFeed D-value variant NSGA-II. 22 [PITH_FULL_IMAGE:figures/full_fig_p022_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: RQ3: Comparison of each iReFeed variant against the Baseline across 10 runs [PITH_FULL_IMAGE:figures/full_fig_p024_6.png] view at source ↗

discussion (0)

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

Reference graph

Works this paper leans on

48 extracted references · 21 canonical work pages

  1. [1]

    Marner, S

    K. Marner, S. Wagner, G. Ruhe, Release planning patterns for the au- tomotive domain, Computers 11 (6) (2022) 89:1–89:26. URLhttps://doi.org/10.3390/computers11060089

    work page doi:10.3390/computers11060089 2022

  2. [2]

    Spinellis, The strategic importance of release engineering, IEEE Soft- ware 32 (2) (2015) 3–5

    D. Spinellis, The strategic importance of release engineering, IEEE Soft- ware 32 (2) (2015) 3–5. URLhttps://doi.org/10.1109/MS.2015.54

    work page doi:10.1109/ms.2015.54 2015

  3. [3]

    Nayebi, G

    M. Nayebi, G. Ruhe, Analytical product release planning, in: C. Bird, T. Menzies, T. Zimmermann (Eds.), The Art and Science of Analyzing Software Data, Morgan Kaufmann, 2015, pp. 555–589. URLhttps://doi.org/10.1016/b978-0-12-411519-4.00019-7

    work page doi:10.1016/b978-0-12-411519-4.00019-7 2015

  4. [4]

    Zorn-Pauli, B

    G. Zorn-Pauli, B. Paech, T. Beck, H. Karey, G. Ruhe, Analyzing an industrial strategic release planning process - a case study at Roche Diagnostics, in: Proceedings of the 19th International Working Con- ference on Requirements Engineering: Foundation for Software Quality (REFSQ), Essen, Germany, 2013, pp. 269–284. URLhttps://doi.org/10.1007/978-3-642-37422-7\_19

    work page doi:10.1007/978-3-642-37422-7 2013

  5. [5]

    A. J. Bagnall, V. J. Rayward-Smith, I. M. Whittley, The next release problem, Information & Software Technology 43 (14) (2001) 883–890. URLhttps://doi.org/10.1016/S0950-5849(01)00194-X

    work page doi:10.1016/s0950-5849(01)00194-x 2001

  6. [6]

    M. S. Feather, T. Menzies, Converging on the optimal attainment of re- quirements, in: Proceedings of the 10th IEEE Joint International Con- ference on Requirements Engineering (RE), Essen, Germany, 2002, pp. 263–272. URLhttps://doi.org/10.1109/ICRE.2002.1048537 26

    Pith/arXiv arXiv 2002

  7. [7]

    Zhang, M

    Y. Zhang, M. Harman, S. A. Mansouri, The multi-objective next release problem, in: Proceedings of the 9th Annual Conference on Genetic and Evolutionary Computation (GECCO), London, UK, 2007, pp. 1129– 1137. URLhttps://doi.org/10.1145/1276958.1277179

    arXiv 2007

  8. [8]

    Finkelstein, M

    A. Finkelstein, M. Harman, S. A. Mansouri, J. Ren, Y. Zhang, A search based approach to fairness analysis in requirement assignments to aid negotiation, mediation and decision making, Requirements Engineering 14 (4) (2009) 231–245. URLhttps://doi.org/10.1007/s00766-009-0075-y

    work page doi:10.1007/s00766-009-0075-y 2009

  9. [9]

    J. J. Durillo, Y. Zhang, E. Alba, M. Harman, A. J. Nebro, A study of the bi-objective next release problem, Empirical Software Engineering 16 (1) (2011) 29–60. URLhttps://doi.org/10.1007/s10664-010-9147-3

    work page doi:10.1007/s10664-010-9147-3 2011

  10. [10]

    X. Cai, O. Wei, Z. Huang, Evolutionary approaches for multi-objective next release problem, Computing and Informatics 31 (4) (2012) 847–875

    2012

  11. [11]

    J. Xuan, H. Jiang, Z. Ren, Z. Luo, Solving the large scale next release problemwithabackbone-basedmultilevelalgorithm, IEEETransactions on Software Engineering 38 (5) (2012) 261–284. URLhttps://doi.org/10.1109/TSE.2011.92

    doi:10.1109/tse.2011.92 2012

  12. [12]

    M.R.Karim, G.Ruhe, Bi-objectivegeneticsearchforreleaseplanningin support of themes, in: Proceedings of the 6th International Symposium on Search-Based Software Engineering (SSBSE), Fortaleza, Brazil, 2014, pp. 123–137. URLhttps://doi.org/10.1007/978-3-319-09940-8\_9

    work page doi:10.1007/978-3-319-09940-8 2014

  13. [13]

    F. M. Kifetew, A. Perini, A. Susi, A. Siena, D. M. nante, I. Morales- Ramirez, Automating user-feedback driven requirements prioritization, Information & Software Technology 138 (2021) 106635:1–106635:16. URLhttps://doi.org/10.1016/j.infsof.2021.106635

    arXiv 2021

  14. [14]

    F. B. Aydemir, F. Dalpiaz, S. Brinkkemper, P. Giorgini, J. Mylopoulos, The next release problem revisited: A new avenue for goal models, in: Proceedings of the 26th IEEE International Requirements Engineering 27 Conference (RE), Banff, Canada, 2018, pp. 5–16. URLhttps://doi.org/10.1109/RE.2018.00-56

    work page doi:10.1109/re.2018.00-56 2018

  15. [15]

    Carlshamre, K

    P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, J. N. och Dag, An industrial survey of requirements interdependencies in software product release planning, in: Proceedings of the 5th IEEE International Sym- posium on Requirements Engineering (RE), Toronto, Canada, 2001, pp. 84–91. URLhttps://doi.org/10.1109/ISRE.2001.948547

    arXiv 2001

  16. [16]

    W. N. Robinson, S. D. Pawlowski, V. Volkov, Requirements interaction management, ACM Computing Surveys 35 (1) (2003) 132–190. URLhttps://doi.org/10.1145/857076.857079

    arXiv 2003

  17. [17]

    bi-objective genetic search for re- lease planning in support of themes

    M. R. Karim, G. Ruhe, Datasets of “bi-objective genetic search for re- lease planning in support of themes”,https://sites.google.com/sit e/mrkarim/data-sets, Last accessed: March 31, 2026(2016)

    2026

  18. [18]

    Perini, A

    A. Perini, A. Susi, P. Avesani, A machine learning approach to software requirements prioritization, IEEE Transactions on Software Engineering 39 (4) (2013) 445–461. URLhttps://doi.org/10.1109/TSE.2012.52

    work page doi:10.1109/tse.2012.52 2013

  19. [19]

    Ruhe, Product Release Planning - Methods, Tools and Applications, CRC Press, 2010

    G. Ruhe, Product Release Planning - Methods, Tools and Applications, CRC Press, 2010

    2010

  20. [21]

    Leffingwell, D

    D. Leffingwell, D. Widrig, Managing Software Requirements: A Use Case Approach, Addison-Wesley, 2003. URLhttps://dl.acm.org/doi/10.5555/829554

    work page doi:10.5555/829554 2003

  21. [22]

    Karlsson, K

    J. Karlsson, K. Ryan, A cost-value approach for prioritizing require- ments, IEEE Software 14 (5) (1997) 67–74. URLhttps://doi.org/10.1109/52.605933 28

    work page doi:10.1109/52.605933 1997

  22. [23]

    Karlsson, C

    J. Karlsson, C. Wohlin, B. Regnell, An evaluation of methods for priori- tizingsoftwarerequirements, Information&SoftwareTechnology39(14-

  23. [24]

    URLhttps://doi.org/10.1016/S0950-5849(97)00053-0

    (1998) 939–947. URLhttps://doi.org/10.1016/S0950-5849(97)00053-0

    work page doi:10.1016/s0950-5849(97)00053-0 1998

  24. [25]

    Perini, A

    A. Perini, A. Susi, F. Ricca, C. Bazzanella, An empirical study to com- pare the accuracy of ahp and cbranking techniques for requirements pri- oritization, in: Proceedings of the 5th International Workshop on Com- parative Evaluation in Requirements Engineering (CERE), New Delhi, India, 2007, pp. 23–35. URLhttps://doi.org/10.1109/CERE.2007.1

    work page doi:10.1109/cere.2007.1 2007

  25. [26]

    Rahimi, A

    I. Rahimi, A. H. Gandomi, M. R. Nikoo, F. Chen, A compara- tive study on evolutionary multi-objective algorithms for next release problem, Applied Soft Computing 52 (3) (2023) 110472:1–110472:13. doi:https://doi.org/10.1016/j.asoc.2023.110472

    arXiv 2023

  26. [27]

    Zhang, M

    Y. Zhang, M. Harman, G. Ochoa, G. Ruhe, S. Brinkkemper, An empiri- cal study of meta- and hyper-heuristic search for multi-objective release planning, ACM Transactions on Software Engineering and Methodology 27 (1) (2012) 3:1–3:32. URLhttps://doi.org/10.1145/3196831

    work page doi:10.1145/3196831 2012

  27. [28]

    Svahnberg, T

    M. Svahnberg, T. Gorschek, R. Feldt, R. Torkar, S. B. Saleem, M. U. Shafique, A systematic review on strategic release planning models, In- formation & Software Technology 52 (3) (2010) 237–248. URLhttps://doi.org/10.1016/j.infsof.2009.11.006

    work page doi:10.1016/j.infsof.2009.11.006 2010

  28. [29]

    Ameller, C

    D. Ameller, C. Farré, X. Franch, G. Rufián, A survey on software release planning models, in: Proceedings of the 17th International Conference on Product-Focused Software Process Improvement (PROFES), Trond- heim, Norway, 2016, pp. 48–65. URLhttps://doi.org/10.1007/978-3-319-49094-6\_4

    work page doi:10.1007/978-3-319-49094-6 2016

  29. [30]

    E. C. Groen, J. Dörr, S. Adam, Towards crowd-based requirements en- gineering a research preview, in: Proceedings of the 21st International Working Conference on Requirements Engineering: Foundation for Soft- ware Quality (REFSQ), Essen, Germany, 2015, pp. 247–253. URLhttps://doi.org/10.1007/978-3-319-16101-3\_16 29

    work page doi:10.1007/978-3-319-16101-3 2015

  30. [31]

    Palomba, P

    F. Palomba, P. Salza, A. Ciurumelea, S. Panichella, H. C. Gall, F. Fer- rucci, A. De Lucia, Recommending and localizing change requests for mobile apps based on user reviews, in: Proceedings of the 39th IEEE/ACM International Conference on Software Engineering (ICSE), Buenos Aires, Argentina, 2017, pp. 106–117. URLhttps://doi.org/10.1109/ICSE.2017.18

    doi:10.1109/icse.2017.18 2017

  31. [32]

    Scalabrino, G

    S. Scalabrino, G. Bavota, B. Russo, M. Di Penta, R. Oliveto, Listening to the crowd for the release planning of mobile apps, IEEE Transactions on Software Engineering 45 (1) (2019) 68–86. URLhttps://doi.org/10.1109/TSE.2017.2759112

    arXiv 2019

  32. [35]

    C. M. C. Silva, M. Galster, F. Gilson, Topic modeling in software engi- neering research, Empirical Software Engineering 26 (6) (2021) 120:1– 120:62. URLhttps://doi.org/10.1007/s10664-021-10026-0

    work page doi:10.1007/s10664-021-10026-0 2021

  33. [37]

    doi:10.1007/s10664-014-9312-1

    A.Hindle, C.Bird, T.Zimmermann, N.Nagappan, Dotopicsmakesense to managers and developers?, Empirical Software Engineering 20 (2) (2015) 479–515. doi:10.1007/s10664-014-9312-1. URLhttps://doi.org/10.1007/s10664-014-9312-1 30

    work page doi:10.1007/s10664-014-9312-1 2015

  34. [38]

    Tiarks, W

    R. Tiarks, W. Maalej, How does a typical tutorial for mobile de- velopment look like?, in: Proceedings of the 11th Working Confer- ence on Mining Software Repositories (MSR 2014), Association for Computing Machinery, New York, NY, USA, 2014, pp. 272–281. doi:10.1145/2597073.2597106. URLhttps://doi.org/10.1145/2597073.2597106

    arXiv 2014

  35. [39]

    Palomba, M

    F. Palomba, M. L. Vásquez, G. Bavota, M. D. Rocco Oliveto, D. Poshy- vanyk, A. De Lucia, User reviews matter! Tracking crowdsourced re- views to support evolution of successful apps, in: Proceedings of the 31st IEEE International Conference on Software Maintenance and Evo- lution (ICSME), Bremen, Germany, 2015, pp. 291–300. URLhttps://doi.org/10.1109/ICSM...

    arXiv 2015

  36. [40]

    P. Qi, Y. Zhang, Y. Zhang, J. Bolton, C. D. Manning, Stanza: A Python natural language processing toolkit for many human languages, CoRR (March 2020). URLhttps://doi.org/10.48550/arXiv.2003.07082

    Pith/arXiv arXiv doi:10.48550/arxiv.2003.07082 2020

  37. [41]

    Discord, Change Log,https://discord.com/developers/docs/chan ge-log, Last accessed: March 31, 2026(2026)

    2026

  38. [42]

    Microsoft, Microsoft 365 Apps for Windows: Archived Release Notes, https://learn.microsoft.com/en-us/officeupdates/monthly-cha nnel-archived, Last accessed: March 31, 2026(2026)

    2026

  39. [43]

    Cisco, Webex App: What’s New,https://help.webex.com/en-us/ar ticle/8dmbcr/Webex-App-|-What’s-New, Last accessed: March 31, 2026(2026)

    2026

  40. [44]

    Zoom, Release Notes for Windows,https://support.zoom.us/hc /en-us/articles/201361953-Release-notes-for-Windows, Last accessed: March 31, 2026(2026)

    arXiv 2026

  41. [45]

    Python Software Foundation, Google-Play-Scraper,https://pypi.o rg/project/google- play- scraper/, Last accessed: March 31, 2026(2026)

    2026

  42. [46]

    D. M. Berry, J. Cleland-Huang, A. Ferrari, W. Maalej, J. Mylopoulos, D. Zowghi, Panel: Context-dependent evaluation of tools for NL RE 31 tasks: Recall vs. precision, and beyond, in: Proceedings of the 25th IEEE International Requirements Engineering Conference (RE), Lisbon, Portugal, 2017, pp. 570–573. URLhttps://doi.org/10.1109/RE.2017.64

    work page doi:10.1109/re.2017.64 2017

  43. [47]

    Fantechi, S

    A. Fantechi, S. Gnesi, L. C. Passaro, L. Semini, Inconsistency detection in natural language requirements using ChatGPT: A preliminary eval- uation, in: Proceedings of the 31st IEEE International Requirements Engineering Conference (RE), Hannover, Germany, 2023, pp. 335–340. URLhttps://doi.org/10.1109/RE57278.2023.00045

    arXiv 2023

  44. [48]

    A. D. Rodriguez, K. R. Dearstyne, J. Cleland-Huang, Prompts mat- ter: Insights and strategies for prompt engineering in automated soft- ware traceability, in: Proceedings of the 11th International Workshop on Software and Systems Traceability (SST), Hannover, Germany, 2023, pp. 455–464. URLhttps://doi.org/10.1109/REW57809.2023.00087

    arXiv 2023

  45. [49]

    Preda, C

    A.-R. Preda, C. Mayr-Dorn, A. Mashkoor, A. Egyed, Supporting high- level to low-level requirements coverage reviewing with large language models, in: Proceedings of the 14th International Conference on Soft- ware Engineering and Knowledge Engineering, SEKE’02, Ischia, Italy, 2024, pp. 159–166. doi:https://doi.org/10.1145/568760.568789

    arXiv 2024

  46. [50]

    Santos, T

    S. Santos, T. D. Breaux, T. B. Norton, S. Haghighi, S. Ghanavati, Inter- linking user stories and GUI prototyping: A semi-automatic LLM-based approach, in: Proceedings of the 32nd IEEE International Requirements Engineering Conference (RE), Reykjavik, Iceland, 2024, pp. 380–388. URLhttps://doi.org/10.1109/RE59067.2024.00045

    arXiv 2024

  47. [51]

    Mori, GPT-4.5 vs GPT-4o: Comparing OpenAI’s Latest AI Models, https://giancarlomori.substack.com/p/gpt-45-vs-gpt-4o-com paring-openais, Last accessed: March 31, 2026(2025)

    G. Mori, GPT-4.5 vs GPT-4o: Comparing OpenAI’s Latest AI Models, https://giancarlomori.substack.com/p/gpt-45-vs-gpt-4o-com paring-openais, Last accessed: March 31, 2026(2025)

    2026

  48. [52]

    Raymond, Top 10 Cons or Disadvantages of Agile Methodology,ht tps://projectmanagers.net/top-10-cons-or-disadvantages-o f-agile-methodology/, Last accessed: March 31, 2026(2023)

    D. Raymond, Top 10 Cons or Disadvantages of Agile Methodology,ht tps://projectmanagers.net/top-10-cons-or-disadvantages-o f-agile-methodology/, Last accessed: March 31, 2026(2023). 32

    2026