Requirements Engineering (RE) is a process used in the development of software-based systems to address the needs of stakeholders. During the RE process, requirements are elicited, documented, validated, and managed. A requirement is a statement that reflects the needs of the stakeholder, such as the capabilities or characteristics that the software to be developed must have [1,2]. A distinction is made between functional and non-functional requirements (NFRs). Functional requirements describe functionalities that must be provided by a system. NFRs are understood to be quality requirements on the one hand and constraints on the other [1,3].
In this paper, only NFRs are considered. Quality requirements describe quality criteria that the system must meet, such as performance and availability, and constraints describe conditions and restrictions that can influence the development of the system, such as laws, regulations or standards [1,3]. According to Ahmad et al. [3], RE has been sufficiently explored in the development of classical software-based systems, and it is clear which techniques can be used in RE activities. Recent software developments are increasingly using artificial intelligence (AI) components and machine learning (ML) [3]. According to Kreutzer and Sirrenberg [4] AI is understood as an overarching term for systems that automatically generate intelligent solutions to a problem [4]. ML is understood as a subfield of AI in which self-learning algorithms are used. These systems are able to learn and solve problems on their own without a human being programming them to do so [4,5]. The difference between classical software-based systems and systems with ML components is that systems with ML components are probabilistic [6]. According to Ahmad et al. [3], the use of RE in the development of systems with AI or ML components has not been sufficiently explored. This statement is confirmed by Yoshioka et al. [6] and Villamizar et al. [7] in that research regarding techniques of RE in the development of MLbased systems is insufficient. According to Ahmad et al. [3], new techniques are needed for RE activities that can be used in the development of systems with AI or ML components. According to Rupp and the SOPHISTs [2], the specification of ML-based systems differs from classical systems in that this type of system focuses on the quality of the ML model used as well as the training, validation, and test data. Greater emphasis must be placed on NFRs in ML-based systems [2]. A ML model is built using a selected ML algorithm trained on training data for solving a particular problem [4,5,8]. Validation and test data are then used to check the quality of the ML model before it is deployed [9]. The quality aspects of NFRs that must be taken into account when developing classic software-based systems are defined and categorized in ISO/IEC 25010 [10]. This standard does not yet explicitly consider quality criteria related to systems with ML components. Quality criteria should not only refer to the end product, but also to the previous aspects such as the training data used, or the ML model used. Summarizing this, there is a need for specific ML-related requirements documentation techniques. This is also confirmed by the employees of adesso SE. Due to the lack of best practices in this area, it is still unclear which documentation techniques are specifically suitable for systems with ML components. With over 9,000 employees and annual sales of EUR 900.3 million in 2022, adesso Group is one of Germany's largest IT service providers. We aim to provide a template, focusing requirements analysts to ML specifics and improve the completeness of requirements by specifying ML quality requirements. This approach promises to improve project success and to help on save development costs. The primary goal of this paper is twofold: (1) to identify the NFRs of systems with ML components that need to be specified in greater detail when applying ML and (2) to conceptualize a template for the documentation of the most relevant NFRs. This paper will answer the following research questions (RQ):
• RQ1: How are requirements for systems with ML components documented? • RQ2: Which NFRs are specific to systems with ML components? • RQ3: Which documentation styles for systems with ML components are most used in industrial projects at adesso SE? • RQ4: Which problems do current elicitation and documentation techniques have for ML components in industrial projects at adesso SE? • RQ5: What is the template design to document NFRs for ML systems?
The following previous works are relevant: The systematic mapping study of Villamizar et al. [7] covers RE for ML-based systems. They provide an overview of 35 studies (2018-2020) starting from the results of a Scopus search and snowballing. They investigated specific ML based systems NFRs, based on their frequency in the primary studies, given in brackets hereinafter. The ML specific requirements are Usability (1), Scalability (1), Modularity (1), Robustness (1), Autonomy (1), Uncertainty (1), Suitability (1), Accuracy (2), Ethics (2), Accountability (2), Testability (2), Legal requirements (2), Maintainability (3), Performance (3), Safety (4), Reliability (4), Transparency (5), Fairness (5), Data quality (5), Privacy (6), Explainability (6) and Security (6). The systematic literature review (SLR) of Yoshioka et al. [6] covers 32 papers (2017-2021), investigating which techniques are used to document ML system requirements with concrete examples. They found GORE (i* and KAOS) in 10 cases, UML in 7 and safety cases in 1 case. The ML specific requirements are Overfitting (2), Fairness (2), dataset requirements (6), Robustness (6), Accuracy (7), Explainability, Transparency and Accountability (9). The literature review from Ahmad et al. [3] covers RE for AI and ML based systems. They analyzed 27 studies (2011-2020). The authors focused on the documentation techniques of requirements for systems with AI or ML components with an emphasis on their specific NFRs. First of all, the GORE notations FLAGS, CORE, GRL, i* und GORE-MLOps are used (5), and with the same frequency UML and SysML notations (5) and Conceptual Models (CM). Further they summarized ML relevant NFRs: Transparency, Trust, Privacy, Safety, Reliability, Security, Fairness, Explainability, Ethics, Robustness, Accuracy, Uncertainty, Data quality, Testability, Legal requirements und Availability of training-, validation-and test-data. The literature review of Gjorgjevikj et al. [54] shows an interesting mixed-method study on the use of requirements for ML in projects. They validate that RE activities are crucial to the ML development process. Requirements should cover quality ML specifics, which are Interpretability, Fairness, Robustness, Security, Privacy, and Safety, that occurs also in our research. Most importantly, they state future research should focus on adjusting the RE activities to fit the ML development. The template described in this study, provides further research to this direction. The existing SLRs show documentation forms for ML components (RQ1) and specific ML components NFRs (RQ2) till 2021. We complete this view of related works to June 2022.
In this article, we perform a systematic mapping study according to the principles of Petersen [53] to provide an overview of the state-of-the-art regarding use of NFR for ML systems, answering RQ1 and RQ2. The mapping study, particularly the data gathering, was performed by the first and reviewed by the third author. We used principles of Kitchenham und Charters [11] for study selection and search term construction. Data was gathered in June 2022.
As RQ1 and RQ2 are closely related, we use one search term for the literature acquisition:
(("requirements engineering") AND (documentation OR specification OR notation OR "modeling language") AND "machine learning" AND (software OR application OR system)). For a broad search and a high level of completeness around machine learning, the search for additional ML sub-terms was omitted. We used the following databases: (i) Spring-erLink1 as they have broad basis on RE and AI, (ii) ScienceDirect2 focuses on engineering of AI systems and architectures, (iii) IEEE Xplore 3 and (iv) ACM Digital Library 4 are engineering databases for studies with emphasis on AI applications. Inclusion (In) and exclusion (En) criteria are shown in Table 1. I1 selects studies after the SLRs in related works have been published. I2 assures studies to have minimal scientific standard, whilst the selected databases list peer reviewed articles only. I3 includes papers that contribute to the topic of this article. A paper was selected if a review showed it to offer a contribution to documentation techniques or NFRs for systems with ML components. E1 filters studies that use ML techniques to support RE: If the paper's main focus was on approaches to support requirements activities by AI or ML, the paper was excluded, as this was not our scope. This criterion was validated by a detailed review of the article. E2 avoids SLRs or mapping studies, that we already addressed as related works. E3 deselects similar studies from the same authorship. Study Selection. Fig. 1. shows the four phases of study selection. In phase 1 we queried the selected databases with the presented search term, applied I1 and I2, resulting in 1233 publications. In phase 2 the title, keywords and abstracts were considered using I3 and E1. In phase 3 we reviewed the content and filtered according I3 and E2. As there were no duplicates E3, we summed up to 15 relevant publications shown in Table 3. No relevant publication could be identified from ScienceDirect. The contents of the listed publications did not cover documentation techniques or NFRs for systems with ML components. The references of the literature from phase 2 onwards are available for download in the last section.
Documentation Techniques of Systems with ML Components. Four out of 15 selected studies cover techniques for requirements documentation. The other 11 studies cover NFRs of systems with ML components. Zaidi [12] shows the use of conceptual models (CM) in various phases of ML to document requirements and goals of the project. The use i* and UML, Business Process Model and Notation (BPMN) [13] and Building Information Modeling (BIM). The latter is a domain specific notation model for building [14]. Tun et al. [15] found several requirements documentation notations: An AI Project Canvas is used to document decision making considerations and to capture the impact on organizational structure due to are used for safety analysis, modelling possible accidents and giving evidence for the systems suitability [16]. The architectural design of the system is described with SysML [17] and the functional requirements with a Goal Model (GORE) notation.
Khan et al. [18] investigates the use of NFRs for ML systems. They propose an extended SysML requirements diagram, and a GORE-MLOps model, that addresses uncertainty and unpredictability in ML systems during RE. Husen et al. [19] proposes a framework for safetycritical ML systems consisting of the documentation techniques AI project canvas, ML Canvas, KAOS, UML Component Diagram, STAMP/Systems Theoretic Process Analysis (STPA) and Safety Cases. The AI project canvas details early business requirements from the system specification. KAOS is used to document functional requirements that are detailed into an architectural component model. By using safety cases counter measures for risks through STAMP/STPA are defined, whereas STAMP is a method for risk [19,20]. Table 2 summarizes these techniques.
In summary, GORE notations and UML or SysML diagrams are mostly used for ML requirements. Three studies provide details about GORE: i* [12], KAOS [19] and GORE-MLOps [18]. All four works use UML/SysML diagrams: in two papers this is detailed to component diagrams [19] and extended SysML requirements diagrams [18]. For the documentation of NFRs GORE [15], GORE-MLOps and an extension of a SysML requirements diagrams [18] is mentioned.
Within 14 of the 15 selected studies, we identified in summary 54 NFRs for ML components as shown in the extraction table available for download as open research data (see last section). The related works showed four more NFRs that were not included in the 14 selected studies. We have added the additional four NFRs to the results: (i) Autonomy of ML algorithm, (ii) Suitability, (iii) Legal requirements and (iv) dataset requirements. As there is no common set of ML specific NFRs yet, we identified NFRs with synonymous terms or describing similar phenomena. Therefore, we consolidated the 58 identified NFRs into 33 relevant NFRs with the following descriptions. An overview of these results is given in Table 3.
NFR-1 Suitability describes the appropriateness of the ML usage and the extent to which the ML solves the given problem [7,21]. NFR-2 Explainability and Interpretability describes mechanisms that allows users to comprehend the systems results [22][23][24][25]. NFR-3 Justifiability Users require system's decision to be rational [26]. NFR-4 Transparency describes details about ML algorithms, training-and test data to validate the systems decisions [22,24,26,27]. NFR-5 Traceability For users and developers the source of training and validation data, artifacts and processes must be documented [22,28]. NFR-6 Fairness describes that systems must respect human rights, equal rights, equal opportunity for all users, and follow the democracy principles. The results of AI are supposed to be un-biased and discrimination free [22,25,29,30]. NFR-7 Safety describes requirements that avoids risks to humans or the environment [23]. NFR-8 Trust describes users expectation to the reliability of system decisions and the correctness of results [10,24]. NFR-9 Efficiency of ML algorithm are used to describes quality aspects of the ML training and prediction algorithms [26]. NFR-10 Performance of ML model describes the expectations to performance and correctness of the ML model for prediction and the resources to gain these predictions [22]. This incorporates accuracy as internal performance metric for the prediction quality [23,31,32] and correctness of the decisions or prediction results [22,23]. NFR-11 Latency of ML model defines the acceptable time between data acquisition and the result of the prediction [33]. NFR-12 Security defines the access to used and created data (sets) [22,23]. NFR-13 Privacy considers rights of human privacy due to confidentiality and protection of data [22,23]. NFR-14 Integrity of data defines quality attributes to training, validation and test data, e.g. correctness, preprocessing and data integrity [22,23,27]. NFR-15 Dataset requirements capture requirements to data records such as topic, domain, context, origin of data [34], quantity of data [9,27]. NFR-16 Accountability describes details to the extent to which the system takes ownership and responsibility of its decisions [26,35]. NFR-17 Reliability captures the predicted functioning expectations for the system [23,25]. NFR-18 Reproducibility and Repeatability address the necessity that predictions must be identical for multiple requests with the same data [23,26,36]. This is synonymously referred to as consistency [37]. NFR-19 Fault tolerance describes expectation to resilience to incorrect data or partial system failures to avoid complete failure [38], sometimes referred to as robustness [22,39]. NFR-20 Autonomy of ML algorithm expresses the independence or encapsulation of ML algorithms. The retraining of a ML subsystem must be possible without depending on the application's development [4,7]. NFR-21 Maintainability describes the needs regarding further development as extensions or system evolutions [10,40]. NFR-22 Modularity defines the required level of maintainability. A system consist of several modules that work independent but collectively to provide the necessary functionality [10,40]. NFR-23 Reusability describes details about the possibility to reuse parts or components of the system in other contexts or systems. In ML contexts this could be the reuse of ML models or data sets [40]. This NFR also covers the domain adaptation, where in transfer learning scenarios labelled data are used to create models of other domains [41]. NFR-24 Modifiability describes the extent to which a module can be changed without affecting the ML module quality [10,40]. NFR-25 Retrainability describes that ML models must be newly trained with other than initial data [27]. NFR-26 Testability defines, how ML models and their prediction components can be tested and what the resulting quality of decisions can be [40]. NFR-27 Usability describes the same aspects as in ISO/IEC 25010 with a focus on ML models and their decision or prediction presentation to users [10,27]. NFR-28 Interoperability describes the requirements that allow the communication and data exchange with other systems [10,42]. NFR-29 Portability defines to what extend ML models are supposed to be transferred to other contexts, e.g. a classification of blood diseases for cancer patients to non-cancer patients [10,32]. NFR-30 Adaptability (portability of ISO/IEC 25010) describes how the ML model can be used in other contexts such as operating systems or system environments [10,27]. NFR-31 Scalability of ML pipeline defines requirements for processing tools with regard to data volumes, large data sets and runtime is-sues during training [37,43]. NFR-32 Complexity of ML model describes the number of features the ML model is capable of. A too high model complexity leads to overfitting and a too low complexity leads to underfitting [44]. NFR-33 Legal requirements covers the specification of regulatory needs such as standards, acts, laws etc. [1,45].
In addition to these NFRs, further requirements were mentioned in the primary studies, as given below. We combined these requirements to the following NFRs: Ethics is part of NFR-33, Uncertainty is part of NFR-17, data issues are details of dataset requirements in NFR-15 covering cleaning of datasets, revision and transition is part of Maintainability NFR-21. Completeness is discussed in Habibullah und Horkoff [37] but is not clearly defined; Flexibility covers the flexibility of the ML pipeline and is categorized as Reusability NFR-23.
An online survey (12 persons) and expert interviews (4 experts) with employees were conducted at adesso SE, to identify the special needs of the documentation of NFRs for systems with ML components. We used this case to prove the relevance of the NFRs identified by the literature review and to identify further NFRs (RQ2). Moreover, we wanted to understand the documentation techniques used by adesso SE (RQ3) and related problems of the documentation (RQ4).
After the analysis of the systematic mapping study, the online survey and the expert interviews, the following 30 of the 33 NFRs mentioned in Table 3 were identified as especially relevant for ML components and provide the final answer to RQ2: The NFRs marked in blue in Table 3 have been classified as relevant in literature research but also in the online survey and expert interviews at adesso SE. The NFRs marked in grey were additionally classified as relevant in the online survey and in the expert interviews. The online survey questions are available for download, given in the last section. Based on the online survey, the following NFRs were rated as the most relevant NFRs (all of the participants gave a positive response): Suitability, Integrity of data, Reliability, Latency of ML model, Testability, Explainability and Interpretability, Performance of ML model, Security and Retrainability. Through the expert interviews, it was determined that the NFRs Accountability and Transparency must be considered relevant, even though they were not classified as relevant by the online survey. The expert interviews showed that Integrity of data always appears in the top 2 of the most important NFRs. This is justified by the fact that data is the basic building block of ML and therefore its integrity is necessary. The questions of the expert interviews are available for download, given in the last section. Table 3 shows that NFRs occur with different frequency in the articles. In particular the work of Habibullah and Horkoff [37] show the most NFRs, as they performed a comprehensive qualitative interview study in which NFRs for ML were explored in detail. Part of the interview study was to identify NFRs that are more or less important in the industry. The Importance through online survey column shows how many people classified the respective NFR as relevant in the online survey. For each NFR, the participants were asked to state whether it is a relevant NFR for systems with ML components. The participants could respond to the statement as follows: strongly disagree, disagree, neither, agree and strongly agree. When evaluating the relevance of the NFRs, the answers with the selection Neither were sorted out in relation to neutrality. An NFR was categorized as relevant for systems with ML components if more than 50% of the participants in the online survey agreed with the statement. Only 14 of the 15 papers identified in Fig. 1. are listed in this table, as the paper from Zaidi [12] only deals with documentation techniques and therefore makes no reference to the NFRs of systems with ML components. This table answers RQ2.
The online survey at adesso SE showed that employees use the following techniques to document NFRs (in order of occurrences): user stories, sentence templates, to be concepts, UMLs (e.g. use case diagram), entity relationship models (ERM), tests, service level agreements (SLA), authorization concepts, mockups and usability standards. The first two techniques were also identified as appropriate by online survey participants. These findings answer RQ3: Using user stories, sentence templates, NFRs can be documented in natural language. The expert interviews also confirm this finding.
Through the online survey and expert interviews, the following problems in documenting NFRs were identified, which provide the answer to RQ4: (1) No consistent, appropriate, or proper format in documentation, (2) definition problems in certain situations, (3) insufficient specification and thus missing information, which later led to problems during implementation, and (4) missing technical aspect in the requirements documentation.
Based on project examples, the specifics of documenting NFRs for systems with ML components were examined in the expert interviews. Table 4 shows the roles, skills and the work experience in years of the experts. The projects did not use a standard template for the documentation of NFRs. For example, in one project a combination of user story and key results was used to document the requirements, and in another project the requirements were documented without using an appropriate sentence template or similar. However, each requirement was prioritized using the MoSCoW prioritization technique [1]. Based on the results of the expert interviews and a literature review, a template was designed that can be used to document NFRs as a natural language documentation technique in a uniform manner. A natural language documentation technique was chosen because natural language documentation techniques are used most frequently at adesso SE. This does not exclude the possibility that the specified template can also be supplemented by model-based documentation techniques. After the initial conception, the template was evaluated with a further five experts in semi-structured expert interviews at adesso SE. The template used for the evaluation is available for download in the last section. The expert interviews showed beneficial aspects of the template and some need for optimization. The experts were asked whether they would recommend the first conception of the template to colleagues, measured by the Net Promoter Score (NPS). NPS is a metric that categorizes people into three groups, promoters, passives, and detractors based on a question that can be answered on a scale of 0-10. Only the number of detractors and promoters is required to calculate the NPS, as the percentage of detractors is subtracted from the percentage of promoters [49]. Out of five experts, two experts have a neutral attitude (passives), one expert has a critical attitude (detractor) and two experts have a positive attitude (promoters) towards the present template. The expert with the critical attitude mentioned that s/he would rate the template with a much higher value if the role and benefits were taken out of the template. The benefit field is covered by the justification of priority, which is why this field does not offer any added value. Another expert agreed that the role should be removed, as this does not add any value. The benefit field and the <role> in the sentence template have therefore been removed. But the Other notes (optional) field was added to the template. The following NPS was determined for the first draft of the template: NPS = ((2-1)/5) x 100 = 20%. According to Lee [50], 20% is a good value. The improved template can be found in Table 5. and provides the answer to RQ5. Furthermore, an example can be seen in Table 6. The template supports the management of requirements through consistent documentation and the relation the NFR-classes in Table 3 defined by the NFR-class and the object of consideration in the template. The NFR-class, for example, is relevant because different metrics must be defined in the acceptance criteria depending on the NFR-class. These metrics are not considered in more detail in this paper but would need to be analyzed and defined in more detail in further research work. The NFR-classes are only an example in our template. These can be extended by further NFR-classes. In addition, further research could determine whether the template could be expanded to include further elements. Additionally, the template was evaluated in a second company Serapion, presented below. This template is the answer to RQ5.
The second evaluation was done with Serapion GmbH, which is an IT service provider and management consultancy with more than 100 employees that develops cross-industry solutions in Europe. In order to expand the survey, Serapion was chosen as another consulting company because this company is known as a pioneer of AI technology in the German market. The proposed NFR-template was evaluated in practice using three projects with ML components. By using the technology acceptance model (TAM) [51] the perceived usefulness was evaluated by analysts to measure the degree to which a person believes that using this template would enhance their job performance. Three randomly selected projects have been identified where ML components currently or in the future are used. For each of the three projects, the responsible project manager has been identified in the role of the Requirements Engineer, and the implementing party has been pinpointed. The templated was presented to project members. After a short discussion and feedback about the template, a real NFR was documented using the template. The template was filled out together with the respective project manager and feedback was then obtained through verbal interviews with the respective project manager and a respective developer. The results illustrate the benefit (one of the experts called it a remarkable benefit) of the proposed NFR template in specifically capturing and documenting requirements in projects with ML components. Through the practical application of the project examples, the template´s effectiveness in improving communication within the project team and stakeholders as well as in helping to prioritize requirements became clear.
The general feedback to the template was: (i) during a proof-of-concept phase, the template is not required. In early project stages the focus lie on validating ideas and testing concepts. (ii) The template is highly valuable in subsequent stages, where implementation and scaling occur.
The NFR template represents a valuable resource for managing NFR. The recommended extensions ensure improved practicality and completeness. It is recommended to use this template in software projects and customize it according to project situation and requirements.
We follow the classification of Wohlin et al. [52]. Conclusion validity address whether the soundness of the treatment is related to the actual observed outcome. As the template was found useful by the experts, this is an indication that it contributes to capturing the requirements for ML components adequately. Construct validity considers whether the study measures what it claims to measure. For the systematic mapping study, the RQs were discussed in the team of authors and feedback from a university talk was considered. The online survey was conducted in one company only and contained 177 questions, which might frighten some participants. Pretests were conducted with three people. Some answers did not describe precisely how the NFRs were documented by the specified techniques. Expert interviews were conducted with adesso SE using a guideline with questions, that might have been misunderstood by experts. We used pretests with two people to mitigate misunderstanding. Internal validity determines the extent of conclusions that can be drawn from a study. We scoped the systematic mapping study to RE of NFRs for ML components. The search term was validated by all three authors and the process of Petersens mapping study was followed, beside the quality measurement of primary studies. The use of four databases covers publications since 2021 in a broad range. Three related SLRs cover results before 2021. The online survey of adesso SE employees gained a small sample size of 12. Results of the expert interviews were biased upon the level of expertness of participants. Therefore, we raised questions about the participant's ML experience. Only 4 people from adesso SE participated in the expert interviews. External validity describes the possible generalization or transfer of the study results to other situations. The results of the mapping study might be biased through the missing quality evaluation. The scope ML based components limit the generality of the presented insights of the mapping study, online survey and interviews; thus, results are not valid for other types of systems. We did not distinguish different types of ML such as supervised, unsupervised, and reinforced learning. The evaluation expert interviews were only conducted in two companies, which limits transferability to other companies. For the evaluation in the second company, the template was rated by 3 people, who had not seen the template before. However, the rating of the template overall, was useful.
The peculiarities of documenting NFRs in systems with ML components were identified and 30 NFRs were considered relevant. In addition, no consistent, suitable format for the documentation of ML NFRs could be found. Expert interviews showed a missing standardized approach to documenting NFRs for ML systems. As a result, a specific template to capture NFR requirements was proposed. The template was evaluated in practice and showed significant advantages in usefulness. Criticisms have been raised wrt. early research phases of a project, where detailed requirement documentation may not be relevant. The added value of the proposed NFR template in later project phases was recognized, especially for the implementation of NFRs. Feedback during the evaluations lead to a revision of the NFR template. There is still a need to understand the effectiveness and applicability of the template in larger companies. The adaptation of the template to different ML methods is still in its early stages and requires further research. The identification and integration of relevant NFRs for these learning methods is an underresearched area. In summary, this research showed particularly important NFRs for ML components and showed the usefulness of the proposed NFR template to support the implementation of projects with ML components.
Additional material for this article can be downloaded from the zenodo online repository of the European Union: https://10.5281/zenodo.10640638.