Requirements Engineering for Machine Learning: Perspectives from Data Scientists

Andreas Vogelsang; Markus Borg

REVIEW 3 major objections 4 minor 35 references

Requirements Engineering for Machine Learning: Perspectives from Data Scientists

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

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

Pith's one-line read The paper argues that building software by training models rather than writing code changes what requirements engineering must do, and it maps the needed changes from interviews with four data scientists.

desk verdict A transparent n=4 interview study that is worth reading as an exploratory research agenda, but the abstract's 'demands' wording outruns the evidence. read the letter →

arxiv 1908.04674 v1 pith:U7WSYY3Y submitted 2019-08-13 cs.LG cs.SE

Andreas Vogelsang , Markus Borg This is my paper · ORCID

classification cs.LGcs.SE

keywords machinelearningrequirementsengineeringdatascientistsinterviewstudyexplainabilityfreedomfromdiscriminationMLperformancemeasures

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 argues that building software by training models rather than writing code changes what requirements engineering must do. Based on four interviews with data scientists, it concludes that requirements engineers need to understand ML performance measures such as accuracy, precision, recall, and lift in order to state good functional requirements, and that they must handle new quality requirements such as explainability, freedom from discrimination, and legal constraints. It also claims that training data itself needs explicit requirements, and that verification and validation of ML systems continue during operation through monitoring and retraining. The contribution is an early map of how RE activities—elicitation, analysis, specification, and verification and validation—need to adjust for ML-based systems.

What carries the argument

The carrying mechanism is the Software 2.0 paradigm shift: instead of manually coding rules, developers generate behavior by fitting a model to training data with a fitness function. The paper uses this shift to explain why ML systems introduce requirements types that conventional RE lacks. The second mechanism is the standard RE activity framework—elicitation, analysis, specification, and verification and validation—used as the grid for organizing interview findings; this lets the authors turn scattered practitioner statements into concrete changes to each RE activity. Named techniques such as performance measures and data lineage carry the detailed argument.

What would settle it

A broad survey or interview series covering, say, fifty ML projects that finds most data scientists see conventional RE practices as sufficient, or that teams using only classical requirements methods deliver ML systems just as successfully, would directly contradict the paper's central claim. A less severe check: if data scientists in other domains do not recognize the new quality requirements (explainability, non-discrimination, data requirements) as part of their work, the proposed RE methodology loses its empirical basis.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that the shift from coding to training forces requirements engineering to change, not just adapt its notation. Functional requirements for ML systems become quantitative performance targets: the interviewees treat predictive power measured by accuracy, precision, recall, or lift as a functional requirement, and emphasize that customers often do not understand these measures. New quality requirements appear that are absent from standard quality models, including explainability (both of the model and of single predictions) and freedom from discrimination, meaning only societally and legally accepted logics of discrimination may be used. Training data becomes a first-class object of specification, covering data quantity (diversity rather than raw count), data quality (completeness, consistency, correctness), provenance, and legal constraints such as GDPR consent. Finally, the paper claims that verification and validation do not end at deployment: the requirements engineer should specify when retraining happens, how runtime data is monitored, and what counts as a data anomaly.

Load-bearing premise

The study's conclusions rest on the assumption that four interviewed data scientists' experiences and opinions represent the wider population of ML practitioners; if those four are atypical, the proposed changes to RE may not transfer.

Editorial extensions

If this is right

Requirements engineers will need enough statistical literacy to translate stakeholder goals into the right ML performance measure and to explain what precision, recall, or lift mean in a given domain.
Requirements specifications for ML systems will include new quality requirements—explainability, freedom from discrimination, and legal and regulatory constraints—alongside functional and data requirements.
Data requirements become a distinct class, specifying data quantity as diversity, data quality dimensions, collection conditions, and provenance.
Verification and validation extends into operations: monitoring runtime data, detecting anomalies, and scheduling retraining become requirements-level concerns.
Elicitation must bring data scientists and legal experts into requirements activities from the start, and identify protected characteristics before model training.

Reading between the lines

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

If the paper is right, RE training and hiring criteria should include data-science literacy; a testable extension would be comparing project outcomes between teams with and without ML-aware RE support.
The framework suggests a concrete checklist for ML requirements—single-number evaluation metric, protected attributes, explanation situations, data source list, retraining triggers—that could be validated on industrial ML projects.
The paper's distinction between trained and continuously learning systems implies that learning systems may also need requirements on the update mechanism itself, not just on model behavior.

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

Quick take: this is a small qualitative study worth knowing about, and it probably should be published as an exploratory contribution—but read the abstract as a proposal, not a finding.

What's new: the authors interviewed four data scientists about how they handle requirements-related activities for ML systems, and they synthesize three concrete implications for RE: understanding performance measures, new quality requirements (explainability, nondiscrimination, legal), and process integration. The individual items are not new—Horkoff and Ishikawa & Yoshioka already say similar things, and the authors cite them. The new bit is the empirical grounding: direct quotes from practitioners, a described coding process, an interview guide on figshare, and explicit threats to validity. That is genuine, if modest, evidence.

What it does well: it is honest. The authors say this is a first step, and they explicitly defer the requirements-engineer perspective to future work. They acknowledge the small sample in the validity section. No quantitative fitting, no hidden parameters, no invented entities. The coding procedure is collaborative and described in enough detail to follow. The citation pattern is also fine: the self-citations are on topic and not self-promotional.

Soft spots: the main one is the distance between what the interviews support and what the abstract claims. Four data scientists saying 'we struggle with metrics, explainability, and legal issues' supports a claim that these are relevant challenges. It does not establish that requirements engineers are 'demanded' to do three specific things. That prescriptive step is the authors' synthesis, and it is plausible—but it is a hypothesis, not a measurement. The stress-test note is right about this overreach; it is not fatal, but the paper should soften the wording in the abstract and conclusion. A second, lighter issue is that there is no saturation check and no independent auditor; for an exploratory study with n=4, that is more a limitation than a defect, and the authors mostly frame it that way.

Who it's for: researchers in requirements engineering and software engineering for ML who want a compact, citable baseline for the 'RE for ML is different' argument. Practitioners may find the table of RE activities useful as a checklist.

Verdict: this deserves a serious referee. I would accept it with minor revisions asking them to temper 'demands' to something like 'suggests that requirements engineers may need to' and to label the conclusions as research hypotheses. That does not diminish the paper; it makes it more accurate.

Recommendation: send it out. If I were the editor, I would treat it as a lightweight empirical/position paper and not hold it to a standard that a n=4 qualitative study cannot meet.

Referee Report

3 major / 4 minor

Summary. This paper reports an exploratory interview study with four data scientists, aiming to characterize what is unique about Requirements Engineering (RE) for machine learning (ML) systems. The authors describe their study design, present interview findings organized around quantitative targets, explainability, freedom from discrimination, legal requirements, and data requirements, and then map these onto RE activities (elicitation, analysis, specification, verification and validation). The paper concludes that ML development "demands" requirements engineers to understand ML performance measures, to be aware of new quality requirements, and to integrate ML specifics into the RE process. The paper positions this as a first step toward an RE methodology for ML systems and explicitly defers the perspective of requirements engineers themselves to future work.

Significance. If the conclusions are read as well-founded hypotheses, this is a useful early contribution to an important and rapidly growing area. The paper is transparent in its methodology: the interview guide is published, quotes are provided, and the authors discuss several threats to validity. It also offers a compact, actionable taxonomy of challenges (Table I) that can inform both practitioners and follow-up research. The strength of the contribution is, however, limited by the evidence base: four interviewees, no requirements engineers among them, no saturation check, and coding validated only by mutual cross-checking between the two authors. The prescriptive framing in the abstract and conclusions goes beyond what the data can establish. As exploratory qualitative research, the paper is credible; as an empirical demonstration that RE for ML must change in the claimed ways, it is not.

major comments (3)

[Abstract, Section I, and Section IV/V] The central conclusion—"development of ML systems demands requirements engineers to..."—is stated as an established finding, but the evidence consists of perceptions from four data scientists. The step from "data scientists report challenges with metrics, explainability, and legal constraints" to "requirements engineers must perform these three activities" is the authors' analytical synthesis, not an empirical result of the interviews. The authors themselves acknowledge in Section VI that the requirements-engineering perspective is future work. This mismatch between evidence and prescriptive wording is load-bearing because the abstract and introduction invite readers to treat these as validated demands. I recommend reframing the conclusions as hypotheses or propositions, e.g., "our analysis suggests that RE for ML will require...", and adding an explicit external-validity limitation to Section III-D.
[Section III-B and III-D] The subject selection and validation method limit the strength of any generalizable claim. Only four data scientists were interviewed (two in research, two in industry, with one domain each for the industry participants), and no requirements engineers were included. The authors do not report a saturation check or any formal inter-rater agreement measure; the validation consisted of each author reviewing the other's coding and meeting to synthesize themes. This is acceptable for an exploratory study, but it cannot support strong prescriptive claims. The threats-to-validity section discusses descriptive validity, interpretation validity, researcher bias, and reactivity, but does not address generalizability or transferability. Please add a discussion of how the findings might transfer to other settings and what would be needed to confirm the conclusions.
[Section IV-A and Table I] The paper equates quantitative ML performance targets with functional requirements, using "Quantitative Targets a.k.a. Functional Requirements" as a heading and quoting P3 as saying "I consider predictive power as functional requirement." In conventional RE terminology, predictive power is typically a quality or performance characteristic, not a functional requirement. This conflation could confuse the RE audience that the paper addresses. The later discussion in Section V-C correctly differentiates expected versus desired performance, which suggests the authors are aware of the distinction. Please either justify the terminology or replace it with language such as "functional requirements expressed quantitatively" and clarify how this relates to the RE literature.

minor comments (4)

[Section I] Grammar: "ML engineering constitute a paradigm shift" should be "ML engineering constitutes a paradigm shift."
[Abstract] The sentence "changes in the development paradigm... also demands changes in RE" has a subject-verb agreement error; it should be "also demand changes."
[Section III-C] "We then combined data from all transcripts in a meeting to ensure that we do cover the full data" mixes tenses; "ensure that we covered" would be clearer.
[Section IV-E] The claim "training data needs specified and validated requirements like code" is an interesting synthesis, but it is presented without direct interviewee support; the preceding P3 quote states the opposite for data requirements ("You could try, but it won't help"). Please clarify how the authors derive this normative conclusion from the data.

Circularity Check

0 steps flagged · score 0.0 of 10

No material circularity: the findings are grounded in external interview statements, and the few self-citations are background only.

full rationale

This paper makes no quantitative derivation or fitting, so the circularity patterns based on equations or fitted parameters do not apply. The central conclusions about what requirements engineers must do are synthesized from semi-structured interviews with four data scientists; the interviewees' statements are external evidence that does not reduce to the paper's own premises. The paper's own discussion of limitations, e.g., Section VI stating the authors plan to 'augment it with the view of requirements engineers,' is an acknowledged external-validity concern, not a circular step. The only self-citations (e.g., Winkler and Vogelsang 2016, 2019, and Borg et al. 2019) appear in related-work or reference contexts and are not load-bearing for the interview findings or the conclusions. The concern that n=4 may not support strong prescriptive claims is a legitimate critique of generalizability and evidence strength, but it is not circularity: the paper does not define its conclusions into existence, nor does it rely on self-citation to establish its claims. Accordingly, no specific circular step can be quoted, and the appropriate score is 0.

Assumptions & free parameters 0 free parameters · 2 assumptions · 0 invented entities

The study rests on interpretive qualitative research assumptions. There are no free parameters or invented entities; the main external inputs are the participants' self-reports and the researchers' coding judgments.

assumptions (2)

domain assumption The four interviewed data scientists are sufficiently representative of ML practitioners to support general conclusions about RE for ML.
The conclusions in Section VI generalize from n=4 interviews to an RE methodology for ML, but the sample mixes two researchers and two industry practitioners, with no explicit sampling strategy for representativeness.
domain assumption Semi-structured interviews and thematic coding are valid instruments to elicit and summarize practitioners' practices.
The paper uses interview guides and qualitative coding (Section III) without a formal validation of the instruments beyond a review of the interview guide.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Requirements Engineering for Machine Learning: Perspectives from Data Scientists." pith.science (2026). https://pith.science/paper/U7WSYY3Y

@misc{pith2026190804674,
  author       = {Pith},
  title        = {Pith review of: Requirements Engineering for Machine Learning: Perspectives from Data Scientists},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/U7WSYY3Y}},
  note         = {Machine review of arXiv:1908.04674}
}

read the original abstract

Machine learning (ML) is used increasingly in real-world applications. In this paper, we describe our ongoing endeavor to define characteristics and challenges unique to Requirements Engineering (RE) for ML-based systems. As a first step, we interviewed four data scientists to understand how ML experts approach elicitation, specification, and assurance of requirements and expectations. The results show that changes in the development paradigm, i.e., from coding to training, also demands changes in RE. We conclude that development of ML systems demands requirements engineers to: (1) understand ML performance measures to state good functional requirements, (2) be aware of new quality requirements such as explainability, freedom from discrimination, or specific legal requirements, and (3) integrate ML specifics in the RE process. Our study provides a first contribution towards an RE methodology for ML systems.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 35 canonical work pages

[1]

Software engineering for machine-learning applications: The road a head,

F. Khomh, B. Adams, J. Cheng, M. Fokaefs, and G. Antoniol, “Software engineering for machine-learning applications: The road a head,” IEEE Software, vol. 35, no. 5, 2018

work page 2018
[2]

How do engineers perceive d ifﬁculties in engineering of machine-learning systems? - Questionnai re survey,

F. Ishikawa and N. Y oshioka, “How do engineers perceive d ifﬁculties in engineering of machine-learning systems? - Questionnai re survey,” in Joint Intl. W orkshop on Conducting Empirical Studies in Ind ustry and Intl. W orkshop on Software Engineering Research and Ind ustrial Practice (CESSER-IP) , 2019

work page 2019
[3]

Machine learning to guide performance testing: An autonom ous test framework,

M. H. Moghadam, M. Saadatmand, M. Borg, M. Bohlin, and B. L isper, “Machine learning to guide performance testing: An autonom ous test framework,” in 3rd International W orkshop on Testing Extra-Functional Properties and Quality Characteristics of Software System s, 2019

work page 2019
[4]

Using reinforcemen t learning to handle the runtime uncertainties in self-adapt ive software,

T. Wu, Q. Li, L. Wang, L. He, and Y . Li, “Using reinforcemen t learning to handle the runtime uncertainties in self-adapt ive software,” in Federation of International Conferences on Software Techn ologies: Applications and F oundations. Springer, 2018

work page 2018
[5]

Safely enteri ng the deep: A review of veriﬁcation and validation for machine lea rning and a challenge elicitation in the automotive industry,

M. Borg, C. Englund, K. Wnuk, B. Duran, C. Levandowski, S. Gao, Y . Tan, H. Kaijser, H. Lönn, and J. Törnqvist, “Safely enteri ng the deep: A review of veriﬁcation and validation for machine lea rning and a challenge elicitation in the automotive industry,” Journal of Automotive Software Engineering, vol. 1, no. 1, 2019

work page 2019
[6]

A machine learning ap proach to software requirements prioritization,

A. Perini, A. Susi, and P . Avesani, “A machine learning ap proach to software requirements prioritization,” IEEE Transactions on Software Engineering, vol. 39, no. 4, 2013

work page 2013
[7]

An act ive learning approach for improving the accuracy of automated domain mod el extraction,

C. Arora, M. Sabetzadeh, S. Nejati, and L. Briand, “An act ive learning approach for improving the accuracy of automated domain mod el extraction,” ACM Trans. Softw. Eng. Methodol. , vol. 28, no. 1, 2019

work page 2019
[8]

Extractio n of system states from natural language requirements,

F. Pudlitz, F. Brokhausen, and A. V ogelsang, “Extractio n of system states from natural language requirements,” in 27th IEEE International Requirements Engineering Conference (RE) , 2019

work page 2019

Show all 35 references

[9]

Automatic classiﬁcation o f requirements based on convolutional neural networks,

J. Winkler and A. V ogelsang, “Automatic classiﬁcation o f requirements based on convolutional neural networks,” in 3rd International W orkshop on Artiﬁcial Intelligence for Requirements Engineering (A IRE), 2016

2016
[10]

On the automatic classiﬁcation of app reviews,

W. Maalej, Z. Kurtanovi ´c, H. Nabil, and C. Stanik, “On the automatic classiﬁcation of app reviews,” Requirements Engineering, vol. 21, no. 3, 2016

2016
[11]

Introduction to knowledge dis covery and data mining,

O. Maimon and L. Rokach, “Introduction to knowledge dis covery and data mining,” in Data Mining and Knowledge Discovery Handbook , O. Maimon and L. Rokach, Eds. Springer US, 2010

2010
[12]

The CRISP-DM model: the new blueprint for d ata mining,

C. Shearer, “The CRISP-DM model: the new blueprint for d ata mining,” Journal of Data W arehousing, vol. 5, no. 4, 2000

2000
[13]

Non-functional requirements for machine learning: Chal- lenges and new directions,

J. Horkoff, “Non-functional requirements for machine learning: Chal- lenges and new directions,” in IEEE International Requirements Engi- neering Conference (RE) , 2019

2019
[14]

A clas siﬁcation framework of uncertainty in architecture-based self-adap tive systems with multiple quality requirements,

S. Mahdavi-Hezavehi, P . Avgeriou, and D. Weyns, “A clas siﬁcation framework of uncertainty in architecture-based self-adap tive systems with multiple quality requirements,” in Managing Trade-Offs in Adapt- able Software Architectures . Elsevier, 2017, pp. 45–77

2017
[15]

Soft- ware engineering for self-adaptive systems. Lecture Notes in Computer Science, vol. 5525,

B. H. Cheng, R. de Lemos, H. Giese, P . Inverardi, and J. Ma gee, “Soft- ware engineering for self-adaptive systems. Lecture Notes in Computer Science, vol. 5525,” 2009

2009
[16]

The vision of autonomic co mputing,

J. O. Kephart and D. M. Chess, “The vision of autonomic co mputing,” Computer, no. 1, pp. 41–50, 2003

2003
[17]

Engineering requirements for adaptive systems,

M. Morandini, L. Penserini, A. Perini, and A. Marchetto , “Engineering requirements for adaptive systems,” Requirements Engineering, vol. 22, no. 1, 2017

2017
[18]

Business-driven data analytic s: A conceptual modeling framework,

S. Nalchigar and E. Y u, “Business-driven data analytic s: A conceptual modeling framework,” Data & Knowledge Engineering , vol. 117, 2018

2018
[19]

Requirements enginee ring for health data analytics: Challenges and possible directions,

L. Liu, L. Feng, Z. Cao, and J. Li, “Requirements enginee ring for health data analytics: Challenges and possible directions,” in 24th International Requirements Engineering Conference (RE) , 2016

2016
[20]

G. R. Gibbs, Analyzing qualitative data . SAGE Publications, Ltd, 2007

2007
[21]

J. A. Maxwell, Qualitative research design: An interactive approach . Sage publications, 2012, vol. 41

2012
[22]

An investiga tion of how quality requirements are speciﬁed in industrial practice,

R. B. Svensson, T. Olsson, and B. Regnell, “An investiga tion of how quality requirements are speciﬁed in industrial practice, ” Information and Software Technology , vol. 55, no. 7, 2013

2013
[23]

Ng, Machine Learning Yearning

A. Ng, Machine Learning Yearning . deeplearning.ai, 2017

2017
[24]

Why should I tr ust you?: Explaining the predictions of any classiﬁer,

M. T. Ribeiro, S. Singh, and C. Guestrin, “Why should I tr ust you?: Explaining the predictions of any classiﬁer,” in ACM SIGKDD Intl. Conference on Knowledge Discovery and Data Mining (KDD) , 2016

2016
[25]

What does my classiﬁer lea rn? A visual approach to understanding natural language text classiﬁer s,

J. Winkler and A. V ogelsang, “What does my classiﬁer lea rn? A visual approach to understanding natural language text classiﬁer s,” in Intl. Conference on Natural Language & Information Systems (NLDB ), 2017

2017
[26]

Systems and software engineering – Systems a nd software quality requirements and evaluation (SQuaRE) – System and s oftware quality models,

ISO/IEC, “Systems and software engineering – Systems a nd software quality requirements and evaluation (SQuaRE) – System and s oftware quality models,” ISO/IEC 25010, 2011

2011
[27]

Women also snowboard: Overcoming bias in captioning model s,

L. A. Hendricks, K. Burns, K. Saenko, T. Darrell, and A. R ohrbach, “Women also snowboard: Overcoming bias in captioning model s,” in Computer Vision – ECCV . Springer, 2018

2018
[28]

Barocas, M

S. Barocas, M. Hardt, and A. Narayanan, Fairness and Machine Learn- ing. fairmlbook.org, 2018, http://www.fairmlbook.org

2018
[29]

T he ML test score: A rubric for ML production readiness and technic al debt reduction,

E. Breck, S. Cai, E. Nielsen, M. Salib, and D. Sculley, “T he ML test score: A rubric for ML production readiness and technic al debt reduction,” in Proceedings of IEEE Big Data , 2017

2017
[30]

Systems and software engineering – Systems a nd software quality requirements and evaluation (SQuaRE) – Data qualit y model,

ISO/IEC, “Systems and software engineering – Systems a nd software quality requirements and evaluation (SQuaRE) – Data qualit y model,” ISO/IEC 25012, 2008

2008
[31]

Big data provenance: Challenges, state of the art and opportunities ,

J. Wang, D. Crawl, S. Purawat, M. Nguyen, and I. Altintas , “Big data provenance: Challenges, state of the art and opportunities ,” in IEEE International Conference on Big Data (Big Data) , 2015

2015
[32]

Evaluation of tools for hairy requirement s and software engineering tasks,

D. M. Berry, “Evaluation of tools for hairy requirement s and software engineering tasks,” in 25th IEEE International Requirements Engineer- ing Conference W orkshops (REW) , 2017

2017
[33]

Optimizing for recall in automatic requirements classiﬁcation: An empirical study ,

J. Winkler, J. Grönberg, and A. V ogelsang, “Optimizing for recall in automatic requirements classiﬁcation: An empirical study ,” in IEEE International Requirements Engineering Conference (RE) , 2019

2019
[34]

Big data, fast data an d data lake concepts,

N. Miloslavskaya and A. Tolstoy, “Big data, fast data an d data lake concepts,” Procedia Computer Science , vol. 88, 2016

2016
[35]

Ten ways to fool the m asses with machine learning,

F. Minhas, A. Asif, and A. Ben-Hur, “Ten ways to fool the m asses with machine learning,” ArXiv, vol. abs/1901.01686, 2019

1901 arXiv

Pith tools

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

[1] [1]

Software engineering for machine-learning applications: The road a head,

F. Khomh, B. Adams, J. Cheng, M. Fokaefs, and G. Antoniol, “Software engineering for machine-learning applications: The road a head,” IEEE Software, vol. 35, no. 5, 2018

work page 2018

[2] [2]

How do engineers perceive d ifﬁculties in engineering of machine-learning systems? - Questionnai re survey,

F. Ishikawa and N. Y oshioka, “How do engineers perceive d ifﬁculties in engineering of machine-learning systems? - Questionnai re survey,” in Joint Intl. W orkshop on Conducting Empirical Studies in Ind ustry and Intl. W orkshop on Software Engineering Research and Ind ustrial Practice (CESSER-IP) , 2019

work page 2019

[3] [3]

Machine learning to guide performance testing: An autonom ous test framework,

M. H. Moghadam, M. Saadatmand, M. Borg, M. Bohlin, and B. L isper, “Machine learning to guide performance testing: An autonom ous test framework,” in 3rd International W orkshop on Testing Extra-Functional Properties and Quality Characteristics of Software System s, 2019

work page 2019

[4] [4]

Using reinforcemen t learning to handle the runtime uncertainties in self-adapt ive software,

T. Wu, Q. Li, L. Wang, L. He, and Y . Li, “Using reinforcemen t learning to handle the runtime uncertainties in self-adapt ive software,” in Federation of International Conferences on Software Techn ologies: Applications and F oundations. Springer, 2018

work page 2018

[5] [5]

Safely enteri ng the deep: A review of veriﬁcation and validation for machine lea rning and a challenge elicitation in the automotive industry,

M. Borg, C. Englund, K. Wnuk, B. Duran, C. Levandowski, S. Gao, Y . Tan, H. Kaijser, H. Lönn, and J. Törnqvist, “Safely enteri ng the deep: A review of veriﬁcation and validation for machine lea rning and a challenge elicitation in the automotive industry,” Journal of Automotive Software Engineering, vol. 1, no. 1, 2019

work page 2019

[6] [6]

A machine learning ap proach to software requirements prioritization,

A. Perini, A. Susi, and P . Avesani, “A machine learning ap proach to software requirements prioritization,” IEEE Transactions on Software Engineering, vol. 39, no. 4, 2013

work page 2013

[7] [7]

An act ive learning approach for improving the accuracy of automated domain mod el extraction,

C. Arora, M. Sabetzadeh, S. Nejati, and L. Briand, “An act ive learning approach for improving the accuracy of automated domain mod el extraction,” ACM Trans. Softw. Eng. Methodol. , vol. 28, no. 1, 2019

work page 2019

[8] [8]

Extractio n of system states from natural language requirements,

F. Pudlitz, F. Brokhausen, and A. V ogelsang, “Extractio n of system states from natural language requirements,” in 27th IEEE International Requirements Engineering Conference (RE) , 2019

work page 2019