A Guideline for the Definition of Use Cases in Software Development Projects

Chapter 17 A Guideline for the Definition of Use Cases in Software Development Projects Beatriz Andres, Faustino Alarcon, and Raul Poler Abstract This paper proposes a guideline to support researchers, technology developers, and industrial pilots, which are part of a project consortium, on the definition of use cases for the software development, testing, and validation of the project results. The proposed guideline is applied in a European project where a suite of software solutions is predefined in the proposal. This guideline aids in the identification and description of use cases in an organized way, ensuring that the necessary information to develop software solutions is gathered. In this regard, the guideline enables to (i) conceptually define the project solutions; (ii) identify the pilots’ needs through modelling of the As Is business processes of each industrial pilot; (iii) map the project solutions with the pilot needs; and (iv) assign the project solutions on the preidentified business processes through modelling the To Be business process. The proposed guideline is applied for use cases definition in a European project. Keywords Use case ·Guideline ·Industrial pilots ·Business processes · European project ·Software engineering This chapter is a derivative publication expanded from an earlier publication: Andres, B., Alarcon, F., Cubero, D., Poler, R. (2023). A Methodology for Project Use Case Definition. In: García Márquez, F.P., Segovia Ramírez, I., Bernalte Sánchez, P.J., Muñoz del Río, A. (eds) IoT and Data Science in Engineering Management. CIO 2022. Lecture Notes on Data Engineering and Communications Technologies, vol 160. Springer, Cham. https://doi.org/10.1007/978-3-03127915-7_78; Therefore, this manuscript uses part of the material published i n https://link.springer. com/book/10.1007/978-3-031-27915-7. B. Andres (B) · F. Alarcon · R. Poler Research Centre on Production Management and Engineering (CIGIP), Universitat Politècnica de València (UPV), Valencia, Spain e-mail: [email protected].es F. Alarcon e-mail: faualv[email protected].es R. Poler e-mail: [email protected].es © The Author(s), under exclusive license to Springer Nature Switzerland AG 2026 F. P. García Márquez et al. (eds.), Internet of Things and Data Science in Engineering Management, Lecture Notes in Management and Industrial Engineering, https://doi.org/10.1007/978-3-031-92251-0_17 243 244 B. Andres et al. 17.1 Introduction Horizon Europe is the EU’s key funding programme for research and innovation with a budget of e95.5 billion [1]. It aims to support Sustainable Development Goals (SDG) implementation and boost the EU’s industrial competitiveness and growth. Horizon Europe programme leads its activities on creating jobs, gathering talented personnel, stimulating economic growth, and increasing industrial competitiveness, through the proper use of investment to strengthen the European research area. In the Horizon Europe programme, a new approach of partnerships is boosted with the aim of achieving more ambitious collaboration with industry, thus fulfilling the EU policy objectives [1]. The European Framework Programmes stress t he importance of applying the solutions developed in European-founded projects. Accordingly, Framework Programme calls are associated with the Technology Readiness Level (TLR), namely the development degree of a technical product to be achieved by the technologies developed within the project [2]. For Horizon 2020 and Horizon Europe the TRL definition to the work programme has been adapted, ranging on the scale from TRL 1 to TRL 9. TRL 1 leads to identify fundamental laws and TRL 9 refers to technological solutions applied in an enterprise context. From TRL 5 on technological solutions have to be tested in real industrial conditions. Accordingly, industrial pilots and definition of use cases are key elements to validate the technology solutions developed in a project when TRL5 or higher is demanded. In this context, a use case is a succession of interactions between the system and the user that leads to an assessable outcome. A use case is created when the actor employs the system. The whole capacity of the system is determined by a set of use cases [3, 4]. Moreover, a s cenario is a specific instance of a use case, in which a set of possible actions are carried out for that use case [5]. Use cases are required in order to support the software engineering, the user interface design, the software creation and management, and the software verification and validation [6]. With this aim, this paper proposes a guideline to support the project consortium, namely researchers, technology developers, and industrial pilots, on the identification and definition of use cases for the technologies’ development, testing, and validation. To deal with this main objective the paper is organized as follows: Sect. 17.2 provides a literature review on use cases, Sect. 17.3 proposes the guideline for the definition of use cases in software development projects, and Sect. 17.4 depicts an application of the proposed guideline in a European project. Finally, in Sect. 17.5, conclusions and future research lines are discussed. 17 A Guideline for the Definition of Use Cases in Software Development … 245 17.2 Literature Review Software engineering refers to software development and covers design principles, documentation, and further engines to create software according to the users’ requirements. Software requirement specification comprises the function of the system and includes the actors’ requirements, including the user or another system. Different methods are used for the requirements gathering, including formal languages, user stories, use case models, or activity diagrams [7]. Use case models are used in all the phases of software development, from the requirement phase to the testing phase. According to Chaudron et al. [8], use case models can be used for different purposes; consequently, use case models can be used by (i) the users’ and developers’ analysis to better understand of all the parts of a system t hrough modelling an organized abstraction of the complex real world; (ii) the system developers to communicate and share information from the system design to the system implementation; (iii) the system developers to have a baseline for the system implementation and program the system code. Moreover, Chaudron et al. [8] highlight the importance of use cases correct definition in software development projects, in which developers of different parts of the world, in order to avoid misunderstandings. Use cases have been firstly considered by Jacobson et al. [3, 9]. These authors define a use case as a part of the system operation that leads the user to obtain a valuable result. The use case enables to gather functional requirements that determine how the system works and describes the characteristics of the system according to the requisites of the user. Thus, functional requirements are captured in use cases. A set of use cases composes a use case model, which defines the complete functionality of the system. Use cases trigger the process of system development and allow the developers to design, implement, and test the requirements gathered from the user [10] (see Fi g.17.1). Different methodologies and modelling languages have been developed and used to model the use cases at all levels, including Object-Oriented Software Engineering (OOSE) [11], Booch methodology [12], use case maps (UCM) [13], OPEN Modelling Language (OML), unified modelling language (UML) [14], use case diagrams, class diagrams and sequence diagrams [8, 15], Model-Based Engineering (MBE) [7]. A detailed review on the aforementioned methodologies and modelling languages can be seen in Rui and Butler [16]. The extent of this paper is to provide a guideline for use case identification and definition in order to deal with the requirements gathering through a sustainable process in the phases of design, implementation, and test of a use case in a system service. Sustainability in terms of reducing or avoiding the refactoring [17] on the use case definition, in the testing phase to avoid redesigns and further implementations. Use cases can be used not only for designing user interfaces and creating user documentation as a guideline for the use of a system, but also to plan the implementation iterations, to scope the testing phase, to create the architecture of the system, and to validate design and definition of test cases and procedures [6]. 246 B. Andres et al. Fig. 17.1 Hierarchy of systems requirement gathering Qi and Boehm [7] describe, according to IBM Software Group report [6], the process of use case modelling as business-driven development approach, which enables to develop a software from a use case-driven perspective. When raising a use case methodology, these authors include the phases of business modelling, requirements gathering, analysis design, implementation, and testing. The current paper focuses on the business modelling phase, so that once the technological solutions are conceptually defined, the proposed guideline allows to (i) identify the pilots’ needs through modelling the As Is business processes; (ii) map the technological solutions with the pilot needs; and (iii) assign the technological solutions on the preidentified business processes through modelling the To Be business process. 17.3 A Guideline for Use Cases Definition In this section, a guideline to identify and define use cases for the design, implementation, and test of technological solutions in European projects (G-UC) is proposed (Fig. 17.2). Concretely, this paper applies the proposed guideline in a European project founded under Horizon 2020 Framework Programme. In European projects, if the proposal is founded, the Project Coordinator receives the Evaluation Summary Report and according to this prepares the Grant Agreement, jointly with the consortium. The Grant Agreement, to be signed between the Project Coordinator and the European Council, contains a set of annexes among which them is the Description of Action (DoA). The DoA describes the work to be developed, including the work packages and deliverables in which t he technological solutions will be developed, as well as the pilots that will participate in the validation of such solutions. More detailed, the DoA includes: (i) the project summary; (ii) the list 17 A Guideline for the Definition of Use Cases in Software Development … 247 Fig. 17.2 Use cases conceptual model [18]. Adapted with permission from Springer Nature Switzerland AG from Andres, B., Alarcon, F., Cubero, D., Poler, R. (2023). A Methodology for Project Use Case Definition. In: García Márquez, F. P., Segovia Ramírez, I., Bernalte Sánchez, P. J., Muñoz del Río, A. (eds) IoT and Data Science in Engineering Management. CIO 2022. Lecture Notes on Data Engineering and Communications Technologies, vol 160. Springer, Cham. https:// doi.org/10.1007/978-3-031-27915-7_78 of beneficiaries; (iii) work plan tables—detailed implementation; (iv) list of work packages; (v) list of deliverables; (vi) work package descriptions, including the pilots participating and use cases; (vii) list of milestones; (viii) critical risks and mitigation actions; (ix) summary of project efforts in person months; (x) tentative schedule of project reviews. The conceptual model of the G-UC is proposed in Fig. 17.2, where the use cases are to be defined (UCm) according to the definition of the As Is business processes (BP0X) of each pilot (PY )–AsIs_Py_BP0x, and the To Be business processes–ToBe_ Py_BP0x, both of them represented through business processes modelling notation (BPMN). Thus, starting from the AsIs_Py_BP0x models, the ToBe_Py_BP0x models have to reflect both, the results of the project and the part of the model in which the results are going to be implemented (ERP_SN). Finally, a mapping between the solutions that are going to be developed along the European project (ERP_SN) with the use cases (UCm) is presented. That is, among all the ERP_SN solutions which of them are going to be implemented and validated in each of the UCm defined. Moreover, the conceptual model also shows the definition and formulation of the key performance indicators (KPIs) to be measured for identifying the extent into which the solutions developed within the project (ERP_SN) contribute to the industrial pilots’ performance improvement. Nevertheless, the KPIs definition will be 248 B. Andres et al. considered in extended works of the G-UC. Parallel to the project use cases definition, the requirements analysis and the functional specifications gathering must also be carried out. This work will be also included in further versions of the proposed G-UC. The complete definition of requirements and functional specifications will be based on the use cases definition, from the To Be models. Thus, the As Is and To Be models defined according to the steps of G-UC will enable to have further knowledge to analyse t he requirements and functional specifications of the project solutions (ERP_SN). The purpose of G-UC is to identify, describe, and characterize European project use cases. The G-UC reflects the steps to be carried out to help the industrial pilots become aware of the solutions developed in a project, as well as the technical capabilities and potentiality, and at the same time expresses the needs and future expectations from the project results. Hence, G-UC is based on: •The overview of technological solutions to be developed. •The industrial pilots’ characterization, modelling their current state (As Is), and the future state (To Be), where the technological solutions are going to be implemented. With this, G-UC will enable to identify and describe the use cases, based on the industrial pilots’ processes and the set of project results. Considering a set of industrial pilots, the G-UC steps are described next: Step 1. Identify and define the technological solutions to be developed within the project, according to the DoA document (namely Annex 1 of the Grant Agreement). Step 2. Select the technological solutions prompt to be applied in a specific pilot and determine the potential business processes in which the technological solutions are to be involved. Step 3. Distinguish the profile of users involved in the business process identified, which will use the technological solutions. Step 4. Describe and represent, in BPMN, the current situation of each business process (As Is model). The As Is model will represent activities, flows, and events of a specific business process selected in step 2. Thus, the current industrial pilot business processes involved are defined. Moreover, the pilot analyses the As Is model and describes the needs for improvement. Step 5. Map the industrial needs identified in step 4 with the specific technological solutions. Step 6. Describe and represent, in BPMN, the future situation of each business process (To Be model), described in step 4, considering the incorporation of technological solutions selected. The To Be model will represent in activities, flows, and events the industrial pilot business processes expected after the implementation of technological solutions developed in the project. 17 A Guideline for the Definition of Use Cases in Software Development … 249 Step 7. Identify and define the use case based on the activities of the To Be model that change with respect to the As Is model and that incorporate the technological solutions. Finally, the result of the G-UC application is the identification and definition of use cases that are obtained from the To Be models, concretely from the activities that involve the implementation of the technological solutions. 17.4 G-UC Application for Use Cases Identification and Definition in a Pilot of a European Project The study provided in this paper specifically focuses on the use case definition for an industrial pilot participating in the European project i4Q “Industrial Data Services for Quality Control in Smart Manufacturing” [19]. i4Q project is devoted to the development of solutions to improve the quality of manufactured products aiming at zero-defect manufacturing. The goal of i4Q is the creation of 22 microservices, belonging to the IoT-based Reliable Industrial Data Services (RIDS), to improve the quality of manufactured products aiming at zero-defect manufacturing, therefore pushing forward the concept of a s mart, fully digitized factory. i4Q European project [19] participate six industrial pilots, and each one takes part in different use cases that will serve to design, implement, and test i4Q project technological solutions. This paper focuses on the industrial pilot of aeronautics and aerospace metal parts quality that consists of an engineering and metal machining company and is labelled as pilot 4 within the i4Q European project. Subsequently, the seven steps of the G-UC are applied in the metal machining pilot with the aim of identifying and describing a use case that will enable the design, implementation, and test of a specific technological solution developed in the i4Q project. Step 1. i4Q RIDS is a complete service that encompasses 22 s olutions founded on a modular way [20], so the result of carrying out the first step of the guideline is shown in Table 17.1. Step 2. From this technological solutions list, the solutions that metal machining pilot is interested in are the ones selected in Table 17.2. Thus, the business process related with this set of solutions, which the metal machining pilot wants to improve, is the “product quality control process” (AsIs_ P4_BP01). The installations of Pilot 4 are composed by computerized numerical control (CNC) machines distributed in a job shop configuration. Every machine has to be set up by an assembler when a new product has to be machined. The selected process begins after the assembler sets up the machine for a new batch of machined products and notices to the operator that the machine is ready. From this moment, the machine starts the machining process and it is necessary to control the quality of 250 B. Andres et al. Table 17.1 G-UC Step 1: i4Q solutions i4QDQG Data Quality Guidelines i4QQE QualiExplore for Data Quality Factor Knowledge i4QBC Blockchain Traceability of Data i4QTN Trusted Networks with Wireless and Wired Industrial Interfaces i4QCSG Cybersecurity Guidelines i4QSH IIoT Security Handler i4QDRG Guidelines for building Data Repositories for Industry 4.0 i4QDR Data Repository i4QDIT Data Integration and Transformation Services i4QDA Services for Data Analytics i4QBDA Big Data Analytics Suite i4QAD Analytics Dashboard i4QAI AI Models Distribution to the Edge i4QEW Edge Workloads Placement and Deployment i4QIM Infrastructure Monitoring i4QDT Digital Twin simulation services i4QPQ Data-driven C ontinuous Process Qualification i4QQD Rapid Quality Diagnosis i4QPA Prescriptive Analysis Tools i4QLRG Manufacturing Line Reconfiguration Guidelines i4QLRT Manufacturing Line Reconfiguration Toolkit i4QLCP Manufacturing Line Data Certification Procedure Table 17.2 G-UC Step 2: i4Q solutions selection i4QDR Data Repository i4QDA Services for Data Analytics i4QBDA Big Data Analytics Suite i4QQD Rapid Quality Diagnosis the product processed. The quality control is made at two levels: a more superficial control carried out by the machine operator and a deeper control carried out by the quality control personnel. Although both product controls are considered quality controls, to differentiate them, the first one is called operator control and the second one quality control: (i) the operator control is made to almost all the processed products, sometimes with simple visual control and others with the measure of some critical parameters, depending on the complexity of the product and the instructions from quality department while (ii) the quality control is made every certain number of parts calculated through statistical process control techniques and consists of measuring all the product characteristics and dimensions to ensure its total quality. 17 A Guideline for the Definition of Use Cases in Software Development … 251 During the quality control process, every measurement obtained from the product is stored in a database that registers the measurements and every fail (measurements DB). Incidences and non-conformities are also stored in another database (incidences DB). If a no conformity is detected, machine adjustments may be required. In these cases, the machine operator evaluates the situation and decides if himself will be able to perform the adjustments or if it will be required the assembler’s presence. When the problem is solved, machining process will be restored, and the control quality will be resumed. Step 3. The users’ profiles participating in the product quality control process are identified. In this case, the main responsible for this process are the assembler, the operator, and the quality control personnel. Step 4. The current functioning of the product quality control process (As Is model) is modelled using the Business Process Modelling Language (BPMN) as follows (Fig. 17.3). Step 5. The problems existing in the current product control quality process are summarized in three: (i) all activities in the quality process are manually developed and strongly depend on the skills and abilities of the operator who performs them; (ii) the i nformation logging about the measurements can take much time and can generate some mistakes difficult to find and solve; and (iii) the number of products manufactured is shown in the machine, but there is no notification about when a product control has to be done, so that the operator must be concentrated in the product counter and in when a quality control has to be done. From these problems, the industrial needs aim to increase the automation of the activities for quality control and could mainly focus on: (i) measuring the parts; (ii) recording the data of the measurements; and (iii) precisely knowing when a quality control of parts should be carried out. These needs can be mapped with the four technological solutions selected in step 2, since (i) Data Repository (i4QDR) solution can continuously capture data from sensors and measurement devices and log it into the database; (ii) Services for Data Analytics (i4QDA) can analyse the data logged and prevent quality defects; (iii) the pilot staff can use Big Data Analytics Suite (i4QBDA) solution to customize the information analysis and to figure out recurring defects; and (iv) Rapid Quality Diagnosis (i4QQD) solution can evaluate each product more quickly and detect any defect. Step 6. To Be business process. The future and improved product control quality process must be modelled with the new activities indicating, for each one, if the activity will be done by a technological solution developed in the i4Q project [20]. In the following BPMN model (Fig. 17.4), the activities the BPMN process related to the Data Repository solution (i4QDR) are depicted (red ellipses). For the other solutions selected, the same procedure should be done. Step 7. The new process activities related to the Data Repository solution allow us to identify use cases for i4QDR solution (see Fig. 17.4). In this case, the use cases are