pith. sign in

arxiv: 2604.18770 · v1 · submitted 2026-04-20 · 💻 cs.SE

From Business Problems to AI Solutions: Where Does Transformation Support Fail

Pith reviewed 2026-05-10 03:58 UTC · model grok-4.3

classification 💻 cs.SE
keywords Analytics Translation ProblemRequirements EngineeringMachine Learning Project ManagementBusiness to AI TranslationLiterature ReviewAI Methodology
0
0 comments X

The pith

Existing approaches for translating business problems into AI solutions offer almost no systematic guidance on deriving the machine learning task specification.

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

The paper reviews 18 approaches drawn from requirements engineering, machine learning project management, and automation to evaluate how they support the step from business problems to machine learning solutions. It organizes the approaches into four families and compares them against six input artifact types, six output artifact types, and a seven-stage transformation framework. The study finds that most approaches expect an ML task or algorithm specification as an output yet only four supply partial guidance for producing it and none supplies systematic guidance. This shortfall is named the Analytics Translation Problem. The authors close by listing five research directions to close the identified gap.

Core claim

The paper establishes that translating business problems into well-specified machine learning solutions remains one of the least supported steps in existing methodologies. After mapping 18 approaches onto a seven-stage framework, it shows that while ML task or algorithm specification appears among the expected outputs in most cases, only four approaches give partial help in deriving it and none gives systematic help; the authors therefore define this missing support as the Analytics Translation Problem (ATP).

What carries the argument

The Analytics Translation Problem (ATP): the absence of systematic guidance for deriving machine learning task or algorithm specifications from business problems inside current transformation approaches.

If this is right

  • Support for multi-formulation exploration is needed so practitioners can consider alternative framings of the same business problem.
  • Explicit task-derivation guidance must be developed to convert business requirements into concrete machine-learning tasks.
  • Constraint-algorithm filtering techniques should be added to narrow candidate algorithms once constraints are known.
  • Probabilistic traceability mechanisms are required to maintain links between business elements and downstream ML decisions.
  • Data-triggered revision processes should allow the translation to be updated automatically when new data arrives.

Where Pith is reading between the lines

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

  • AI project failures may stem more often from incomplete problem translation than from later technical shortcomings.
  • Tool builders could apply natural-language processing to business documents to produce candidate ML formulations automatically.
  • The identified gap indicates that current AI methodologies remain stronger on implementation and deployment than on initial problem definition.
  • Extending the survey to cover more recent or industry-specific approaches could reveal whether the gap is shrinking over time.

Load-bearing premise

The 18 chosen approaches represent the full range of existing transformation support and the seven-stage framework captures every necessary step in moving from business problems to AI solutions.

What would settle it

Discovery of even one additional approach outside the reviewed set that supplies complete systematic guidance for deriving an ML task specification from business requirements would show the gap is not as general as claimed.

Figures

Figures reproduced from arXiv: 2604.18770 by Abir Trabelsi, Darine Ameyed, Hafedh Mili, Imen Benzarti.

Figure 1
Figure 1. Figure 1: The Analytics Translation Problem: the S2–S3 formulation gap. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
read the original abstract

Translating business problems into well-specified machine learning solutions is a prerequisite for successful AI systems, yet this upstream translation is still one of the least supported steps in existing methodologies. We conduct a structured narrative literature review of 18 approaches spanning requirements engineering (RE), machine learning (ML) project management, and automation. We organize these approaches into a taxonomy of four families and compare them across six input artifact categories, six output artifact categories, and a transformation framework of seven stages, grounded in RE refinement theory and ML lifecycle process. Our study shows that most approaches list ML task or algorithm specification among their expected outputs, yet only four provide partial guidance for deriving it, and none provides systematic guidance. We characterize this gap as the Analytics Translation Problem (ATP) and derive five research recommendations addressing multi-formulation exploration, task derivation guidance, constraint-algorithm filtering, probabilistic traceability, and data-triggered revision.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper conducts a structured narrative literature review of 18 approaches drawn from requirements engineering (RE), ML project management, and automation. It organizes them into a four-family taxonomy and compares them against six input artifact categories, six output artifact categories, and a seven-stage transformation framework derived from RE refinement theory and the ML lifecycle. The central finding is that while most approaches list ML task or algorithm specification as an expected output, only four supply partial derivation guidance and none offers systematic guidance; the authors term this gap the Analytics Translation Problem (ATP) and propose five research recommendations on multi-formulation exploration, task derivation, constraint filtering, probabilistic traceability, and data-triggered revision.

Significance. If the representativeness and framework-completeness premises hold, the work usefully isolates an upstream translation step that is widely acknowledged as difficult yet poorly supported in existing methodologies. The taxonomy and cross-artifact comparison supply a reusable lens for future RE-for-ML research, and the five recommendations are concrete enough to seed targeted follow-on studies. The paper also earns credit for grounding its framework in established RE and ML process literature rather than ad-hoc invention.

major comments (3)
  1. [Methodology / Selection of approaches] Methodology section (likely §3): No search protocol, databases, keywords, time bounds, or inclusion/exclusion criteria are stated for the selection of the 18 approaches. Because the headline claim ('none provides systematic guidance') is an exhaustive negative over the sampled literature, the absence of a reproducible selection method leaves the ATP gap vulnerable to selection bias; influential methods that do supply derivation steps could have been omitted.
  2. [Transformation framework] Seven-stage framework (likely §4): The framework is asserted to be 'grounded in RE refinement theory and ML lifecycle process,' yet the paper supplies neither an explicit stage-by-stage mapping to those source theories nor an argument that the seven stages are jointly necessary and sufficient for business-to-ML translation. If a stage that naturally hosts task-derivation guidance (e.g., data-requirements elicitation or iterative formulation) is missing, the 'none systematic' conclusion does not follow from the comparison.
  3. [Comparison results] Results / Artifact comparison (likely §5 and associated table): The four approaches said to give 'partial guidance' are not described with concrete mechanisms or excerpts. Without this detail, readers cannot independently judge why the guidance is only partial and why it fails to qualify as systematic, weakening the load-bearing distinction drawn between 'list as output' and 'provide derivation support.'
minor comments (2)
  1. [Taxonomy] The taxonomy diagram would benefit from one-sentence characterizations or canonical examples for each of the four families to aid quick comprehension.
  2. [Related work / Framework] A small number of citations to foundational RE refinement papers (e.g., on goal-oriented requirements) appear to be missing or under-cited in the framework grounding paragraph.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We appreciate the referee's detailed and constructive feedback on our manuscript. We address each of the major comments below and outline the revisions we plan to make to strengthen the paper.

read point-by-point responses
  1. Referee: Methodology section (likely §3): No search protocol, databases, keywords, time bounds, or inclusion/exclusion criteria are stated for the selection of the 18 approaches. Because the headline claim ('none provides systematic guidance') is an exhaustive negative over the sampled literature, the absence of a reproducible selection method leaves the ATP gap vulnerable to selection bias; influential methods that do supply derivation steps could have been omitted.

    Authors: We acknowledge that a more explicit description of our selection process would enhance the reproducibility of the review. Although the paper is framed as a structured narrative literature review rather than a systematic one, we selected the 18 approaches based on their prominence in RE, ML project management, and automation literature, drawing from key surveys and standards in the field. To address this concern, we will add a dedicated subsection in §3 detailing the sources consulted, keywords used in our literature search, and the criteria for inclusion. This will clarify the scope and mitigate potential selection bias concerns. We maintain that the selected set is representative of the main families of approaches, but agree that transparency is important. revision: yes

  2. Referee: Seven-stage framework (likely §4): The framework is asserted to be 'grounded in RE refinement theory and ML lifecycle process,' yet the paper supplies neither an explicit stage-by-stage mapping to those source theories nor an argument that the seven stages are jointly necessary and sufficient for business-to-ML translation. If a stage that naturally hosts task-derivation guidance (e.g., data-requirements elicitation or iterative formulation) is missing, the 'none systematic' conclusion does not follow from the comparison.

    Authors: The seven-stage framework is derived from established RE refinement processes (such as goal-oriented requirements engineering) and the standard ML lifecycle stages (problem definition, data collection, modeling, etc.). While we reference these foundations, we agree that an explicit mapping table or section would strengthen the grounding. We will include in the revised manuscript a table mapping each of the seven stages to specific elements from RE theory (e.g., problem decomposition, artifact refinement) and ML process models (e.g., CRISP-DM or similar). Additionally, we will provide a brief argument for why these stages are necessary and sufficient for capturing the translation process, addressing potential missing stages like iterative formulation by noting that they are subsumed under the 'formulation exploration' and 'revision' stages. This will ensure the comparison's validity is clear. revision: yes

  3. Referee: Results / Artifact comparison (likely §5 and associated table): The four approaches said to give 'partial guidance' are not described with concrete mechanisms or excerpts. Without this detail, readers cannot independently judge why the guidance is only partial and why it fails to qualify as systematic, weakening the load-bearing distinction drawn between 'list as output' and 'provide derivation support.'

    Authors: We recognize the value of providing concrete examples to illustrate the distinction. In the original manuscript, the table in §5 summarizes the comparison, but we did not include detailed excerpts for the four approaches. To improve this, we will expand the results section with a new subsection or appendix that describes the partial guidance mechanisms in each of the four approaches, including specific excerpts or descriptions of how they support derivation (e.g., templates, heuristics, or partial processes). This will allow readers to assess why they are partial rather than systematic, reinforcing our characterization of the ATP. revision: yes

Circularity Check

0 steps flagged

No significant circularity; claims rest on external literature review

full rationale

The paper performs a structured narrative review of 18 external approaches from RE and ML literature, organizes them into a taxonomy, and compares them against six input/output artifact categories plus a seven-stage transformation framework explicitly grounded in established RE refinement theory and ML lifecycle processes. The central claim (only four approaches provide partial guidance for deriving ML task/algorithm specification, none systematic) follows directly from that external analysis rather than any self-referential derivation, fitted parameter, or self-citation chain. No equations, ansatzes, or uniqueness theorems are invoked that reduce to the paper's own inputs. The representativeness assumption and framework completeness are methodological premises, not circular reductions. This is a standard, self-contained literature synthesis against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim depends on the assumption that the chosen literature sample and the custom seven-stage framework are sufficient to expose a genuine systematic gap across the field.

axioms (1)
  • domain assumption RE refinement theory and ML lifecycle process provide a valid seven-stage transformation framework for comparing approaches
    Invoked to structure the comparison of input/output artifacts and stages across the 18 approaches.
invented entities (1)
  • Analytics Translation Problem (ATP) no independent evidence
    purpose: To name and highlight the identified lack of systematic guidance for deriving ML task specifications
    Introduced as a label for the gap observed in the review; no independent falsifiable evidence provided beyond the review itself.

pith-pipeline@v0.9.0 · 5458 in / 1338 out tokens · 48957 ms · 2026-05-10T03:58:06.427353+00:00 · methodology

discussion (0)

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

Reference graph

Works this paper leans on

57 extracted references · 57 canonical work pages

  1. [1]

    The root causes of failure for artificial intelligence projects and how they can succeed: Avoiding the anti-patterns of AI,

    J. Ryseff, B. F. De Bruhl, and S. J. Newberry, “The root causes of failure for artificial intelligence projects and how they can succeed: Avoiding the anti-patterns of AI,” RAND Corporation, Tech. Rep. RR-A2680-1, 2024. [Online]. Available: https://www.rand.org/pubs/ research reports/RRA2680-1.html

  2. [2]

    Solving business problems: the business-driven data-supported pro- cess,

    M. Rodgers, S. Mukherjee, B. Melamed, A. Baveja, and A. Kapoor, “Solving business problems: the business-driven data-supported pro- cess,”Annals of Operations Research, vol. 332, pp. 705–741, 2024

  3. [3]

    Requirement engineering challenges for AI-intense systems development,

    H.-M. Heyn, E. Knauss, A. P. Muhammad, O. Eriksson, J. Linder, P. Subbiah, S. K. Pradhan, and S. Tungal, “Requirement engineering challenges for AI-intense systems development,”arXiv preprint, 2021. [Online]. Available: https://arxiv.org/abs/2103.10270

  4. [4]

    Towards modelling and reasoning support for early- phase requirements engineering,

    E. S. K. Yu, “Towards modelling and reasoning support for early- phase requirements engineering,” inProceedings of ISRE ’97: 3rd IEEE International Symposium on Requirements Engineering, Annapolis, MD, USA, 1997, pp. 226–235

  5. [5]

    Interactive goal model analysis for early re- quirements engineering,

    J. Horkoff and E. Yu, “Interactive goal model analysis for early re- quirements engineering,”Requirements Engineering, vol. 21, pp. 29–61, 2016

  6. [6]

    Goal-oriented requirements engineering: An overview of the current research,

    A. Lapouchnian, “Goal-oriented requirements engineering: An overview of the current research,” Department of Computer Science, University of Toronto, Toronto, ON, Canada, Tech. Rep., 2005, accessed: Jul. 15, 2025. [Online]. Available: https://www.cs.utoronto.ca/ ∼alexei/pub/ Lapouchnian-Depth.pdf

  7. [7]

    Requirements engineering in machine learning projects,

    A. Gjorgjevikj, K. Mishev, L. Antovski, and D. Trajanov, “Requirements engineering in machine learning projects,”IEEE Access, vol. 11, pp. 72 186–72 208, 2023

  8. [8]

    Requirements engineering for artificial intelligence systems: A systematic mapping study,

    K. Ahmad, M. Abdelrazek, C. Arora, M. Bano, and J. Grundy, “Requirements engineering for artificial intelligence systems: A systematic mapping study,”arXiv preprint, 2022. [Online]. Available: https://arxiv.org/abs/2212.10693

  9. [9]

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

    J. Horkoff, “Non-functional requirements for machine learning: Chal- lenges and new directions,” in2019 IEEE 27th International Require- ments Engineering Conference (RE), 2019, pp. 386–391

  10. [10]

    A survey of data mining and knowledge discovery process models and methodologies,

    G. Mariscal, ´O. Marb ´an, and C. Fern ´andez, “A survey of data mining and knowledge discovery process models and methodologies,”The Knowledge Engineering Review, vol. 25, no. 2, pp. 137–166, 2010

  11. [11]

    A survey of knowledge discovery and data mining process models,

    L. A. Kurgan and P. Musilek, “A survey of knowledge discovery and data mining process models,”The Knowledge Engineering Review, vol. 21, no. 1, pp. 1–24, 2006

  12. [12]

    Machine learning operations (MLOps): Overview, definition, and architecture,

    D. Kreuzberger, N. K ¨uhl, and S. Hirschl, “Machine learning operations (MLOps): Overview, definition, and architecture,”IEEE Access, vol. 11, pp. 31 866–31 879, 2023

  13. [13]

    Modeling machine learning requirements from three perspectives: a case report from the healthcare domain,

    S. Nalchigar, E. Yu, and K. Keshavjee, “Modeling machine learning requirements from three perspectives: a case report from the healthcare domain,”Requirements Engineering, vol. 26, pp. 237–254, 2021

  14. [14]

    Requirements elicitation and modelling of artificial intelligence systems: An empirical study,

    K. Ahmad, M. Abdelrazek, C. Arora, J. Grundy, and M. Bano, “Requirements elicitation and modelling of artificial intelligence systems: An empirical study,”arXiv preprint, 2023. [Online]. Available: https://arxiv.org/abs/2302.06034

  15. [15]

    SmartML: A meta learning-based framework for automated selection and hyperparameter tuning for machine learning algorithms,

    M. Maher and S. Sakr, “SmartML: A meta learning-based framework for automated selection and hyperparameter tuning for machine learning algorithms,” inProceedings of the 22nd International Conference on Extending Database Technology (EDBT). OpenProceedings.org, 2019. 1https://doi.org/10.5281/zenodo.18779531

  16. [16]

    Toronto, ON, Canada: International Institute of Business Analysis, 2015

    International Institute of Business Analysis,A Guide to the Business Analysis Body of Knowledge (BABOK ® Guide), Version 3. Toronto, ON, Canada: International Institute of Business Analysis, 2015

  17. [17]

    Strategic business modeling: representation and reasoning,

    J. Horkoff, D. Barone, L. Jiang, E. Yu, D. Amyot, A. Borgida, and J. My- lopoulos, “Strategic business modeling: representation and reasoning,” Software and Systems Modeling, vol. 13, pp. 1015–1041, 2014

  18. [18]

    Enterprise modeling for business intelligence,

    D. Barone, E. Yu, J. Won, L. Jiang, and J. Mylopoulos, “Enterprise modeling for business intelligence,” inThe Practice of Enterprise Modeling, ser. Lecture Notes in Business Information Processing, P. van Bommel, S. Hoppenbrouwers, S. Overbeek, E. Proper, and J. Barjis, Eds., vol. 68. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, pp. 31–45. [Onlin...

  19. [19]

    Matching problems to solutions: An explainable way of solving machine learning problems,

    L. Saleh, H. Mili, M. Boukadoum, and A. Leshob, “Matching problems to solutions: An explainable way of solving machine learning problems,” arXiv preprint arXiv:2406.15662, 2024

  20. [20]

    The Big Three: A methodology to increase data science ROI by answering the questions companies care about,

    D. K. Griffin, “The Big Three: A methodology to increase data science ROI by answering the questions companies care about,”arXiv preprint,

  21. [21]

    Available: https://arxiv.org/abs/2002.07069

    [Online]. Available: https://arxiv.org/abs/2002.07069

  22. [22]

    Writing narrative literature reviews for peer-reviewed journals: Secrets of the trade,

    B. N. Green, C. D. Johnson, and A. Adams, “Writing narrative literature reviews for peer-reviewed journals: Secrets of the trade,”Journal of Chiropractic Medicine, vol. 5, no. 3, pp. 101–117, 2006

  23. [23]

    Guidelines for performing system- atic literature reviews in software engineering,

    B. Kitchenham and S. Charters, “Guidelines for performing system- atic literature reviews in software engineering,” Keele University and Durham University, Tech. Rep. EBSE-2007-01, 2007

  24. [24]

    A conceptual modeling framework for business analytics,

    S. Nalchigar, E. Yu, and R. Ramani, “A conceptual modeling framework for business analytics,” inConceptual Modeling, ser. Lecture Notes in Computer Science, I. Comyn-Wattiau, K. Tanaka, I.-Y . Song, S. Ya- mamoto, and M. Saeki, Eds., vol. 9974. Cham: Springer International Publishing, 2016, pp. 35–49

  25. [25]

    Conceptual modeling for business analytics: A framework and potential benefits,

    S. Nalchigar and E. Yu, “Conceptual modeling for business analytics: A framework and potential benefits,” in2017 IEEE 19th Conference on Business Informatics (CBI), vol. 01, 2017, pp. 369–378

  26. [26]

    Business-driven data analytics: A conceptual modeling framework,

    ——, “Business-driven data analytics: A conceptual modeling framework,”Data & Knowledge Engineering, vol. 117, pp. 359– 372, 2018. [Online]. Available: https://www.sciencedirect.com/science/ article/pii/S0169023X18301691

  27. [27]

    Designing business analytics solutions: A model-driven ap- proach,

    ——, “Designing business analytics solutions: A model-driven ap- proach,”Business & Information Systems Engineering, vol. 62, pp. 61– 75, 2020

  28. [28]

    Solution patterns for machine learning,

    S. Nalchigar, E. Yu, Y . Obeidi, S. Carbajales, J. Green, and A. Chan, “Solution patterns for machine learning,” inAdvanced Information Systems Engineering. Cham: Springer International Publishing, 2019, pp. 627–642

  29. [29]

    A catalogue of concerns for specifying machine learning-enabled systems,

    H. Villamizar, M. Kalinowski, and H. Lopes, “A catalogue of concerns for specifying machine learning-enabled systems,”arXiv preprint, 2022. [Online]. Available: https://arxiv.org/abs/2204.07662

  30. [30]

    A framework for requirements specification of machine-learning systems,

    X. Wang and W. Miao, “A framework for requirements specification of machine-learning systems,” inProceedings, 2022, pp. 7–12, [Accessed: Jul. 24, 2025]. [Online]. Available: https://doi.org/10.18293/ seke2022-143

  31. [31]

    RM4ML: Requirements model for machine learning-enabled software systems,

    Y . Yang, B. Zeng, and J. Gao, “RM4ML: Requirements model for machine learning-enabled software systems,”Requirements Engineering, 2025, [Accessed: Aug. 21, 2025]. [Online]. Available: https://link. springer.com/article/10.1007/s00766-024-00431-4

  32. [32]

    Towards artefact-based requirements engineering for data-centric systems,

    T. Chuprina, D. Mendez, and K. Wnuk, “Towards artefact-based requirements engineering for data-centric systems,”arXiv preprint,

  33. [33]

    Available: https://arxiv.org/abs/2103.05233

    [Online]. Available: https://arxiv.org/abs/2103.05233

  34. [34]

    Toward requirements specification for machine-learned components,

    M. Rahimi, J. L. Guo, S. Kokaly, and M. Chechik, “Toward requirements specification for machine-learned components,” in2019 IEEE 27th International Requirements Engineering Conference Workshops (REW), 2019, pp. 241–244

  35. [35]

    A multi-layered collaborative framework for evidence-driven data requirements engineering for machine learning- based safety-critical systems,

    S. Dey and S.-W. Lee, “A multi-layered collaborative framework for evidence-driven data requirements engineering for machine learning- based safety-critical systems,” inProceedings of the 38th ACM/SIGAPP Symposium on Applied Computing, ser. SAC ’23. New York, NY , USA: Association for Computing Machinery, 2023, pp. 1404—-1413. [Online]. Available: https:/...

  36. [36]

    CRISP-DM twenty years later: From data mining processes to data science trajectories,

    F. Mart ´ınez-Plumed, L. Contreras-Ochando, C. Ferri, J. Hern ´andez- Orallo, M. Kull, N. Lachiche, M. J. Ram ´ırez-Quintana, and P. Flach, “CRISP-DM twenty years later: From data mining processes to data science trajectories,”IEEE Transactions on Knowledge and Data Engi- neering, vol. 33, no. 8, pp. 3048–3061, 2021

  37. [37]

    AI lifecycle models need to be revised,

    M. Haakman, L. Cruz, H. Huijgens, and A. van Deursen, “AI lifecycle models need to be revised,”Empirical Software Engineering, vol. 26, no. 95, 2021

  38. [38]

    Towards CRISP-ML(Q): A machine learning process model with quality assurance methodology,

    S. Studer, T. B. Bui, C. Drescher, A. Hanuschkin, L. Winkler, S. Peters, and K.-R. M ¨uller, “Towards CRISP-ML(Q): A machine learning process model with quality assurance methodology,”Machine Learning and Knowledge Extraction, vol. 3, no. 2, pp. 392–413, 2021. [Online]. Available: https://www.mdpi.com/2504-4990/3/2/20

  39. [39]

    Interpretability of machine learning solutions in industrial decision engineering,

    I. Kolyshkina and S. Simoff, “Interpretability of machine learning solutions in industrial decision engineering,” inData Mining, T. D. Le, K.-L. Ong, Y . Zhao, W. H. Jin, S. Wong, L. Liu, and G. Williams, Eds. Singapore: Springer Singapore, 2019, pp. 156–170

  40. [40]

    Developing purposeful AI use cases - a structured method and its application in project management,

    P. Hofmann, J. J ¨ohnk, D. Protschky, and N. Urbach, “Developing purposeful AI use cases - a structured method and its application in project management,” inWirtschaftsinformatik, 2020. [Online]. Available: https://api.semanticscholar.org/CorpusID:209179056

  41. [41]

    MAISTRO: Towards an agile methodology for AI system development projects,

    N. S. M. Petrin, J. Carlos, M. N ´eto, and H. C. Mariano, “MAISTRO: Towards an agile methodology for AI system development projects,”Applied Sciences, vol. 15, no. 5, 2025. [Online]. Available: https://www.mdpi.com/2076-3417/15/5/2628

  42. [42]

    The goal question metric approach,

    V . R. Basili, G. Caldiera, and H. D. Rombach, “The goal question metric approach,”Encyclopedia of Software Engineering, pp. 528–532, 1994

  43. [43]

    C. M. Bishop,Pattern Recognition and Machine Learning. Springer, 2006

  44. [44]

    A few useful things to know about machine learning,

    P. Domingos, “A few useful things to know about machine learning,” Communications of the ACM, vol. 55, no. 10, pp. 78–87, 2012

  45. [45]

    ISO/IEC,25012: Software Engineering — Software Product Quality Requirements and Evaluation (SQuaRE) — Data Quality Model, In- ternational Organization for Standardization Std., 2008

  46. [46]

    Datasheets for datasets,

    T. Gebru, J. Morgenstern, B. Vecchione, J. W. Vaughan, H. Wallach, H. Daum ´e III, and K. Crawford, “Datasheets for datasets,” inCommu- nications of the ACM, vol. 64, no. 12, 2021, pp. 86–92

  47. [47]

    ISO/IEC,25010: Systems and Software Engineering — Systems and Software Quality Requirements and Evaluation (SQuaRE) — System and Software Quality Models, International Organization for Standardization Std., 2011

  48. [48]

    A systematic analysis of performance measures for classification tasks,

    M. Sokolova and G. Lapalme, “A systematic analysis of performance measures for classification tasks,”Information Processing & Manage- ment, vol. 45, no. 4, pp. 427–437, 2009

  49. [49]

    Flach,Machine Learning: The Art and Science of Algorithms that Make Sense of Data

    P. Flach,Machine Learning: The Art and Science of Algorithms that Make Sense of Data. Cambridge University Press, 2012

  50. [50]

    Hidden technical debt in machine learning systems,

    D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V . Chaudhary, M. Young, J.-F. Crespo, and D. Dennison, “Hidden technical debt in machine learning systems,” inAdvances in Neural Information Processing Systems, vol. 28, 2015

  51. [51]

    What’s up with requirements engineering for artificial intelligence systems?

    K. Ahmad, M. Bano, M. Abdelrazek, C. Arora, and J. Grundy, “What’s up with requirements engineering for artificial intelligence systems?” in2021 IEEE 29th International Requirements Engineering Conference (RE), 2021, pp. 1–12

  52. [52]

    How mature is requirements engineering for AI-based systems? a systematic mapping study on practices, challenges, and future research directions,

    U. e Habiba, M. Haug, J. Bogner, and S. Wagner, “How mature is requirements engineering for AI-based systems? a systematic mapping study on practices, challenges, and future research directions,”Require- ments Engineering, vol. 29, no. 4, pp. 567–600, 2024

  53. [53]

    Requirements engi- neering for machine learning: A systematic mapping study,

    H. Villamizar, T. Escovedo, and M. Kalinowski, “Requirements engi- neering for machine learning: A systematic mapping study,” in2021 47th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 2021, pp. 29–36

  54. [54]

    Requirements engineering practices for AI/ML-based systems: A systematic literature review,

    Z. Nasri, “Requirements engineering practices for AI/ML-based systems: A systematic literature review,” SSRN, Tech. Rep., October

  55. [55]

    Available: https://ssrn.com/abstract=5563700

    [Online]. Available: https://ssrn.com/abstract=5563700

  56. [56]

    The evolution of CRISP-DM for data science: Methods, processes and frameworks,

    A. M. Shimaoka, R. C. Ferreira, and A. Goldman, “The evolution of CRISP-DM for data science: Methods, processes and frameworks,” SBC Computing Reviews, vol. 4, no. 1, pp. 28–43, Oct. 2024. [Online]. Available: https://journals-sol.sbc.org.br/index.php/reviews/article/view/ 3757

  57. [57]

    A literature review on automated machine learning,

    E. Alcobac ¸a and A. C. P. L. F. de Carvalho, “A literature review on automated machine learning,”Artificial Intelligence Review, vol. 59, p. 5, 2026