Andrey Sadovykh
email: andrey.sadovykh@softeam.fr

Bilal Said
email: bilal.said@softeam.fr

Dragos Truscan
email: dragos.truscan@abo.fi

Hugo Bruneliere
email: hugo.bruneliere@imt-atlantique.fr

An Iterative Approach for Model-based Requirements Engineering in Large Collaborative

Keywords: Requirements Engineering, Model-based Engineering, Collaborative Projects, Experience Report

HAL is

Introduction

In many European countries, collaborative projects involving academic and industrial partners are a preferential way of implementing ambitious Research and Innovation Actions (RIAs) [START_REF] Van Noorden | Science in europe: by the numbers[END_REF][START_REF]Digital economy and society index (DESI) 2020 -the EU ICT sector and its R&D performance[END_REF]. They also foster international collaborations and develop long-term partnerships between organizations from various countries. For example, the European Commission has several funding agencies (ECSEL, Horizon, ITEA, etc.) with various programs targeting different societal, economic, and scientific grand challenges [START_REF]EU research programmes[END_REF]. As a result, collaborative projects are one of the primary sources of innovation in Europe [START_REF]Digital economy and society index (DESI) 2020 -the EU ICT sector and its R&D performance[END_REF]. The average number of involved organizations goes from 4.69 in Horizon 2020 [START_REF]Accelopment, Lessons learnt from horizon 2020 for its final 2 years[END_REF] to 30 and 40 in ECSEL (now KDT) projects [START_REF]Ecsel joint undertaking work plan[END_REF], even exceeding 100 organizations in some large ECSEL/KDT projects [START_REF]Productive4.0 project[END_REF].

A key element of such European research projects is the heterogeneity and complementarity of the project's participants. The participating organizations can come from different application domains (e.g., railway, avionics, telecommunications, manufacturing), have different sizes (e.g., from small and medium enterprises to large industrial groups), have various maturity levels, or come with different kinds of research backgrounds. They must work together to achieve a set of shared R&D goals, usually validated via several case studies that typically serve as a common sandbox for experimenting on newly designed and developed technologies. The objective is to provide evidence to the European Commission and the European community of the benefits and drawbacks, both scientific and economical, that the developed innovative technologies can offer.

In most cases, such collaborative research projects are driven by the needs of the industry. Therefore, the entire project activity is focused on identifying those needs and providing corresponding technologies to address them. However, the diversity and number of partners [START_REF] Gürses | Requirements engineering within a large-scale security-oriented research project: lessons learned[END_REF] amplify challenges related to 1) the elicitation of the needs from the industrial case study providers and 2) the identification of concrete solutions to be provided during the project (lasting typically three years or more), and 3) the creation of a roadmap for the development of these solutions. When such challenges are not addressed properly, they can negatively influence the outcomes of the project [START_REF] Nepelski | Organizational diversity and innovation potential of EU-funded research projects[END_REF].

The main expected results in the Software and Systems Engineering area projects are generally large and complex integrated frameworks or tool sets. To allow for their actual design, development, and deployment, it is thus fundamental to support and manage as efficiently as possible the corresponding Requirements Engineering processes [START_REF]IEEE/ISO/IEC, International standard -systems and software engineering -life cycle processes -requirements engineering[END_REF].

Requirements Engineering (RE) is the process of identifying, describing, using, and maintaining requirements within engineering processes [START_REF]IEEE/ISO/IEC, International standard -systems and software engineering -life cycle processes -requirements engineering[END_REF][START_REF] Dick | Requirements Engineering[END_REF]. There is a widely accepted consensus on the main steps of RE processes [START_REF] Pohl | Requirements Engineering -Fundamentals, Principles, and Techniques[END_REF][START_REF] Van Lamsweerde | Requirements Engineering: From System Goals to UML Models to Software[END_REF]: 1) requirements elicitation, 2) requirements analysis, 3) requirements specification, and 4) requirements validation. Requirement management is a transverse activity covering all these steps and ensuring their smooth execution. Even if requirements have been used for a long time in different disciplines, the RE advent mostly coincides with the software expansion in the 90s [START_REF] Kotonya | Requirements Engineering: Processes and Techniques[END_REF]. This resulted in the progressive growth of an active research community [START_REF] Nuseibeh | Requirements Engineering: a Roadmap[END_REF][START_REF] Cheng | Research directions in requirements engineering[END_REF].

In large collaborative projects, the first major challenge #1 is the elicitation, analysis, and specification of the requirements supporting the needs of the industrial case study providers, i.e., the case study requirements. This is not trivial since it requires the collaboration of all the partners, each having different application domains and technical backgrounds. Thus, having a centralized and accurately described mapping between case study requirements, on the one hand, and the framework and tool components requirements, on the other hand, can allow the technical coordination team of the project to better track the progress of the case studies development, spot further needs for technical solutions, and mitigate the risks. The second major challenge #2 is to validate the requirements and create a roadmap for framework development by collecting, in addition to the previously gathered information, the development plans for individual tool components. This allows all partners to be aware of when different features of the framework will be implemented. This way, case study providers know when these tools can be evaluated against their case studies. In addition, having such a roadmap allows the technical coordination team to plan better and produce the different deliverables, demonstrations, and management or dissemination events. Appropriate RE approaches and tools are needed to address these two major challenges to maximize the benefits and achieve good technical results.

In this article, we propose a solution that combines Model-based Requirements Engineering (MBRE) with iterative project management practices to improve the support for large and diverse collaborative projects. Our main contributions are the following:

1. A MBRE approach for collaborative projects supporting the different stakeholders' activities in the project concerning both functional and non-functional requirements as well as data requirements;

2. An underlying iterative RE process with microtasks for improving both the collaborative collection of requirements (challenge #1) and their further analysis and exploitation (challenge #2);

3. A dedicated modeling language for RE, implemented in Modelio tool [START_REF]Modelio: A Collaborative Business or Software Modeling Platform[END_REF] and allowing to realize the proposed approach and process in practice;

4. An evaluation of the approach and process via quantitative and qualitative data from the large collaborative projects where the solution was applied;

5. A discussion on the main lessons learned and corresponding identified challenges as far as MBRE and, more generally, RE are concerned.

From an industrial perspective, the proposed solution is rooted in acknowledged software and system modeling standards such as UML [START_REF]OMG Unified Modeling Language[END_REF] and SysML [START_REF]OMG Systems Modeling Language (SysML)[END_REF] to foster genericity, reusability, and interoperability, as well as by the recommendations of using iterative development in model-driven engineering practices [START_REF] Hutchinson | Model-driven engineering practices in industry: Social, organizational and managerial factors that lead to success or failure[END_REF][START_REF] Leffingwell | Agile software requirements: lean requirements practices for teams, programs, and the enterprise[END_REF]. The solution is also inspired by the microtask programming concept used in the context of software engineering crowd-sourcing. Finally, it is also partially inspired by the European Space Agency standard terminology and structure for RE documents [START_REF]European Cooperation for Space Standardization[END_REF].

The solution was incrementally designed, developed, refined, and applied in five large European projects over more than seven years: H2020 DataBio1 2017-2019 [START_REF] Sadovykh | Archimate as a specification language for big data applications -databio example[END_REF], ITEA3 REVaMP22 2016-2019 [START_REF] Sadovykh | Revamp2 project: Towards round-trip engineering of software product lines -approach, intermediate results and challenges[END_REF], ECSEL MegaM@Rt23 2017-2020 [START_REF] Afzal | The MegaM@Rt2 ECSEL project: Meg-aModelling at runtime -scalable model-based framework for continuous development and runtime validation of complex systems[END_REF], H2020 VeriDevOps4 2020-2023 [START_REF] Sadovykh | Veridevops: Automated protection and prevention to meet security requirements in devops[END_REF], and ECSEL AIDOaRt5 2021-2024 [START_REF] Bruneliere | Aidoart: Ai-augmented automation for devops, a model-based framework for continuous development in cyber-physical systems[END_REF], providing various complex software solutions (frameworks, integrated tool sets, etc.). However, we have already faced similar challenges in coordinating RE processes and developments in more than fifteen similar European collaborative research projects.

An initial version of our solution was published a couple of years ago [START_REF] Sadovykh | Applying Model-based Requirements Engineering in Three Large European Collaborative Projects: An Experience Report[END_REF]. Since then, we significantly extended it with the concept of microtasks for a facilitated iterative collaboration and more uniformity in the produced requirements. We also added the modeling of requirements on training and validation data sets and obtained improved evaluation results based on new data collected from recent projects. Overall, we intend to show that modeling in a RE context can bring interesting benefits in terms of :

• scalability, e.g., a large number of handled requirements,

• heterogeneity, e.g., partners with different profiles and types of RE background,

• adaptability and extensibility, e.g., new project configurations or produced artifacts,

• traceability, e.g., from the initial requirements to the software components,

• automation, e.g., requirement documentation generation,

• consistency and quality, e.g., of the requirements and their metadata,

• as well as general usefulness and usability from the project partners' perspective.

This article is structured as follows. Section 2 introduces the current state of the art related to MBRE, particularly for large collaborative projects. Section 3 describes the MBRE solution we propose. Section 4 evaluates this solution and demonstrates its practical application in the context of five large European collaborative projects. Section 5 discusses the lessons learned and open challenges we identified during this long-term experience. Finally, Section 6 concludes the paper.

State of the art

The related literature is rich concerning RE approaches and corresponding technical solutions [START_REF] Cheng | Research directions in requirements engineering[END_REF]. In the following, we will revisit works that are closer to our approach from different points of view.

Requirements elicitation and specification for collabo-

rative projects Tool-supported requirement management approaches for projects and teams have been traditionally developed using communication systems (e.g., wikis and online forums) to increase collaboration between heterogeneous participants. For instance, this is the case of a wiki-based approach for eliciting and consolidating requirements in a relatively small-sized European project [START_REF] De Angelis | Collaborative requirements elicitation in a european research project[END_REF][START_REF] De Angelis | Requirements elicitation and refinement in collaborative research projects[END_REF]. The approach focuses on improving requirements' quality by combining online tools and physical meetings. Notably, using a wiki to collect requirements intends to reduce the communication barrier among project partners while allowing a certain level of requirements versioning and tracking. However, the authors do not mention how the requirements are used and maintained later during the project.

The authors of [START_REF] Lopes | A collaborative platform for better managing technical documentation: An analysis from a requirements engineering perspective[END_REF] propose a web-based tool for managing requirements specifications collaboratively. The main focus is providing access control roles, templates, and variability modeling of requirements. Even though the concepts of the approach are defined using a domain-specific language, the tool is implemented using Google Drive and its APIs. Architecture identification and requirements validation road mapping are not addressed.

Requirements modeling approaches

Modeling has often been essential in the RE process [START_REF] Van Lamsweerde | Requirements engineering in the year 00: a research perspective[END_REF]. Thus, model-based principles and techniques have already been applied to address different RE activities [START_REF] Assar | Model driven requirements engineering: Mapping the field and beyond[END_REF]. Indeed, providing relevant abstraction, genericity, or reusability capabilities (among others) has become more prevalent in the industry over the last two decades [START_REF] Brambilla | Model-Driven software engineering in practice[END_REF]. From a RE perspective, this resulted in acknowledged contributions such as goal modeling languages [START_REF] Yu | Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering[END_REF][START_REF] Van Lamsweerde | Goal-Oriented Requirements Engineering: A Guided Tour[END_REF] or the ReqIF requirement modeling standard [START_REF]Object Management Group (OMG), Requirements Interchange Format (ReqIF)[END_REF]. However, few proposed model-based approaches partially cover RE processes. To the best of our knowledge, none of them allows systematically addressing complete RE processes in the general case.

For example, an existing solution relies on a generic modeling framework to represent and simulate requirements independently from their context [START_REF] Baudry | Model-driven engineering for requirements analysis[END_REF]. Another solution is based on a customized core requirements metamodel to support various RE processes [START_REF] Goknil | A metamodeling approach for reasoning about requirements[END_REF]. We can also mention transformation-based approaches from goals models to design models, such as the KAOS method [START_REF] Letier | Deriving eventbased transition systems from goal-oriented requirements models[END_REF]. Furthermore, [START_REF] Konaté | Collaborative requirements elicitation: A process-centred approach[END_REF] provides a collaborative requirement elicitation process based on the EIA-632 standard. The approach uses UML object diagrams to model the requirements, while tool support is provided as a web application SPECJ. However, these approaches only target the requirements elicitation phase. Other approaches have been deployed only in single projects [START_REF] Karg | Model-driven software engineering in the openetcs project: Project experiences and lessons learned[END_REF] or primarily focused on some particular RE aspects, such as requirements visualization, for instance [START_REF] Solheim | Model-driven visual requirements engineering[END_REF].

Model-based collaborative approaches

Closer to our context and objective, a few model-based approaches have been proposed and used in the context of collaborative research projects to handle, at least partially, the corresponding RE processes.

For instance, Nielsen et al. [START_REF] Nielsen | Requirement engineering for a small project with pre-specified scope[END_REF] proposed a RE process for small EU-funded projects. They offered to have each case study provider paired with an academic partner to assist the former in eliciting and specifying the requirements. This can be very challenging in the context of large projects with many partners, potentially leading to incomplete resulting requirements.

Another work introduced a visual modeling notation to help project managers proactively plan the collaboration infrastructures needed to support requirements-related activities in distributed projects [START_REF] Laurent | Requirements-gathering collaborative networks in distributed software projects[END_REF][START_REF] Laurent | Evaluating the effectiveness of a collaborative requirements engineering modeling notation for planning globally distributed projects[END_REF]. The underlying metamodel allows one to model site locations, stakeholder roles, communication flows, critical documents, supporting tools, and repositories. However, the communication process between stakeholders is not clearly defined. Furthermore, it is not clearly explained how the business requirements analysis from multiple locations, stakeholders, domains, and products should be instrumented. The approach uses a model-based approach, is collaborative, and can be customized based on the specific needs of different projects. However, it does not target architecture identification or projects with heterogeneous partners.

In a different work, lessons learned from a large-scale research project are discussed, and various elicitation, traceability, and gap analysis techniques are identified [START_REF] Gürses | Requirements engineering within a large-scale security-oriented research project: lessons learned[END_REF]. They partially use model-based techniques for elicitation and analysis as well as for identifying the framework architecture. However, the authors did not apply this method to support traceability. Nevertheless, they also defined metrics-based validation criteria for requirements. The authors used a wiki system to manage the requirements collaboratively. They thus had to develop a dedicated tool to detect inconsistencies and perform gap analysis using a visualization toolchain based on GraphViz to better explore their requirements database with generated viewpoints such as graphs and diagrams.

A more recent work presents an empirical study using requirements modeling in large-scale agile development [START_REF] Liebel | Aspects of modelling requirements in very-large agile systems engineering[END_REF][START_REF] Kasauli | Requirements engineering challenges and practices in large-scale agile system development[END_REF]. It notably introduces a set of interesting conclusions, challenges, and needs. Among them, the authors highlighted that "requirements models are useful and valuable" but creating and maintaining requirements models with high quality is challenging. They also mentioned that it was difficult to model collaboratively with existing technologies and that, many times, requirements models have to coexist with textual representations to provide better access and understanding. Therefore, their main suggestions for improvement are that 1) models should contain enough information to satisfy the needs of different stakeholders, 2) there should be means for the automated generation of artifacts from models depending on stakeholder needs, and 3) it is important, in general, to support the heterogeneity of the agile teams. These observations align with our long-term experience and the two main challenges we intend to address with our proposed solution. Furthermore, they support their approach with a homemade RE tool called T-Reqs [START_REF] Knauss | T-reqs: Tool support for managing requirements in large-scale agile system development[END_REF]. It is a text-based Git-powered tool that allows for collaborative requirements management and offers several requirements modeling features intended to address RE challenges faced in large, collaborative, and agile projects. It also allows keeping the requirements close to the code base when hosted on the same Git repository. However, they highlight the tool's limitations in capturing complex requirements modeling aspects, namely in supporting traceability [START_REF] Liebel | Aspects of modelling requirements in very-large agile systems engineering[END_REF].

Framework identification

Another work [START_REF] Koukias | Approach on analysis of heterogeneous requirements in software engineering[END_REF] focuses on identifying the framework architecture in a European project with heterogeneous requirements. The approach provides a set of steps to find commonalities in the requirements and to extract common requirements and the architecture components. However, the proposed approach is not model-based, tool support is not discussed, and the links between the overall architecture and the tools developed by technology providers are missing. Consequently, this makes gap analysis and road mapping more challenging to perform.

The authors of [START_REF] Hesse | Supporting the collaborative development of requirements and architecture documentation[END_REF] propose a model-based approach for supporting requirements and architecture documentation. Their process is iterative, enabling collaboration and bridging the terminology gap between requirements engineers and system architects. However, the approach is primarily targeted at documenting design decisions, and it is not intended explicitly for large-scale collaborative projects.

Iterative requirements modeling with microtasks

The microtasks-based approach proposed in this article has been influenced by microtask programming [START_REF] Latoza | Microtask programming[END_REF]. In there, the software development tasks are broken down into smaller tasks that can be distributed to different development teams or individual developers to provide easyto-follow decontextualized assignments, decrease joining barriers, and optimize the effort of allocating developers to multiple projects.

Microtask programming has been applied in the past in the context of behavioral-driven crowd-sourcing projects [START_REF] Saito | Can microtask programming work in industry?[END_REF], which yielded fewer programming errors in the resulting code. However, to the best of our knowledge, the idea has not been applied to requirements engineering activities in large-scale collaborative European projects.

Summary

While reviewing the state-of-the-art and related work, we observed several challenges. The presented processes are generic and lack clarity on how to implement them effectively in real settings. One major issue is the absence of a solution for involving heterogeneous partners in the modeling work, organizing their contributions, and integrating the results. Additionally, there is a scarcity of experience-based reports that provide concrete guidelines for a process implemented, tested, and validated in several projects. Moreover, the presented solutions often heavily depend on specific tools, making them less adaptable. Furthermore, many MBRE solutions lack scalability, both in terms of tooling and organizing large teams.

Proposed Solution

Our Model-Based Requirements Engineering (MBRE) solution comprises a comprehensive overall approach, a related process, and a dedicated modeling language, all associated with tooling support. In this section, we describe the solution while emphasizing the novelty compared to the initial published version [START_REF] Sadovykh | Applying Model-based Requirements Engineering in Three Large European Collaborative Projects: An Experience Report[END_REF]. This latest version integrates several improvements in terms of iterations toward the project's milestones (cf. Section 3.1). In addition, we describe the accompanying MBRE process that now relies on the use of microtasks (cf. Section 3.2). Then, we present our related MBRE language that now also captures additional important aspects such as data requirements (cf. Section 3.3). Finally, we present the updated implementation and related tooling supporting our overall MBRE solution (c.f. Section 3.4).

An Iterative Model-based Approach for RE

Our MBRE approach is defined to take into account the roles and activities of typical project participants in large collaborative research projects involving both academic and industrial partners. From our long-term experience in many projects of this type, both at the national level in each of our respective countries and at the international level (e.g., in Europe), we have been able to observe a common project participants: Case Study Providers bring a practical problem, e.g., in terms of development processes, product quality, or features, for which they are looking for innovative solutions; Research Partners develop new methods and prototypes and Technology Providers offer technological solutions that can be deployed and evaluated against the industrial case studies in collaboration with the research partners. It is then the task of a Technical Coordination Team to ensure a smooth collaboration between the involved parties, as well as the global achievement of the project's goals. Of course, there are different kinds of projects, and the participants' roles may vary. For example, the same entity can sometimes be both a Research Partner and a Technology Provider, or a Case Study Provider can also become a customer of a Technology Provider. However, we believe that the proposed categories of partners are adapted to cover most of the large collaborative research projects we target.

As shown in Figure 1, our approach proposes that the technological solutions are provided in the form of a generic framework, which is the main artifact being developed throughout the project and produced by its participants. The framework is created following the traditional phases of the software development life cycle (SDLC), as follows:

Requirements Engineering. The framework requirements are elicited from industrial case study requirements, whereas Research and Technology Providers derive Tool Component Requirements for their individual tools to satisfy case study requirements. Furthermore, in this phase, requirements for validation data sets are identified depending on the specifics of the case studies. For example, a telecom company that manufactures routers with proprietary firmware may be interested in validating their case study by performing system failures root-cause analysis on real-time logs generated by the routers when put in production environments. Similarly, a research and technology provider working on critical systems verification may provide proof obligations data sets to be mined by other partners to help in developing ML-based proof assistants.

Architecture Definition and Roadmap. The framework aggregates Tool Components specific to different application domains and applicable to one or several case studies. Each tool component has a specific architecture, including the interfaces for interconnection with other tools. This notably allows different toolchains to be easily created for particular case studies. Each tool component is developed with different priorities and becomes available at different milestones from the Tool Component Roadmap.

Based on the individual tool component architectures and roadmaps, the technical coordination team designs the Framework Architecture and the Framework Development Roadmap. This roadmap allows the case study providers to know when different technologies will be available for evaluation and consequently to define Case Study Requirements Validation KPIs and Roadmaps.

Framework Development and Validation. Re-search and technology providers develop their individual tools as Tool Component Implementations. At the same time, necessary data sets are collected for validating the component implementations. When the latter become available at different project milestones, they are integrated into the framework and evaluated against the case studies. After each evaluation phase, feedback is collected and provided to relevant parties. In addition, incremental versions of the framework are released.

A Dedicated Process for RE based on Microtasks

The general MBRE approach in Fig. 1 is applied continuously during the implementation of the project. In each iteration, the Technical Coordination Team analyzes the project's schedule and deliverables and defines microtasks for the next working period. A given microtask consists of adding new model elements and may correspond to one or more steps in the MBRE approach (Fig. 2). For example, one microtask may consist of collecting data requirements and mapping them to the various use case scenarios. Another microtask could be defined to collect additional info about the proposed solutions licenses, URLs, and expected delivery dates.

Following the process described in Fig. 2 the microtasks are specified in detail via a set of Modeling Guidelines and communicated and explained to partners during regular project meetings. In addition, the Technical Coordination Team will perform necessary updates to the shared Model, by adding, for instance, new model element types and containers as placeholders for the work and initiating a template for the deliverable.

Subsequently, all three categories of partners will collaboratively update the model according to their specific guidelines. At any moment, any of the partners may choose to generate an intermediate version of the deliverable containing all the information available in the model needed for that deliverable to check the status and completeness of the information. If more updates are needed, they will be added to the model. When all partners have finalized their contribution to the model, the Technical Coordination Team will check that all requested information is present in the model. In case more information is needed, partners are asked for more contributions. Also, if the deliverable requires further updates, microtask modeling guidelines, and the model are updated to accommodate the new information, and the process is restarted.

This workflow enables an iterative application of our MBRE approach. Its key advantage is the continuous integration of content from the partners in the requirements model, which is considered the single source of truth for providing coherent and up-to-date content to all the project's deliverables. The incremental metamodel extension allows adaptation according to changes in the project's initial objectives and plan, as well as its dynamic progress while meeting the deliverable deadlines. Furthermore, this iterative application through smaller microtasks allowed for a smoother learning curve of the approach, model, and tool by all the involved partners. This notably includes those who were unfamiliar at first with our MBRE approach or even with modeling in general.

An Enriched Modeling Language for RE

To realize the proposed conceptual approach and to represent and share appropriately the requirements during the full RE process, we developed a dedicated modeling language for RE. The reason for developing a dedicated language, rather than directly using an existing one, is that the commonly used modeling languages, e.g., general-purpose ones, are very broad in scope. Thus, users tend to have diverse ways of specifying requirements by applying a variety of design decisions that are difficult to unify. This is an issue in our context of large collaborative projects involving partners with different backgrounds and expertise.

Thus, we decided to design and build our modeling language by following a bottom-up approach: we started by analyzing which documents (i.e., deliverables) were generally needed in terms of both requirements and architecture in large collaborative projects. To this end, we studied standard representation formats such as ESA ESS [START_REF]European Cooperation for Space Standardization[END_REF] and standard modeling languages such as UML [START_REF]OMG Unified Modeling Language[END_REF], SysML [START_REF]OMG Systems Modeling Language (SysML)[END_REF]. Then, inspired by them, we designed a generic modeling language that would help in supporting and simplifying the automated generation of these documents/deliverables. This language was designed and evolved based on the needs of our requirements engineering processes. However, the language also went through tailoring and customization depending on the project in which we used it. Overall, the objective of the language is to allow the project participants to elicit, specify, and then share both the requirements and the details of corresponding architectural elements involved in our approach (cf. Section 3.1).

Fig. 3 shows the current version of the metamodel of our RE modeling language. There are different types of requirements, i.e., ToolRequirement, FrameworkRequirement,Ca-seStudyRequirement, and DataRequirement. We generalize all types of requirements into a generic Requirement element. A CaseStudyRequirement can also be classified w.r.t. five main DevOps activities (i.e., requirements engineering, modeling, coding, testing, and monitoring) for better requirements understanding, monitoring, and valida- tion. To be able to manage large numbers of requirements, a RequirementsContainer can be used for grouping them.

On the framework side, the main element is the Archi-tecturalElement from which architectural Components are derived to describe the tools implemented in the project (i.e., ToolComponents and the FrameworkComponents they support). Each component will provide an Interface and can consist of several SubComponents. The Package is defined to organize and group Components, deployment Nodes, and Interfaces. This grouping can be done based, for instance, on the case study or the purpose of the architectural element (e.g., design, testing, monitoring, etc.). An ArchitecturalElement may satisfy one or more Requirement elements. This allows the project partners to specify which tool components may fulfill a framework, tool, or case study requirement and which data models are associated with which data requirements. A more detailed example of the use case and tool requirements is provided in Section 3.4.3.

Compared to the initial version of the language [START_REF] Sadovykh | Applying Model-based Requirements Engineering in Three Large European Collaborative Projects: An Experience Report[END_REF], the newly added concepts notably cover data-and DevOpsrelated aspects. Due to the crucial role of data in large collaborative projects, we now capture DataRequirements for each case study as well as the DataModel(s) considered for handling the related data (i.e., data metamodels/languages). Moreover, we also capture to which DevOps-Phases (i.e., the main engineering activities) the case study requirements relate. This allows for a more precise classification of the case study requirements and, thus, a finergrained matching with corresponding technical solutions (challenge #1). Overall, such a more refined matching allows us to better characterize both existing and potential collaborations between case study and solution providers. It also facilitates a more detailed validation of the requirements by the case study providers and the provisioning of more complete feedback to the solution provider (challenge #2).

Current Implementation in Modelio

The MBRE solution presented in this paper may be possibly implemented by relying on different modeling tools. However, for integration purposes, we chose to implement them in the single Modelio tool [START_REF]Modelio: A Collaborative Business or Software Modeling Platform[END_REF] developed by SOFT-EAM -one of the core partners of the projects mentioned in this paper. This allowed us to benefit from extensive support during the design, development, deployment, and progressive evolution of our global MBRE solution.

In particular, our concepts map to the UML and SysML metaclasses as depicted in Table 1.

To illustrate, Fig. 4 shows an example project structure in Modelio using the previous version of the metamodel. For the Requirements level, we directly benefited from Modelio Analyst features such as tabular and diagram view, traceability matrices, and automated import from Excel. For the Architecture level, we relied on the standard implementation of UML as currently available in Modelio. We refined this UML implementation to limit the use of UML to the concepts considered in our RE language. Moreover, to facilitate the initial use of the RE language, we have also built a specific template for tool components and made it available directly from the Modelio workbench. This To complement this, Fig. 5 shows the structure of the enriched RE model in Modelio, as instantiated and tailored for the AIDOaRt project. We can observe that the model is richer in terms of requirements modeling as it now includes both CaseStudyRequirements and DataRequirements. Furthermore, the Case Studies container holds the high-level description of each case study, while Case Stories and Use Case Scenario containers list more detailed descriptions of the aims of each case study from an end-user point of view. These model elements were added in AIDOaRt as instances of CaseStudyRequirement to allow the case study providers to gradually elicit their needs. Thus, case study providers can start from a high-level textual description and end up with a structured list of atomic and functional Use Case Requirements as well as Use Case Data Requirements. Finally, the fulfillment of all these requirements can be evaluated towards the end of the project with measurable KPIs. Note that these KPIs are also modeled, but we do not present them in this article for the sake of simplicity.

This last version of our model also adds new elements to the framework architecture. For example, the framework is defined in the AIDOaRt Framework package as a set of components and functional interfaces that aim to fulfill the case study requirements. These requirements are implemented by various research and industrial solutions specified in the Solutions package. For each solution, the list of capabilities can be specified in terms of operations, with input/output data defined in the Library package. Finally, the Data Models and Metamodels package contains the specification of the data models specified and listed in various case studies and solution data requirements (NB: when the data is a set of models, to be mined with AI/ML techniques, the data model is then a metamodel).

In addition, the model contains a Documentation package holding the various document generation templates grouped by project milestone (M9, M12, etc.). These templates are used to automatically generate the project's Deliverables based on the latest model content that is collaboratively and continuously updated by the project's participants (cf. Section 3.4.1).

The model repository system named Constellation [START_REF] Desfray | Model repositories at the enterprises and systems scale: The Modelio Constellation solution[END_REF], offered by Modelio SaaS6 , allows collaborative and concurrent model editing by all partners. It preserves the model change history throughout the whole project. This allows us to revert unwanted accidental changes, as well as to navigate back to a particular version related to a given milestone or a specific deliverable.

The Constellation employs Subversion as its model repository (Fig. 6). The model is divided into atomic fragments, facilitating concurrent modifications even at a fine granularity. The Subversion server is configured and managed by an Administration server, which handles all aspects related to modeling projects. This includes setting up Users, Roles, and their access rights based on specific Domains, Project levels, or a specific Model repository. Each project can rely on a set of modules, document generation templates, and read-only model libraries for configuration management. The User's local environment is configured through synchronization with the Administration server. In particular, our MBRE solution leverages pre-configured SysML and DocPublisher modules, along with a set of custom-made document generation templates. All these customizations are delivered to the local user's environment upon connection. We deliberately avoided creating specific UML Profiles or custom diagrams to ensure that we could rely on commonly known standard UML modeling techniques.

In addition to that, we created dedicated model containers for each partner (Fig. 7). Thus, team members of a given organization can freely edit the model elements related to their case study or solution in isolation without altering other partners' content. Model containers can be edited separately by several partners in parallel to maximize the concurrent access and update the model in a shorter time (particularly close to a tight deliverable deadline) while minimizing the conflicts. Furthermore, we enforced the approach of locking model elements before editing them. This eliminates the possibility that two members of the same partner's organization simultaneously edit the same model element.

We have deliberately minimized the common parts of the model that partners may edit. This includes the standard interfaces between the tools, such as XMI files, and deployment platforms, such as Java runtime. Those parts are typically defined only once in a specific package. Afterward, the individual model container will only reference (like "expose" or "use") those common model elements. These operations do not require any changes in the common model. In addition, the parts of the model that require multiple modifications, such as the component architecture of the framework, are done during live meetings by the technical coordination team.

Collaborative modeling may also be influenced by the adopted modeling language. Indeed, in the DataBio project, we first experimented with extending/refining the Archi-Mate modeling language [START_REF]The ArchiMate Enterprise Architecture Modeling Language[END_REF] as the high-level model representation for the architecture. However, due to the constraints imposed by the ArchiMate metamodel, collaborative modeling was quite tedious in Modelio. For example, the locking of a single element was leading to the locking of a large portion of the model, possibly impacting other users. For this reason, in the subsequent projects, we opted for extending/refining UML as it allows atomic editing of model elements.

Document Generation Support

The Modelio Document Publisher was a major feature of Modelio to construct our MS Word document generator. Indeed, Modelio provides a simplified document template editor with a graphical interface that has pre-built functionalities for navigating the model, filtering model elements, extracting textual notes and diagrams, as well as for building sections, paragraphs, tables, and matrices. These features were particularly useful to generate important parts of our project's deliverables. This is notably the case for roadmaps, where we created tables displaying mappings between case study and tool requirements with planned delivery dates. Based on such roadmaps, the case study providers could anticipate and organize both the building of their toolchains and their validation activities. Moreover, the traceability information in the RE model was extremely important to identify the case study requirements that are not addressed by any tool component. This way, we were able to conduct a gap analysis from our RE model to better plan corrective actions.

Fig. 8 shows an excerpt from two generated deliverable documents, D3.2 [START_REF] Bruneliere | AIDOaRt Consortium, D 3.2 -AIDOaRt Core Infrastructure and Framework -Initial Version[END_REF] and D3.3 [START_REF] Bruneliere | AIDOaRt Consortium, D 3.3 -AIDOaRt Core Infrastructure and Framework -Intermediate Version, Deliverable, H2020/KDT AIDOaRt project[END_REF] 7 . This example shows the cover page, meta-data, auto-generated table of contents, as well as headings, paragraphs, lists, diagrams, and tables that are generated from the MBRE model. Besides the model elements, text definitions, and UML text-based annotations, partners can annotate particular elements with rich-text documents (e.g., MS Word documents) and commit them to the model repository. These embedded document snippets are then seamlessly included in the de- liverable at generation-time (cf. the custom system description diagrams in the bottom-right page of Fig. 8). This allows for incorporation in the deliverables of custom-rich content that is freely edited outside of Modelio without being bound by the tool capabilities nor constrained by the formal modeling languages. The automated generation of significant parts of the deliverables ensures overall coherence and consistency of their content, as well as the alignment of their format and style with the project's quality control templates and guidelines.

Traceability Support

Another interesting feature is the capability to relate and trace our RE models to elements coming from other kinds of models in Modelio. Indeed, the tool integrates UML and many other metamodels, e.g., Enterprise Architecture models expressed in ArchiMate, business models in BPMN [START_REF]OMG, Business Process Model and Notation (BPMN)[END_REF], system models in SysML, etc. This allows us to use elements of various metamodels together and trace model elements across several metamodels. However, modeling these links is not always an easy task. For instance, in AIDOaRt, before linking a solution component to an architecture component with an implements relationship, the solution provider must check that the specification of their solution is aligned with one of the architecture components and its functional interfaces. This requires time-consuming navigation throughout the long list of components and interfaces, reading their descriptions, and checking if they can be met by the solution. An extra action is then needed to navigate back to the solution component and to create the implements link element. Similarly, case study providers had to define that a given architecture component or functional interface satisfies some of their requirements. Several similar actions were needed to define other relationships, e.g., refinement relations between requirements, dependencies between case study scenarios and corresponding functional and data requirements, and associations from data models to data requirements. As shown in Fig. 10, and to facilitate the creation of these links, we developed and added custom matrices that filter the right type of model elements on rows and columns. This allows us to easily create relations between them by selecting the right value in the corresponding cells.

Architecture and Requirement Validation Roadmap

Having explicit traceability between case study requirements and tool/solution requirements allows the project management to have a clear view of which case study requirements will be satisfied during the project and which require additional development. In addition, by having specified for each tool requirement at which milestone will be available for evaluation via the ReleaseType property (see Figure 3), the case study providers and the project management are able to create a roadmap of when the architecture components become available and when case requirements can be validated.

For example, let us consider two case study requirements and two corresponding tool requirements for each of them. By analyzing the requirement mappings and their Re-leaseType, one can conclude that UCReq1 will be fully validated at milestone intermediate, whereas requirement UCReq2 will be fully validated at milestone final, as depicted in Fig. 11.

Evaluation

To evaluate our MBRE solution, we collected various kinds of data associated with the five large collaborative projects we considered. We describe quantitative and qualitative data resulting from the projects' execution in Section 4.1. We also present general statistics on using our approach in different projects in Sections 4.2 and 4.3. A survey realized in these projects is then presented in Section 4.4. Finally, in Section 4.5, the collected data is used to discuss the relevance of our model-based solution according to the main targeted properties.

General Data on Projects

The first concerned project is named DataBio, standing for Data-Driven Bioeconomy (Horizon 2020). It lasted 3 years from 2017 to 2019, and involved 48 partners from 17 countries, for a total budget of e15M. 27 case studies in the agriculture, forestry, and fishery areas were developed during this project.

The second project is named REVaMP2, standing for Round-trip Engineering and Variability Management Platform and Process (EUREKA ITEA3). It lasted 3 and a half years, from 2016 to 2019, and involved 27 partners from 5 countries, for a total budget of e22M. 7 case studies in the cyber-physical systems, electronic systems, and tourism domains were analyzed during the REVaMP2 project.

The third project is named MegaM@Rt2, standing for MegaModeling at RunTime -A scalable model-based framework for continuous development and runtime validation of complex systems (ECSEL). It lasted 3 years, from 2017 to 2020, and involved 27 partners from 6 countries, for a total budget of e16.7M. 9 industrial use cases in the aeronautics, warehousing, automotive, construction, transportation, and telecommunications domains were evaluated.

The fourth project is VeriDevOps [START_REF] Sadovykh | Veridevops: Automated protection and prevention to meet security requirements in devops[END_REF] dealing with automated protection and prevention to meet security requirements in DevOps (H2020). It started in 2020 and is scheduled to end in 2024. The project involves 7 partners from 4 countries for a total budget of e3.9M. The project develops 2 industrial case studies in the industrial automation domain. Compared to the other discussed projects, VeriDevOps is relatively small, though it shares most of the needs in terms of requirements engineering and technical coordination with the other projects. In our analysis, we provide some of the data in a size-normalized way to demonstrate the commonalities among the projects.

The fifth and last project is AIDOaRt, a 3 years long H2020-ECSEL European project involving 31 partners, grouped in clusters from 7 different countries, focusing on AI-augmented automation supporting modeling, coding, testing, monitoring, and continuous development in Cyber-Physical Systems (CPS). From 2021 to 2024, the project involves in its consortium 80 full-time equivalents with academic and industrial researchers, project managers, and other staff, for a total budget of e24M. 22 solution providers propose around 50 state-of-the-art research and industrial solutions to tackle 15 case studies proposed by 10 key industrial actors in the fields of automotive, construction, communication, and logistics.

Analysis of Facts and Figures from the RE Model

Repositories Along with the previously mentioned global figures, we provide in Table 2 additional data about the scale of the RE activity, as registered during these five projects, and we illustrate the evolution of this activity in Fig. 12. We collected this data directly from the logs of the model repository used in each project. The repositories are managed by Modelio Constellation using the SVN version control system. Each log trace corresponds to a user's commit to the model and consists of a timestamp, a user ID (i.e., a member of a partner organization in the project), and an (auto-generated yet user-editable) commit message that indicates the modified model elements being committed (added, removed, edited). At the time of writing, data captured in VeriDevOps and AIDOaRt concern the period up to months M28 and M24, respectively, over the whole project duration, which is 36 months. Thus, this data may further evolve in the upcoming months until the end of these two projects.

Overall, the data show that the number of individuals involved in the RE process, whether just registered users with a "read-only" profile or active contributors with a read-and-write profile, was important. Interestingly, the ratio of active contributors is globally similar in all projects the month of this paper submission. # In DataBio, there was no clear separation of framework and tool requirements. $ In VeriDevOps, due to the size of the projects, it has been decided to directly map the case study requirements to the tools. † Includes all applied elements, e.g., attributes, relations, and diagrams. ‡ In AIDOaRt, we generated 11 deliverables, with ∼80 to ∼300 pages each, and ∼160 pages on average.

(∼ 50 to 60%), including the relatively smaller project VeriDevOps.

Regarding RE activities, as illustrated in our case by the number of commits on the requirements model, we observed a disparity between the five projects even though it stays globally important in all of them (cf. Figure 12a). This can be explained by the slightly different sizes of the five projects, e.g., the number of partners or case studies. This can also be partly explained by the nature of the single commits: a given user may frequently do small single commits while another may commit a large number of updates as a single commit. This effect may have been amplified with microtasking in recent projects.

Regarding the requirements models, the data highlight the globally high number of handled requirements and related elements in the context of the five projects (cf. Fig. 12b). We can observe differences between the projects, but, as stated before, this can be explained by the specificity of each particular project, e.g., the number of partners and the case studies to be covered. These differences are also directly reflected and visible in the number/size of the various project documents or deliverables generated from the requirements models in the five projects. We also want to note that the initial use of ArchiMate in the DataBio project, as previously mentioned in Section 3.4, does not have a significant influence since the number of concepts considered for modeling the architecture is exactly the same as in UML. The slightly bigger numbers can be explained by the greater size of the DataBio project in terms of involved partners and tools. Generally, the number of commits, model elements, and active users are higher in projects with larger consortia and tend to increase over time. This reflects an increasing involvement of the partners and a larger adoption of the MBRE solution (cf. Fig. 12).

Finally, we can observe that there is a significant difference between the number of requirements level elements and architecture level elements in the five projects. There are several possible explanations: 1) Architecture specification requires many elements, e.g., interfaces, components, relations, to satisfy a set of requirements; 2) the UML metamodel usually requires the creation of several elements for a given goal, e.g., association ends are created when an association is added (and these are also counted).

Analysis of the Chronological Activity in the RE Model

Repositories In this section, we provide a more in-depth analysis of the chronology of the repository logs. The goal is to study the evolution of the actual modeling activity monitored during the execution of the projects and to identify common patterns occurring across the various projects.

To this end, we analyzed the timestamps of the log traces and aggregated the number of edited model elements in every commit by each one of the contributors over the same periods. We present this data for the REVaMP2, MegaM@Rt2, and AIDOaRt projects (cf. Fig. 13a,13b, and 13c, respectively). We visualize the data in stacked area charts, where the colored area under a certain curve denotes the number of model elements edited by a given user (the names of the contributors were anonymized into "user 1", "user 2", etc., for privacy reasons).

The model repository administrators and maintainers (e.g., user 19 and user 12 from AIDOaRt in Figure 13c) contributed the most, i.e., they are associated with the largest areas in the chart. These users are typically SOFT-EAM R&D team members who closely work on Modelio and Constellation. They instantiate and configure the RE model and create the model templates, document generation, and model verification scripts. They also perform initial bulk imports from external data sheets and often complete partners' submissions with some corrections or enhancements while doing recurrent reviews and model quality control routines. Some of the large areas correspond to active users from the core teams, work package leaders, or partners maintaining a large number of model elements, e.g., participating with a large number of case studies or solutions in the project.

The chronological evolution of the users' activity in the three projects shows a common pattern:

• Very low activity takes place at the beginning of each project, typically by the model administrators, to initialize and prepare the model repository. Then, for almost 6 months after the project's kick-off, partners informally present and discuss their case studies and solutions, and data is typically collected in semi-structured sheets and documents. Meanwhile, the core teams plan the first microtasks, and model administrators familiarize the partners with the MBRE solution. The partners are generally not asked to directly contribute to the RE model during this period.

• High activity is identified towards the end of the first year in each project. It corresponds to the initial phase of requirements elicitation and collection of solution descriptions directly submitted by the partners into the RE model.

• Intermittent and sporadic phases of relatively lower activities are witnessed afterward. They correspond to the phases of updating the model to refine the requirements and solutions definitions, specify generic requirements or a common framework architecture, and declare development roadmaps, potential mappings, and integration between requirements and solutions.

• Interleaving inactivity phases correspond to vacations and holidays, to the beginning of a new milestone where new deliverables are planned but no content is collected from the partners yet, or to the periods where the R&D activities are taking place but not being reported into the RE model yet.

• A final wave of activities systematically occurs towards the end of the project. It typically allows reporting about case studies implementation/results, KPIs measures, and project objectives achievement. These are typically reported in the last deliverables of each project.

A closer look at the AIDOaRt project (Fig. 13c) shows a strong correlation between the users' activity in the RE model and the projects' deliverable timelines. Notable exceptions are those in italics, i.e., D5.1, D5.2, and D5.6 which were not generated from the RE model, and to a lower extent D4.2 whose content was mostly provided at the same time as D2.2 and D3.3 (thus relying on the same set of microtasks). The peaks of activity take place close to the deliverable submission deadlines.

In general, several observations can be made from the previous analysis:

• Given the slow start at the beginning of each project, it is complicated to start collecting partner contributions in the RE model before several months of work. Thus, promising deliverables relying on contributions to the RE model at this early stage would require amendments to reschedule these deliverables' submission dates and probably several subsequent ones, which might delay the whole project.

• Having most of the partners' contributions close to the deliverables deadlines highlights the importance of having an approach that allows for timely, continuous, and coherent integration of last-minute contributions and corrections in the deliverables. In this sense, our collaborative model-based solution, coupled with (semi-) automated document generation, is relevant for real-time integration of partners' content in the deliverables while guaranteeing global coherence.

• The ability to do such an analysis also shows that our solution and the use of a collaborative model repository should be considered an important project management tool. Especially in projects with large consortia, this allows to plan and follow up the implementation of project milestones more easily. Moreover, it can also be used as a monitoring tool to measure partners' regular and active involvement throughout the project's lifetime.

Survey for Projects' Participants

To evaluate our MBRE solution according to more data, we also ran two consecutive online surveys among the partners of the AIDOaRt, MegaM@Rt2, REVAMP, and DataBio projects. We wanted to validate whether our approach is relevant and helpful in practice in the context of large collaborative research projects.

Survey Design

We ran the first survey in 2021 with DataBio, REVAMP, and MegaM@Rt2 projects participants [START_REF] Sadovykh | Applying Model-based Requirements Engineering in Three Large European Collaborative Projects: An Experience Report[END_REF]. The second survey was conducted with AIDOaRt participants in the middle of that project. Note that we plan to run the second survey once again at the end of the AIDOaRt project to collect additional data.

In the first survey, we started with three quantitative assessment questions: • Q1: In your opinion, did you find this graphical modelbased approach useful in different activities of Requirements Engineering? Followed by the list of main RE activities.

• Q2: In your opinion, do you see the modeling approach as an improvement compared to other non-modeling (e.g., text-only or table-based) regarding the following aspects?

Followed by the list of characteristics that the requirements have to follow, such as correctness and traceability [START_REF] Wiegers | Software Requirements[END_REF]. and(c) show the evolution of the number of commits over the whole project duration for REVaMP2, MegaM@Rt2, and AIDOaRt (on M24, i.e., up to month 24 over 36), respectively. Peaks correspond to deliverable submission deadlines. Areas are colored w.r.t. to the different users of the model repository. The surface of the colored areas reflects the extent of involvement of the users in editing and updating the MBRE model.

• Q3: In your opinion, did you find the following Modelio tool features useful in different Requirements Engineering activities? We listed all presumably key features of Modelio that could be considered helpful.

In addition to these quantitative assessment questions, we proposed three qualitative assessment questions: In the second survey for the AIDOaRt participants, we decided to replace the "model-based" with "Modeliobased", since we believe this was easier to understand for the participants. In addition, we added a specific section to poll their perception of the benefits of the microtask-based iterative process for RE. We intended to validate our hy-pothesis that microtasks facilitate (1) comprehension of the full RE approach; (2) uniformity of the RE model that is produced collectively; (3) addressing requirements changeability and uncertainty in a large-scale research project. These questions were structured as follows:

• Q7: In your experience, microtasks greatly facilitate learning of the proposed MBRE approach? • Q8: In your experience, microtasks result in a coherent and uniform model? • Q9: In your experience, microtasks enable great flexibility in addressing evolving requirements?

For questions Q1-Q3 and Q7-Q9, we utilized a modified Likert scale [START_REF] Likert | A technique for the measurement of attitudes[END_REF]. Respondents were asked to indicate their level of agreement with the statements in these questions. They were presented with five options in the following order: strongly disagree, disagree, agree, strongly agree, and no opinion. For questions Q4-Q6, we provided a text box to allow respondents to express their thoughts and reflections openly.

In all cases, the potential respondents were project partners who held an account in the shared model repository and had access to the modeling. To mitigate subjectivity bias, we deliberately excluded ourselves from the survey, despite being the primary beneficiaries of the solution, as we are responsible for architecture definition in the concerned projects.

Survey Results

In what follows, we summarize the main findings of the surveys. The complete results are available online [START_REF] Sadovykh | Dataset -Survey results -Applying Model-based Requirements Engineering in Three Large European Collaborative Projects[END_REF][START_REF] Sadovykh | Dataset -Survey results -Applying Model-based Requirements Engineering in AIDOaRt Collaborative Project[END_REF]. For the first survey, we had in total 154 individual contact persons: 55 for DataBio, 43 for REVAMP, and 56 for MegaM@Rt2. We received 15 complete answers, including one from a person not involved in RE activities. For the second survey, we contacted 83 persons from the AIDOaRt project and received 32 replies. Thus, the total number of respondents to the surveys is 47.

We explain this level of participation by several factors. For the first survey: (1) Few of these contact persons were active contributors to the RE process in these projects. Most of them were "readers" or contributed very few elements; (2) It has been at least 1 year since the projects terminated and at least 2 years since the end of the corresponding RE work. For the second survey, the RE work was still ongoing at that time. It is also possible that the non-respondents do not have a definitive opinion on the MBRE solution. Thus, we expect to get a second wave of feedback when we re-run the survey towards the end of the project. We would also like to note that several respondents are part of several projects. Thus, the number of possibly available unique participants in our survey would be lower than the total number of participants in all of the surveyed projects.

While this amount of data cannot be considered statistically representative, we believe that the received feedback still provides interesting and relevant complementary insights. In the next paragraphs, we outline the combined data of both surveys for questions 1-to-6 to present a more coherent analysis.

The majority of the respondents considered that our model-based RE approach was useful for different RE activities. On average, 79.43% would agree that the proposed graphical model-based approach is useful for RE (Q1), 68.80% would agree that the modeling approach is better for RE (Q2), and 60.70% would agree that the implementation of the approach in Modelio was useful for RE (Q3). In Q1, 91.49% agree that model-based approaches are useful in System modeling. In contrast, 61.70% also find that model-based approaches are useful in Requirements inception or requirements elicitation. In Q2, the highest agreement (80.85%) concerns the advantages of a model-based approach regarding Traceability: it can be linked to system requirements, designs, code, and tests. The lowest agreement (59.57%) concerns the benefits of model-based versus non-model-based approaches for dealing with Verifiability (it allows for correct implementation to be determined by testing, inspection, analysis, or demonstration). In Q3, a high number of respondents (95.74%) would find Traceability visualization in a diagram view to be useful. The lowest agreement (57.45%) concerns the usefulness of the approach for road-mapping (e.g., setting up expected delivery dates and completion stages for designed components). This latest result may be due to the very nature of research projects, where some partners are unable to provide exact expected delivery dates for their proposed solutions, prototypes and tools.

Moreover, additional questions on the appropriateness of the approach resulted in the following assessments: • 85.11% would find the approach appropriate for the given size and scope of the project; • 87.23% would find the tool support useful for guiding the RE process and enforcing project conventions; • 78.72% would find the approach easy to learn; • 76.60% would find the approach easy to apply and 61.70% would use it again in the future.

Concerning our hypothesis about the microtask-based process for MBRE (Fig. 14), the respondents generally agree (100%) that this approach facilitates learning (Q7) and that it provides flexibility to address changing requirements (Q9). In addition, 88.24% agree that the approach helps produce a coherent and uniform model (Q8). This is a promising indication that such microtasking can be recommended in model-based and RE contexts.

Comparative Analysis

We analyzed the differences in survey results for both the MegaM@Rt (2021) and AIDOaRt (2022) projects, and we summarize them in Fig. 15. We noticed that the respondents from AIDOaRt were less senior with 70.6% having less than 3 years of experience with RE. Half of the participants were academic partners, and 88.2% of respondents identified themselves as technology providers in the project context. 64.7% were used to allocate less than 10% of their time to maintaining RE documents. Based on the comparison analysis (Fig. 15), we can be satisfied that the AIDOaRt respondents approved the use of our MBRE solution on a very similar scale as the more senior respondents of the MegaM@Rt survey. Once again, we believe that microtasking in collaborative modeling was beneficial to overcome the learning barrier and saved time on maintaining the RE documents.

Qualitative Feedback

Finally, we also received open qualitative feedback from the surveys, as summarized in Tables 3 and4. Respondents mention their overall appreciation in terms of the unification of the RE process provided by our solution, its relevance in large European research projects (via our collaborative model repository), the usefulness of microtasks, the improved consistency with traceability support, and the fast and clean documentation generation support. We would like to note that our MBRE solution has already been presented to the independent external experts mandated by the European Commission during project review meetings of the MegaM@Rt2 and AIDOaRt projects. In both cases, our solution received very positive feedback.

Nevertheless, the survey respondents also mentioned some limitations. In the first survey, they mentioned the difficulty of convincing stakeholders to apply the approach at first and difficulties in terms of model synchronization during collaborative editing. In the second survey, they identified the difficulty of navigating and querying the model with a large number of model elements. While extensively using the tool, they also complained about some of its technical details (e.g., limited support on some OS platforms, issues in the teamwork module, and the difficulty of finding specific components).

Furthermore, the respondents proposed several potential improvements according to their past and present practices. Notably, they suggested supporting in the future a better connection with other tools (modeling tools but not only), more advanced traceability between our RE language and other languages (e.g., for software design and development), and providing more structured templates for the requirements description. They also requested to better illustrate new microtasks with additional examples and tool use guidelines, and to show model changes' effects on the generated documentation timely.

Overall Assessment of our MBRE Solution

Based on all the collected data, we can provide an assessment of the relevance of our MBRE solution according to various important properties:

• Scalability -The consolidated data extracted from the requirements model repository in the five projects clearly shows that we have been able to support a significant number of users (including regularly active ones) as well as to handle a relatively large number of requirements and related model elements. Moreover, the success of the five projects in terms of deliveries (i.e., documents, tools, demonstrators) and the survey results also demonstrate the general scalability of our MBRE solution, at least for projects going up to the size of the five mentioned ones. However, as some survey respondents notice, the larger the model becomes, the more difficult it is to find and work with its elements. To overcome this, we suggested using containers to efficiently group model elements in different ways according to the needs. On the contrary, documentation generation was not affected by the large size of the models and proved its usefulness. Indeed, physical limitations, such as the operating memory size of client computers, may hinder the handling of large models. To address these constraints for very large models, we propose adopting the fragment technique. This approach involves having individual contributors work on smaller pieces of the model, which are then seamlessly integrated into the joint model in a read-only manner.

• Heterogeneity -The varied characteristics of the five projects (e.g., various partners providing different kinds of tools and technologies, various case studies covering several application domains) show that we have handled a certain level of heterogeneity. Based on our experience in these five projects, and the participants' feedback we collected via the surveys, we can also argue that our MBRE solution can be applied similarly in any large collaborating project whose main purpose is to produce integrated software solutions.

• Adaptability and Extensibility -We have also shown that our MBRE solution can be extended with new elements (e.g., in the RE language or in the microtasks) that satisfy the needs of given projects. This is particularly useful to adapt to the partners' different levels of experience and their various practices. In particular, we have added extensive support for various types of Use Case requirements in the AIDOaRt project. Moreover, we applied this type of customization in the VeriDevOps project where, due to its smaller size, we skipped the use of microtasks. Overall, the adaptability and extensibility of our approach are subject to the limitations of UML. While UML is an excellent tool for high-level architecture and software design, it has limited applicability in other areas, such as embedded systems. However, specialized extensions like SysML and the MARTE UML profile address these limitations and offer more suitable solutions for certain domains.

• Traceability -From the surveys' results, we can state that traceability and the capability to guide and enforce full MBRE processes have been the most acknowledged features of our MBRE solution (85.11% agree on the usefulness of traceability in Q2). It should be noted that the requirements and architecture elements are traced using manually modeled dependency relations. Furthermore, there is room for potential improvements and extensions in this area, such as the implementation of tooling support for traceability from the model down to the source code. Nevertheless, the feedback received up to now already highlights an acceptable support for traceability.

• Automation -The quantitative data collected show that we have automatically generated documents of significant sizes from the corresponding RE models. These were quite complete requirements, architecture, or roadmap documents whose content could then be reused Table 4: Excerpt of feedback from the survey respondents on the limitations of the adoption of the MBRE approach, its iterative application through the use of microtasks, and the use of the modeling tool, Modelio. Most remarks concern the tool and its technical details rather than the approach per se.

I feel that [the microtasks] could often be made clearer via tool examples instead of descriptions, and indeed often this was the case via demos from Softeam or highlighting partner input [. . . ] Doing queries in the model as a more casual user. I sometimes wanted to find some information that could be queried, but I found it hard to solve intuitively. Navigation in the tool: Where is the link between object A and object B? Should I add a document, or a note, or make a comment in some other way?

The initial learning curve is steep for partners not coming from a strong modeling background. Also, collaboration is difficult on some occasions (e.g., nearing a deadline, everybody is locking the same items so it gets difficult and time-consuming to find an available slot to make changes). For a new user like me it took effort to learn how to use it. I had some personal help to solve some tasks, otherwise it could take a bit long.

From the point of view of the end user, the use of the tool is cumbersome; within the European projects in which it was used, the maximum effort was on the Modelio experts. The usability of the tool and some facilities can be improved. I had a few issues with obtaining locks when working on some microtasks, but otherwise no special challenges.

directly to produce the official project deliverables. The survey confirms participants' appreciation towards document generation since 91.49% agree in Q3 on the usefulness of this feature. The document generation heavily relies on manually created templates, which necessitates expert support. Though not total, the achieved level of automation was already quite appreciated in the projects.

• Consistency and Quality -Having a single central model allows us to periodically inspect the quality and consistency of the data using automated scripts. This has been used at different steps of our overall RE process in order to check various kinds of properties regarding the case study requirements, architecture components, tool components, etc. However, improvements are still possible regarding the use of Model Verification and Validation techniques.

• Usefulness and Usability -The fact that our MBRE solution has been successfully used in practice in the context of five different collaborative projects already shows a certain level of usability. The qualitative data collected from the surveys also confirm that users globally found our solution useful, as 79.43% replied positively in Q1. Furthermore, they appreciated in particular the fact that the solution was relatively easy to both learn and apply in their respective contexts.

Discussion

In the following, we summarize our experience from applying our MBRE approach into a set of lessons learned (Section 5.1), we discuss threats to validity we have identified concerning the current evaluation of our MBRE solution (Section 5.2), and we introduce some open challenges concerning both our model-based approach and its application in other contexts in the future (Section 5.3).

Lessons Learned

From our experience of designing and then applying our MBRE solution in the context of five different large collaborative European projects, we have been able to extract some general lessons learned. We hope that they will be useful to the modeling community as well as more globally to the whole Software Engineering community:

• Model as a common language -Having a common modeling language and process for the entire project consortium allowed us to address the heterogeneity of the partners by "forcing" them to use the same steps, concepts, and notations. In addition, the tool support for the approach allowed the partners to work collaboratively on the same model by updating and retrieving the relevant information at different phases of the project. Finally, having traceability links between the elements of the same model allowed us to easily analyze the model to generate road maps and perform gap analysis.

• Project Planning -As discussed in Section 4.3, we have observed that using a model-based approach in our RE context can impact how the project's milestones and deliverables are planned. Notably, we suggest considering the time needed to plan the contents of the deliverables and define the required microtasks at the beginning of each milestone. This is crucial to be completed before all partners can collaborate on the RE model.

• Project Management -The feedback received shows that our model-based solution is beneficial from the project management perspective: One of the most valuable user features is the automation capability. Notably, the possibility to perform more easily gap analysis, obtain a corresponding roadmap, and generate long documents directly from the requirements model was highly appreciated. In addition, the funding agencies highly appreciated and recommended the model-based solution since the technical coordination effort was made visible, and the projects were more manageable.

• Framework Architecture -The proposed modelbased solution was naturally relevant for defining the framework architecture. Notably, the combination of well-known diagrams originating from UML and SysML with tabular views was perceived as a good way to facilitate the use of our solution, e.g., for partners already having experience in modeling activities. In addition, the support for collaborative work and the integration with a model repository were considered among the most appreciated features by our partners.

• Language and Model Complexity -With the growth of the project complexity and related needs, more and more concepts had to be modeled. For example, data requirements, data models, and solutions were added to the model in the context of AIDOaRt. Thus, it is important to adopt a flexible approach that can easily incorporate new concepts. To this extent, microtasking helps in bringing all the team on the same page. Nevertheless, it is still necessary to rely on modeling experts for the coordination effort.

• Learning Curve -Some participants in our projects had a somehow limited experience in modeling, both conceptually and technically. This resulted in difficulties for them to catch up with some of the concepts in our RE language. It also appears that initially provided guidelines on the approach/language and Modelio tooling were not sufficiently detailed. This was quickly fixed by the Modelio team via online hands-on sessions, for example. The participants were then more easily able to go on with their modeling activities in the context of their respective projects. In addition, we recommend the microtasking approach to overcome the learning barriers and enhance the uniformity of the modeling effort.

• MBRE and Collaboration -Our experience has demonstrated that MBRE and microtasking greatly facilitate collaboration. The joint model repository encompasses various types of case study requirements, framework architecture, and high-level architecture of proposed solutions. Accessible to every project member, the repository enables seamless navigation from requirements to solutions and vice versa. This approach provides the case study partners with clear indicators of which technology providers address their use cases. Simultaneously, the technology providers identify potential partners for a joint solution to address a case study. Microtasks serve as synchronization points where all partners contribute and become aware of each other's contributions during the synchronization meetings. These essential synchronizations are conducted at regular intervals.

Threats to Validity

The main threat to validity concerns the amount of survey data we have been able to gather from project participants. Indeed, our MBRE solution has been deployed in "only" five different projects from which we have extracted mostly quantitative data. However, the fact that these were large projects that ran over 7 years in total already provides a certain level of confidence about the quality and relevance of the collected data. Moreover, we complemented this quantitative data with extra data (quantitative but also qualitative this time) collected from two surveys largely distributed among the participants of the five projects. Obviously, it would have been more significant to get more answers to the survey. However, we believe the collected feedback coming from 47 different participants is already interesting to improve our global appreciation of the proposed solution. Another threat stands in the fact that the evaluation of the proposed solution included several dimensions of our work, i.e., the modeling language, the model-based process, and the supporting tooling. To this end, we paid attention to gathering different types of data on these dimensions and specifying separate groups of complementary questions in the survey.

Challenges

As a result of all our work and experience, we highlight some big challenges we believe to be worth investigating as far as MBRE or, more generally, modeling is concerned:

• From Requirements to Source Code -Our RE models contain information concerning mostly the needs and architectural decisions at the project level. While this is already useful for coordinating the common global effort toward the realization of the target solution, it remains relatively far from being fully model-driven. Indeed, we have not yet integrated the use of software models, and related capabilities, such as the generation of implementation and verification artifacts from the model(s), are not supported at this stage. Thus, efforts still have to be made to better fill this gap between the system's architecture and development levels in our MBRE solution and more globally in many others.

• User Training and Support -In our RE language, we deliberately decided to extend UML and restrict its usage to a limited number of concepts. We also provided tooling support, user guidelines, and online workshops to get the various projects' partners more acquainted with modeling in the Modelio environment. Nevertheless, some partners appeared to still need regular support concerning both the tooling and the solution. Thus, we strongly believe that the usability and learning curve of model-based solutions are the key elements to consider and improve accordingly to allow for their large dissemination in different contexts. In the AIDOaRt project, this was partially achieved by integrating the use of microtasks.

• Collaborative and Online Model Editing -One of the most reported issues concerned restrictions in the collaborative editing capabilities provided by our model-based solution. The Modelio model repository we use currently relies on a Subversion-based "lock -edit -commit -release" operation mode. However, modern users generally tend to prefer online editing collaboration modes, e.g., via their favorite web browser. Even if the situation has improved during the last few years, we have seen limited support for that so far in existing modeling tools or even in popular IDEs. Extended support for online collaboration at the model level is probably a path to be explored more deeply in the future to improve current model-based solutions.

• Automation and Production-Readiness -There are still open challenges related to the support for automation in model-based processes and, more generally, in Software Engineering processes. For instance, we have been considering the possibility of building some more automated support for document generation or even code generation to be integrated into our overall RE process. However, it is always a matter of cost/benefit balance since development resources can be limited in collaborative R&D projects. Thus, our model-based solution is still not in the full production stage. Indeed, it requires some level of customization for each new project and will require higher investments and efforts to eventually become an actual product in the future.

Conclusion

In this paper, we reported on our practical experience of designing, developing, and deploying a Model-based Requirements Engineering (MBRE) solution over 7 years in the context of 5 different large European collaborative projects providing complex software solutions. Our overall MBRE solution provides an iterative model-based approach accompanied by an RE modeling language and the corresponding tooling support. To address the two main challenges introduced in Section 1, our solution aims at supporting several complementary activities: 1) requirements can be modeled appropriately in different layers (case study, framework, tool), 2) modeled requirements can be better interconnected and traced during the RE process, 3) modeled requirements can be used to (semi-)-automatically perform gap analysis and propose a roadmap, 4) modeled requirements are also used for designing, implementing, and validating the architecture of the framework provided by the project, 5) different deliverables of the project are automatically generated from the RE model and 6) modeling activities are done incrementally using microtasks with clearly specified guidelines.

Based on this global experience and the collected data, we demonstrated that our model-based solution can bring interesting benefits in terms of scalability, heterogeneity, adaptability/extensibility, traceability, automation, consistency/quality, and general usefulness or usability. We also discussed the limitations we faced, as well as open challenges to improve our solution in terms of modeling support (among others). In the next steps of our work, we will continue to collect even more data from the solution usage within the still-running projects VeriDevOps and AIDOaRt. We will also re-apply and extend the solution within new collaborative projects to start. In particular, we already plan to take into account the modeling of projects' KPIs, high-level objectives, and evaluation results from the case studies. Furthermore, we also want to consider the technical integration of our solution with existing project management tools.

Figure 2 :

 2 Figure 2: Iterative process of our MBRE Approach: iterative model extensions and continuous updates timely support the project's evolution and the deliverables creation process.

Figure 3 :

 3 Figure 3: Metamodel of our Extended RE Language (elements in purple depict the newly added concepts to the abstract syntax of our language).

  way, the users of our RE language can benefit from clear guidelines in Modelio on what is expected from them when elaborating on the RE model for their tool components.

Figure 4 :

 4 Figure 4: Structure of the base RE model in Modelio: Example from the MegaM@Rt2 project.

Figure 5 :

 5 Figure 5: Structure of the enriched RE model in Modelio: Example from the AIDOaRt project.

Figure 6 :

 6 Figure 6: High-level view of the Modelio and Constellation solutions for collaborative modeling support.

Figure 7 :

 7 Figure 7: The MBRE model elements are arranged by partner. Model elements of a given partner are isolated in a separate container to allow concurrent access and update while avoiding conflicts.

Figure 8 :

 8 Figure 8: Selected pages from AIDOaRt deliverables that have been automatically initiated from the MBRE model using Modelio.

Figure 9 :

 9 Figure 9: Traceability diagram in Modelio: Example from AIDOaRt showing the mapping between an architecture component, related solutions, and case study requirements.

Fig. 9

 9 Fig. 9 shows the list of solutions (ToolComponent) that implement the AI for Requirements Engineering architecture component (FramewokComponent) from the AIDOaRt project. It also shows the list of case study requirements and data requirements that can be fulfilled (via the Satisfy links) by this architecture component. Such traceability links established an indirect relation between tool components and case study requirements, which allowed the AIDOaRt consortium to identify potential collaboration links between solution providers and case study providers.However, modeling these links is not always an easy task. For instance, in AIDOaRt, before linking a solution component to an architecture component with an implements relationship, the solution provider must check that the specification of their solution is aligned with one of

Figure 10 :

 10 Figure 10: Matrices in Modelio are used to define relations between the MBRE model elements. The above is a matrix that allows the creation of "implements" relations between solution components and architecture components.

Figure 11 :

 11 Figure 11: Generic example of creating the roadmap for use case requirements validation.

Figure 12 :

 12 Figure 12: Figure (a) shows the evolution of the total number of commits or revisions made by the project members to their model repositories, and Figure (b) shows the total number of created model elements. The left charts show the raw numbers, whereas the right charts show these numbers normalized w.r.t. to the size of the projects (i.e., the number of partners, case studies, and solutions). The dotted curves illustrate the moving average trends.

Figure 13 :

 13 Figure 13: (a), (b), and (c) show the evolution of the number of commits over the whole project duration for REVaMP2, MegaM@Rt2, and AIDOaRt (on M24, i.e., up to month 24 over 36), respectively. Peaks correspond to deliverable submission deadlines. Areas are colored w.r.t. to the different users of the model repository. The surface of the colored areas reflects the extent of involvement of the users in editing and updating the MBRE model.

  • Q4: In your opinion, what was the most challenging aspect of the Modelio-based approach? • Q5: In your opinion, what was the most useful aspect of the Modelio-based approach? • Q6: In your opinion, which additional Modelio tool features would have been useful for RE in the project?

Figure 14 :

 14 Figure 14: AIDOaRt survey's respondent opinions about the iterative application of the MBRE approach through the use of microtasks.

Figure 15 :

 15 Figure 15: Percentage of the participants who agree with the positive statements in response to the four main questions of the survey.

Coordinate Technical Workflow Conduct Model-based Requirements-driven Engineering Framework Development Requirements Engineering Architecture Definition and Roadmap Framework Validation

  Our Iterative Model-based Requirements Engineering Conceptual Approach.

	Technical Coordination Team	Analyze Next Project Milestone Deliverables Define Microtasks Generate Deliverables Conduct Model-based Requirements-driven Engineering		Case Study Technical Coordination Providers Team	Define Case Study Requirements Define Framework Requirements Define Data Artefacts Requirements	Define Case Study Requirements Validation KPIs & Roadmap Define Framework Architecture Create Framework Development Roadmap	Report on Prepared Demonstrators Report on Framework Integration Specify Collected Data Artefacts	Report on Requirements Validation & Solutions Evaluation Collect Framework Evaluation & Feedback	Release Framework
	Complete & Review Deliverables Release Deliverables	Research &	Technology	Providers		Define Tool Component Requirements	Define Tool Component Architecture	Create Individual Tool Roadmap	Report on Implemented Tool Components	Collect Tool Component Evaluation & Feedback
	Figure 1: Technical Coordination Team Case Study Providers	Research & Technology Providers
		Specify Microtask
	Implementation Guidelines
								Modeling
								Guidelines
	Customize RE Language
		+	Model
		Update Framework Requirements & Architecture	Update Case Study Requirements, Roadmap Integration & Evaluation	Update Tool Features & Tool Requirements
		Generate		Generate		Generate
		Intermediate		Intermediate		Intermediate
		Deliverable		Deliverable		Deliverable
	Yes	Need to Improve?			Need to Improve?	Yes	Need to Improve?	Yes
		No				No			No
		+
		Validate Microtasks
		Implementation
		Microtask
	No	Implementation
		Valid?
		Yes
	No	Deliverable Completed?
		Yes

Table 1 :

 1 Mapping to UML and SysML.

	MBRE metamodel	UML / SysML mapping -abstract syntax
	Requirement	SysML::Requirements::Requirement

  AI Log Traces Analyzer This AI toolset analyzes system logs using text analytics, statistics, and NLP techniques to generate indications of current and prospective system health statuses, and current and future potential issues. ReleaseType: initial

	•UCReq2 -AI/ML-based Test Generation -use automated
	reasoning and ML techniques for the generation of opti-
	mal test suites.
	-ToolReq2 -Automatic Test Generator. This tool is
	meant for automatic test generation and prioritiza-
	tion for software-intensive cyber-physical systems using
	AI/ML techniques. ReleaseType: final
	-ToolReq4 -Model-based Test Case Generator. This
	suite provides automated test case and test code gen-
	eration using model-and AI-based approaches for test
	automation and test data determination. ReleaseType:
	intermediate
	•UCReq1 -Automated Anomaly Detection -automati-
	cally detect anomalies in cloud-based IoT infrastructures
	during the execution based on AI.

-ToolReq1 -AI/ML Anomaly Detector. This tool provides log and trace processing, and it uses AI/ML techniques to detect anomalies and flaws in them and provides diagnosis and prediction of potential issues. Re-leaseType: intermediate -ToolReq3 -Where initial, intermediate, and final are project milestones when versions of the framework architecture are released.

Table 2 :

 2 Key figures related to the DataBio, REVaMP2, MegaM@Rt2, VeriDevOps, and AIDOaRt projects in terms of RE activities.

	Number of	DataBio	REVaMP2	MegaM@Rt2	VeriDevOps *	AIDOaRt *
	Partners	48	27	27	7	31
	Countries	17	5	6	4	7
	Case studies	27	7	9	2	15
	Project months	36	36	36	36	36
	Registered users 55	43	56	15	100
	Contributors	31 (56%)	24 (56%)	27 (48 %)	7 (47%)	60 (60%)
	Commits	958	534	1322	328	2548
	Requirements:	=181	=535	=428	=124	=455
	(Case Study r.	77	190	106	39	363
	+ Framework r.	104	56	91	NA $	17
	+ Tool r.)	NA #	289		85	75
	Model elements † =5406	=3307	=4744	=2087	=9512
	(Requirements	535	1091	2351	1211	3507
	+ Architecture)	4871	2216	2393	876	6005
	Pages generated 61	109	125	120	∼160 x 11 ‡
	* Data from VeriDevOps and AIDOaRt were collected at months M28 and M24, respectively, corresponding to

Table 3 :

 3 Positive feedback in the surveys focuses on the importance of (1) collaborative teamwork on the model repository, (2) the continuous guarantee of the model consistency, (3) the usefulness of document generation, and (4) the satisfaction with the agile MBRE approach with the iterative definition and application of microtasks.

	The visualization and document generation aspects
	Getting rid of plain text (or MS Word) descriptions.
	Being able to detect inconsistencies easily.
	Consistency consistency consistency
	The teamwork module aspects!
	[. . . ] collecting data, subversion system, and revision control
	The centralized 'Ground truth' and the document generation.
	Central management of all requirements and links
	[. . . ] provides a project-wide basis for deeper analysis and research conclusions.
	The automatic generation of the documentation, link between the different software component
	[. . . ] on the other hand, through the MBRE and the use of Modelio it was possible to bring many industrial
	realities closer to model-based design and requirement management.
	From my experience the microtasks

were great Microtasks saved me a lot of time

  , [. . . ] the support given (especially by Modelio's team) in the documentation/instruction/video recording of each microtask made it very simple for me to do the tasks. [. . . ] microtasks remind me of test-driven development (TDD) -the project is good if you have TDD [. . . ] because the tasks are small and simple. [. . . ] AIDOaRt gained very much from these microtasks because they made it clear [. . . ] what to do, and how you could review that it had been done. We

have achieved significant advantages in requirements management and architecture when applied to European projects

  . I believe it is very useful for both project management and system (software) development.Supports in resource and timeline planning for RE engineeringThe achievable consistency of the different documents needed is absolutely great. It eases the writing of docs as well. Thanks! Visualization, uniform representation, traceability for large scale / complex systems It provides basic support for requirements

traceability and automated documentation generation.

  Keeping the overview of cross-relations once the model is evolving Learning to add information [. . . ] the initial install and the more or less hidden changes to the doc generation ... Installing the application on a non-Windows-based OS + Getting an overview where specific components could be found [We faced several problems with] MS Word in Modelio under MacOS and Linux. It is still much better than sparsely editing offline documents with a large number of collaborators! I think that adding a feature for generating documents from LaTeX snippets would be great. [...] As an academic who is used to work with LaTeX, my view is certainly biased. Difficulty in uploading Word documents from Linux.

https://cordis.europa.eu/project/id/732064

http://www.revamp2-project.eu/

https://megamart2-ecsel.eu/

https://www.veridevops.eu/

https://www.aidoart.eu/

More on Modelio SaaS at https://www.modeliosoft.com/, and its Modelio open source version at https://www.modelio.org/

additional public deliverables in AIDOaRt are available here: https://www.aidoart.eu/aidoart/results/deliverables

Acknowledgments

This work has received funding from the ECSEL Joint Undertaking under grant agreements No. 101007350 (AID-OaRt project) and No. 737494 (MegaM@Rt2 project), ITEA3 (REVaMP2 project No. 15010), and H2020 under grant agreements No. 732064 (DataBio project) and No. 957212 (VeriDevOps project).