Pith. sign in

REVIEW 5 major objections 6 minor 1 cited by

Automatic Multi-level Feature Tree Construction for Domain-Specific Reusable Artifacts Management

T0 review · 5 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read FTBUILDER claims that multi-level feature trees for software artifacts can be built automatically by clustering functional descriptions and asking an LLM to name each cluster, and that on Linux distributions the resulting tree beats the…

desk verdict The pipeline is sensible and worth publishing eventually, but the headline quality gain is an artifact of in-sample selection, not demonstrated superiority. read the letter →

arxiv 2506.03946 v2 pith:FRZVYVSN submitted 2025-06-04 cs.SE

Dongming Jin , Zhi Jin , Nianyu Li , Kai Yang , Linyu Li , Suijing Guan This is my paper
classification cs.SE
keywords softwarereusefeaturetreelargelanguagemodelsartifactmanagementclusteringembeddingLinuxdistributions
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper tries to show that the multi-level feature tree — a hierarchy that organizes reusable software artifacts by what they do — can be built automatically, without a domain expert curating every node. Its proposed pipeline, FTBUILDER, crawls Linux distribution metadata, merges duplicate artifacts, clusters artifact descriptions by embedding similarity, and asks an LLM to summarize each cluster as a parent feature, recursing until a tree of the desired depth emerges. On the Linux distribution testbed, the paper reports that the best of 24 pipeline configurations produces a three-level tree that beats the official hand-built feature tree on the silhouette coefficient (9% higher) and GValue (11% higher), and that developers using the tree select correct artifacts 26% faster while GPT-4o's artifact-recommendation accuracy rises from 20% to 67%. If true, this would turn a slow, expertise-bound task into a repeatable, mostly automatic process and make large software ecosystems navigable by function rather than by package name.

What carries the argument

The load-bearing mechanism is the recursive cluster-then-summarize loop. At each level, functional descriptions of artifacts (or of lower-level clusters) are mapped to embedding vectors; a clustering algorithm groups vectors so that in-cluster similarity is high; then a prompt asks an LLM to read the descriptions in each cluster and output a parent feature of the form 'feature name: feature description.' The parent features become the next level up, and the loop recurses until a stop criterion — here, at least four features at the top level — is reached. The identity that carries the argument is the multi-level feature tree itself, in which a node's semantic coverage is assumed to be exactly the union of its children's artifact clusters.

What would settle it

Take a random sample of nodes from the constructed tree, hide the LLM-generated feature names, and have independent Linux experts name the feature that best covers each node's artifact descriptions; if expert names rarely match the LLM names, or if a tree built from the same artifacts using expert-assigned clusters outscores the FTBUILDER tree on silhouette and GValue, the central claim that the automated tree captures expert-grade semantics would be refuted.

Watch

Extended reading notes

Core claim

The paper's claim is that a feature tree for a domain-specific artifact collection — a hierarchy where each parent node names a function shared by its children — need not be hand-crafted by experts. FTBUILDER builds it bottom-up: it scrapes package metadata from five Linux distributions, merges duplicate artifacts with an LLM, embeds each artifact's functional description, clusters the embeddings so each cluster is treated as sharing one feature, asks GPT-4 to write the feature name and description for the cluster, and repeats the cluster-and-summarize step level by level until a stopping rule is met. The paper reports that among 24 combinations of embedding, clustering, and cluster-count choices, the best is text-embedding-ada-002 with Gaussian mixture models and BIC cluster selection, and that the resulting three-level tree scores 9% higher on the silhouette coefficient and 11% higher on GValue than the official Linux feature tree, reduces developers' average artifact-selection time by 26%, and raises GPT-4o's recommendation accuracy from 20% to 67% (a 235% relative gain).

Load-bearing premise

The pipeline's validity rests on the assumption that artifacts grouped by embedding similarity genuinely share one feature and that an LLM's summary is the correct name for that shared feature; the paper never tests this correspondence against human judgment on the constructed nodes.

Editorial extensions

If this is right

  • Artifact libraries can be re-indexed automatically whenever the ecosystem changes, so the feature tree can stay current without a manual curation pass.
  • The winning configuration — text-embedding-ada-002, GMM with BIC, and GPT-4 summarization — gives teams a concrete starting recipe, although the paper expects the best choice to vary by domain.
  • A more compact tree (3 levels and fewer nodes than the official 5-level, 723-node tree) can communicate the same functional structure with less navigation overhead.
  • Grounding LLM recommendations in a functional hierarchy substantially improves accuracy, suggesting that retrieval context, not just model size, determines recommendation quality.

Reading between the lines

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

  • Because silhouette and GValue are computed on the same embeddings that define the clusters, those scores could be measuring internal consistency rather than whether the named features match what experts would call them; a direct human judgment study of node names would test this.
  • The recommendation-accuracy gain is measured on only 15 requirement-artifact pairs, so the 235% figure is likely to shrink on a larger benchmark even if the qualitative benefit persists.
  • The same cluster-and-summarize loop should transfer to other collections of short textual descriptions — API documentation, dataset catalogs, research artifact registries — where a hierarchical index is wanted but manual construction is too costly.
  • If the method scales to other ecosystems, feature trees could become versioned artifacts that evolve with each release, enabling requirements-driven selection across ecosystems rather than within a single distribution.
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

5 major / 6 minor

Summary. The paper proposes FTBUILDER, a framework for automatically constructing a multi-level feature tree for reusable software artifacts. The pipeline consists of three stages: crawling and merging artifact metadata from Linux distribution repositories into a structured library; embedding artifact descriptions and clustering them to identify groups with common features; and prompting GPT-4 to summarize each cluster into a feature name and description. The identification and summarization stages are applied recursively bottom-up. The authors implement 24 alternative configurations of embedding techniques, clustering algorithms, and cluster-number selection methods, and they evaluate the best configuration against the official Linux RPM feature tree using silhouette score and GValue. They report a 9% improvement in silhouette score, an 11% improvement in GValue, a 26% reduction in developer selection time (three participants), and a 235% improvement in LLM-based artifact recommendation accuracy on a 15-sample dataset.

Significance. If the claims were established, FTBUILDER would be a useful contribution: it is a concrete, end-to-end pipeline for an important software-engineering problem, and the authors provide an open-source replication package and 24 alternative solutions. The framework is clearly described and the recursive bottom-up construction is a sensible design. However, the evaluation as presented does not support the headline claims. The central weakness is that the same embedding-based metrics used to select the best configuration are then used to compare that configuration against the official tree, so the reported advantage is an in-sample, biased estimate. The downstream studies are also too small and lack statistical inference. The paper would need a substantially reworked evaluation, including external validation of the generated feature nodes and a held-out or independent comparison, before its central claims can be accepted.

major comments (5)
  1. [Section V, Table II and Table III (RQ1/RQ2)] The comparison is in-sample: the best of the 24 FTBUILDER configurations is selected by maximizing the silhouette coefficient and GValue (Table II), and the same two metrics are then used in Table III to claim superiority over the official tree. Moreover, both metrics are computed on text-embedding-ada-002 embeddings (Section IV-B), which is the same embedding space in which the GMM/BIC clustering is performed. The 9% and 11% improvements are therefore a biased estimate of true quality and could appear even if FTBUILDER has no semantic advantage. Please provide a held-out evaluation, cross-validation over the configuration selection, or an independent metric not used during model selection.
  2. [Section IV-D and Table III (RQ2)] The GValue metric is not defined in this paper; the text refers to the authors' own prior arXiv paper [8]. Since GValue is used both for configuration selection and for the headline comparison, its definition, properties, and independence from the embedding/clustering choices must be stated. In addition, the reported improvement percentages do not match the numbers: 0.067 versus 0.059 is a 13.6% relative increase, and 0.56 versus 0.50 is 12%, not 9% and 11%. The absolute silhouette scores are also near zero (0.067 max), indicating weak cluster structure; please clarify how this supports a claim of higher-quality semantic organization.
  3. [Section V, RQ3 (Table IV)] The time-reduction claim rests on three Ph.D. students and 15 requirement-artifact samples, with no statistical testing, confidence intervals, or discussion of task ordering or learning effects. The reported average times (5 vs. 3.67 minutes per sample) are based on very small samples, and the improvement percentages per participant (33%, 25%, 20%) have no inferential support. Please report effect sizes with uncertainty and consider a larger, more diverse participant pool.
  4. [Section V, RQ4 (Table V)] The 235% and 237% accuracy improvements are calculated on a 15-sample dataset (ARTSEL). With 15 samples, a change from 20% to 67% corresponds to roughly 3 versus 10 correct answers, and the confidence intervals around these proportions are extremely wide. The paper reports no statistical test or interval for the accuracy difference. Please report absolute counts, confidence intervals, and a significance test, and discuss the small-sample limitation explicitly.
  5. [Section III-C and III-D] The core assumption of the framework—that clustering artifacts by embedding similarity produces groups that genuinely share a common feature, and that the LLM can name that feature from the cluster texts—is never tested against human judgment. The generated 201 nodes are not evaluated for semantic coherence or for whether the LLM's feature names match what a domain expert would produce. Without such external validation, the claim that FTBUILDER produces 'semantic organization comparable to human experts' is unsupported. Please add a human evaluation of node quality, e.g., expert ratings of feature-name appropriateness and cluster coherence.
minor comments (6)
  1. [Abstract and Table III] Reconcile the reported improvement ratios: the table's silhouette and GValue values imply 13.6% and 12% relative improvements, not 9% and 11%.
  2. [Section IV-B] The statement that 24 solutions cover 4 embedding techniques, 3 clustering algorithms, and 3 cluster-number strategies is imprecise; the table omits k-means with BIC and hierarchical clustering with explicit cluster-number selection. Please state the compatibility constraints explicitly.
  3. [Section IV-D, Eq. (3)] The silhouette score formula uses distances between features, but the paper does not define how feature vectors or distances are computed in tree space. Specify the distance metric and how each feature node is represented.
  4. [Section III-B] The GPT-4-based artifact merging step is a load-bearing part of library construction, but its accuracy is not evaluated. If the LLM incorrectly merges or fails to merge artifacts, all downstream tree construction is affected; please report a validation of this step.
  5. [Section V, RQ3] The three participants are described as computer science Ph.D. students, not necessarily Linux domain experts; please clarify their relevant expertise and how they were recruited, and whether they were blind to the purpose of the study.
  6. [Section VI] The future-work section acknowledges the limited ecosystem coverage and small dataset; these limitations should also be stated in the evaluation section rather than deferred entirely to future plans.

Circularity Check

2 steps flagged · score 6.0 of 10

Headline 9%/11% quality gain is the in-sample selection objective, not an independent estimate; silhouette shares the embedding space that built the tree.

  1. fitted input called prediction [Abstract; Section V RQ1 (Table II) and RQ2 (Table III); Section IV-D]
    "We first simultaneously develop and evaluate 24 alternative solutions in the FTBUILDER. We then construct a three-level feature tree using the best solution among them. Compared to the official feature tree, our tree exhibits higher quality, with a 9% improvement in the silhouette coefficient and an 11% increase in GValue."

    Table II ranks the 24 configurations by silhouette score and GValue; the text states that the best solution is text-embedding-ada-002 with GMM and BIC, achieving SS 0.067 and GS 0.56. Table III then reports the same SS/GS metrics for that same winning configuration against the official tree and presents the 9%/11% gains as evidence. No held-out split separates configuration selection from evaluation, so the headline improvement is the very objective used to choose the configuration. The comparison is an in-sample selection result: the claimed advantage is optimistically biased by construction, matching the fitted-input-called-prediction pattern.

  2. other [Section III-C, Eq. (1)-(2); Section IV-D, Eq. (3)-(4); Section V RQ2]
    "FTBUILDER utilizes an embedding model (e.g., all-MiniLM) to convert artifacts’ functional descriptions into embedding vectors as semantic representations. The vectors are passed into a clustering algorithm (e.g., k-means) to identify a set of artifacts that contain common functional features. ... Silhouette Score (SS) measures the similarity of a feature to other features under the same parent and its distinction from features under different parents."

    The internal nodes of the constructed tree are obtained by clustering the artifact embedding vectors, and the silhouette score then measures, in that same embedding space, whether features under one parent are close to each other and far from features under other parents. The official comparison tree is derived from RPM group labels, not from this embedding geometry. Consequently, the reported SS advantage partly measures how well the tree conforms to the representation that generated it, rather than semantic quality validated independently of that representation. The comparison is therefore not apples-to-apples and is partially circular: the evaluation metric overlaps with the construction objective.

full rationale

The core generation pipeline (crawling, embedding, clustering, LLM summarization) is a real mechanism and is not defined in terms of the official tree or the reported metrics; if evaluated on held-out or human-judged quality, it could stand or fall on its own. However, the main quality evidence in the abstract and RQ2 is not self-contained. The same silhouette/GValue metrics are used to choose the best of 24 configurations (RQ1) and then to claim superiority over the official tree (RQ2), with no validation split, so the headline 9%/11% is an in-sample selection artifact. The silhouette component is computed on the same embedding vectors that drive GMM/BIC clustering, compounding the dependence. GValue's definition is deferred to the authors' prior paper [8], which adds a self-citation element but is not by itself a definitional circularity. RQ3/RQ4 rest on only 15 self-authored requirement-artifact pairs and three participants, which are correctness/statistical concerns rather than circular steps. Overall score 6: partial circularity in the quality evaluation, not full equivalence of derivation and input.

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

The central claims rest on the validity of automated metrics and the selected solution; these are in-sample and partly self-authored, so the paper contributes a pipeline plus an empirical configuration sweep rather than a parameter-free derivation.

free parameters (3)
  • best solution selection = text-embedding-ada-002 + GMM + BIC
    The 24 alternative solutions are evaluated on the same dataset and the one with the highest SS and GS is chosen; the reported improvements are for this selected model, in-sample.
  • cluster count k at each level = selected via BIC, elbow, or silhouette; exact values not reported
    The number of clusters determines the tree structure and is data-dependent, fitted per level.
  • recursive stopping threshold = highest-level feature count at least 4
    Stopping criterion borrowed from [47] and applied without validation for this domain.
assumptions (4)
  • domain assumption Embedding-space clusters correspond to shared functional features
    Section III-C assumes grouping artifacts by embedding similarity identifies common features, but no human validation of cluster coherence is provided beyond the SS metric itself.
  • domain assumption GValue and silhouette scores are valid and unbiased measures of feature tree quality
    Section IV-D uses these metrics for both solution selection and final comparison; GValue derives from the authors' prior work [8].
  • ad hoc to paper GPT-4 correctly merges duplicate artifacts during library construction
    Section III-B relies on GPT-4 judgments for artifact merging, but no evaluation of merge accuracy is reported.
  • domain assumption The official RPM feature tree is a fair baseline
    Section V RQ2 compares against the official tree; tree size and granularity differ (5 layers and 723 nodes vs 3 layers and 245 nodes), and metrics may favor the compact tree.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Automatic Multi-level Feature Tree Construction for Domain-Specific Reusable Artifacts Management." pith.science (2026). https://pith.science/paper/FRZVYVSN

@misc{pith2026250603946,
  author       = {Pith},
  title        = {Pith review of: Automatic Multi-level Feature Tree Construction for Domain-Specific Reusable Artifacts Management},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FRZVYVSN}},
  note         = {Machine review of arXiv:2506.03946}
}
read the original abstract

With the rapid growth of open-source ecosystems (e.g., Linux) and domain-specific software projects (e.g., aerospace), efficient management of reusable artifacts is becoming increasingly crucial for software reuse. The multi-level feature tree enables semantic management based on functionality and supports requirements-driven artifact selection. However, constructing such a tree heavily relies on domain expertise, which is time-consuming and labor-intensive. To address this issue, this paper proposes an automatic multi-level feature tree construction framework named FTBUILDER, which consists of three stages. It automatically crawls domain-specific software repositories and merges their metadata to construct a structured artifact library. It employs clustering algorithms to identify a set of artifacts with common features. It constructs a prompt and uses LLMs to summarize their common features. FTBUILDER recursively applies the identification and summarization stages to construct a multi-level feature tree from the bottom up. To validate FTBUILDER, we conduct experiments from multiple aspects (e.g., tree quality and time cost) using the Linux distribution ecosystem. Specifically, we first simultaneously develop and evaluate 24 alternative solutions in the FTBUILDER. We then construct a three-level feature tree using the best solution among them. Compared to the official feature tree, our tree exhibits higher quality, with a 9% improvement in the silhouette coefficient and an 11% increase in GValue. Furthermore, it can save developers more time in selecting artifacts by 26% and improve the accuracy of artifact recommendations with GPT-4 by 235%. FTBUILDER can be extended to other open-source software communities and domain-specific industrial enterprises.

Figures

Figures reproduced from arXiv: 2506.03946 by the authors.

Figure 1
Figure 1. An example of selecting reusable software artifacts by developers. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Overview of our FTBUILDER C = [C1, C2, ..., Ck]. Artifacts within the same cluster are considered to have a common feature. C = CA([h1, h2, ..., hn]) (2) This stage involves various design choices of the ET, CA, and the selection of the cluster number (CN). These choices can affect the quality of constructed feature trees and the best solution is closely related to the domain-specific data. Thus, we develop 24 solut… view at source ↗
Figure 3
Figure 3. A fragment of the constructed multi-level feature tree for Linux distributions. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. A Conceptual Framework for Requirements Engineering of Pretrained-Model-Enabled Systems

    cs.SE 2025-07 conditional novelty 4.0 of 10

    A conceptual framework reorganizes requirements engineering for pretrained-model-enabled systems into six activities, based on identified challenges of opaque capabilities, context sensitivity, and continuous evolution.

Reference graph

Works this paper leans on

47 extracted references · 44 canonical work pages · cited by 1 Pith paper

  1. [8]

    A First Look at Package-to-Group Mechanism: An Empirical Study of the Linux Distributions

    D. Jin, N. Li, K. Yang, M. Zhou, and Z. Jin, “A first look at package-to- group mechanism: An empirical study of the linux distributions,” arXiv preprint arXiv:2410.10131, 2024

    work page Pith review arXiv 2024

  2. [1]

    Software reuse research: Status and future,

    W. B. Frakes and K. Kang, “Software reuse research: Status and future,” IEEE transactions on Software Engineering, vol. 31, no. 7, pp. 529–536, 2005

    work page 2005

  3. [2]

    Effects of reuse on quality, productivity, and economics,

    W. C. Lim, “Effects of reuse on quality, productivity, and economics,” IEEE software, vol. 11, no. 5, pp. 23–30, 1994

    work page 1994

  4. [3]

    An empirical study of software reuse vs. defect-density and stability,

    P. Mohagheghi, R. Conradi, O. M. Killi, and H. Schwarz, “An empirical study of software reuse vs. defect-density and stability,” in Proceedings. 26th International Conference on Software Engineering , 2004, pp. 282– 291

    work page 2004

  5. [4]

    Quality, productivity and economic benefits of software reuse: a review of industrial studies,

    P. Mohagheghi and R. Conradi, “Quality, productivity and economic benefits of software reuse: a review of industrial studies,” Empirical Software Engineering, vol. 12, pp. 471–516, 2007

    work page 2007

  6. [5]

    A look at the dynamics of the javascript package ecosystem,

    E. Wittern, P. Suter, and S. Rajagopalan, “A look at the dynamics of the javascript package ecosystem,” in Proceedings of the 13th international conference on mining software repositories , 2016, pp. 351–361

    work page 2016

  7. [6]

    Node package manager for javascript,

    NPM, “Node package manager for javascript,” https://www.npmjs.com/, 2025

    work page 2025

  8. [7]

    A case study of open source software development: the apache server,

    A. Mockus, R. T. Fielding, and J. Herbsleb, “A case study of open source software development: the apache server,” in Proceedings of the 22nd international conference on Software engineering , 2000, pp. 263–272

    work page 2000

Show all 47 references
  1. [9]

    Feature extraction ap- proaches from natural language requirements for reuse in software product lines: A systematic literature review,

    N. H. Bakar, Z. M. Kasirun, and N. Salleh, “Feature extraction ap- proaches from natural language requirements for reuse in software product lines: A systematic literature review,” Journal of Systems and Software, vol. 106, pp. 132–149, 2015

    2015

  2. [10]

    Multi-level feature trees: A pragmatic approach to managing highly complex product families,

    M.-O. Reiser and M. Weber, “Multi-level feature trees: A pragmatic approach to managing highly complex product families,” Requirements Engineering, vol. 12, pp. 57–75, 2007

    2007

  3. [11]

    Supporting domain analysis through mining and recom- mending features from online product listings,

    N. Hariri, C. Castro-Herrera, M. Mirakhorli, J. Cleland-Huang, and B. Mobasher, “Supporting domain analysis through mining and recom- mending features from online product listings,” IEEE Transactions on Software Engineering, vol. 39, no. 12, pp. 1736–1752, 2013

    2013

  4. [12]

    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), 2014, pp. 153–162

    2014

  5. [13]

    Mining commonalities and variabilities from natural language documents,

    A. Ferrari, G. O. Spagnolo, and F. Dell’Orletta, “Mining commonalities and variabilities from natural language documents,” in Proceedings of the 17th International Software Product Line Conference, 2013, pp. 116– 120

    2013

  6. [14]

    A framework for constructing semantically composable feature models from natural language require- ments,

    N. Weston, R. Chitchyan, and A. Rashid, “A framework for constructing semantically composable feature models from natural language require- ments,” in Proceedings of the 13th International Software Product Line Conference, 2009, pp. 211–220

    2009

  7. [15]

    Feature model extraction from large collections of informal product descriptions,

    J.-M. Davril, E. Delfosse, N. Hariri, M. Acher, J. Cleland-Huang, and P. Heymans, “Feature model extraction from large collections of informal product descriptions,” in proceedings of the 2013 9th joint meeting on foundations of software engineering , 2013, pp. 290–300

    2013

  8. [16]

    Supporting commonality and variability analysis of requirements and structural models,

    K. Kumaki, R. Tsuchiya, H. Washizaki, and Y . Fukazawa, “Supporting commonality and variability analysis of requirements and structural models,” in Proceedings of the 16th International Software Product Line Conference-Volume 2, 2012, pp. 115–118

    2012

  9. [17]

    Mining and recommending software features across multiple web repositories,

    Y . Yu, H. Wang, G. Yin, and B. Liu, “Mining and recommending software features across multiple web repositories,” in Proceedings of the 5th Asia-Pacific Symposium on Internetware , 2013, pp. 1–9

    2013

  10. [18]

    On extracting feature models from product descriptions,

    M. Acher, A. Cleve, G. Perrouin, P. Heymans, C. Vanbeneden, P. Collet, and P. Lahire, “On extracting feature models from product descriptions,” in Proceedings of the 6th International Workshop on Variability Model- ing of Software-Intensive Systems , 2012, pp. 45–54

    2012

  11. [19]

    Large lan- guage models are zero-shot reasoners,

    T. Kojima, S. S. Gu, M. Reid, Y . Matsuo, and Y . Iwasawa, “Large lan- guage models are zero-shot reasoners,” Advances in neural information processing systems, vol. 35, pp. 22 199–22 213, 2022

    2022

  12. [20]

    Generating requirements elicitation interview scripts with large language models,

    B. Görer and F. B. Aydemir, “Generating requirements elicitation interview scripts with large language models,” inIEEE 31st International Requirements Engineering Conference Workshops , 2023, pp. 44–51

    2023

  13. [21]

    An evaluation of requirements modeling for cyber-physical systems via llms,

    D. Jin, S. Zhao, Z. Jin, X. Chen, C. Wang, Z. Fang, and H. Xiao, “An evaluation of requirements modeling for cyber-physical systems via llms,” arXiv preprint arXiv:2408.02450 , 2024

    2024 arXiv

  14. [22]

    On the assessment of generative ai in modeling tasks: an experience report with chatgpt and uml,

    J. Cámara, J. Troya, L. Burgueño, and A. Vallecillo, “On the assessment of generative ai in modeling tasks: an experience report with chatgpt and uml,” Software and Systems Modeling, vol. 22, no. 3, pp. 781–793, 2023

    2023

  15. [23]

    Leveraging llms for the quality assurance of software requirements,

    S. Lubos, A. Felfernig, T. N. T. Tran, D. Garber, M. El Mansi, S. P. Erdeniz, and V .-M. Le, “Leveraging llms for the quality assurance of software requirements,” in 32nd International Requirements Engineering Conference, 2024, pp. 389–397

    2024

  16. [24]

    Generating specifications from requirements documents for smart devices using large language models (llms),

    R. Lutze and K. Waldhör, “Generating specifications from requirements documents for smart devices using large language models (llms),” in International Conference on Human-Computer Interaction , 2024, pp. 94–108

    2024

  17. [25]

    Different approaches to the silhouette coefficient calcu- lation in cluster evaluation,

    H. ˇRezanková, “Different approaches to the silhouette coefficient calcu- lation in cluster evaluation,” in 21st international scientific conference AMSE applications of mathematics and statistics in economics , 2018, pp. 1–10

    2018

  18. [26]

    https://rpmfind.net/linux/rpm/groups.html,

    RPM, “https://rpmfind.net/linux/rpm/groups.html,” https://rpmfind.net/ linux/RPM/Groups.html, 2025

    2025

  19. [27]

    Our code and constructed trees,

    “Our code and constructed trees,” https://github.com/jdm4pku/ FTBuilder

  20. [28]

    Reusing software: Issues and research directions,

    H. Mili, F. Mili, and A. Mili, “Reusing software: Issues and research directions,” IEEE transactions on Software Engineering , vol. 21, no. 6, pp. 528–562, 1995

    1995

  21. [29]

    Importance of software component characterization for better software reusability,

    N. S. Gill, “Importance of software component characterization for better software reusability,”ACM SIGSOFT Software Engineering Notes, vol. 31, no. 1, pp. 1–3, 2006

    2006

  22. [30]

    Supporting search for reusable software objects,

    T. Isakowitz and R. J. Kauffman, “Supporting search for reusable software objects,” IEEE Transactions on Software engineering , vol. 22, no. 6, pp. 407–423, 1996

    1996

  23. [31]

    Evaluating software reuse alternatives: a model and its application to an industrial case study,

    A. Tomer, L. Goldin, T. Kuflik, E. Kimchi, and S. R. Schach, “Evaluating software reuse alternatives: a model and its application to an industrial case study,” IEEE Transactions on Software Engineering, vol. 30, no. 9, pp. 601–612, 2004

    2004

  24. [32]

    Strategies for software reuse: A principal component analysis of reuse practices,

    M. A. Rothenberger, K. J. Dooley, U. R. Kulkarni, and N. Nada, “Strategies for software reuse: A principal component analysis of reuse practices,” IEEE Transactions on Software Engineering , vol. 29, no. 9, pp. 825–837, 2003

    2003

  25. [33]

    An empirical study of software reuse with special attention to ada,

    N.-Y . Lee and C. R. Litecky, “An empirical study of software reuse with special attention to ada,” IEEE Transactions on Software Engineering , vol. 23, no. 9, pp. 537–549, 1997

    1997

  26. [34]

    Scenario-based analysis of software architecture,

    R. Kazman, G. Abowd, L. Bass, and P. Clements, “Scenario-based analysis of software architecture,” IEEE software , vol. 13, no. 6, pp. 47–55, 1996

    1996

  27. [35]

    Large language model for requirements engineering: A systematic literature review,

    J. A. Khan, S. Qayyum, and H. S. Dar, “Large language model for requirements engineering: A systematic literature review,” 2025

    2025

  28. [36]

    Combining prompts with examples to enhance llm-based requirement elicitation,

    S. Ren, H. Nakagawa, and T. Tsuchiya, “Combining prompts with examples to enhance llm-based requirement elicitation,” in 2024 IEEE 48th Annual Computers, Software, and Applications Conference , 2024, pp. 1376–1381

    2024

  29. [37]

    Mare: Multi-agents col- laboration framework for requirements engineering,

    D. Jin, Z. Jin, X. Chen, and C. Wang, “Mare: Multi-agents col- laboration framework for requirements engineering,” arXiv preprint arXiv:2405.03256, 2024

    2024 arXiv

  30. [38]

    Chatmodeler: a human-machine collaborative and iterative re- quirements elicitation and modeling approach via large language mod- els,

    ——, “Chatmodeler: a human-machine collaborative and iterative re- quirements elicitation and modeling approach via large language mod- els,” J Comput Res Develop , vol. 61, no. 02, pp. 338–350, 2024

    2024

  31. [39]

    Metapackage in linux distributions,

    “Metapackage in linux distributions,” https://help.ubuntu.com/ community/MetaPackages

  32. [40]

    Requests library: Http for humans,

    Requests, “Requests library: Http for humans,” https://requests. readthedocs.io/en/latest/, 2025

    2025

  33. [41]

    Using tf-idf to determine word relevance in document queries,

    J. Ramos et al., “Using tf-idf to determine word relevance in document queries,” in Proceedings of the first instructional conference on machine learning, vol. 242, no. 1, 2003, pp. 29–48

    2003

  34. [42]

    Making monolingual sentence embed- dings multilingual using knowledge distillation,

    N. Reimers and I. Gurevych, “Making monolingual sentence embed- dings multilingual using knowledge distillation,” in Proceedings of the 2020 Conference on Empirical Methods in Natural Language Process- ing, 11 2020

    2020

  35. [43]

    Text-embedding-ada-002,

    OpenAI, “Text-embedding-ada-002,” https://openai.com/index/ new-and-improved-embedding-model/, 2025

    2025

  36. [44]

    Algorithm as 136: A k-means clustering algorithm,

    J. A. Hartigan and M. A. Wong, “Algorithm as 136: A k-means clustering algorithm,” Journal of the royal statistical society. series c (applied statistics), vol. 28, no. 1, pp. 100–108, 1979

    1979

  37. [45]

    Gaussian mixture models

    D. A. Reynolds et al. , “Gaussian mixture models.” Encyclopedia of biometrics, vol. 741, no. 659-663, p. 3, 2009

    2009

  38. [46]

    Methods of hierarchical clustering,

    F. Murtagh and P. Contreras, “Methods of hierarchical clustering,” arXiv preprint arXiv:1105.0121, 2011

    2011 arXiv

  39. [47]

    A case study of an automatic package layering algorithm for linux distributions,

    J. Tan, L. Zhang, J. Meng, H. Xue, Z. Liu, Z. Ding, and Q. Jing, “A case study of an automatic package layering algorithm for linux distributions,” in Proceedings of the 2023 4th International Conference on Computing, Networks and Internet of Things , 2023, pp. 67–74

    2023

Pith tools

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