# Towards a Requirements Co-engineering Improvement Framework: Supporting Digital Delivery Methods in Complex Infrastructure Projects

Yu Chen, Julie R. Jupp

► To cite this version:

Yu Chen, Julie R. Jupp. Towards a Requirements Co-engineering Improvement Framework: Supporting Digital Delivery Methods in Complex Infrastructure Projects. 19th IFIP International Conference on Product Lifecycle Management (PLM), Jul 2022, Grenoble, France. pp.262-273, 10.1007/978-3-031-25182-5_26. hal-05420913

HAL Id: hal-05420913

https://inria.hal.science/hal-05420913v1

Submitted on 17 Dec 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Towards a Requirements Co-engineering Improvement Framework: Supporting Digital Delivery Methods in Complex Infrastructure Projects

Yu Chen(✉) and Julie R. Jupp

Faculty of Engineering and IT, University of Technology Sydney, Sydney, Australia
yu.chen-4@student.uts.edu.au

**Abstract.** To support the delivery of cyber-physical systems of complex infrastructure assets, different requirements (e.g., physical system requirements, asset information requirements) must be developed and managed properly during the lifecycle of the assets. However, there is a lack of integrated and continuous approach to support the co-development and co-management of physical systems requirements and asset information requirements. Adopting a design science research methodology, this paper develops the structure of Requirements Co-engineering Improvement Framework for complex infrastructure projects. This framework defines five maturity levels for requirements relevant process, protocol and supporting software tools. Further validation will be conducted using the Delphi Method in future research.

**Keywords:** Requirements co-engineering · Capability maturity · Process · Protocol · Technology

## 1 Introduction

As modern transport infrastructure projects have grown in size and complexity, there has been an increasing need to move away from traditional spreadsheets and find more efficient and reliable methods of managing large volume of requirements. For example, as a part of a linear network, rail transport assets can each be defined as a complex cyber-physical system. Requirements engineering (RE) in the context of the delivery of these projects is increasingly complex. This is particularly true when it comes to ‘mega projects’, where requirements can number in the hundreds of thousands. All of which must be managed and traced across multiple stakeholders, work packages and interfaces in a complex, high-pressure environment where errors, changes and delays can cost millions of dollars.

Different types of requirements about the cyber systems and physical systems of complex infrastructure assets must be developed and managed throughout the planning and delivery phases. Requirement types include, amongst others; high-level capability
requirements defining system architecture capabilities; current and future operational requirements; system-, sub-system-, and unit- level requirements spanning functional, physical and performance-based needs; and business case requirements. To support more strategic approaches to digital asset management, during the planning and acquisition of complex infrastructure projects, asset information requirements describing physical systems, their virtual replicas, and real-time behaviours must also be developed and managed.

Yet, often due to issues related to the scale, complexity, and emergent properties of the cyber-physical systems being developed, the different (and evolving) requirement types of cyber systems and physical systems and corresponding asset information requirements are increasingly difficult for current engineering practices to handle. The digital delivery of complex infrastructure projects increases the need to implement more integrated and continuous approaches to RE that recognised the importance of asset information requirements review processes and verification traceability methods.

Based on the Software Engineering Institute's (SEI's) Capability Maturity Model for Integration (CMMI), this paper develops a Requirements Co-engineering Improvement Framework for complex infrastructure projects. The proposed framework presents an approach for the organisation or project team to understand the current maturity level of requirements management capabilities and a potential pathway for improvement. The paper proceeds in Sects. 2 with an overview of current requirement engineering maturity models. Section 3 describes the design science research methodology, and Sect. 4 presents the development of the Improvement Framework. Section 5 concludes the paper with future research plan to further development and verification of the framework and the limitation of the research.

## 2 Requirements Engineering Maturity Models

The effectiveness level of an organisation to develop quality products or services is directly related to the maturity of their processes [1]. In the context of this research, measuring the maturity level of RE processes offers a solution to organisations who are seeking for RE process improvement. This section investigates the capability of existing capability maturity model, especially the relatively new and up to date RE process maturity models and discusses their applicability in supporting capability measurement of RE in rail infrastructure.

Several RE capability models have been proposed based on Software Process Improvement (SPI) standards and framework such as Software Engineering Institute's (SEI's) old Capability Maturity Model (CMM) and relatively new Capability Maturity Model for integration (CMMI). Existing models supporting RE process maturity assessment include Requirements Capability Maturity Model (RCMM) [2, 3], Market-Driven Requirements Engineering Process Model [4], Requirements Engineering Good Practice Guide [5] and Requirements Engineering Process Maturity Model [6]. However, all these four models arose in software industry and were built based on the retired and unsupported Software-CMM or CMM [7]. Some of them are not completely developed and validated while others are difficult to implement [8, 9].

In this research, Requirements Engineering Process Assessment and Improvement Model (REPAIM) and Capability Maturity Model improved (R-CMMi) are selected for
further review as they are both cited as two of the most popular maturity models [8, 9]. However, REPAIM uses the continuous representation model to describe capability levels of processes, while R-CMMi adopts the staged representation model to define maturity levels, which characterise the organisation's behaviour. These two types of representation models are both defined in the CMMI standard (see Table 1) [10].

<table><caption>**Table 1.** REPAIM and R-CMMi levels in CMMi</caption><thead><tr><th></th><th>REPAIM</th><th>R-CMMi</th></tr></thead><tbody><tr><td>Level</td><td>Capability levels<br>Continuous/Process</td><td>Maturity levels<br>Staged/Organisation</td></tr><tr><td>Level 0</td><td>Incomplete</td><td>–</td></tr><tr><td>Level 1</td><td>Performed</td><td>Initial</td></tr><tr><td>Level 2</td><td>Managed</td><td>Managed</td></tr><tr><td>Level 3</td><td>Defined</td><td>Defined</td></tr><tr><td>Level 4</td><td>–</td><td>Qualitatively managed</td></tr><tr><td>Level 5</td><td>–</td><td>Optimised</td></tr></tbody></table>

In REPAIM, four levels of maturity are defined as incomplete, performed, managed and defined. The REPAIM shows its capability to access RE processes and prioritise their improvement, adapt and complement existing maturity standards and assessment approaches, and adapt to the demands of different organisations [7]. However, there are two identified drawbacks of REPAIM. One of the main drawback is that training is still required by the practitioner in order to understand the model [7]. Another drawback is that it appears to need further examples, templates, and instructions to inform an effective implementation by potential users [7].

Five maturity levels are defined as initial, managed, defined, qualitatively managed and optimised in R-CMMi which shows a high consistency with CMMI standard [9]. The drawback of R-CMMi is similar with REPAIM in terms of validation, implementation issue, training, future work of instructions, examples and templates.

Furthermore, there are important interrelationships between maturity levels and capability levels. These organisational maturity levels are dependent on the capability levels of their processes. To research a certain maturity level, the organisation have to successfully achieve the objective of the targeted process areas to that level [1]. The maturity levels reflect the current status of RE in an organisation or a project, while capability levels provide with an improvement pathway to the higher maturity level. Thus, a combination of these two types of representation model would potentially resolve these issues and is adopted in this research.
# 3 Design Science Research Methodology

A design science research methodology (DSRM) was adopted as this whole research project seeks to extend the boundaries of human and organisational capabilities by creating new and innovative artefacts. Figure 1 adapts the design science research framework of Information System proposed by Hevner et al. [11] and overlays three inherent research cycles – relevance cycle, rigor cycle, and design cycle [12].

<figure><img src="image_3.png" /><figcaption>Fig. 1. Design science research conceptual framework [Adapted from 11]</figcaption></figure>

Figure 1 reflects three main areas of the whole research project including the general knowledge base of the research area, the environment of research problem we are focusing on, and the core design science research activity. The content in each area has been adapted based on the research scope, nature of research problem, industrial context, as well as the availability of resource. The content of this paper focus on the Build and Define activity as highlighted in green in Fig. 1.

The central Design Cycle iterates between core activities of developing the Improvement Framework, its evaluation, and subsequent feedback to refine the framework [12]. Findings drawn from the systematic literature review form ‘Knowledge Base’ and semi-structured interviews form ‘Environment’ foundation of the design. Section 4 of this paper focuses on presenting the development of the structure of Requirements Co-engineering Improvement Framework. In the next stage of this research, survey among a group of experts will be implemented as evaluation methods to test and validate key elements of the framework and their significance with regards to supporting higher levels of integration and model-based approaches to requirements management in complex infrastructure.
# 4 Requirements Co-engineering Improvement Framework

## 4.1 System Requirements and Information Requirements

Different types of requirements about the cyber systems and physical systems in the built environment must be developed and managed throughout the Planning and Acquisition Phases of complex infrastructure projects. Requirement types include, high-level capability requirements defining system architecture capabilities; current and future operational requirements; system-, sub-system-, and unit-level requirements spanning functional, physical and performance-based needs; and business case requirements. To support more strategic approaches to digital asset management, during the Acquisition Phase, asset information requirements describing physical systems, their virtual replicas, and real-time behaviours must also be developed and managed.

Asset information requirements (AIR) is the precise description of the information required to operate and maintain a specific built asset through its lifecycle. The information required in AIR focuses on the as-built state. It defines not only what information is required (content) but also how it should be delivered (form and accepted formats of deliverables). The AIR is a subset of the overall project brief. The processes of delivering the assets and the associated data and information are parallel and connected (see the Fig. 2 below).

<figure><img src="image_4.png" /><figcaption>Fig. 2. Parallel delivery of built asset and asset data [28]</figcaption></figure>

In complex infrastructure projects, especially in rail sector, the development and management of physical system requirements usually follow the process of the traditional systems engineering approach which also be described in the traditional “V” model. In order to understand the co-development and co-management of physical system requirements and AIR, a “Diamond” model (see Fig. 3) has been developed based on Boeing [29] and TfNSW [30]. The lower V reflects the classic systems engineering process of the physical system, while the mirror reflection of the V above represents the digital twins modelling and simulation [29, 30]. The inverted V represents the design and realisation of the behavioural simulations [29].

## 4.2 Contemporary Approaches to Requirements Engineering

Previous work of this research includes a systematic literature review which explored contemporary and state-of-the-art RE approaches to supporting the creation of complex software dependent systems (e.g., digital twins and cyber-physical systems) and
semi-structured interviews with industry experts from transport infrastructure. Main
capabilities supporting RE are identified and categorised into three main aspects includ-
ing process and protocol, technology, organisation and people (as shown in Table 2).
Based on this, the structure of Requirements Co-engineering Improvement Framework
is developed and described in the following section.

<figure><img src="image_5.png" /><figcaption>Fig. 3. “Diamond” model reflecting interaction of physical system requirements and AIR</figcaption></figure>

**4.3 Structure of Improvement Framework**

Main capabilities identified in Table 2 have been developed into 14 requirements co-
engineering sub-capabilities. Figure 4 presents the matrix displaying the score system
for these sub-capabilities in different maturity levels. Once the maturity levels of capabil-
ities are evaluated, a final score of three categories (i.e., process and protocol, technology,
organisation and people) will reflect the status of requirements co-engineering prac-
tices in a project or an organisation. ‘Requirements’ in Fig. 4 refer to physical systems
requirements and asset information requirements.

Activities contained in each capability will be further developed and verified in
the next stage of research which will then support identifying improvement pathway
of requirement co-engineering capability in an organisation or a project. Moreover,
the derivation of a sorting or rating system for all capabilities supports a modular and
flexible approach assessment. A final weighting system is yet to be identified according
to capabilities domains.
<table><caption>**Table 2.** Main capabilities supporting requirements engineering</caption><thead><tr><th>Category</th><th>Main capabilities</th><th>Sources</th></tr></thead><tbody><tr><td rowspan="7">Process & protocol</td><td>Requirements elicitation process</td><td>[13–15]</td></tr><tr><td>Requirements analysis and prioritisation process</td><td>[14, 16, 17]</td></tr><tr><td>Requirements allocation and verification process</td><td>[14, 16]</td></tr><tr><td>Negotiation of conflicting requirements amongst stakeholders</td><td>[14, 15]</td></tr><tr><td>Requirements change management process</td><td>[18–20]</td></tr><tr><td>Requirements validation process</td><td>[18, 21]</td></tr><tr><td>Use a recognised standard to support the definition and specification of requirements</td><td>[15]</td></tr><tr><td rowspan="2">Technology</td><td>Use a dedicated requirements management software supporting requirements documentation, verification, and validation</td><td>[16, 22, 23]</td></tr><tr><td>Integration of requirements management software with 3D modelling software support the handling of Physical system requirements and Asset information requirements</td><td>[19, 24, 25]</td></tr><tr><td rowspan="3">Organisation & people</td><td>Involvement of stakeholders in eliciting and analysing requirements</td><td>[21, 26, 27]</td></tr><tr><td>Formally defined roles and responsibilities for handling requirements in multiple phases of a project</td><td>[19, 21]</td></tr><tr><td>Training in requirements software in support of requirements handling in multiple phases of a project</td><td>[18]</td></tr></tbody></table>

## 4.4 Development of Requirements Co-engineering Maturity Levels

In this research, a combination of REPAIM and R-CMMi maturity levels are adopted for the definition of processes and protocols maturity levels. While the definition of supporting technology maturity levels is concluded based on findings from semi-structured interviews with industry experts. Table 3 presents the description of maturity levels of process and protocol, as well as technology related capabilities supporting requirements co-engineering. Organisation and people related capabilities are relative intangible compared with process and technology. This requires a different way to describe its maturity. For example, the frequency of formally defined roles and responsibilities, and the frequency of trainings. Because of the page limitation, organisation and people related maturity levels will not be included in this paper.
<figure><img src="image_6.png" /><figcaption>Fig. 4. Matrix displaying the scores for 14 capabilities in different maturity levels</figcaption></figure>

<table><caption>Table 3. Description of requirements co-engineering maturity levels</caption><thead><tr><th rowspan="2">Main capabilities</th><th colspan="5">Maturity levels</th></tr><tr><th>Level 1: Incomplete</th><th>Level 2: Performed</th><th>Level 3: Managed</th><th>Level 4: Qualitatively managed</th><th>Level 5: Optimised</th></tr></thead><tbody><tr><th colspan="6">Process & protocol</th></tr><tr><th>Process</th><td>There is no formal process defined or implemented</td><td>An ad hoc process is implemented during project delivery</td><td>An organisational standard that describes a generic process exists</td><td>Level 3 + Process is monitored, and performance is assessed</td><td>Level 4 + Continuous process improvement enabled by performance feedback loop</td></tr><tr><th>Protocol</th><td>There is no standard used to define and specify requirements</td><td>Standards supporting definition and specification of requirements based on individual delivery-side stakeholder approach</td><td>An industry sector-specific standard is used to define and specify requirements</td><td>A standard specified by the Government Agency/Client is used to define and specify requirements)</td><td>International standards are utilised (E.g., ISO Standard used to define and specify requirements)</td></tr></tbody></table>

(continued)
<table><caption>**Table 3.** (continued)</caption><thead><tr><th rowspan="2">Main capabilities</th><th colspan="5">Maturity levels</th></tr><tr><th>Level 1: Incomplete</th><th>Level 2: Performed</th><th>Level 3: Managed</th><th>Level 4: Qualitatively managed</th><th>Level 5: Optimised</th></tr></thead><tbody><tr><td><strong>Technology</strong></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Software tools</td><td>There is no dedicated requirements software tool utilised by project delivery team organisations</td><td>Separate requirements software tools are utilised across the various project delivery team organisations</td><td>An integrated requirements software tool/platform is used by a minority of relevant project delivery team organisations</td><td>An integrated requirements software tool/platform is used by a majority of relevant project delivery team organisations</td><td>Level 4 + Requirements managed by a dedicated project role, e.g., requirements engineer, systems engineer, digital engineer, BIM manager</td></tr><tr><td>Integration of requirements management software and 3D modelling software</td><td>Neither requirements management nor 3D modelling software is used</td><td>Only requirements management software is used but 3D modelling software is not</td><td>Separate and distinct requirements management and 3D modelling software is used, however there are no digital links between them</td><td>There is basic integration enabled between the requirements management and 3D modelling software utilised, e.g., providing spatially enabled requirements mapping, linking requirements with 3D objects, and automating a basic level of spatial requirements verification</td><td>There is a high level of integration enabled between the requirements management and 3D modelling software utilised, supporting the use of configuration management to establish and maintain consistency of system performance, functional, and physical attributes with its requirements, design, and operational information</td></tr></tbody></table>

# 5 Discussion and Future Research

Adopting a design science research methodology, a preliminary requirements co-engineering capability improvement framework is developed. This framework includes
two parts: i) capabilities supporting requirements co-engineering, and ii) maturity levels of capabilities. The main capabilities are developed based on findings from a systematic literature review and semi-structure interview survey with industry experts. They are then categorised into process and protocol, technology, organisation and people. Maturity levels of process and protocols in this research follow the structure of REPAIM and R-CMMi models while technology related maturity levels conclude from semi-structured interview survey.

During our semi-structured interview survey, we identified that there exists a great dependency on a co-engineering approach during the creation of complex and adaptive systems, where “co” requires the project team to work towards the virtual deliverables (e.g., digital twin, or cyber-physical systems) as a common goal [31]. Co-engineering therefore addresses both collaborative and concurrent engineering concepts. The impacts of the implementation of systems and co-engineering approaches can be identified at two levels; the organisation and project relative to the “mind-set” and sharing of the digital twin system objectives and vision. Thus, adopting systems and co-engineering approaches is identified as a key criterion for complex and adaptive systems when the lifetime of the asset extends over several decades [31]. For complex infrastructure projects the co-engineering of information requirements is key to support the delivery of both physical and virtual assets with decades long lifespans.

Thus, the development of this improvement framework is aimed at identifying main capabilities supporting requirements co-engineering and presenting an approach for the organisation or project team to understand the current maturity level of requirements management capabilities and a potential pathway for improvement. Further development and validation of this improvement framework will be conducted using the Delphi Method through an expert panel consisting of experienced practitioners and researchers in the area of complex infrastructure, systems engineering and requirements engineering.

**Acknowledgement.** This research is supported by an Australian Government Research Training Program scholarship.

## References

1. Ramos, V.S.S.A.: A CMMI-compliant requirements management and development process. Ph.D. thesis (2014)

2. Beecham, S., Hall, T., Rainer, A.: Building a requirements process improvement model. 20 (2003)

3. Beecham, S., Hall, T., Rainer, A.: Defining a requirements process improvement model. Softw. Qual. J. 13, 247–279 (2005). https://doi.org/10.1007/s11219-005-1752-9

4. Pettersson, F., Ivarsson, M., Gorschek, T., Öhman, P.: A practitioner’s guide to light weight software process assessment and improvement planning. J. Syst. Softw. 81, 972–995 (2008)

5. Sommerville, I., Sawyer, P.: Requirements Engineering: A Good Practice Guide. Wiley, Hoboken (1997)

6. Gorschek, T., Tejle, K.: A method for assessing requirements engineering process maturity in software projects (2002)

7. Solemon, B., Sahibuddin, S., Ghani, A.A.A.: A new maturity model for requirements engineering process: an overview (2012)
8. Rana, M.E., Dauren, J., Kumaran, S.: An improved requirements engineering framework for cloud based application development. In: 2015 IEEE Student Conference on Research and Development (SCOReD), pp. 702–709 (2015)

9. Solemon, B., Shahibuddin, S., Ghani, A.A.A.: Re-defining the requirements engineering process improvement model. In: 2009 16th Asia-Pacific Software Engineering Conference, pp. 87–92. IEEE, Batu Ferringhi (2009)

10. Software Engineering Institute (2010) CMMI for Development, Version 1.3

11. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in information systems research. MIS Q. 28, 75–105 (2004)

12. Hevner, A.R.: A three cycle view of design science research. Scand. J. Inf. Syst. 19, 87–92 (2007)

13. Johnson, A., Heaton, J., Yule, S., et al.: Informing the information requirements of a digital twin: a rail industry case study. Proc. Inst. Civ. Eng. - Smart Infrastru. Constr. 174, 1–13 (2021)

14. Heaton, J., Parlikad, A.K., Schooling, J.: A building information modelling approach to the alignment of organisational objectives to asset information requirements. Autom. Constr. 104, 14–26 (2019)

15. Cavka, H.B., Staub-French, S., Poirier, E.A.: Developing owner information requirements for BIM-enabled project delivery and asset management. Autom. Constr. 83, 169–183 (2017)

16. Baldauf, J.P., Formoso, C.T., Tzortzopoulos, P., et al.: Using building information modelling to manage client requirements in social housing projects. Sustainability 12, 2804 (2020)

17. Nekvi, M.R.I., Madhavji, N.H.: Impediments to regulatory compliance of requirements in contractual systems engineering projects: a case study. ACM Trans. Manage. Inf. Syst. 5, 15:1–15:35 (2014)

18. Ramos, C.: Requirements management-how 110,000 requirements are managed on northwest rapid transit. In: CORE 2018: Conference on Railway Excellence. Railway Technical Society of Australasia (RTSA) (2018)

19. Jallow, A.K., Demian, P., Anumba, C.J., Baldwin, A.N.: An enterprise architecture framework for electronic requirements information management. Int. J. Inf. Manage. 37, 455–472 (2017)

20. Koltun, G.D., Feldmann, S., Schütz, D., Vogel-Heuser, B.: Model-document coupling in aPS engineering: challenges and requirements engineering use case. In: 2017 IEEE International Conference on Industrial Technology (ICIT), pp. 1177–1182. IEEE (2017)

21. Arnaut, B.M., Ferrari, D.B., Souza M.L.D.O.: A requirements engineering and management process in concept phase of complex systems. In: 2016 IEEE International Symposium on Systems Engineering (ISSE), pp. 1–6 (2016)

22. Gebru, H.M., Staub-French, S.: Leveraging data to visualize and assess space planning compliance (2019)

23. Junior, J.S., Baldauf, J.P., Tzortzopoulos, P., et al.: The role of building information modelling on assessing healthcare design. In: CIB World Building Congress 2019: Constructing Smart Cities. International Council for Research and Innovation in Building and Construction, pp. 1659–1672 (2019)

24. Arayici, Y., Fernando, T., Munoz, V., Bassanino, M.: Interoperability specification development for integrated BIM use in performance based design. Autom. Constr. 85, 167–181 (2018)

25. Fucci, D., Palomares, C., Franch, X., et al.: Needs and challenges for a platform to support large-scale requirements engineering: a multiple-case study. In: Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, pp. 1–10. ACM, Oulu (2018)

26. Jupp, J., Awad, R.: BIM-FM and information requirements management: missing links in the AEC and FM interface. In: Ríos, J., Bernard, A., Bouras, A., Foufou, S. (eds.) PLM 2017.
IAICT, vol. 517, pp. 311–323. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-72905-3_28

27. Navendren, D., Mahdjoubi, L., Shelbourn, M., Mason, J.: An examination of clients and project teams developing information requirements for the asset information model (AIM). Build. Inf. Modell. (BIM) Design Constr. Oper. **149**, 169 (2015)

28. NATSPEC BIM - ABAB AIR Guide. https://bim.natspec.org/documents/abab-air-guide. Accessed 19 Mar 2022

29. Hatakeyama, J., Seal, D., Farr, D., Haase, S.: An alternate view of the systems engineering “V” in a model-based engineering environment. American Institute of Aeronautics and Astronautics, Orlando, FL (2018)

30. TfNSW: T MU AM 06006 ST Systems Engineering (2017)

31. Chen, Y., Jupp, J.R.: Challenges to asset information requirements development supporting digital twin creation. In: Canciglieri Junior, O., Noël, F., Rivest, L., Bouras, A. (eds.) PLM 2021. FIP Advances in Information and Communication Technology, vol. 639, pp. 474–491. Springer, Cham (2022). https://doi.org/10.1007/978-3-030-94335-6_34