1. Introduction
Today’s products are getting increasingly complex. Systems engineering (SE) is an established approach to tackle this complexity (INCOSE, 2023). However, current SE solutions fail to deliver on the promised benefits. Challenges such as the high manual effort in model creation and maintenance, inconsistencies across tools, and the cognitive load on engineers in dealing with extensive system models hinder efficiency and adoption (Reference Chami and BruelChami & Bruel, 2018). As artificial intelligence (AI) continues to gain importance across various industries, it is also impacting product development. From data-driven decision-making to automation of design and verification tasks, AI offers the potential to enhance SE processes (Reference Noy and ZhangNoy & Zhang, 2023). Particularly, the integration of AI into SE tools can improve existing bottlenecks by automating repetitive activities, supporting knowledge-based reasoning, and enabling adaptive assistance for engineers. Therefore, the integration of AI into SE tools is a promising path of fostering the drawbacks of manual SE (Reference Schrader, Bernijazov, Foullois, Hillebrand, Kaiser and DumitrescuSchrader et al., 2022). Especially since the hype around generative AI (GenAI) and more recently agentic AI has sparked several research initiatives, multiple use cases in that area have been documented in literature (e.g., Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022; Reference Patel, Maheshwaran and SanthyaPatel et al., 2024).
Currently, research around AI in systems engineering focuses on technical advancements rather than the design of the human-AI interaction. This is despite several advantages of having a suitable user interaction. Through understandable and trust-building interactions that give people control and insight into the behaviour of AI, a common understanding of tasks and system status is created, enabling both secure and sustainable collaboration in system development (Reference Hinsen, Hofmann, Jöhnk and UrbachHinsen et al., 2022). There are domain-independent solutions on how to design meaningful interactions between humans and AI systems (e.g., Reference Amershi, Weld, Vorvoreanu, Fourney, Nushi, Collisson, Suh, Iqbal, Bennett, Inkpen, Teevan, Kikin-Gil and HorvitzAmershi et al., 2019). Yet for SEAs, no overview about suitable solutions exists.
Against this background, the goal of this paper is to close this gap by systematically exploring the landscape of SE assistants and examining the role of human-AI interaction in their development. To purposefully consider interaction design in this context, a three-step process was developed, aiming at understanding the field of SEAs in general, to derive, how they are being developed for a later consideration of interaction design during SEA development, and lastly to identify already existing approaches on how to integrate interaction design into SEAs to build upon that.
Therefore, this paper aims at three main goals:
-
1. Get an overview of the landscape of SE assistants.
-
2. Understand current development processes of SE assistants.
-
3. Define the consideration of interaction design in the development of SE assistants.
To fulfil those goals, the paper is structured as followed: In chapter 2, important terms are introduced and general overview of the research field is provided. Thereafter, the research methodology is described in chapter 3. In chapter 4, the gathered results are presented, before the implications of the findings as well as the limitations of the methodology are discussed, and the resulting research agenda is derived in chapter 5. The paper closes with a brief conclusion and outlook in chapter 6.
2. Scientific context
For the understanding of this paper, a short introduction of key topics is necessary. First, the application domain systems engineering assistants will be introduced and then the theoretical domain of interaction design for AI systems with the focus of the advantages of good interactions will be analysed.
Systems Engineering (SE) is an interdisciplinary approach to developing complex systems. In the context of SE, processes and activities are typically complex, iterative, and multidisciplinary. They encompass tasks throughout the V-Model, defined in standard literature such as the INCOSE Handbook (INCOSE, 2023). As these tasks become increasingly data-intensive, there is growing interest in leveraging AI to support engineers in handling complexity, making decisions, and increasing process efficiency (Reference Crabb and JonesCrabb & Jones, 2024).
Some authors have examined the potentials of using AI in the context of SE. One emerging concept in this context is the systems engineering assistant (SEA). The term is gaining traction in recent literature to describe AI-enabled tools that actively support or automate SE activities (e.g., Reference Demagall, Apaza and SelvaDemagall et al., 2023; Reference Schrader, Bernijazov, Foullois, Hillebrand, Kaiser and DumitrescuSchrader et al., 2022). SEAs are conceptually aligned with software engineering assistants, which are established in the software engineering domain and support tasks such as code completion, bug detection, or test generation (Reference Savary-Leblanc, Burgueño, Cabot, Le Pallec and GérardSavary-Leblanc et al., 2023). Yet, there remains a lack of conceptual clarity for SEAs as research on SEAs is often application oriented. E.g., a maturity model was developed that classifies SEAs into six levels depending on their technological advancement. The responsibility of the AI for a task and the degree of automation increase with each level of the model (Reference Bernijazov, Dumitrescu, Hanke, Heißen, Kaiser and TissenBernijazov et al., 2025). Furthermore, recommendations for prompting techniques throughout the whole product development process have been derived based on experiments and expert knowledge (Reference Hovemann, Mpidi Bita, Aldade, Heißen and DumitrescuHovemann et al., 2025). Lastly, the potential of AI in SE has been indicated with the introduction of multiple use case implementations and future directions (Reference Schrader, Bernijazov, Foullois, Hillebrand, Kaiser and DumitrescuSchrader et al., 2022).
The other necessary perspective is on human-AI interactions. Well-designed human-AI interactions bring several advantages by raising the acceptance, trust, and user engagement. When AI systems are transparent, intuitive, and meet user expectations, people feel confident using them, which increases long-term adoption. As trust grows through consistent and positive experiences, users collaborate more effectively with AI, delegate tasks with less hesitation, and benefit from improved efficiency and decision quality. These successful interactions also create a positive feedback loop in which both users and AI systems learn and adapt, enhancing overall performance and satisfaction. Ultimately, good interaction design empowers users, reduces resistance, and supports smoother, more meaningful integration of AI into everyday work and life. (Reference Hinsen, Hofmann, Jöhnk and UrbachHinsen et al., 2022)
Furthermore, a well-designed delegation mechanism can vastly improve the output quality. Although AI-to-human delegation improves combined performance, human-to-AI delegation does not (Reference Fügener, Grahl, Gupta and KetterFügener et al., 2022). Currently, most AI systems miss an adequate amount of user interactivity and user agency (Reference Raees, Meijerink, Lykourentzou, Khan and PapangelisRaees et al., 2024). To enable software developers designing effective human-AI interactions, tools such as design guidelines, methods, and principles can be utilized. Most famous in recent years has been Microsoft’s guidelines for human-AI Interaction, which propose a set of best practices structured around phases of interaction, including initiation, adaptation, and feedback (Reference Amershi, Weld, Vorvoreanu, Fourney, Nushi, Collisson, Suh, Iqbal, Bennett, Inkpen, Teevan, Kikin-Gil and HorvitzAmershi et al., 2019).
Following this, the section introduces that the integration of AI into SE requires not only technological advancement through SEAs, but also the thoughtful design of human-AI interaction, ensuring that such assistants are trusted, accepted, and effectively used to enhance SE processes.
3. Research design
No literature about designing SEAs exists. Therefore, it was chosen to conduct a systematic literature with the goal to identify relevant academic publications in the context of AI-implementations for systems engineering. The general process followed Reference Webster and WatsonWebster & Watson (2002), and the documentation principles align with Reference vom Brocke, Simons, Niehaves, Riemer, Plattfaut and Clevenvom Brocke et al. (2009). The search string was constructed along three conceptual dimensions. The final query requires at least one term from each dimension to appear in the title, abstract, or keywords, i.e., the terms are connected via OR and the dimensions via AND:
-
• Domain: “Systems Engineering”, “MBSE”
-
• Technology: “AI”, “Artificial Intelligence”, “ML”, “Machine Learning”, “Data-Driven”
-
• Application: “Use Case”, “Application”, “Case Study”, “Implementation”, “Assistan*”, “co?pilot”
More specific terms such as “System Architecture” or “Agentic AI” were purposefully excluded, as they did not significantly increase the result quality, while introducing unwanted noise with publications from discipline specific solutions, such as software engineering.
The review was conducted in July of 2025, and all results obtained until then have been considered for screening. The search was executed in Scopus as the primary database, and Web of Science was added to ensure result saturation. No further filtering has been applied, as the total result set has not been too extensive and bias through filtering should not be introduced. Further information systems literature through databases like AISeL or computer science literature through acm did not add new publications.
In new and evolving fields, it is reasonable to include “grey” literature in the review process (Reference Garousi, Felderer and MäntyläGarousi et al., 2019). Thus, arXiv has been searched for relevant preprints to find the most recent insights. The search resulted in 55 results; however, none of them were found to be relevant later. After removing duplicates, a total of 3,129 publications were retrieved. Through title and abstract screening based on predefined inclusion criteria, focusing on studies of AI-based implementations in the context of systems engineering, 102 papers were retained. Forward and backward citation tracking yielded an additional 16 relevant sources. A subsequent full-text screening resulted in 27 highly relevant papers.
During the full-text screening, relevant passages were marked and categorized into characteristics of the artefacts. Those included three topics: characteristics, development process, and human-AI interaction.
4. Results
The results section is organized into three subsections to provide an overview of our findings. The first subsection presents the characteristics of SEAs. The second subsection delves into the current development processes used for creating SEAs. The third subsection examines the role of interaction design in SEAs and in their development workflows. An overview of the results is shown in Figure 1. The left and right box show the input and output of the SEAs, while the middle box shows the general characteristics. The round brackets indicate the number of occurrences in the literature.
Characteristics of systems engineering assistants
Figure 1 Long description
The table is divided into three main sections: Input, System, and Output. Each section contains various categories and subcategories that describe the characteristics of systems engineering assistants. The Input section includes categories such as Artefact, Information, and Interaction, with specific items listed under each. The System section is divided into categories like Label, Domain, UI-Design, Interaction Design, Process Step, User, Technology, Task, and Integration, each containing specific items. The Output section includes categories such as Artefact, Information, and Interaction, with specific items listed under each. Each row in the table provides detailed information about the items within these categories.
4.1. Characteristics of systems engineering assistants
In this subsection, the characteristics of SEAs will be stated to establish an understanding of the scope of assistant systems. Eight characteristics could be identified: supported process, task, domain, user, value proposition, technology, integration, and label.
Supported process: Systems engineering typically follows a standard process. The examined tools cover either a specific step or are overarching. Is was found that most of the tools support a specific process step, with a strong focus on requirements engineering (e.g., Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al., 2025; Reference Maleki, Jazdi and AshtariMaleki et al., 2022) and even more on system architecture design (e.g., Reference Guariniello, Mockus, Raz and DeLaurentisGuariniello et al., 2019; Reference Lameh, Dubray and JankovicLameh et al., 2025). Tools for system design (Reference Nabizada, Jeleniewski, Gehlhoff and FayNabizada et al., 2024b) or verification and validation (Reference Bleisinger, Keil and EignerBleisinger et al., 2024) are only found in isolated cases. In contrast, a variety of tools supports overarching processes such as the early phases of product development (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019). They mainly support the tasks of knowledge structuring (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019) or process support (e.g., Reference Gauthier, Jenn and ConejoGauthier et al., 2025).
Task: Within each process step, a variety of tasks can be AI-supported. Five tasks that are already being implemented were identified. The most implemented task by far is artefact generation. Examples include requirements (e.g., Reference Hegedűs, Varga and HongHegedűs & Varga, 2024; Reference Lameh, Dubray and JankovicLameh et al., 2025), system architectures (e.g., Reference Lameh, Dubray and JankovicLameh et al., 2025), or domain-specific files (e.g., Reference Nabizada, Jeleniewski, Beers, Gehlhoff and FayNabizada et al., 2024a). This is either done from scratch, using textual prompts with instructions (Reference Johns, Carroll, Medina, Lewark and WalliserJohns et al., 2024), or based on some artefact from a previous process step, such as requirements for generating the system architecture (Reference Guntupalli and WatanabeGuntupalli & Watanabe, 2024). Another task is the analysis of an existing artefact. This could be error checking within one artefact (Reference Guntupalli and WatanabeGuntupalli & Watanabe, 2024) or consistency checking between multiple artefacts (Reference Sultan and ApvrilleSultan & Apvrille, 2024). General automation of process steps has also occurred a few times (e.g., Reference Maleki, Jazdi and AshtariMaleki et al., 2022). Another task is the design support. An example is the recommendation of model elements (e.g., Reference Kulkarni, Tissen, Bernijazov and DumitrescuKulkarni et al., 2024). The last task is evaluation, which can be for example the ranking of multiple design alternatives (e.g., Reference Guariniello, Mockus, Raz and DeLaurentisGuariniello et al., 2019).
Domain: By domain, we refer to the context in which the system is used. A strong focus in the reviewed literature lies on cross-domain systems or systems where the domain is not explicitly specified (e.g., Reference Apvrille and SultanApvrille & Sultan, 2024; Reference Crabb and JonesCrabb & Jones, 2024). Nevertheless, there are approaches that have been developed within specific contexts such as automotive, aerospace, or manufacturing, which consider distinctive characteristics, processes, and constraints of these domains (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019; Reference Schleifer, Lungu, Kruse, van Putten, Goetz and WartzackSchleifer et al., 2024).
User: The user of a system directly interacts with it, so he is the most relevant stakeholder when it comes to interaction design. In contrast to other characteristics, almost all studied papers contain a description of the target user. The main user that was identified is the systems engineer or system engineer (e.g., Reference Krishnan, Coronado and ReedKrishnan et al., 2019; Reference Maleki, Jazdi and AshtariMaleki et al., 2022). In literature, those roles are not clearly differentiated, so they are used interchangeable here. Another key user is the system architect, who oversees the whole system, but with a focus on the system architecture (Reference Apvrille and SultanApvrille & Sultan, 2024). Only a few systems target a domain user from, e.g., software engineering (e.g., Reference Biffl, Berardinelli, Maetzler, Wimmer, Lueder and SchmidtBiffl et al., 2015) or simulation (e.g., Reference Bleisinger, Keil and EignerBleisinger et al., 2024).
Value Proposition: Some of the literature provided reasons, why the application of AI might be useful for the use case. It is important, that the proposed value is usually not evaluated. Six value propositions of using the SEA rather than manual engineering have been extracted. The system values from the literature illustrate that current approaches to systems engineering assistance systems are primarily focused on quality and efficiency. The most frequent value proposition is improved quality (e.g., Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al., 2025), followed by improved efficiency (e.g., Reference RudolphRudolph, 2024). Another value proposition that has been mentioned a couple of times is the reduction of human errors (Reference Gauthier, Jenn and ConejoGauthier et al., 2025). Although it may appear similar to enhanced quality, we have deliberately made a distinction here, as the focus is on the human engineer. In some cases, a reduction in system complexity (e.g., Reference Johns, Carroll, Medina, Lewark and WalliserJohns et al., 2024) and automation of repetitive tasks (e.g., Reference Demagall, Apaza and SelvaDemagall et al., 2023) are also mentioned.
Technology: To solve a specific use case, multiple technological options are available. The technological basis of the assistance systems examined shows a clear focus on large language models (LLMs) (e.g., Reference Crabb and JonesCrabb & Jones, 2024; Reference Sultan and ApvrilleSultan & Apvrille, 2024). A variety of use cases also relies on classic machine learning (e.g., Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022) and natural language processing approaches (e.g., Reference Maleki, Jazdi and AshtariMaleki et al., 2022). Isolated works integrate agentic behaviour (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019) or algorithmic methods to map specific decision-making or optimisation problems in system design (e.g., Reference Biffl, Berardinelli, Maetzler, Wimmer, Lueder and SchmidtBiffl et al., 2015). Only a few publications deal with knowledge graphs as a semantic basis for assistance systems, although they would be particularly suitable for traceability and explainable decisions due to the semantic representation (Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019).
Integration: Two main approaches dominate the integration of assistance systems in current research. Most of the systems are directly integrated into existing system engineering tools, so they are an extension of existing modelling and development environments. This close integration enables users to receive support in their familiar working context (Reference Sultan and ApvrilleSultan & Apvrille, 2024). In contrast, there is a slightly smaller group of standalone applications that operate independently of existing tools (e.g., Reference Kulkarni, Tissen, Bernijazov and DumitrescuKulkarni et al., 2024).
Label: It was found that, while a variety of terms are being used, sometimes describing the specific implementation, such as “TToolAI” (Reference Apvrille and SultanApvrille & Sultan, 2024) or “iQBuddy” (Reference Kulkarni, Tissen, Bernijazov and DumitrescuKulkarni et al., 2024), only one instance labelled as a “Copilot” (Reference Hegedűs, Varga and HongHegedűs & Varga, 2024) was found. For the remaining instances, the majority circles around the term “assistance system” (Reference Schrader, Bernijazov, Foullois, Hillebrand, Kaiser and DumitrescuSchrader et al., 2022) or “assistant system” (Reference Schleifer, Lungu, Kruse, van Putten, Goetz and WartzackSchleifer et al., 2024) with variations such as “Digital Engineering Assistant” (Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019), describing the domain more specifically, “Virtual Assistant” (Reference Demagall, Apaza and SelvaDemagall et al., 2023) concretising its appearance, or “LLM-based Assistant” (Reference Gauthier, Jenn and ConejoGauthier et al., 2025) with regards to the used technology.
4.2. Development process of systems engineering assistants
The focus of this subsection is to investigate how existing systems engineering use cases and assistant systems were developed. The derived process is described in Figure 2. Each element indicates a distinct step in the process. The number in the round brackets states the number of occurrences in the literature. All process steps are optional.
Development process of SEAs
Development Processes: First, most processes start with some sort of requirements definition (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019; Reference Demagall, Apaza and SelvaDemagall et al., 2023). This can happen in collaboration with stakeholders (Reference Schrader, Bernijazov, Foullois, Hillebrand, Kaiser and DumitrescuSchrader et al., 2022). Requirements can be directed towards the system, e.g., the integration in a modelling environment (Reference Sultan and ApvrilleSultan & Apvrille, 2024), or towards the technical implementation, such as output quality (Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022). Following that, some start the implementation (e.g., Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022), others derive a software architecture first (e.g., Reference Kulkarni, Tissen, Bernijazov and DumitrescuKulkarni et al., 2024). After the system implementation, the AI model can be trained (Reference Sultan and ApvrilleSultan & Apvrille, 2024). The model is then evaluated and improved if needed (Reference Bleisinger, Keil and EignerBleisinger et al., 2024). The final step is the system evaluation, where aspects such as usability or fulfilment of stakeholder requirements are checked (Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019).
Output Evaluation: When talking about output evaluation, it can be viewed as the evaluation of the artefacts or the provided information by the system. Due to the nature of scientific literature, some kind of evaluation is often part of a publication. It can also be understood as an evaluation of the “AI”-components of the system (Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022). Depending on the kind of output and the evaluation goal, the evaluation can have a varying focus. For one, the output can be mathematically examined with regards to its quality (e.g., Reference Hegedűs, Varga and HongHegedűs & Varga, 2024), correctness (e.g., Reference Nabizada, Jeleniewski, Beers, Gehlhoff and FayNabizada et al., 2024a), or consistency (e.g., Reference Schleifer, Lungu, Kruse, van Putten, Goetz and WartzackSchleifer et al., 2024). Another option in the case of generation is the manual analysis of the generated output based on predefined dimensions (e.g., Reference Heissen, Hanke, Mpidi Bita, Hovemann and DumitrescuHeissen et al., 2024; Reference Timperley, Berthoud, Snider and TryfonasTimperley et al., 2025).
System Evaluation: In contrast, the system evaluation is concerned with the overall system. Only five publications included some form of system evaluation, most commonly involving user testing. This can be done during the development phase to keep the user in the loop (Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019), or after the implementation (Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022) to show and evaluate the functionality of the system (Reference Gauthier, Jenn and ConejoGauthier et al., 2025). This especially includes checking the effectiveness of system instructions and the support of the user through the system (Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al., 2025). Hints and tips for the user while using the system it increase usability and thus are being appreciated. What hinders a good experience is a slow response time of a system (Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022).
4.3. Interaction design in systems engineering assistant development
In this third subsection, the focus is on structuring, whether interactions with identified SEAs have actually been designed or just “chosen” based on recent technology advancements. Three main categories for both the input and output interactions were identified: artefact, information, and interaction. After that, the to what the interaction has been designed is stated, following a certain method or process, and the goal of the interaction.
Input artefacts: In our understanding, the transmitted artefact is the specific work product that is used to initiate the SEA. This could be some document or a system model. Analysis of the artefacts used shows that the assistance systems examined in systems engineering have a clear focus on system models and requirements as inputs (e.g., Reference Guntupalli and WatanabeGuntupalli & Watanabe, 2024; Reference Nabizada, Jeleniewski, Gehlhoff and FayNabizada et al., 2024b)). Documents and specifications are used less frequently (e.g., Reference Patel, Maheshwaran and SanthyaPatel et al., 2024), Design principles, parameters, and results occur only sporadically (e.g., Reference Lameh, Dubray and JankovicLameh et al., 2025).
Input information: Information will be defined as any additional input that is given to the assistant system besides the artefact. Our analysis shows that the systems primarily rely on descriptive and context-related information. Descriptions are used most frequently (e.g., Reference Lameh, Dubray and JankovicLameh et al., 2025). Constraints and contextual information are also used multiple times (e.g., Reference Bleisinger, Keil and EignerBleisinger et al., 2024). Goals towards the engineering task are also cited as a relevant type of information (e.g., Reference Gauthier, Jenn and ConejoGauthier et al., 2025). Questions and system model information, i.e. information that either arises from user interaction or is extracted from existing system models, appear much less frequently (e.g., Reference Guariniello, Mockus, Raz and DeLaurentisGuariniello et al., 2019).
Input interaction: The interaction describes the way that either the artefact or the information is provided to the system. The most frequent interaction by far is prompting (e.g., Reference Heissen, Hanke, Mpidi Bita, Hovemann and DumitrescuHeissen et al., 2024). As a result, interaction is controlled less by structured forms or clearly defined model elements and more by a dialogue-oriented exchange between user and system. Structured forms of interaction, such as checkboxes (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019) occur much less frequently. Similar, alternative input methods such as uploads, numerical inputs, whiteboards or voice inputs are only used sporadically (e.g., Reference Bleisinger, Keil and EignerBleisinger et al., 2024; Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022).
Output artefacts: Analysis of the output artefacts shows that the assistance systems predominantly generate system model-centric results (e.g., Reference Crabb and JonesCrabb & Jones, 2024; Reference Timperley, Berthoud, Snider and TryfonasTimperley et al., 2025). Domain files and requirements are also mentioned as outputs (e.g., Reference Nabizada, Jeleniewski, Beers, Gehlhoff and FayNabizada et al., 2024a; Reference Patel, Maheshwaran and SanthyaPatel et al., 2024). System elements appear only in a few cases, suggesting that the detailed modelling of individual structures has been less addressed to date (e.g., Reference Kulkarni, Tissen, Bernijazov and DumitrescuKulkarni et al., 2024).
Output information: The evaluation of the output information shows that the assistance systems primarily provide result-oriented feedback (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019). This information is mostly used to provide feedback on the current system status or on the quality of the results of the model created (e.g., Reference Guntupalli and WatanabeGuntupalli & Watanabe, 2024). In addition, some systems provide information on modelling or architecture evaluations (e.g., Reference Demagall, Apaza and SelvaDemagall et al., 2023). Instructions are also mentioned several times (e.g., Reference Hegedűs, Varga and HongHegedűs & Varga, 2024).
Output interaction: Analysis of output interactions shows that the systems mostly provide their results in a structured, model- or file-based form (e.g., Reference Apvrille and SultanApvrille & Sultan, 2024; Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al., 2025; Reference Johns, Carroll, Medina, Lewark and WalliserJohns et al., 2024). In addition, text outputs appear relatively frequently (e.g., Reference Guariniello, Mockus, Raz and DeLaurentisGuariniello et al., 2019). Less common are tables or matrices, which are mostly used for the structured presentation of evaluation results or comparative data (e.g., Reference Biffl, Berardinelli, Maetzler, Wimmer, Lueder and SchmidtBiffl et al., 2015; Reference Bourdon, Rodriguez, Lesigne, Suchet, Fister, Montagne, Malhomme, Benmiloud-Bechet and PlanaBourdon et al., 2025).
Consideration of interaction design: Only eight out of the 27 examined sources mention some degree of conscious interaction design. One aspect that was included here is prompt engineering. It is not necessarily a part of typical interaction design practices, but a central mechanism to improve LLM-based assistants. Two publications deal with prompt engineering (e.g., Reference Hovemann, Mpidi Bita, Aldade, Heißen and DumitrescuHovemann et al., 2025; Reference Timperley, Berthoud, Snider and TryfonasTimperley et al., 2025). One further aspect mentioned a few times is the principle of human-in-the-loop, meaning that the user has been involved during the design of the interaction to provide feedback for improvement (e.g., Reference Sultan and ApvrilleSultan & Apvrille, 2024). Interaction design has been addressed just as rarely via role-based approaches (e.g., Reference Gauthier, Jenn and ConejoGauthier et al., 2025) or expert surveys to gather an initial set of requirements (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019). Only one publication mentioned the use of specific human-machine interaction methods (e.g., Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019).
Value of designed interactions: Also, very few publications mention the purpose or the goal of the interaction design process. Four aspects can be observed. Improved know-how is most frequently mentioned. It means, that the systems are not only designed to automate tasks but are also understood as learning and support tools (Reference Castellanos-Paez, Hili, Albore and Pérez-SanagustínCastellanos-Paez et al., 2022). Another aspect is the fulfilment of user needs, which is concerned with user-friendliness (Reference Berquand, Murdaca, Riccardi, Soares, Genere, Brauer and KumarBerquand et al., 2019). Also mentioned was the improvement of the output quality, enabling the user to make better decisions (Reference Maleki, Jazdi and AshtariMaleki et al., 2022). The last aspect is the improved efficiency, speeding up the development process (Reference Demagall, Apaza and SelvaDemagall et al., 2023).
5. Discussion, limitations, and research perspectives
The results have implications for the scope of SEAs as well as for future research. Furthermore, as a systematic literature review has been conducted, the results come with some limitations due to that method. All of this will be detailed in this chapter.
5.1. Discussion
Our analysis shows that current research primarily supports tasks requiring structural and model-driven decision-making, particularly during system architecture design. Late phases of systems engineering are only marginally addressed by existing assistance systems. Verification and validation aspects appear only in isolated cases, indicating that later development stages have so far received limited attention. This gap highlights a significant research opportunity to develop concepts for continuous assistance throughout the entire SE process. Alternatively, it could indicate the need to assist more towards the early phases. The exact reasons could not be extracted from the literature.
Further research is necessary to assess the role of domain specificity in SEA development. It remains unclear whether tailored, domain-specific systems are needed or whether more generic designs might yield wider applicability. At the same time, the actual demand and perceived benefit of domain-specific approaches must be systematically investigated to guide future design strategies.
Current systems tend to emphasise cognitive relief and standardisation, while creative-cognitive support is rarely considered. The limited reporting of enhanced creativity (e.g., Reference Guntupalli and WatanabeGuntupalli & Watanabe, 2024) suggests that fostering creativity in engineering processes remains an underexplored but promising direction.
Most of the systems are directly integrated into existing system engineering tools, which indicates a desire to provide assistance functions as an extension of existing modelling and development environments rather than creating completely new experiences. The meaningfulness of that approach must be observed further, as it, especially in conjunction with organisational change, could lead to relevant insights. It also must be explored further, if the integration in existing tools leads to using the most effective forms of interactions or if tools designed from scratch can embrace those more ideally.
Although development processes are often described only briefly, the findings suggest that established software engineering practices or selected subsets remain predominant. This observation indicates methodological maturity but also limited adaptation to the specific requirements of SEA development. Understanding these processes supports identifying opportunities for the early integration of interaction design considerations.
Evaluation of system outputs remains scarce. In one documented example, manually created system models still outperformed automatically generated ones due to human expertise (Reference Johns, Carroll, Medina, Lewark and WalliserJohns et al., 2024). Regarding input artefacts, current systems mainly operate in analytical and structure-oriented modes, while exploratory and creative processes based on design knowledge are rarely addressed. Similarly, the low use of interactive or model-internal knowledge indicates limited incorporation of dynamic input data.
A clear trend towards intuitive, generative, and natural-language-based interactions is visible. This is driven by the current trend of using large pre-trained models for text-based reasoning, knowledge extraction, and support in complex engineering contexts. Such approaches position the assistance system as an active dialogue partner while structured, model-integrated interaction remains secondary. The integration of interaction design considerations into technical assistance systems is still at an early stage, leaving significant potential to make future SEAs more human-centred, application-oriented, and explainable. The specific benefits to be gained would need to be identified in more detail in the context of systems engineering.
Findings further confirm that well-designed interactions improve both user experience and task outcomes. The main benefit lies in qualitative enhancement of interaction rather than in purely technical improvements, underlining the value of integrating design thinking into technical development.
Current results show that interaction aspects have mostly emerged as by-products of technical decisions rather than outcomes of structured design. To leverage the full potential of SEAs, interaction design should be treated as a core development element. Early integration during requirements specification can ensure systematic consideration of user needs, usage contexts, and interaction goals. In architecture and implementation phases, these criteria should guide interface and communication mechanism design to ensure transparency, usability, and adaptability in real engineering contexts. Evaluation should explicitly address user experience, acceptance, and trust in addition to functional performance. Interdisciplinary collaboration among systems engineering, human–computer interaction, and cognitive ergonomics will be essential to create SEAs that are not only technically competent but also well-embedded in engineering workflows and cognitive processes. Hence, interaction design in SEAs should evolve from an implicit, technology-driven by-product to a methodologically defined and systematically applied design dimension.
This paper makes three core contributions. First, it structures the research space of AI-assisted systems engineering and SEAs by identifying relevant characteristics. This provides a theoretical foundation complementing existing technical insights. Second, it outlines typical SEA development processes, enabling further research on how to integrate interaction design principles into SEA development that will be considered by the developer. Third, it documents initial efforts to design user interactions for SEAs, highlighting current reasoning and stating early design approaches aimed at improving human-SEA interaction.
5.2. Limitations and research perspective
Despite the systematic approach, limitations remain. Empirical studies are limited, as many detailed insights are contained in unpublished reports or internal documents. Due to the small number of published SEAs, the findings need to be treated with care and represent more of an intermediate state. Rapid technological progress further constrains the completeness of available evidence. While grey literature was included to increase timeliness, complementary expert interviews or workshops are needed to capture current practice more comprehensively and to find out more about the underlying motivation and thought processes.
Two main research directions arise. First, further work should investigate why interaction design currently plays only a minor role in SEA development despite its proven value in related domains. Interviews with SEA developers and systems engineers could shed light on barriers and opportunities. Second, deriving and comparing existing interaction patterns with those established in human–computer interaction literature could help identify both shared and domain-specific characteristics. These insights would support the creation of improved interaction patterns that can be co-developed and validated with industry experts through prototypes.
6. Conclusion
The increasing complexity of today’s products holds significant challenges to traditional SE approaches, many of which have struggled to deliver the efficiency, accuracy, and scalability demanded by modern development environments. The research explored the emerging role of AI in addressing these shortcomings through SEAs. Central characteristics and trends of SEAs haven been shown. It has further been explained how SEAs are currently developed and a typical development process has been derived. Current interactions between the user and the SEA have been examined as well and the role of interaction design in SEA development was discussed.
The analysis shows that SEAs are a promising means of coping with increasing complexity in SE, but so far, their development has been heavily technology oriented. Interaction design has only been considered sporadically, even though it offers significant advantages in terms of user acceptance, trust and work performance. We argue that interaction design should play a central role in future SEA development. Not as an afterthought, but as an integral component of the engineering process. Incorporating established human-AI design principles into SE-specific contexts holds promise for enabling assistants that not only provide accurate and relevant outputs but also actively support engineers in decision-making, creativity, and collaboration. Our findings highlight the need for dedicated interaction design frameworks for SEAs that ensure effective human-AI collaboration, enabling engineering practices to meet the demands of increasingly complex system lifecycles.
Open access
