MBSE driven approach for defining problem domain

Towards Solving MBSE Adoption Challenges: The D3 MBSE Adoption Toolbox

“…Analysis of MBSE methods and enterprise architecture frameworks reveals that the majority are conceptual and thus can hardly be used in combination with modeling languages, such as SysML, in practice. In contrast, the MBSE Grid approach proposed by (Morkevicius et al 2017), (Mazeika et al 2016) is fully compatible with SysML. Based on a transparent system architecture framework, it clearly defines the modeling process, reveals what model artefacts should be produced in each step of system lifecycle, and explains how to manage traceability relationships.…”

“…The new approach summarizes the experience of numerous MBSE adoption projects in many organizations from various industry sectors, including KDA and BT. In contrast to other methods, the MBSE Grid approach is completely applicable in practice (Mazeika et al 2016), because it is both fully compatible with SysML and it clearly defines the modeling process, which is based on the best practices of the systems engineering process.…”

MBSE Grid: A Simplified SysML‐Based Approach for Modeling Complex Systems

“…The proposed framework is based on (Mazeika et al, 2016), the work done in this area, and on the experience working with several systems engineering companies worldwide. The main idea is represented in the form of the grid (Figure 3), where columns are aspects, originating from (Friedenthal, 2008), (OMG, 2012a), also known as four pillars of SysML, and rows are viewpoints, originating from (US Department of Defense, 2009), (ISO, 2011), (OMG, 2009).…”

“…Originally, MBSE Grid was proposed in (Mazeika et al, 2016), where problem domain has been described. This paper adds slight modifications to the previously introduced problem domain, such as: (i) name change of the sub-domains, (ii) name change of some of the views, (iii) traceability updates, (iv) different, more mature case study, and (v) two examples from industry.…”

“…This paper adds slight modifications to the previously introduced problem domain, such as: (i) name change of the sub-domains, (ii) name change of some of the views, (iii) traceability updates, (iv) different, more mature case study, and (v) two examples from industry. (Mazeika et al, 2016) does not analyze solution domain and traceability among view specifications in the problem and solution domains. It also does not describe the idea behind separating architecture into problem and solution domains.…”