Synthline: A Product Line Approach for Synthetic Requirements Engineering Data Generation using Large Language Models

Abdelkarim El-Hajjami; Camille Salinesi

REVIEW 3 major objections 5 minor 31 references

Synthline: A Product Line Approach for Synthetic Requirements Engineering Data Generation using Large Language Models

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read The paper claims that a feature-model-configured LLM pipeline can generate synthetic requirements data that, when mixed with real data, raises defect-classification precision by 85 percent and doubles recall.

desk verdict Useful first iteration: feature-model-controlled synthetic data for RE defect classification, with an honest but underpowered evaluation that needs a contamination audit before its headline 85% precision gain is taken at face value. read the letter →

arxiv 2505.03265 v1 pith:PGY6CXS3 submitted 2025-05-06 cs.SE cs.AI

Abdelkarim El-Hajjami , Camille Salinesi This is my paper · ORCID

classification cs.SEcs.AI

keywords requirementsengineeringsyntheticdatalargelanguagemodelsproductlinefeaturemodelspecificationdefectsscarcityclassification

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

Synthline is a product-line method for generating synthetic requirements-engineering data: a feature model controls the LLM prompt, and each valid configuration is turned into a prompt that asks the model for a requirement with chosen label, type, domain, source, format, and level. The paper argues that this gives systematic control over data properties while producing data that, although less diverse than real requirements, is good enough to train classifiers. Its central evidence is the defect-classification experiment: training a BERT classifier on real requirements alone gives macro precision 0.310 and recall 0.256, while adding GPT-4o-generated data raises precision to 0.575 and recall to 0.512. If this holds, the method gives practitioners a way to escape the data-scarcity bottleneck in requirements engineering without collecting or sharing more private project data.

What carries the argument

The carrying mechanism is a feature model plus a configurable generation workflow. The feature model enumerates four core dimensions: Generator (which LLM, temperature, TopP), Artifact (requirement type, specification level, source, format, domain, language), MLTask (classification label and label description), and Output (format and subset size). A configuration is expanded into atomic configurations, and a Promptline module renders each one into a standardized prompt. The prompt template is the link between a desired data property and a generated sample, and the feature model is what makes that link systematic and inspectable.

What would settle it

Re-run the best hybrid configuration on a larger held-out set of several hundred real requirements that are checked for near-duplicate overlap with every synthetic training text; if the 85 percent precision gain and recall doubling shrink into the noise, the headline result was an artifact of test-set scale or model memorization rather than genuine data complementarity.

Watch

Extended reading notes

Core claim

The central discovery is that synthetic and real requirements data are complementary: a classifier trained on the hybrid of real plus GPT-4o synthetic data outperforms one trained on real data alone by 85 percent in macro precision (0.575 vs 0.310) and by 2x in recall (0.512 vs 0.256). Synthetic-only training also beats the real-data baseline on both metrics, although the gains are smaller. The same experiment shows that more synthetic data is not automatically better: mixing GPT-4o and DeepSeek-V3 data together degraded performance below either source alone, and adding DeepSeek data to the best hybrid also hurt it. The authors read this as evidence that source curation matters more than volume, and that a product-line configuration is a workable way to produce curated, task-aligned synthetic requirements at scale.

Load-bearing premise

The load-bearing premise is that a roughly forty-requirement holdout slice of the 131-sample real corpus is large enough, and free enough of overlap with what GPT-4o and DeepSeek-V3 have already seen, to yield stable and uncontaminated precision and recall estimates.

Editorial extensions

If this is right

For classification use cases in requirements engineering, hybrid training can substantially beat real-only training when the real dataset is small and imbalanced.
Synthetic data alone is a viable fallback when no real training data can be shared.
The choice of synthetic data source should be treated as a design decision, since blending two LLM sources can reduce performance below the better single source.
The feature-model configuration makes each generated dataset's provenance explicit, so dataset variants can be regenerated, audited, and adapted to new domains without changing the pipeline.

Reading between the lines

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

The authors do not isolate why GPT-4o data helped more than DeepSeek data; a direct extension would compare per-class generation quality and identify which defect classes drive the 2x recall gain.
Their diversity results suggest a testable remedy: relaxing the constrained-NL specification format or varying temperature and TopP might close the 6x lexical-density gap, and would give a direct check on whether diversity is what limits synthetic-only performance.
Since the real corpus is small and single-domain, the same pipeline could be pointed at a larger, independently collected set of defects to see whether the hybrid gain persists outside healthcare and restaurant management.
The negative synergy from mixing synthetic sources hints that dataset curation should be modeled as a selection problem, perhaps by scoring candidate synthetic subsets on a small real validation set before training.

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

Synthline is a sensible first iteration of a product-line approach to generating synthetic requirements data with LLMs. The paper's real contribution is the feature-model-based configurator that turns FM configurations into prompts; that is new for RE and genuinely useful. The empirical side is transparently reported: they release code and data, use a held-out human-labeled test set, and compare several training compositions with fixed hyperparameters. The central directional finding—mixing synthetic and real data beats real-only training—holds across all three hybrid conditions, so it is not a single lucky run. The diversity analysis is also honest: synthetic data is measurably less diverse than real data, yet still helpful.

Soft spots are real but proportionate. The headline magnitude (85% precision gain) rests on a test set of roughly 39-40 requirements. The best configuration's standard deviation is 0.575 ± 0.229, which means the 85% gain is not statistically distinguished from a much smaller effect. No significance test is reported. The second concern, raised both by the stress-test note and by the paper's own Section 6, is potential test-set leakage: the public Zenodo holdout predates the LLMs, and the synthetic data were generated using prompts that deliberately match that dataset's domain and format. Without an overlap/deduplication audit against the test set, the magnitude is uncertain. This is not a fatal flaw—the paper explicitly acknowledges the small test set—but it means the main result should be treated as promising evidence, not an established effect.

The citation pattern looks fine: they build on attributed prompting, synthetic data surveys, and the Fazelnia dataset, and they don't overclaim novelty. The feature model itself is minimal, but as part of a design science cycle that is acceptable.

Who is this for? Researchers in RE who need synthetic training data for classification and want a configurable generation workflow. Practitioners building defect classifiers might also find the hybrid training recipe useful, with caution about the effect size. It deserves a serious referee: the idea is on-topic, the artifacts are public, and the limitations are clearly stated, so a competent reviewer could push for a contamination audit and significance testing without much effort. My own verdict would be: useful first iteration, conditional acceptance if the authors add an overlap analysis and either pair the 39-sample test with a bootstrap interval or lower the claims.

Referee Report

3 major / 5 minor

Summary. The paper proposes Synthline, a product-line-based workflow that uses LLMs (GPT-4o and DeepSeek-V3) guided by a feature model to generate synthetic requirements text labeled with specification-defect categories. The evaluation has two parts: a diversity analysis (vocabulary size, semantic similarity, n-gram repetition) and a utility analysis in which BERT-base is fine-tuned on synthetic-only, real-only, and hybrid training sets and tested on a fixed 30% holdout of the 131-sample Fazelnia et al. dataset. The headline result is that training on Real+GPT-4o data raises macro precision from 0.310 to 0.575 (an 85% relative improvement) and recall from 0.256 to 0.512, and the paper concludes that hybrid synthetic/real training is a promising answer to data scarcity in requirements engineering.

Significance. If the central performance claim holds, the paper makes a useful contribution: it provides a configurable, feature-model-driven method for generating synthetic RE data, it evaluates that data with transparent diversity metrics, and it releases code and datasets for reproducibility. The finding that synthetic data is less diverse than real data but can still be a viable training resource, and that hybrid training can outperform real-only training, is a valuable empirical data point for the RE community. However, the strength of the headline claim is not yet established because of the small holdout set, the lack of statistical testing, and the absence of a contamination audit between the synthetic training data and the public test set. These are load-bearing concerns for the paper's main conclusion.

major comments (3)

[§4 (Utility Evaluation) and §5.2 (Table 8)] The test set is a fixed 30% holdout of the 131-sample real dataset, i.e., roughly 39 requirements, and no significance test or confidence interval is reported. The headline comparison, 0.575 ± 0.229 versus 0.310 ± 0.050, has a standard deviation on the hybrid condition that is comparable to the entire claimed improvement, and the paper's own Section 6 concedes that the small test set threatens conclusion validity. Because the abstract and conclusion state the improvement as 'substantial' and 'up to 85%', the claim needs per-class results, bootstrap confidence intervals, or a significance test across the multiple training runs before it can be accepted at this strength.
[§3.2 (Data Generation, Table 3) and §4 (Utility Evaluation)] The synthetic generation deliberately aligns with the real dataset along several dimensions: Healthcare domain, Constrained NL format, English language, and the exact defect classes and label definitions from Fazelnia et al. The test set is a public Zenodo dataset that predates the training data of GPT-4o and DeepSeek-V3, yet the paper reports no overlap audit or deduplication between the synthetic training data and the held-out test set beyond removing exact duplicates within the synthetic data. If even a few of the ~39 test items have near-duplicates among the 6,720 GPT-4o-generated samples, the precision gain could reflect memorization or leakage rather than the product-line generation approach. An overlap analysis using n-gram or embedding similarity, followed by a rerun of the experiments after removing near-duplicates, is necessary to support the central claim.
[§5.2 (Table 8) and §4 (Utility Evaluation)] The experimental comparison confounds data composition with training-set size. The real-only baseline is trained on roughly 92 examples, while the synthetic-only and hybrid configurations use thousands of examples (up to 6,720 per LLM before deduplication). The observed improvements could therefore be driven by the larger number of training examples rather than by the quality or source of the synthetic data. A size-controlled experiment, such as subsampling the synthetic data to match the real training-set size or otherwise balancing the number of training examples, is needed to attribute the gains to the synthetic data itself.

minor comments (5)

[§4 (Utility Evaluation)] The number of training runs and the random seeds used to produce the means and standard deviations in Table 8 are not specified; please report them so that the results are reproducible.
[§4 (Diversity Evaluation)] The deduplication criterion is not defined: it is unclear whether exact string matching, normalization, or near-duplicate removal was used to obtain the counts in Table 4.
[§3.1 (Feature Model)] The text refers to 'the Appendix 7' when describing the feature model, but the appendix appears after the references; please fix the cross-reference and numbering.
[§3.2 (Data Generation)] Table 3 lists seven requirement types while the text in Section 3.1 describes the RequirementType subfeature with six categories; please reconcile the count and the feature model.
[§1 (Contributions)] The manuscript states that both the implementation and generated datasets are publicly available, but the footnote points to a v0.0.0 release; please ensure the link is stable and that the datasets are included at that location.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Synthline's central results are measured on a held-out real dataset, not derived from fitted inputs or self-citation chains.

full rationale

Synthline is an empirical study, not a derivation. The headline claims (Section 5.2, Table 8: precision 0.575 vs 0.310; recall 0.512 vs 0.256) are observed macro-averaged scores on a fixed 30% holdout of the public Zenodo requirements-defect dataset ([25], Section 4), so the reported gains are measurements, not quantities fitted to the test set. Synthetic data are generated from the FM configuration plus the defect-category definitions of [25]; reusing those definitions as label descriptions aligns the training distribution with the target task and is a design choice, not a circular reduction. Hyperparameters were fixed from [30] and no validation-set selection was used. The only self-citation ([15]) supports background motivation about data imbalance and is not load-bearing. The one dangling citation in Section 3.1 ('structured prompt pattern from [34]') is a reference-integrity defect, but it does not make the argument circular. No equation reduces to an input by construction, no 'prediction' is a renamed fit, and no uniqueness theorem is imported from the authors' prior work.

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

The central claims rest on the assumptions that the real dataset is trustworthy, that LLM-generated samples are valid instances of the target classes, and that the fixed evaluation setup gives a fair comparison. No new entities are introduced. The free parameters are configuration choices from prior work or author choices; none is fitted to the test results.

free parameters (8)

Temperature = 1.0
Chosen following prior synthetic data work [19,29], not tuned. Controls randomness in LLM generation and therefore diversity.
TopP = 1.0
Same justification as Temperature; nucleus sampling parameter held at maximum.
SubsetSize = 1120 per defect class per LLM
Chosen by the authors without a stated power analysis; determines the volume and class balance of synthetic data, which directly affects training.
Learning rate = 5e-5
Fixed hyperparameter from [30] for BERT fine-tuning, used identically across all conditions.
Batch size = 32
Fixed hyperparameter; held constant across all experiments.
Training epochs = 6
Fixed hyperparameter; held constant across all experiments.
Weight decay = 1e-4
Fixed hyperparameter; held constant across all experiments.
Warmup ratio = 6%
Fixed hyperparameter; held constant across all experiments.

assumptions (5)

domain assumption The Fazelnia et al. [25] dataset is a valid, accurately labeled ground truth for requirements specification defects.
The real dataset is both the reference for synthetic data alignment and the testbed for evaluation; if labels are wrong, all downstream comparisons are compromised.
domain assumption LLMs prompted with defect category definitions produce synthetic requirements that are representative of real defective requirements for classifier training.
The training-on-synthetic test-on-real paradigm assumes distributional relevance; no human validation of the synthetic labels is reported.
domain assumption BERT-base-uncased with fixed hyperparameters is an adequate probe for comparing data utility across training sets.
The authors chose a single backbone and hyperparameters from the literature; other models might rank the data sources differently.
domain assumption The proposed diversity metrics (absolute/normalized vocabulary, APS, INGF) capture the aspects of diversity that matter for downstream model performance.
The authors themselves note in Section 6 that these metrics may not fully capture the nuanced characteristics of diverse text.
domain assumption The feature model derived from the ML4RE SLR [10] adequately scopes the variability of classification-based RE use cases.
The FM is claimed to be built reactively from the literature; only one use case (defect identification) is instantiated, so generalizability is untested.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Synthline: A Product Line Approach for Synthetic Requirements Engineering Data Generation using Large Language Models." pith.science (2026). https://pith.science/paper/PGY6CXS3

@misc{pith2026250503265,
  author       = {Pith},
  title        = {Pith review of: Synthline: A Product Line Approach for Synthetic Requirements Engineering Data Generation using Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PGY6CXS3}},
  note         = {Machine review of arXiv:2505.03265}
}

read the original abstract

While modern Requirements Engineering (RE) heavily relies on natural language processing and Machine Learning (ML) techniques, their effectiveness is limited by the scarcity of high-quality datasets. This paper introduces Synthline, a Product Line (PL) approach that leverages Large Language Models to systematically generate synthetic RE data for classification-based use cases. Through an empirical evaluation conducted in the context of using ML for the identification of requirements specification defects, we investigated both the diversity of the generated data and its utility for training downstream models. Our analysis reveals that while synthetic datasets exhibit less diversity than real data, they are good enough to serve as viable training resources. Moreover, our evaluation shows that combining synthetic and real data leads to substantial performance improvements. Specifically, hybrid approaches achieve up to 85% improvement in precision and a 2x increase in recall compared to models trained exclusively on real data. These findings demonstrate the potential of PL-based synthetic data generation to address data scarcity in RE. We make both our implementation and generated datasets publicly available to support reproducibility and advancement in the field.

Figures

Figures reproduced from arXiv: 2505.03265 by the authors.

**Figure 1.** High-level architecture of Synthline. The workflow begins with the PL Configurator, which implements our FM as a graphical interface for feature selection. The interface directly mirrors the hierarchical structure of our FM, organizing controls into four distinct sections corresponding to our core features. For feature selections that require choosing from predefined options, such as OutputFormat between CSV and J… view at source ↗

**Figure 2.** Distribution of cosine similarity of text pairs sampled from the same class. While synthetic datasets offer broader absolute vocabulary coverage, they show lower diversity than real data across all measured dimensions - exhibiting 6× lower lexical density, higher semantic similarity (0.612-0.649 vs 0.544), and increased phrase repetition (2-4× higher INGF values). 5.2 RQ2: How does training on synthetic data affect … view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 20 canonical work pages

[1]

The state-of-practice in require- ments specification: an extended interview study at 12 companies

X. Franch, C. Palomares, C. Quer, P. Chatzipetrou, and T. Gorschek, "The state-of-practice in require- ments specification: an extended interview study at 12 companies", *Requirements Engineering*, pp. 1–33, 2023. doi: 10.1007/s00766-023-00399-7

doi:10.1007/s00766-023-00399-7 2023
[2]

DeepSeek-V3 Technical Report

DeepSeek-AI, "DeepSeek-V3 Technical Report", arXiv:2412.19437 [cs.CL], 2024

arXiv 2024
[3]

Design science as nested problem solving

R. Wieringa, "Design science as nested problem solving", in *Proc. 2009 ACM Int. Conf.*, New York, NY, USA, 2009. doi: 10.1145/1555619.1555630

work page arXiv 2009
[4]

Data Augmentation for Conflict and Duplicate Detection in Software Engineering Sentence Pairs

G. Malik, M. Cevik, and A. Başar, "Data Augmentation for Conflict and Duplicate Detection in Soft- ware Engineering Sentence Pairs", arXiv:2305.09608 [cs.SE], 2023

work page Pith review arXiv 2023
[5]

Multi-type requirements traceability prediction by code data augmentation and fine-tuning MS-CodeBERT

A. Majidzadeh, M. Ashtiani, and M. Zakeri-Nasrabadi, "Multi-type requirements traceability prediction by code data augmentation and fine-tuning MS-CodeBERT", *Computer Standards & Interfaces*, vol. 90, Article 103850, 2024. doi: 10.1016/j.csi.2024.103850

arXiv 2024
[6]

EfficientExtractionofTechnicalRequirementsApplying Data Augmentation

I.Gräßler,D.Preuß,L.Brandt,andM.Mohr,"EfficientExtractionofTechnicalRequirementsApplying Data Augmentation", in *Proc. 2022 IEEE International Symposium on Systems Engineering (ISSE)*, Vienna, Austria, 2022, pp. 1–8. doi: 10.1109/ISSE54508.2022.10005452

arXiv 2022
[7]

Language Models are Few-Shot Learners

T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert-Voss, G. Krueger, T. Henighan, R. Child, A. Ramesh, and D. M. Ziegler, "Language Models are Few-Shot Learners", arXiv:2005.14165 [cs.CL], 2020. 14 A. El-Hajjami and C. Salinesi

arXiv 2005
[8]

Few-shot fine-tuning vs. in-context learning: A fair comparison and evaluation

M. Mosbach, T. Pimentel, S. Ravfogel, D. Klakow, and Y. Elazar, "Few-shot fine-tuning vs. in-context learning: A fair comparison and evaluation", in *Findings of the Association for Computational Linguis- tics: ACL 2023*, Toronto, Canada, pp. 12284–12314, 2023. Association for Computational Linguistics

work page 2023

Show all 31 references

[9]

Natural Language Processing for Requirements Engineering: A Systematic Mapping Study

L. Zhao, W. Alhoshan, A. Ferrari, K. J. Letsholo, M. A. Ajagbe, E.-V. Chioasca, and R. T. Batista- Navarro, "Natural Language Processing for Requirements Engineering: A Systematic Mapping Study", *ACM Computing Surveys*, vol. 54, no. 3, Article 55, pp. 1–41, Apr. 2022

2022
[10]

Machine learning for requirements engineering (ML4RE): A systematic literature review complemented by practitioners’ voices from Stack Overflow

T. Li, X. Zhang, Y. Wang, Q. Zhou, Y. Wang, and F. Dong, "Machine learning for requirements engineering (ML4RE): A systematic literature review complemented by practitioners’ voices from Stack Overflow", *Information and Software Technology*, vol. 172, Article 107477, 2024

2024
[11]

Synthetic Data Generation with Large Language Models for Text Classification: Potential and Limitations

Z. Li, H. Zhu, Z. Lu, and M. Yin, "Synthetic Data Generation with Large Language Models for Text Classification: Potential and Limitations", in *Proc. 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP)*, 2023

2023
[12]

ChatGPT outperforms crowd workers for text-annotation tasks

F. Gilardi, M. Alizadeh, and M. Kubli, "ChatGPT outperforms crowd workers for text-annotation tasks", in *Proc. National Academy of Sciences*, vol. 120, no. 30, Article e2305016120, 2023

2023
[13]

ZeroGen: Efficient Zero-shot Learning via Dataset Generation

J. Ye, J. Gao, Q. Li, H. Xu, J. Feng, Z. Wu, T. Yu, and L. Kong, "ZeroGen: Efficient Zero-shot Learning via Dataset Generation", arXiv:2202.07922 [cs.CL], 2022

2022 arXiv
[14]

On LLMs-Driven Synthetic Data Generation, Curation, and Evaluation: A Survey

L. Long, R. Wang, R. Xiao, J. Zhao, X. Ding, G. Chen, and H. Wang, "On LLMs-Driven Synthetic Data Generation, Curation, and Evaluation: A Survey", arXiv:2406.15126 [cs.CL], 2024

2024 arXiv
[15]

Which AI Technique Is Better to Classify Requirements? An Experiment with SVM, LSTM, and ChatGPT

A. El-Hajjami, N. Fafin, and C. Salinesi, "Which AI Technique Is Better to Classify Requirements? An Experiment with SVM, LSTM, and ChatGPT", arXiv:2311.11547 [cs.AI], 2024

2024 arXiv
[16]

PATE-GAN: Generating Synthetic Data with Differential Privacy Guarantees

J. Yoon, J. Jordon, and M. van der Schaar, "PATE-GAN: Generating Synthetic Data with Differential Privacy Guarantees", in *Proc. International Conference on Learning Representations (ICLR)*, 2019

2019
[17]

Repli- cation in Requirements Engineering: the NLP for RE Case

S. Abualhaija, F. B. Aydemir, F. Dalpiaz, D. Dell’Anna, A. Ferrari, X. Franch, and D. Fucci, "Repli- cation in Requirements Engineering: the NLP for RE Case", arXiv:2304.10265 [cs.SE], 2024

2024 arXiv
[18]

Synthetic Prompting: Generating Chain-of-Thought Demonstrations for Large Language Models

Z. Shao, Y. Gong, Y. Shen, M. Huang, N. Duan, and W. Chen, "Synthetic Prompting: Generating Chain-of-Thought Demonstrations for Large Language Models", arXiv:2302.00618 [cs.CL], 2023

2023 arXiv
[19]

Large Language Model as Attributed Training Data Generator: A Tale of Diversity and Bias

Y. Yu, Y. Zhuang, J. Zhang, Y. Meng, A. Ratner, R. Krishna, J. Shen, and C. Zhang, "Large Language Model as Attributed Training Data Generator: A Tale of Diversity and Bias", in *Proc. Thirty-seventh Conference on Neural Information Processing Systems (NeurIPS) Datasets and Be...

2023
[20]

BERT: Pre-training of Deep Bidirectional Trans- formers for Language Understanding

J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, "BERT: Pre-training of Deep Bidirectional Trans- formers for Language Understanding", in *Proc. 2019 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume...

2019 doi
[21]

K. Pohl, G. Böckle, and F. Van Der Linden, *Software Product Line Engineering: Foundations, Prin- ciples, and Techniques*, vol. 1, Berlin, Germany: Springer, 2005

2005
[22]

S. Apel, D. Batory, C. Kästner, and G. Saake, *Feature-Oriented Software Product Lines: Concepts and Implementation*, Springer, Berlin, Heidelberg, 2013

2013
[23]

Software product lines essentials

L. Northrop, "Software product lines essentials", *Pittsburgh: SEI Carnegie Mellon University*, 2008

2008
[24]

Preventing Requirement Defects: An Experiment in Process Improvement

S. Lauesen and O. Vinter, “Preventing Requirement Defects: An Experiment in Process Improvement”, in Requirements Engineering Journal, vol. 6, no. 1, pp. 37-50, 2001

2001
[25]

Lessons from the Use of Natural Language Inference (NLI) in Requirements Engineering Tasks

M. Fazelnia, V. Koscinski, S. Herzog, and M. Mirakhorli, “Lessons from the Use of Natural Language Inference (NLI) in Requirements Engineering Tasks”, in Proc. 32nd IEEE International Requirements Engineering Conference (RE), 2024

2024
[26]

SDP-BB: A Software Defect Prediction Model Using BiLSTM and BERT-Based Se- mantic Features

S. Goyal et al., “SDP-BB: A Software Defect Prediction Model Using BiLSTM and BERT-Based Se- mantic Features”, in IEEE Transactions on Software Engineering, 2022

2022
[27]

Automated Quality Defect Detection in Software Development Documents

A. Dautovic, R. Plösch, and M. Saft, “Automated Quality Defect Detection in Software Development Documents”, in Proc. 5th International Conference on Software Quality Management, 2011

2011
[28]

Ambiguity in Requirements Specification

D. M. Berry and E. Kamsties, “Ambiguity in Requirements Specification”, in Requirements Engineering: State of the Practice, M. Leite and J. Doorn, Eds., Boston, MA: Springer US, 2004, pp. 7-44. Synthline 15

2004
[29]

Instruction Tuning with GPT-4

B. Peng, C. Li, P. He, M. Galley, and J. Gao, "Instruction Tuning with GPT-4", arXiv:2304.03277 [cs.CL], 2023

2023 arXiv
[30]

True Few-Shot Learning with Language Models

E. Perez, D. Kiela, and K. Cho, "True Few-Shot Learning with Language Models", in *Proc. Advances in Neural Information Processing Systems*, A. Beygelzimer, Y. Dauphin, P. Liang, and J. Wortman Vaughan, Eds., 2021

2021
[31]

Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks

N. Reimers and I. Gurevych, "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks", in *Proc. 2019 Conference on Empirical Methods in Natural Language Processing and the 9th Interna- tional Joint Conference on Natural Language Processing (EMNLP-IJCNLP)*, K. Inui, J. ...

2019 doi

Pith tools

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

[1] [1]

The state-of-practice in require- ments specification: an extended interview study at 12 companies

X. Franch, C. Palomares, C. Quer, P. Chatzipetrou, and T. Gorschek, "The state-of-practice in require- ments specification: an extended interview study at 12 companies", *Requirements Engineering*, pp. 1–33, 2023. doi: 10.1007/s00766-023-00399-7

doi:10.1007/s00766-023-00399-7 2023

[2] [2]

DeepSeek-V3 Technical Report

DeepSeek-AI, "DeepSeek-V3 Technical Report", arXiv:2412.19437 [cs.CL], 2024

arXiv 2024

[3] [3]

Design science as nested problem solving

R. Wieringa, "Design science as nested problem solving", in *Proc. 2009 ACM Int. Conf.*, New York, NY, USA, 2009. doi: 10.1145/1555619.1555630

work page arXiv 2009

[4] [4]

Data Augmentation for Conflict and Duplicate Detection in Software Engineering Sentence Pairs

G. Malik, M. Cevik, and A. Başar, "Data Augmentation for Conflict and Duplicate Detection in Soft- ware Engineering Sentence Pairs", arXiv:2305.09608 [cs.SE], 2023

work page Pith review arXiv 2023

[5] [5]

Multi-type requirements traceability prediction by code data augmentation and fine-tuning MS-CodeBERT

A. Majidzadeh, M. Ashtiani, and M. Zakeri-Nasrabadi, "Multi-type requirements traceability prediction by code data augmentation and fine-tuning MS-CodeBERT", *Computer Standards & Interfaces*, vol. 90, Article 103850, 2024. doi: 10.1016/j.csi.2024.103850

arXiv 2024

[6] [6]

EfficientExtractionofTechnicalRequirementsApplying Data Augmentation

I.Gräßler,D.Preuß,L.Brandt,andM.Mohr,"EfficientExtractionofTechnicalRequirementsApplying Data Augmentation", in *Proc. 2022 IEEE International Symposium on Systems Engineering (ISSE)*, Vienna, Austria, 2022, pp. 1–8. doi: 10.1109/ISSE54508.2022.10005452

arXiv 2022

[7] [7]

Language Models are Few-Shot Learners

T. B. Brown, B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, S. Agarwal, A. Herbert-Voss, G. Krueger, T. Henighan, R. Child, A. Ramesh, and D. M. Ziegler, "Language Models are Few-Shot Learners", arXiv:2005.14165 [cs.CL], 2020. 14 A. El-Hajjami and C. Salinesi

arXiv 2005

[8] [8]

Few-shot fine-tuning vs. in-context learning: A fair comparison and evaluation

M. Mosbach, T. Pimentel, S. Ravfogel, D. Klakow, and Y. Elazar, "Few-shot fine-tuning vs. in-context learning: A fair comparison and evaluation", in *Findings of the Association for Computational Linguis- tics: ACL 2023*, Toronto, Canada, pp. 12284–12314, 2023. Association for Computational Linguistics

work page 2023