Systems engineers need to participate as productive members of interdisciplinary teams.

From Theory to Practice: V Model, IVVQ, and MBSE in Action—Start Your Own MBSE Pilot Projects: The Key to Developing Practical Knowledge

Bangkok, 2024


Jaroensawas, Vorachet. “From Theory to Practice: V Model, IVVQ, and MBSE in Action—Start Your Own MBSE Pilot Projects: The Key to Developing Practical Knowledge.” NORASI Article, NORAIS TEAM, 1 May 2024,

Hard times create strong men, strong men create good times, good times create weak men, and weak men create hard times.

The Practical Lifecycle: Making It Work

The connectivity of knowledge has to come from the way we use. The knowledge developed during the MBSE initiative and pilot projects has to come from the work areas targeted to apply MBSE at the organization.

NORASI team, after visiting various defense, EPC (Engineering, Procurement, and Construction), and engineering-intensive organizations, delivered several training services, discovered a fascinating disconnect between the theoretical V Model and real-world practices. While the V Model, with its clean separation of development and verification activities, holds a prominent place in software development textbooks, its rigid structure often proves impractical in the messy reality of complex projects. This is where the marriage of project management with upstream and downstream engineering becomes crucial.

Model-Based Systems Engineering (MBSE) emerges as a powerful bridge, filling the gap between the theoretical V Model and the dynamic nature of real-world projects. MBSE emphasizes creating a central digital model that integrates all aspects of the system, from requirements to design and verification. This fosters consistency and comprehensiveness throughout the development lifecycle, paving the way for a more practical and effective approach to digital engineering. The V Model principles can still be incorporated within this MBSE framework, but with the flexibility to adapt to the specific needs and challenges of each project.

Figure 1. V-Model and IVVQ in Action – Practical Lifecycle at NORASI TEAM, We maximize operational and system architecture and MBSE environment to support SE activities.
Figure 2. Process view of the functional chains represented in Figure 1

Requirement Viewpoint and Best Practice

The cornerstones of any project lifecycle are well-defined needs and requirements. They act as the guiding light for all activities and deliverables, ensuring everything aligns with the project’s ultimate purpose. However, formulating them effectively requires a nuanced understanding of their distinct roles in verification and validation.

Needs represent the high-level objectives and constraints driven by stakeholder desires. They answer the “why” behind the project, addressing the core problem or desired outcome. Through activities like stakeholder interviews and feasibility studies, needs are validated to ensure they accurately reflect the true needs of the project.

Requirements, on the other hand, translate these validated needs into specific, measurable, achievable, relevant, and time-bound (SMART) statements. They define the “what” and “how” of the system, outlining the functionalities and characteristics it must possess to meet the needs. This is where verification comes in. Requirements are verified against two key baselines: first, against the validated needs to ensure they haven’t strayed from the project’s initial vision. Second, they are verified against design inputs once a preliminary design emerges. This ensures the chosen design solutions effectively meet the established requirements.

By following established guidelines like those in the INCOSE Guide to Writing Requirements (GtWR), you can craft clear, concise, unambiguous, and verifiable needs and requirements. This strong foundation sets the stage for a successful project lifecycle, minimizing rework and ensuring the final product delivers on the identified needs.

Figure 3. INCOSE Guide to Writing Requirements (INCOSE Product)
Figure 4. Need Requirements definition using MBSE (Capella)
Figure 5. Requirement definitions, User-Defined Requirement Types and User-Defined Relation Types

Mission Definition

Figure 6. Mission Engineering in the Defense Context

The High-Level Mission Definition (as HLMD with this article) bridges the gap between the aiming mission and the program phase of a system’s lifecycle. It acts as a critical translator, transforming the broad and aspirational goals of the aiming mission (what the system is envisioned to achieve) into a set of well-defined operational capabilities. These capabilities become the system’s “how,” meticulously outlined within the concept of operation (CONOPS). The CONOPS details the specific actions the system must perform and the functionalities required to fulfill its mission effectively within the expected operational environment. A well-crafted HLMD goes beyond simply listing capabilities. It establishes measurable key capabilities that serve as the bridge between the aiming mission’s objectives and the program execution phase. These key capabilities become the quantifiable benchmarks used to assess the system’s success. For instance, if the aiming mission is to develop a new fighter jet, the HLMD might define a key capability as “achieve sustained supersonic flight for X hours.”

This clarity in defining key capabilities is crucial for guiding subsequent development activities. During concept development and design choices, engineers can evaluate options based on their ability to deliver the necessary functionalities to achieve the established key capabilities. This ensures the final system isn’t just built to specifications, but possesses the right capabilities to successfully fulfill the aiming mission’s objectives. The HLMD becomes a continuous reference point, revisited throughout the development lifecycle to ensure alignment and prevent mission creep.

Figure 7. Mission & Capability Modeling on Capella.

Interface Modeling and Functional Modeling (Function Allocation & Decomposition)

In the world of MBSE, two fundamental practices, Interface Modeling and Functional Modeling, work in concert to bring consistency and comprehensiveness to the development of complex systems and allow effective V-Model implementation. Interface Modeling acts as the system’s intricate blueprint for interaction, meticulously defining how various components connect and exchange data. This eliminates ambiguity, ensuring seamless physical connections and clear communication between design disciplines. Imagine a well-defined interface as a set of precise instructions for two Lego bricks – they click together flawlessly, fulfilling their intended purpose.

Functional Modeling, on the other hand, delves deeper into the system’s behavior. It dissects the overall desired functionality into a hierarchy of smaller, more manageable functions. Much like breaking down a complex recipe into individual steps, functional modeling allows engineers to perform function allocation. This crucial process assigns these specific functions to designated system components, ensuring each part plays a well-defined role in achieving the overall objective.

The true power of MBSE lies in the integration of these models. By weaving Interface Modeling’s focus on interaction with Functional Modeling’s emphasis on behavior, a unified view of the system emerges. This holistic perspective guarantees that all components work together seamlessly, like a well-rehearsed orchestra where each instrument contributes to the harmonious performance. This integrated approach fosters consistency across design disciplines, allowing engineers to identify potential mismatches or inefficiencies early in the development lifecycle. By catching and resolving these issues early, MBSE paves the way for the creation of robust, efficient, and ultimately more successful systems.

Figure 8. Interface & Functional Modeling
Figure 9. Python4Capella allows you to interact with your Capella model using Python. You will be able to create Python scripts to read and write from/to your Capella model.

What’s Next?

In conclusion, the V Model and IVVQ provide a strong foundation for systems development, but real-world projects often demand a more flexible approach. Here’s where MBSE steps in, bridging the gap between theoretical ideals and practical application. By embarking on your own MBSE pilot projects, you gain invaluable hands-on experience. This practical knowledge empowers you to refine your processes, identify potential roadblocks early, and ultimately develop more robust and effective digital engineering solutions. Don’t wait for the perfect moment – take the first step with your pilot project and unlock the true power of MBSE in action.

Visit NORASI service page ad schedule training and join us a consulting program today

NORASI Professional Consulting & Training Services

Read more


Vorachet Jaroensawas (LinkedIn)

Cohort 2018 Student, Ashorne Hill Management College, Management and Leadership CMI Level 5, Former Research Associate at University of York (Model-Driven Engineering / Eclipse Epsilon), MSc Software Engineering, B,Eng Electronic and Telecommunication). Former system engineer at KONEKSYS (2010-2018) performed SE/MBSE projects: Federal RFI/SBIR/STTR Proposal Manager (Federal and Military Project Opportunities), MBSE/OSLC/PLM projects with Airbus,JohnDeere and Modelon.

Arjarn Vorachet (AOT) is a Professional Systems and Software Engineer (OMG Certified Systems Professionals, BU & MBF, expired years ago) specializing in Model-Based Systems Engineering (MBSE) in Thailand. His main area of work interest is MBSE, focusing on defense applications and the technologies offered by Thales Arcadia/Eclipse Capella and OBEO commercial addons. This includes Astah System Safety – SysML/STAMP/STPA/GSN and UAF Plugin, Domain-Specific Languages using Eclipse Epsilon and XText, MBSE-integrated Life Cycle Assessment using OpenLCA and OBEO Ecodesign, NLP software applications, and semantic computing infrastructure for the Digital Thread using Graph Databases. Beyond his primary work, he also has active interests in MBSE work systems, including competency frameworks, tooled SOPs, and KPIs for digital engineering.

  • Active Member of the National Defense Industrial Association NDIA ID 1590773
  • Active Member of the Association for the Advancement of Cost Engineering AACE ID 446758
  • Active Member of the International Council of Systems Engineering INCOSE ID 42112
  • Volunteer Lead for Chapter Development and Representative of INCOSE Thailand (2017 – May 2024)
  • Interim Secretary of INCOSE Thailand (May 2024 – Present)
  • Obeo Thailand Systems Engineering Official Partner – Eclipse Capella
  • Astah Thailand Systems Engineering Official Partner – Astah System Safety/SysML/STAMP/STPA/GSN