2. Background: the need to simultaneously model alternative business cases and architectures

Systems Engineering (SE) was developed as a means to keep consistency between the intended ‘value’ of a system (or its design intent) and the developed technical solutions (Martin Reference Martin1998; INCOSE 2023). As such, the definition of system requirements is one of the cornerstones of SE methodologies and standards, since requirements should convey a precise formulation of what should be developed. However, the translation between the ‘value’ of a system into measurable requirements is difficult, and requirements are often renegotiated, reformulated, and updated during the development process. MBSE (Wymore Reference Wymore1993; Yang, Cormican & Yu Reference Yang, Cormican and Yu2019; ISO 24641 2023b) has been proposed to ensure the consistency between changes in systems requirements and technical solutions through the use of software tools (Hehenberger et al. Reference Hehenberger, Vogel-Heuser, Bradley, Eynard, Tomiyama and Achiche2016; Huldt & Stenius Reference Huldt and Stenius2019). Many industries are currently investing in MBSE, with commercial software tools such MagicDraw™ and Capella™, where MagicDraw™ was acquired by Dassault Systèmes™ and further developed as Cameo™, and Capella™ was adopted by Siemens™ and integrated with Teamcenter™ as System Modeling Workbench™.

While these MBSE tools are currently used in industry, they are often used starting from a single targeted mission or business that has been defined beforehand (Honour Reference Honour2010; Madni & Purohit Reference Madni and Purohit2019). There are a number of reasons that limit the application of MBSE in the business development stages. First, stakeholder ‘values’ are often expressed in natural language at varying levels of detail (Fantoni et al. Reference Fantoni, Coli, Chiarello, Apreda, Dell’Orletta and Pratelli2021). They may be unspecific (e.g., ‘being environmentally sustainable’) or overly specific (e.g., ‘the vane material must be stainless steel’), requiring reformulation into more general terms to avoid premature solutions. Moreover, not all system requirements can be defined beforehand. Particularly ‘non-functional requirements’ like flexibility and maintainability – often emerge once a solution is developed. Finally, the formulation of requirements can unintentionally suggest specific solutions, limiting innovation (Collopy & Hollingsworth Reference Collopy and Hollingsworth2011).

2.1. Existing MBSE approaches to manage stakeholder expectations to system solutions in early phase design

The reasons above led to the development of techniques to model the business and operational contexts at a more granular level than current MBSE methods. These techniques, defined under the more general terms of ‘value modelling’ ‘value assessment,’ and ‘value-driven design’ (Lavi & Reich Reference Lavi and Reich2024), have received attention in recent years, although there is not yet a universally established practice. Two distinct categories of value modelling methods can be distinguished: (1) those that focus on capturing value aspects to specify requirements and guide the generation of engineering solutions and (2) those that focus on assessing solutions based on a number of value aspects.

2.1.1. Techniques that focus on capturing value aspects

Through a series of aerospace enterprise collaboration research projectsFootnote ^1, Footnote ² in Europe, an underlying value information model was developed (Isaksson et al. Reference Isaksson, Kossmann, Bertoni, Eres, Monceaux, Bertoni, Wiseall and Zhang2013) and applied to ensure that the governing intent of high-level expectations and needs can be maintained throughout the requirements engineering process of large systems spanning several levels of a value chain. Figure 1 outlines the key definitions used in this model (represented as a UML Class Diagram), together with an example related to a transportation system.

Figure 1. Meta-model as a class diagram of the ‘Value Model’ by Isaksson et al. (Reference Isaksson, Kossmann, Bertoni, Eres, Monceaux, Bertoni, Wiseall and Zhang2013).

The ‘Value Creation Strategy’ (VCS) describes a high-level context for the system to be developed. In transportation, this context could be formulated as ‘early commuting to a congested city.’ The VCS is formulated as a rank-weight of Stakeholders’ Needs. A different rank-weight of the needs provides a different context for the development (therefore, multiple Value Creation Strategies can be communicated).

The Stakeholders’ Needs are derived after interpreting the ‘raw-data’ statements of expectations from the stakeholders (gathered from interviews and focus groups). This raw data is captured as a stakeholder expectation. The reason for differentiating between expectations and needs is that, in a complex product, stakeholder statements vary in format and detail and often require validation to confirm correct expression and intent. This validation may occur after the project has already started, and a change in the expectation may require reformulation of the needs and may shift the trade-offs involved in the assessment of solutions.

In our example, the stakeholder formulates an over-specific expectation by already specifying a solution (e.g., the engine having low power). If an engineer wants to formulate a solution-independent version of this expectation, it could be interpreted as the need to reduce the time to perform office work. However, this interpretation needs to be confirmed, and it may be subject to change, with potentially profound cascading effects on the solutions targeted by the engineers. For these reasons, Stakeholder Expectations and Needs are contained in two different information objects.

To start investigating solutions to fulfill the needs, value drivers (VDs) are formulated, which are alternative characteristics that can be determined by design to satisfy a stakeholder need. Still aiming to keep the design space as wide as possible, there is a 1:n relationship between a need and a VD. VDs can be considered the pre-stage of requirements and are kept as solution-independent as possible. In our example, system power has an impact on the need to reduce the time to start doing office work, but so does the number of communication systems (since the user can begin office work by communicating while in transit). After solutions (based on the VDs) are generated and evaluated, the VDs can be formalized as requirements.

2.1.2. Techniques that focus on assessing solutions on value aspects

Regarding the assessment of engineering solutions, there is a growing shift in value assessment methods from qualitative, expert-based approaches (e.g., Quality Function Deployment extensions; Bertoni, Bertoni & Isaksson Reference Bertoni, Bertoni and Isaksson2018) to more quantitative, data-driven techniques. For instance, Donelli, Boggero & Nagel (Reference Donelli, Boggero and Nagel2023) combined cost models with expert-based utility functions to assess aircraft wing assemblies, incorporating production time, quality, and risks. While utility–cost curves are common in systems engineering trade-off analysis, a recent trend merges utility and cost into a single financial metric for easier comparison of business alternatives. Panarotto, Borgue & Isaksson (Reference Panarotto, Borgue and Isaksson2020a) implemented the surplus value (SV) financial metric suggested by Collopy & Hollingsworth (Reference Collopy and Hollingsworth2011) to simplify net present value (NPV) analysis in complex cross-company systems. Time factors also affect value and are often missed in expert-based evaluations. For example, Panarotto et al. (Reference Panarotto, Borgue and Isaksson2020a) showed that a system optimized for earlier development – despite lower performance – can be more valuable due to earlier revenue generation. Thus, several approaches (e.g., Panarotto et al. Reference Panarotto, Borgue and Isaksson2020a; Pohya et al. Reference Pohya, Wehrspohn, Meissner and Wicke2021; Ramm et al. Reference Ramm, Pohya, Wicke and Wende2024) integrate NPV or SV analysis with discrete event simulations to model revenues and costs over a system’s lifecycle. However, one issue when running these simulations is that they often use ad hoc lifecycle representations tailored to specific industry objectives. This means that the presented models are often based on specific applications and use cases. Reapplying these models to other technologies and applications can be time-consuming.

3. Proposed method and modelling tool – Value-driven model-based systems engineering (VD-MBSE)

To support both the process of simultaneously modelling alternative business contexts and architectures, VD-MBSE is proposed. VD-MBSE is used to simultaneously iterate business contexts, the associated needs, requirements, and design solutions throughout the development process. The method strives to progressively narrow down both design solutions and business options while ensuring compatibility, using a set-based concurrent engineering approach (Sobek, Ward & Liker Reference Sobek, Ward and Liker1999). More details about the set-based nature of the approach will be provided in Section 5. This approach ensures that even if business contexts change, the system’s solutions remain adaptable. In early design stages, identifying the range of design requirements that make a solution compatible is key to further developing sub-systems and components. The approach aims to connect business and solution design spaces through an MBSE structure. VD-MBSE is structured along four main steps that are repeated as more knowledge is gained (Figure 2).

Figure 2. Overall workflow of the proposed VD-MBSE method: the objective is to gradually narrow down the business design space and the solution design space over time.

VD-MBSE involves:

• • Defining the business design space: Using ‘Value Creation Strategies’ (VCSs) to outline business scenarios that inform design studies. VCSs help translate stakeholder expectations (gathered through interviews and focus groups) into more concrete engineering problems. Stakeholder preferences are ranked and weighted for each business scenario.

• • Defining VDs: VDs link stakeholder needs in the VCSs to design solutions, serving as early versions of design requirements and guiding solution exploration.

• • Defining the solution design space: Designs are created based on VDs or, conversely, design alternatives can update the VDs.

• • Performing Value and Cost studies: Design solutions are evaluated against VCSs using a monetary approach, leveraging the Surplus Value model (Collopy & Hollingsworth Reference Collopy and Hollingsworth2011) integrated with ISO 15288 2023a and discrete event simulation to capture value changes over the system lifecycle. ISO/IEC 15288 provides a standardized framework for systems engineering processes throughout a system’s life cycle. While it is not directly a simulation tool, ISO 15288 can be used to structure a discrete event simulation (DES) by defining the processes, states, transitions, and resources involved in a system’s development and operation.

To perform all these steps, the method has been implemented in a modeling tool (Club Design). Figure 3 shows the web interface of Club Design, which is organized into six different tabs. By clicking the tabs from left to right, users can go through all the steps defined in Figure 2. Full reference and log in details to Club Design can be provided upon request.

Figure 3. Main web interface of club design.

The next section will go through the four main steps to show the key features developed in VD-MBSE, as applied to an industrial case study.

4. Case study – Concurrent design of a Fan Outlet Guide Vane for electrification of aerospace products businesses

In this industrial case study, two companies – an OEM and its second-tier supplier – are tasked with the challenge of concurrently designing an electric aircraft and one engine component (a Fan Outlet Guide Vane – FOGV) for the electrification of aerospace product businesses. An FOGV is a component that establishes a structural linkage between the primary engine carcass and the aircraft’s attachment point (i.e., a structural function), while also directing the flow emanating from the low-pressure turbine (i.e., an aerodynamic function). The challenges faced by the two companies can be introduced after reviewing Figure 4.

Figure 4. Challenges for (a) the OEM and (b) the FOGV manufacturer, showing the position of the FOGV in the aircraft engine.

For the OEM developing the electric aircraft, it is unclear which operational scenarios will emerge and when. Operational targets are uncertain, ranging from traditional ranges (e.g., 1400 km) to new operational scenarios such as ultra-short regional flights for tourism (under 200 km). Additionally, the target customer is undefined, with many start-ups potentially entering the market, each with differing development approaches. Some start-ups may prioritize a radical development approach with quick, cost-effective solutions that compromise initial performance and risk (similar to an ‘Aeronautic SpaceX’ approach), while others may pursue a more traditional and risk-adverse development strategy.

These business uncertainties profoundly impact the FOGV manufacturer. Traditionally, development starts from mature requirements based on fixed engine and aircraft configurations. In the electrification of aerospace products, the uncertainty requires the aircraft and FOGV to be developed concurrently with the evolving business contexts. This evolution leads to changes and updates, affecting adjacent components and FOGV requirements. Consequently, the solution space must remain open, with flexibility to adapt designs as requirements shift. As targeted businesses evolve or are abandoned, it becomes crucial for the FOGV manufacturer to identify design alternatives that are compatible across various business strategies.

4.1. Define business design space

By moving to the leftmost tab in Club Design (VCS), users can define the ‘Value Creation Strategies.’ A VCS is defined as rank-weighted stakeholders’ needs. An example of a VCS for the business scenario ‘ultra-short flight’ (< 200 km) is presented in Figure 5.

Figure 5. One example of VCS as rank-weighted stakeholders needs for the VCS “ultra-short flight” (< 200 km).

A VCS is represented in tabular form, where for each relevant stakeholder (e.g., the aircraft manufacturer and the FOGV manufacturer), the ‘raw data’ captured during interviews and focus groups (often in textual form and natural language) is translated into stakeholder needs that formulate a more concrete engineering problem to be solved. As this ‘translation’ is highly iterative, the tool supports modifications to maintain consistency. The final step in this process is to define rank-weights for the VCS (on the rightmost part of Figure 5). Many methods can be used to define the rank-weights, in this case study a pair-wise comparison has been used. More details about the created VCSs are provided in the next section. Once the first VCS is created, the ‘duplicate’ function can be used to create additional VCSs and define more business scenarios. This is shown in Figure 6, taken from the ‘spider chart’ function of Club Design.

Figure 6. Five VCSs defining different priorities for the design alternatives to investigate.

The focal points of Figure 6 are to show how the VCSs include external stakeholders’ needs such as the OEM (e.g., ‘reduce energy consumption,’ formulated as ‘energy consumption’ in due to space constraints). These will later result in functional requirements to satisfy these needs (e.g., structural stiffness or noise). At the same time, the VCSs contain information regarding the concerns of internal stakeholders, such as the FOGV manufacturer (e.g., ‘ability of multiple sourcing’ or ‘increase environmental sustainability in manufacturing’). These will result in non-functional requirements for the solution.

The VCSs provide preliminary insights into stakeholders’ preferences for design alternatives. For example, using ultra-light materials may reduce weight and energy consumption but limit supplier options, negatively impacting the manufacturer. For short flights, reduced energy consumption may outweigh the need for multiple sourcing, while in long-term scenarios like ‘100 years in service,’ multiple sourcing becomes critical for supply chain resilience. It’s important to note that VCS rank-weights do not dictate a specific design but encourage engineering teams to consider multiple business scenarios simultaneously, especially when the future direction is uncertain.

4.2. Define and update VDs

Although the VCSs provide high-level information about the solutions to be developed, engineers often require more precise and measurable requirements to begin investigating design solutions. As described in the background, VDs are introduced to provide a pre-stage of requirements for two main reasons:

1. 1. To allow room for some volatility in the formulation of requirements, enabling iteration of non-functional attributes of a design (often associated with development, manufacturing, and end-of-life aspects) until a more precise formulation is reached.

2. 2. To keep the requirement space as solution-independent as possible. While requirements are typically clear and detailed, they often implicitly suggest a specific solution direction, which may limit innovation capability (Collopy & Hollingsworth Reference Collopy and Hollingsworth2011).

Figure 7 provides examples illustrating the reasons for using value drivers in the FOGV case study.

Figure 7. Excerpt of a value creation strategy highlighting two alternative value drivers to respond to the need to possess “ability to quickly integrate” the FOGV, leading to two different design solutions.

The figure shows an excerpt of a value creation strategy for the ‘ultra-short flight.’ The VCS attempts to capture expectations, needs, and VDs for as many lifecycle phases as possible (e.g., design, manufacturing, operation, and maintenance). Each row in the VCS (starting with a stakeholder with an expectation) is connected to one of the 30 processes defined in the ISO 15288 standard. The reason to apply ISO/IEC/IEEE 15288:2023 (Dori Reference Dori2024) is that it is a systems engineering standard that provides a common framework for describing system lifecycle processes and terminology. It applies to any level of a system’s structure and can be referenced by anyone involved in system lifecycle or engineering activities. Therefore, ISO 15288 provides a cross-sectoral lifecycle representation of different products and systems, and for these reasons, it is used as the backbone of the software. The software allows users to select these processes via a drop-down menu and to define sub-processes. This specification of processes allows for the definition of a structure that will be crucial for the cost/value study performed using the discrete-event simulation algorithm (to be detailed in Section 4.4).

The focal point of Figure 7 is to highlight how the VCS contains VDs related to the operation and maintenance processes, which are typically the main interest of external stakeholders such as the OEM and the airlines. These aspects often result in ‘functional requirements’ (such as weight, pressure drop, noise, and stiffness). These requirements are often easier to formulate, measure, and verify compared to attributes related to design or integration (assembly), which are typically of interest to internal stakeholders such as the FOGV manufacturer. These aspects, often related to ‘non-functional’ attributes of a design, are more difficult to formulate and assess. To address the need for the ‘ability to quickly integrate the FOGV’ in the ‘integration’ process, two VDs are identified: ‘weld time’ (impacting Solution A) and ‘number of fittings/interfaces’ (impacting Solution B). The reason for using VDs is to retain the benefits of requirements (such as measurability and clarity) while allowing multiple solutions to be explored. Formulating only a requirement for ‘maximum allowable weld time’ would imply Solution A (welding FOGV vanes to the outer structure). However, an alternative requirement – ‘number of fittings/interfaces’ – leads to another solution (pipe fittings on machined holes – Solution B). A more general requirement, such as ‘maximum allowable assembly time,’ could potentially cover both solutions, but it would lack the specificity needed for unbiased and measurable verification, a key systems engineering principle (INCOSE 2023). It also limits the potential for parametric computational design studies, thereby restricting design exploration capabilities.

Another focal point of Figure 7 is to emphasize another key advantage of VDs: their ability to influence multiple needs. For instance, integrating vanes with fittings supports ‘frequent upgradability’ since vanes can be disassembled and reassembled, unlike welding. This demonstrates how VDs help keep the requirement space as solution-independent as possible, particularly for complex attributes that require iteration and reformulation throughout the development process.

4.3. Define solution design space

By moving to the ‘design’ tab, users can start to define their designs (Figure 8) by importing an Excel file that contains the numerical or categorical values for the designs under study, according to the VDs specified in the VCS. The calculation of these VDs comes from dedicated software tools or assessment methods, which are used to populate the Excel file. Figure 8 shows the simulation or assessment methods used to compute four VDs:

1. 1. Design similarity to previous products, calculated using the method proposed in Bonde et al. (Reference Bonde, Kokkolaras, Andersson, Panarotto and Isaksson2023), which impacts the need to reduce risk during development;

2. 2. Socioenvironmental material criticality score, based on Hallstedt & Isaksson (Reference Hallstedt and Isaksson2017), which impacts the need to promote environmental sustainability in manufacturing;

3. 3. Stiffness, calculated using structural simulation tools using a design automation framework (more details provided in Andersson et al. Reference Andersson, Lejon, Chidambaranathan, Wejletorp, Panarotto and Jacobson2023); and

4. 4. Pressure drop, a key aerodynamic feature, calculated using an aerodynamic software developed internally by the company.

Figure 8. Import design input data, from an excel file taking input from simulation tools.

To provide more flexibility and accommodate the different stages of the design process (characterized by varying levels of design maturity), input can also be provided by manually generating designs in the ‘design view.’ Additionally, the tool allows for the creation of more radical designs beyond those defined by parametrically varying the VDs. For example, the choice of using a rotating structure instead of a static FOGV would change the nature of the VDs – for instance, this ‘rotating FOGV’ could generate electricity, and the generated power could become a novel VD.

4.4. Perform value and cost studies

The last step is to evaluate the designs against the VCSs. Traditionally, this evaluation is conducted using QFD-like approaches that require experts to assign semi-quantitative scores to the relationships between needs and VDs (e.g., Bertoni et al. Reference Bertoni, Bertoni and Isaksson2018). In the case of a large design space, such as the one in this FOGV case study (where 90 designs generated with design automation techniques described in Figure 8 are evaluated against 5 VCSs), this expert evaluation can be rather tedious (i.e., there would be 450 potential QFDs to be filled). For these reasons, the VD-MBSE method has implemented a more monetary and simulation-based evaluation of design alternatives, using the SV model (Collopy & Hollingsworth Reference Collopy and Hollingsworth2011).

This monetary evaluation is made possible through the link between the ISO 15288 processes and the value creation strategies. Since each process is connected to VDs (Figure 7) – which are the elements that vary among design alternatives – it becomes possible to associate each design with the time, cost, and potential revenue it incurs in each process by adopting a discrete-event simulation (DES) algorithm (Browning & Eppinger Reference Browning and Eppinger2002). Figure 9 shows the overall logic of the DES algorithm, which enables the calculation of the SV for each design alternative based on its characteristics (the VDs).

Figure 9. Overall architecture of the DES algorithm and SV model.

The simulation of time, cost, and revenue for each product with a specific design configuration “flowing through” the processes allows for the calculation of SV. This first requires organizing the order of the processes. This input can be provided in the ‘process hierarchy’ tab (Figure 9) in the form of a design structure matrix (DSM), as shown in Browning & Eppinger (Reference Browning and Eppinger2002). Although the sequence of processes can be visualized as a process flow (as shown in the upper part of Figure 9), the DSM format is chosen for its compactness. Figure 9, five processes are selected: architectural design, implementation/fabrication, integration, operation, and maintenance.

The DES algorithm requires that ‘entities’ (in this case, new FOGVs with a specific design configuration) are ‘injected’ into the business at a specified rate. Since some processes are independent of the number of entities (e.g., the design process is done only once), it is possible to specify which processes should be run a single time. For the other processes, entities flow at a defined rate (e.g., 1,000 FOGVs per year).

As entities enter a process, the time, cost, and revenue are calculated and accumulated from previous processes. Afterwards, the entities move to the next process based on the defined hierarchy. The time, cost, and revenue spent in each process are functions of two variables:

1. 1. the value drivers, which vary for each design (Figure 8), and

2. 2. design-independent factors (e.g., aircraft range and energy price), which are defined as external factors, since they are outside the control of the engineers.

These relationships are set in the ‘connect design to VCS’ tab (Figure 10) using a formula editor.

Figure 10. Editor for the operation cost formula, highlighting the connection between the VDs (e.g., mass and pressure drop, shown in red) and the external factors (e.g., aircraft range and energy price, shown in blue).

The figure shows the equation for the operation cost (with formulas based on Hepperle Reference Hepperle2012). The equation editor allows users to manipulate classical Excel operators, such as ‘if’ statements and Boolean operators for categorical variables. Figure 10 illustrates how the editor visualizes all the VDs defined in the VCS for that specific process (e.g., mass and pressure drop), making them selectable for the formula (highlighted in red for easier identification). The external factors are shown in blue and are defined in the ‘external factors’ tab (Figure 11). Since external factors depend on the business context, they are closely linked to the defined VCS. For example, an ultra-short flight has a different range than a medium or ultra-long flight. For this reason, the tab displays the selected VCS by default, allowing users to define appropriate values for the external factors.

Figure 11. External factors tab.

The definition of these relationships is the most data-intensive and assumption-intensive part of the method, as it requires the quantification in monetary terms of VDs that are not strictly related to the functionality of the product. For example, in Figure 9, a super-linear relationship has been defined between the design similarity of the new product and the design cost (i.e., a new radical design will result in a super-linear increase in design cost). While this paper acknowledges the limitations of such assumptions on the final SV results, the main focus is to provide support for making it easier to change and update these relationships (as MBSE tools typically aim to do), while leaving the correctness of the input data to the user. However, the paper also recognizes the importance of handling uncertainties, and future research directions on this topic are presented in the discussion.

Once all the equations have been defined, it is possible to run the DES algorithm for all selected designs across all selected VCSs. Since the DES algorithm operates in step changes (Browning & Eppinger Reference Browning and Eppinger2002), the algorithm interpolates the results of the step changes to make a more intuitive visualization (lower part of Figure 9). Additionally, the monetary results are time-adjusted using a discount rate, as is commonly done in economic analysis. All simulations are automatically saved for further inspection. The results of the SV curves (i.e., the cost and revenue profile for each design-VCS combination) can be directly inspected in the web interface or exported as an Excel file for further post-processing.

5. Output from the method: sets of compatible designs for evolving business contexts

This section describes how the results from the modelling tool can be used. In situations where it is not yet clear which business strategies (articulated as VCSs) will take off in the future – such as in the electrification of aerospace propulsion – the objective is not to find the ‘best’ design alternatives (i.e., those with the highest SV), but rather to identify the designs that are most valuable across the widest set of VCSs. Figure 12 shows an example to illustrate this difference.

Figure 12. Examples of filtered results for 10 of the 90 FOGV design alternatives against 5 VCSs. In the upper part, the results are filtered by selecting the 10 designs with the highest SV; however, each design is optimized for a single individual VCS. In the lower part, the filter is applied to select designs with slightly lower SV, but which present comparable SV across multiple VCSs.

Each of the two tables shows an excerpt from the simulation results for the 90 designs evaluated against the 5 VCSs (resulting in a total dataset of 450 entries). The tables display 3 out of the 23 VDs that compose the dataset. One of the three VDs is connected to a functional attribute (mass), while the other two relate to non-functional attributes: the ability to double source, and the design similarity to previous products (calculated using the method proposed in Ref. 1 – omitted to preserve double-blind review). The upper part of Figure 12 shows 10 designs filtered from the dataset by selecting those with the highest SV. The figure highlights that each of these designs is optimized for a single VCS, and only two VCSs show the highest SV. This indicates that while these designs may be optimal, they are highly dependent on the assumption that the corresponding VCS will be implemented. There is a significant risk that these designs will be suboptimal if other VCSs (e.g., VCS3 – disruptive ‘Aeronautic SpaceX’ customer, or VCS4 – long-lasting circular solution) emerge as dominant. Furthermore, SV results rely on both economic and technical assumptions, which may change and alter the design rankings.

A different strategy is shown in the lower part of Figure 12. Each line in the plot represents one of the 90 designs simulated across the five value creation strategies (VCSs). This new filter identifies another set of 10 designs, with Design Case 52 being notable for presenting comparable SV across three VCSs (VCS1, VCS2, and VCS4). This approach – favouring compatibility over optimization – is promoted in set-based concurrent engineering methodologies (Sobek et al. Reference Sobek, Ward and Liker1999) and is particularly relevant in situations where business contexts (articulated through the VCSs) may change. By filtering the results and further examining the VDs, engineering teams can explore why certain designs are more compatible and potentially combine features (e.g., a hybrid configuration with vanes both welded and assembled using fittings) to create new design alternatives. The filtering process also reveals that all designs compatible with VCS5 (medium-range flight, 1400 km) have low SV. This suggests that full electrification of aerospace products may not be viable for medium-range flights unless combined with hybrid configurations (e.g., hydrogen or fuel cells).

6. Positioning the proposed method onto MBSE: a quantitative study

This section has the objective to analyse the advantages of VD-MBSE compared to other traditional MBSE approaches and document-based SE practices. Since the analysis is based on a number of assumptions derived from the literature (e.g., Carroll & Malins Reference Carroll and Malins2016), any comparison is subject to uncertainty. Therefore, the following analysis should be considered a quantitative ‘positioning study’ rather than a direct comparison.

The first step of this study was to apply the proposed method at a meta-level on the method itself, by creating a VCS. This is shown in Figure 13.

Figure 13. VCS applied on the proposed method, highlight the main needs it addresses.

The proposed method targets two phases of a project lifecycle: the business and mission analysis, and the requirements analysis process. The main needs it fulfills are:

1. 1. the ability to analyze the impact of multiple missions to reduce the risk of rework due to changes in the business context, and

2. 2. the ability to quickly iterate value aspects to reduce the risk of rework caused by the volatility of requirements during the development process—a problem discussed in Peña & Valerdi (Reference Peña and Valerdi2015).

The next step is to perform a rank-weight indicating the priority given to the needs. A stronger emphasis is placed on non-functional aspects, since the modeling of functional aspects is assumed to be already addressed in traditional MBSE methods, as detailed in the following sections.

The input data for the analysis consists of the 23 VDs examined in the present study, and the lifecycle process each VD is related to. The authors then proceeded to classify each VD by type – whether it is related to a functional or non-functional aspect. These results are presented in Table 1.

Table 1. Input data for positioning study, with the 23 VDs managed during the case study and assumed effort if no MBSE technique is used

The study highlighted 8 VDs related to functional requirements (FRs), while 15 are related to non-functional requirements (NFRs). These proportions are consistent with recent studies conducted by Morkos et al. (Reference Morkos, Joshi and Summers2019) on student teams. To calculate the effort spent on each VD if no model-based technique is used, a simple assumption was applied using a coefficient that weights the effort depending on the phase in which a specific VD is discovered and managed (i.e., VDs discovered and managed in later phases will require more effort). Additionally, since FRs are typically easier to measure and articulate (Morkos et al. Reference Morkos, Joshi and Summers2019), an effort weight of 1/9 was assigned to FRs, while managing NFRs was assigned a weight of 3/9. For example, the maintenance process (coefficient 9, as it is the latest phase) has 2 FRs and 1 NFR. Managing the 2 FRs during the maintenance phase would imply an effort of 2 × 9 × (1/9) = 2, while managing the NFR would imply an effort of 1 × 9 × (3/9) = 3.

Based on this input data, the benefit of an MBSE and VD-MBSE approach was estimated, and the results are provided in Figure 14. The graph shows the cumulative effort required to manage both FR (blue bars) and NFR requirements (red bars) over the course of a project – assuming no model-based approach is used. Regarding FR requirements (which account for 20.5% of the total effort), the assumption is that MBSE tools already provide mechanisms to support their formulation, measurement, and traceability (therefore the VD-MBSE has no benefit regarding the strict management of FRs). It was therefore assumed that using MBSE to work on the 8 FR requirements during the requirements analysis stage (green bar) for 5.1% of the time would save 20% of managing these FRs in the later stages. These proportions appear to align with studies on the economic benefits of MBSE (Madni & Purohit Reference Madni and Purohit2019).

Figure 14. Estimated investments and savings in terms of effort for a VD-MBSE approach.

Instead, the VD-MBSE approach was estimated to have the benefit of reducing the risk associated with managing NFRs, which account for 79.5% of the total effort. Therefore, working with the 15 NFRs during the requirements analysis stage would save this 79.5%. As shown in Figure 14, applying VD-MBSE to manage the 15 NFRs would require some initial investment effort, estimated at 32.2% of the time.

An additional benefit of VD-MBSE is its ability to analyze multiple business contexts simultaneously, which helps reduce the risk of needing to change the design architecture if the targeted context shifts, as demonstrated in Figure 12. Traditionally, MBSE tools offer limited support for handling multiple missions or business scenarios, thereby restricting their effectiveness during the business or mission analysis phases (Madni & Purohit Reference Madni and Purohit2019). Figure 15 illustrates an example of this limitation in Capella, a commonly used MBSE software.

Figure 15. Capella used for the business and architectural design phases as (a) mission capabilities diagram and (b) logical architecture diagram.

Capella includes ‘mission’ and ‘capabilities’ objects, which correspond to the value creation strategies and the needs in VD-MBSE (as implemented in the Club Design software). In Capella, each of these missions can be connected to the ‘logical architecture,’ which contains the requirements for each system component in each mission (Figure 15). The challenge is that each mission may require a very different logical architecture and set of requirements. For example, in the case study, 90 designs were analysed across 5 missions, resulting in a total of 450 logical architecture diagrams that would need to be created.

Instead, using Club Design before transitioning to MBSE environments helps identify which missions are compatible and which are non-valuable (e.g., VCS5 – ‘Medium range flight’). This allows for the definition of only the compatible architectures and the corresponding requirement ranges, significantly reducing the modelling effort. In Figure 14, this benefit was quantified by considering the effort spent on modelling four additional businesses or missions in VD-MBSE, accounting for 3.8% of the time. This investment would save the time required in MBSE to create four mission capability diagrams and logical architectures during the architectural design phases—thereby saving 11.4%.