1. Introduction
Engineering complex systems demands seamless collaboration across diverse stakeholders from different disciplines. Model-Based Systems Engineering (MBSE) offers a framework to align their perspectives. Central to MBSE are views that provide stakeholder-concern-specific information about the system under development to enhance alignment and decision-making (ISO/IEC/IEEE, 2022). While theoretically well-established, there is a lack of systematic studies on adapting views and viewpoints in engineering systems. The ICED25 motto, “Design is a Team Sport,” highlights that the development of complex engineering systems necessitates close collaboration among diverse stakeholders throughout the entire lifecycle. Engaging users, engineers, and business leaders from initial conception to final deployment ensures that the solutions effectively meet the heterogeneous needs (Reference Nakata and ImNakata & Im, 2010). However, numerous barriers inhibit the effective integration of stakeholders in MBSE.
Despite their theoretical promise, the practical utility of views in MBSE remains underexplored, particularly in industrial contexts. Views are intended to bridge the gaps between stakeholders, offering tailored representations that support better communication, collaboration, and decision-making. However, it remains unclear whether these theoretical benefits are being realized in practice or whether challenges such as tool limitations, organizational aspects, stakeholder misalignment, or methodological barriers hinder their effective use (Henderson et al., Reference Henderson, McDermott and Salado2024; Mandel et al., Reference Mandel, Martin and Albers2022; Weilkiens, Reference Weilkiens, Madni, Augustine and Sievers2022). Numerous educational and scientific publications illustrate how stakeholders could theoretically engage with and derive value from an MBSE system model (cf. Figure 1):
Prototypical illustration of the stakeholders’ involvement in MBSE (Reference Madni and PurohitMadni & Purohit, 2019)
However, it remains unclear whether and to what extent stakeholders are involved in using system models and to what extent stakeholders benefit from information depicted in MBSE models in industrial practice. While MBSE, with its tools and complex frameworks, is increasingly adopted (Weilkiens, Reference Weilkiens, Madni, Augustine and Sievers2022; Dumitrescu et al., Reference Dumitrescu, Albers, Riedel, Stark and Gausemeier2021), anecdotal evidence and initial observations suggest that views are inconsistent and often poorly understood. Stakeholders, particularly those outside traditional engineering roles, frequently report difficulties engaging with MBSE processes in practice (Reference Madni and SieversMadni & Sievers, 2018). Specifically, abstract representations and views created with modeling languages (e.g., SysML) lead to a significant learning curve, often resulting in information overload (Henderson et al., Reference Henderson, McDermott and Salado2024; Madni & Sievers, Reference Madni and Sievers2018). Individual modeling experts frequently act as translators, bridging the gap between the technical representation and the practical understanding needed by various stakeholders across different model islands (Kaiser et al., Reference Kaiser, Wilke, Förster, Köhler and Dumitrescu2024; Weilkiens, Reference Weilkiens, Madni, Augustine and Sievers2022).
As a first step towards improving stakeholder participation using views, this explorative study examines how and to which extent views and viewpoints are already utilized in industrial practice. We seek to understand stakeholders’ motivations, needs, and expectations regarding using views, ultimately identifying pathways to enhance their effectiveness and uncovering opportunities for refinement. Specifically, our research addresses the following questions:
1. How are views and viewpoints utilized to integrate diverse stakeholders in MBSE in industry?
2. What challenges and potentials exist in introducing and using views and viewpoints
2. Theoretical background
MBSE has increasingly established itself as a central approach for managing the complexity of modern systems, wherein mechanical, electronic, and software elements interact in ever more intricate ways. As engineering efforts become more interdisciplinary and distributed, MBSE offers a structured, model-centric paradigm to capture, integrate, and maintain cross-domain information throughout the system lifecycle (Reference Walden, Shortell, Roedler, Delicado, Mornas, Yew-Seng and EndlerWalden et al., 2023). By formalizing systems in a unified model - the so-called system model, MBSE intends to improve traceability, consistency, and communication, enabling more informed decision-making under rising technical and organizational complexity (Reference Dumitrescu, Albers, Riedel, Stark and GausemeierDumitrescu et al., 2021). A key aspect of MBSE is accommodating stakeholders’ diverse perspectives and information needs, including engineers, managers, regulators, or end-users. Each stakeholder may have distinct priorities and concerns, such as technical feasibility, regulatory compliance, usability, cost efficiency, or time-to-market. The International Standard ISO/IEC/IEEE 42010 (2022) provides a conceptual framework to address this multiplicity of viewpoints by defining key concepts, like architecture description, Viewpoint, and View.
The element system in the conceptual model refers to the system under consideration, which has an inherent architecture. The architecture description is the set of artifacts that capture and convey this architecture. Its goal is to express the system’s architecture in a way that addresses various stakeholders’ information needs and concerns. In MBSE, the system model is a central element of the architecture description, often created with formal modeling languages like SysML. This model formalizes the system architecture and integrates engineering information across disciplines, ensuring consistency, traceability, and informed decision-making. While research explores novel visualizations, such as CAD-integrated representations, these approaches are rarely designed with stakeholder-specific perspectives within the concept of views and viewpoints and often see limited adoption in industrial practice (Meussen, Reference Meussen2021; Henderson & Salado, Reference Henderson and Salado2021).
The architecture description includes views that highlight specific stakeholder concerns. A View is a curated collection of representations derived from the system model and may present information at different levels of abstraction or in different formats, depending on stakeholder needs. Each View is governed by a Viewpoint, which defines the conventions, modeling rules, and guidelines for constructing and interpreting that type of View. The resulting views are effectively tailored to their intended audiences by connecting viewpoints to stakeholder concerns. (ISO/IEC/IEEE, 2022)
3. Research design
To answer our research question, we engaged with practitioners and analyzed their perspectives. The following sections describe how we gathered and analyzed data to gain insights.
Data collection
An exploratory interview study was conducted using purposive sampling to select eight professionals responsible for MBSE implementation, modeling, and process design across multiple industry sectors, including agricultural technology, mechanical engineering, the automotive industry, household appliances, and consulting services in systems engineering. The data collection process followed the recommendations of Eisenhardt (Reference Eisenhardt1989) and was organized into four phases: 1) preparing an interview guide, 2) selecting companies, 3) conducting the interviews, and 4) documenting the interviews. Semi-structured interviews, guided by an interview guide, were chosen to address the research question effectively. The interview guide explores the use, challenges, and improvements of views and viewpoints in MBSE from a user perspective. It consists of three sections:
-
General questions about the company and MBSE maturity: This section aims to collect demographic information and provide a general overview of MBSE usage in the company, including the interviewees’ roles, the experience with MBSE implementation, and the tools used.
-
Specific questions on Views: Participants first described their understanding of ‘View and Viewpoint’ before receiving a standardized definition. Then, the use of views in MBSE, the existence of standard views, their management, and benefiting stakeholders is examined.
-
Challenges and improvement potentials: This section addresses the existing challenges in using views and viewpoints to improve the process of creating and using views.
Eight interviews were conducted for this study, which aligns with recommendations for case study research as suggested by Eisenhardt (Reference Eisenhardt1989). The sample exhibited heterogeneity regarding the interviewees’ positions, company revenues, workforce sizes, MBSE maturity level, and product portfolios. Each participant held a key role in MBSE implementation, actively engaging in modeling activities and the design of processes incorporating views and viewpoints. Details of the interviewees and the case companies are outlined in Table 1:
Overview of interview participants
Data Analysis
The analysis used a Grounded Theory approach, systematically exploring themes and patterns within the participants’ experiences (Glaser & Strauss, Reference Glaser and Strauss1967; Corbin & Strauss, Reference Corbin and Strauss2015). Grounded Theory was chosen to derive theory from empirical data, making it ideal for examining the construction and use of views. Its iterative coding process uncovers patterns and relationships in participant experiences. The analysis followed three stages: open coding to identify categories, axial coding to refine them, and selective coding to synthesize core themes. (Reference Corbin and StraussCorbin & Strauss, 2015).
The interview transcripts were coded using MAXQDA, starting with in-vivo coding to minimize premature interpretations and bias. Categories and themes were then identified. Coding was conducted in German to preserve nuances, with two researchers from different institutes collaborating: In this study, we ensured coding consistency through an iterative discussion-based process, and for future research, we plan to incorporate inter-coder reliability metrics to enhance methodological rigor further. Once core themes were established, findings were translated into English, ensuring accuracy through joint review. Ethical considerations included informing participants, obtaining consent, and anonymizing transcripts.
4. Results
In this section, the results of the study are presented. First, we show the stakeholder involvement according to our observations in practice. Next, we illustrate the specific topics surrounding views and viewpoints. Finally, challenges and potential are presented. Direct quotes refer to the interviewees in Table 1, abbreviated as, e.g., Int E for interviewee E. Overall, we identified a variety of challenges:
Fields of action identified by the interview study
4.1. Stakeholder involvement in the MBSE process
At the early stages of MBSE adoption, stakeholder involvement is typically confined to technical experts such as system architects or requirements engineers. One interviewee described their focus as “primarily on requirements management” [Int E]. As companies progress in their MBSE maturity, additional roles, including product architects and domain-specific experts, become more frequently involved. However, non-technical stakeholders, such as those from marketing and sales, largely remain excluded from MBSE activities. The roles of system engineers and product managers also differ across companies. One interviewee noted that “non-technical departments are generally more likely to be reported indirectly from the technical departments” [Int H]. He further elaborated: “Product managers provide input for the MBSE process […] but do not work in tooling and cannot operate any tools” [Int H]. Another interviewee remarked, “All our views so far are more geared towards engineers” [Int C]. To some extent, involvement also depends on individual personalities: “Some feature managers even modeled themselves, others had to be [...] taken by the hand, [...], others were more of a complete refusal” [Int E]. These statements highlight a distinct separation between managerial and technical roles and responsibilities. Stakeholder involvement in MBSE processes varies significantly between companies, primarily depending on their MBSE maturity level. Notably, non-technical stakeholders are rarely included. Current MBSE practices in industry engage and benefit significantly fewer stakeholders than what is described in scientific literature or illustrated in conceptual models (cf. Figure 1).
4.1.1 Challenges in Adopting New Roles and Stakeholder Integration in MBSE
An issue involves integrating and accepting new roles within the MBSE process. As one interviewee described: “In the beginning, it was like this: when these new roles - the architect, the requirements manager, and the V&V engineer - were defined, it was not even possible to align them properly in terms of personnel” [Int E]. Early resistance arose due to unclear responsibilities and overlapping roles. The challenge of identifying the right stakeholders was also emphasized. One interviewee stated: “The first challenge is to know who you need” [Int A].
4.1.2. Knowledge Transfer and Effort/Benefit
Integrating stakeholders into MBSE is associated with substantial challenges, particularly in demonstrating a return on investment, even at the individual level. One interviewee points out the time required to acquire MBSE knowledge as a challenge: “learning and the time you need to understand it. […] Familiarizing yourself with all these concepts is very time-consuming. People say: Does this additional effort justify the added value I get from it?” [Int B]. A significant barrier lies in knowledge transfer and training, with stakeholder acceptance playing a pivotal role. One interviewee asked: “[…], how can we reduce this barrier to entry? Can we offer a reduced SysML where we provide as much guidance as possible to make it easier to start?” [Int G].
The added value of MBSE can be particularly elusive when used primarily as a documentation tool. However, its benefits become clearer when leveraged as a design tool supporting systems engineering through specialized modeling languages. Variability in commitment levels toward MBSE implementation is also evident. “A lot has happened in the last few months and I would say there is more commitment on the part of management, and the demand has also increased” [Int A]. Advances are often tied to stakeholder engagement spanning a spectrum - from proactive modeling involvement to skepticism about MBSE’s necessity.
These accounts illustrate diverse experiences with MBSE adoption across teams and organizations. Key challenges include demonstrating MBSE’s value, addressing the significant time and effort required for training, and managing varying levels of stakeholder commitment. Addressing technical and cultural factors is essential for successfully integrating MBSE into existing workflows.
4.1.3. Challenges Posed by Version Management and Fragmented Models
Models in MBSE are inherently complex, mainly due to different product versions, varying model states throughout the project lifecycle, and the fragmentation of system models into different files, formats, and tools. One interviewee emphasized the challenge of version management, stating, “It must also always be clear: Which version are you referring to with a View?” [Int B]. Another interviewee highlighted issues with fragmentation and duplication, noting, “Fragmented models, there are also some copies” [Int H]. These challenges complicate stakeholder communication and hinder the collaborative potential of MBSE views.
4.1.4. Adoption of MBSE-Tools
The integration of stakeholders into MBSE stalls, especially when new tools replace established ones. One interviewee described the resistance by saying, “Not everything you present in Cameo [...] is accepted, [...] there is also software already in use that you are then competing against” [Int B]. Resistance often stems from the steep learning curve associated with new tools. One interviewee explained, “People have barriers to familiarizing themselves with new software and languages” [Int B]. Another statement echoed this sentiment: “I have the View in Excel, which is much easier for me. Why should I have it in the tool now? It may make sense for you locally, but in a larger context, where other people access the information, it makes sense to have something like this in the MBSE tool” [Int B]. Similarly, the adoption of additional tools was described as “a really big hurdle” [Int H]. These observations underscore the resistance to change and the usability challenges linked to MBSE tools.
4.2. Views, viewpoints and visualizations in practice
4.2.1. Understanding and Implementing the View and Viewpoint Concept in Practice
Views and Viewpoints are often applied implicitly rather than explicitly in practice. While practitioners generally succeed in intuitively defining Views as specific representations of models tailored to stakeholder needs, the concept of Viewpoints proves more challenging to articulate. In practice, elements of the Viewpoint principle are frequently applied unintentionally or indirectly without a systematic approach. These implicit definitions of Viewpoints vary widely, from abstract guidelines provided in documents to concrete templates embedded in tools. One interviewee explained that they utilize standardized Views and templates managed by a central team, which lack flexibility and lead to lengthy coordination processes [Int A]. Another interviewee described using templates but struggling with maintenance, aiming to improve the integration of bottom-up and top-down processes to enhance agility [Int H].
Participants utilized Views for highly individualized and specific purposes, adapted to the unique requirements of each company and sometimes project. Standardized frameworks were not mentioned. Instead, participants emphasized using custom frameworks, sometimes integrated into their tools. Simultaneously, challenges in unambiguously defining Views, particularly in production process modeling, were also raised [Int F].
4.2.2. Visualizations and Views Used in Practice
The interviews highlight various utilizations for views and representations in MBSE, including model-based representations, domain-specific models, and purely graphical depictions. Model-based representations, utilized across all companies interviewed, primarily employ formal languages like SysML, often complemented by tabular and matrix-based views to manage requirements and traceability. One interviewee described their information in tabular visualizations: “This is mainly our requirements engineering” [Int E]. These representations frequently include intricate linkages across system levels, ensuring a consistent flow from stakeholder requirements to technical subcomponent specifications.
Domain-specific models are significant, particularly in specialized fields like software and electronics. As one interviewee noted, “Siemens [Capital], just for the wiring harness and the electronics design has another logical layer on top” [Int B]. This demonstrates how domain-specific knowledge is integrated into MBSE practices to enhance precision and stakeholder relevance.
Non-model-based graphical tools also remain prevalent despite the focus on formal modeling. “We still have a lot of PowerPoint and Visio, “explained one interviewee [Int G], adding that tools like “Draw.IO in Confluence” are also commonly used. Furthermore, multiple interviewees [A, B, C, D, F, H] confirmed the reliance on MS Office tools for additional informal graphical representations. These tools help bridge the gap for stakeholders who are less familiar with formal modeling languages, addressing accessibility challenges in MBSE.
Comprehensive system representation often integrates information from multiple tools and data sources. For example, requirements might be managed in IBM DOORS, Siemens Polarion, or Windchill RV&S, while the architecture is modeled in tools like CATIA Magic or Enterprise Architect using SysML. One interviewee elaborated, “The tool allows us to export from the RE tool. [...] In Enterprise Architect, we then create traceability” [Int H]. This approach ensures consistency and traceability across different model elements, supporting both formal and visual representations.
4.3. Challenges and potential of views, viewpoints and visualizations in practice
4.3.1. Effort and Benefit Ratio of Views
A key finding is that the effort and benefit must align for each Viewpoint. The modeler must “be aware of the utilization of […] the View” [Int F]. One interviewee remarked, “We realize that we have a relatively high hurdle when it comes to the effort involved in creation and maintenance” [Int G]. Securing management support requires demonstrating a return on investment (ROI), a task described as particularly challenging. Another interviewee noted, “The main challenge is always to convince the bosses that this adds value and the initial invested capital to create such complex models will generate a return on investment” [Int A]. Maintenance also presents difficulties, as the required effort is often hard to estimate and can mostly be assessed only qualitatively. “We are quite good at presenting the added value qualitatively, [...] we are not so good at quantifying added value, “ added Int G. One interviewee described a solution: “Views must either arise naturally during the regular modeling process or be generated automatically” [Int D].
4.3.2. Challenges in Adapting Modeling Methods and Governance in MBSE
Adapting modeling methods and guidelines in industrial contexts is often described as a time-consuming process. Participants frequently emphasized challenges in aligning new modeling approaches with established standards and workflows. For instance, one interviewee remarked, “If you go through the governance team, it can take months for the solution to be implemented”[Int A]. It is important that actual end-users play an active role in shaping guidelines and influencing governance, as one participant noted: “It is insufficient for the central department to create model [governance]. The business unit must take ownership by providing the necessary individuals” [Int D]. Another explained that “the people who maintain [the governance] are the bottleneck”[Int G].
4.3.3. Degree of Abstraction and Lack of Legibility of Current Representations and Views
Determining the appropriate level of abstraction in modeling emerges as a central challenge. While software engineers often criticize that “everything is modeled far too superficially” and advocate for “more formalized representations,” other stakeholders and engineers frequently report feeling disconnected, expressing that “they do not [need to] understand it.” [Int F]. A recurring issue is that existing models are often excessively abstract and complex, creating barriers to stakeholder engagement. Usability also plays a crucial role in stakeholder acceptance. For instance, stakeholders encounter significant challenges when required to think across multiple modeling layers, especially when “different layers must be kept consistent, “which many find difficult to manage [Int B]. Participants also noted that non-interactive and inaccessible representations lack the practicality to facilitate stakeholder participation.
Many stakeholders struggle to engage with MBSE due to the absence of “low-threshold visualizations that better address users based on their role and background” [Int B]. Visualizing technical content remains a significant issue, particularly for stakeholders who either do not work directly with MBSE models or lack proficiency in modeling languages such as SysML. Interviewee G emphasized the necessity for “reduced SysML, where we provide as much guidance as possible to make it easier to get started [and] to place maintenance on broader shoulders.” Additionally, Interviewee H remarked that “models are sometimes not appealing enough” to capture senior management’s attention effectively. Another interviewee added: “Management is easier to address if the representation offers enough added value and is simple enough” [Int E]. Another explains: “We still lack the means of communication to disseminate the results to the entire team. Because I cannot print out a logical architecture or insert a screenshot into a requirements management system and then simply assume that the team has now understood it” [Int D]. This highlights the importance of ensuring visual clarity, value, and accessibility in MBSE models. It is not a matter of people failing to understand the content but rather a reflection on the need to present models that resonate with their audience. Just as a poorly designed presentation fails to convey its message effectively, MBSE views are intuitive and engaging to address stakeholders’ diverse needs effectively. This highlights that existing views may not always suffice to engage all stakeholder groups adequately.
In practice, these problems are occasionally solved by the high manual effort required to translate complex system models into comprehensible formats for stakeholders from different disciplines. Modeling engineers frequently serve as intermediaries, tasked with “convert unrefined requirements into structured templates that meet formal criteria” [Int E] while simultaneously “support stakeholders who are not familiar with modeling tools such as SysML” [Int A]. This translation process is labor-intensive and often repetitive due to the necessity of updating non-technical representations in response to technical changes.
The lack of audience-specific customization worsens these challenges. Many stakeholders are reluctant to engage with highly technical models but require sufficient understanding to contribute to technical discussions. Interview feedback underscores the need for MBSE views that balance technical detail with accessibility, ensuring their suitability for diverse audiences. These challenges are crucial to enhancing usability and fostering stakeholder engagement within MBSE practices.
4.3.4. Potential for new Views and Visualizations
To address these challenges and foster stakeholder acceptance, the interviewees stated: “True integration [of MBSE] is achieved only when the View concept [...] is no longer limited to the model in the SysML tool, but [...] captures and visualizes information within an integrated, holistic process at all relevant points” [Int D]. For instance, linking requirements directly with design tools, such as enabling engineers to View specifications within their CAD environment, bridges the gap between abstract requirements and practical design. As Interviewee E highlights the need: “The CAD model [...] is a kind of mother ship that loads it up with various layers and views, [...] can display requirements and functions and cross-effects.” Another interviewee adds the same: “Requirements, […] coupled with logical or […] physical elements, […] should be visible by the mechanical engineer directly at the node in CAD” [Int D]. Similarly, SysML v2 shows promise by offering textual representations that integrate seamlessly into traditional software development environments, eliminating the need for standalone tools and aligning with the workflows of software developers, thereby enhancing acceptance and usability. As Interviewee G observes, “SysML v2, [...] if you can also work textually [the visualization] preference shifts.” A key area of potential lies in the holistic integration of data from diverse sources and tools, creating a unified View that supports cross-disciplinary collaboration and ensures consistency. However, as an interviewee points out, “CAD data or in hydraulics [...] I cannot currently visualize well with languages such as SysML or Arcadia in Capella” [Int B]. Expanding MBSE to include business and cost considerations, as suggested by interviewee E, could facilitate better decision-making: “It would be cool [...] to include financial aspects [in the MBSE modeling] and give the controllers [...] a tracking tool for their change management.”
5. Discussion
5.1. Stakeholder involvement
Our study confirms that the theoretical promise of views as an instrument to integrate diverse stakeholders in MBSE is not yet fully realized in industrial practice. Boujut and Blanco (Reference Boujut and Blanco2003) introduce the concept of intermediary objects as artifacts that mediate collaboration by providing shared representations that facilitate communication in engineering across disciplinary boundaries. MBSE views should allow diverse stakeholders to access and interact with system models meaningfully. However, our findings suggest that current views do not sufficiently fulfill this role, as they often remain too abstract or technically complex to be effectively used outside of modeling teams.
While views are intended to enhance communication and collaboration, our findings indicate that their practical implementation remains inconsistent. In line with Henderson et al. (Reference Henderson, McDermott and Salado2024) and Madni & Sievers (Reference Madni and Sievers2018), we observed that non-technical and non-expert stakeholders are often not actively engaged in MBSE processes. Instead, MBSE remains primarily confined to technical roles, particularly system architects and requirements engineers. The low participation of non-engineering stakeholders can be attributed to multiple factors, including the complexity of MBSE tools, the abstract nature of system models, and the lack of tailored visualizations. Prior studies (Reference Madni and SieversMadni & Sievers, 2018) suggest that abstract representations hinder accessibility for users without formal modeling expertise and the need for new visualizations. Our findings reinforce this, as interviewees repeatedly emphasized that current views are primarily designed for modeling experts, leaving discipline-specific engineers and managerial and business-oriented stakeholders with limited entry points into the modeling process. This calls for rethinking the design of views to lower entry barriers and ensure that they cater to a broader audience and can serve better as a boundary/intermediary object (Reference Panarotto, Bertoni and JohanssonPanarotto et al., 2019).
5.2. Challenges in the adoption and maintenance of views
One of the most pronounced challenges identified in our study is the high effort required to create and maintain views. Multiple interviewees noted that the cost-benefit ratio of developing views is often unclear, leading to skepticism among modelers and management. This aligns with previous work by Mandel et al. (Reference Mandel, Martin and Albers2022), which highlights that views need to demonstrate added value for the individual user to justify their implementation effort.
A contribution of our study is the observation that, while stakeholders generally grasp the fundamental concept of a View, they rarely define viewpoints explicitly. This gap in practice indicates that the systematic differentiation between views and viewpoints is often overlooked, leading to inconsistencies in their application. Addressing this issue could improve the structured use of views in MBSE and enhance their effectiveness for different stakeholder groups.
Furthermore, the lack of standardized methodologies for defining and managing views contributes to inefficiencies. Industrial practice relies heavily on company-specific approaches, which vary significantly in terms of flexibility and maintainability. This observation supports the findings by Weilkiens (Reference Weilkiens, Madni, Augustine and Sievers2022), who pointed out that industrial adoption of structured MBSE methodologies remains limited, leading to fragmented and often redundant modeling efforts.
A key insight from our study is the necessity for automation in View generation. This would reduce manual workload and improve consistency across different views. Future research should explore methods for automated View creation to increase efficiency and adoption.
5.3. The role of MBSE tools and visualizations
Tool-related barriers play a significant role in the adoption and usability of MBSE views. Our study highlights strong resistance to MBSE tools due to their steep learning curve and perceived lack of usability. This confirms prior research by Henderson et al. (Reference Henderson, McDermott and Salado2024), which emphasized that MBSE tooling remains a significant bottleneck for broader adoption. Our findings also indicate a growing interest in SysML v2 as a potential solution. SysML v2’s API could bridge the gap between formal modeling and traditional engineering workflows (Reference Li, Faheem and HusungLi et al., 2024).
A recurring theme in our interviews was the preference for alternative visualization methods outside traditional MBSE tools. Many companies use Excel, PowerPoint, or domain-specific solutions to complement their modeling efforts. While these approaches may enhance accessibility for non-technical stakeholders, they often lead to inconsistencies and redundant data management. This underscores the need for MBSE tools to integrate more intuitive, role-specific visualizations that align with stakeholder needs.
5.4. Limitations and implications for future research and practice
Our study has limitations, notably the small sample size of eight interviews, which reflects the limited availability of suitable participants for this exploratory research. As the analysis suggests, theoretical saturation was likely reached with no significantly new themes or patterns emerging from the later interviews (Reference Glaser and StraussGlaser & Strauss, 1967). Furthermore, the diversity of participants across industries and roles provides a broad range of perspectives, supporting the validity of the findings within the study’s scope (Reference EisenhardtEisenhardt, 1989). Additionally, our sample predominantly relied on SysML-based frameworks and table-based requirements management tools, which might limit the generalizability of our findings to other MBSE approaches. The study’s generalizability beyond Germany is limited, and non-technical stakeholder perspectives may be underrepresented due to their lack of direct questioning.
Future research could use a quantitative questionnaire to systematically assess stakeholder integration in MBSE, enabling statistical analysis and broader generalization. Investigating stakeholders’ needs for MBSE visualizations could improve tailored views. Including business and cost factors in MBSE models could enhance decision-making and engagement. Future research could explore challenges in MBSE viewpoints using an ethnographic approach or a data-intensive method such as eye tracking.
6. Conclusion
This study illuminates the challenges and opportunities associated with using views and viewpoints in MBSE. Our findings indicate that while Views have the potential to enhance stakeholder alignment and collaboration, their practical adoption remains inconsistent across industries. Key barriers include tool complexity, unclear cost-benefit trade-offs, and the lack of standardized View creation and maintenance methodologies.
Recognizing the identified challenges, the industry has a clear and pressing need for novel stakeholder-specific visualizations and smart views. These should utilize intuitively understandable forms of visualization and be accessible through easy-to-use tools – or even better, within the tools that stakeholders already use. They also should incorporate new technologies to facilitate dynamic, adaptive, and intuitive stakeholder-oriented visualizations. This approach can help bridge the gap between technical and non-technical stakeholders, ensuring that all relevant parties can contribute meaningfully to the product development process. To achieve this, we advocate for developing a comprehensive framework for View generation and utilization, which not only systematically structures the creation of smart views.
Open access
