Model-Based Systems Engineering (MBSE) is a powerful tool for helping engineers to maximize quality and efficiency in systems engineering. One of the reasons that MBSE is so effective is because of how it incorporates Verification and Validation into each stage of the System Development Life Cycle (SDLC). Let’s explore how MBSE supports verification and validation in more detail.
V & V Refresher
A quick brushing up on terminology is in order; Verification and Validation (V&V) are two different, but complementary processes that are intended to detect problems and potential problems, and ensure the design meets the requirements of stakeholders and end users.
The verification process is designed to make sure that the product meets performance requirements and functions as intended. Validation, on the other hand, is all about making sure that you are building the right product in the first place. It might work perfectly, but it’s all a waste if it does not meet the needs of the end user.
An expression that is commonly used to define the difference is that verification asks the question “Are we building the thing right?”, whereas the focus of validation is “Are we building the right thing?”
It’s quite common for engineers to bring in a third party to perform the V&V processes. This is called Independent Verification and Validation (IV&V). The idea behind IV&V is to bring an outside, neutral set of eyes onboard that can assess the situation objectively. Sometimes teams and individuals can become so invested in a project that they will overlook potential problems that an outside party would be more willing to examine. Independent verification and validation eliminate this problem.
Verification & Validation in MBSE
There are 4 primary domains of systems engineering (Source Requirements Domain, Behavioral Domain, Architecture Domain, and the Verification and Validation Domain). These 4 domains are related to one another, and information is, at least in theory, supposed to flow back and forth between them. However, they are often operating separately, even within the same company. Teams working in the different domains also might be using different tools and documents, further inhibiting the smooth flow of information, and increasing the likelihood of mistakes, miscommunication and costly delays.
MBSE was designed to solve this problem by utilizing a models-based approach that is shared across all 4 domains. It calls for a single repository of data so that changes made by a team member working in any of the domains can be seen right away across all domains. It also calls for clear, consistent and unambiguous notation in the models to reduce the risk of miscommunication. The result is significantly improved efficiency, fewer delays, and lower costs since problems are detected earlier in the SDLC, where they are easier and cheaper to fix.
Here’s where verification and validation fit in: in MBSE, V&V is performed at each step as you move down the “V” cycle and back up again. Beginning with the Concept of Operations, V&V is performed to make sure that the operational parameters are designed well and meet the customer/end users’ requirements. The team then moves on to Requirements and Architecture phases, followed by Detailed V&V of the Design, before moving on to implementation, testing, integration as illustrated below.
Image credit Wikiwand
While the exact details will vary depending on the project, the verification process always consists of Planning, Execution, and Reporting. Planning will be performed at each level of the system, and it is here that relationships between design levels are assigned, specific methods of verification are chosen, tasks are assigned, configuration definitions are agreed upon, and scheduling of specific tasks is done. Afterward, verification tasks are carried out (Execution) and the results are recorded (Reporting).
The methods of verification include Analysis, Inspection, Demonstration, and Testing. Analysis is the use of analytics and mathematical modeling to predict design compliance with requirements. Inspection is, as the name implies, visual examination of a system, component or subsystem. Demonstration is where a system/subsystem or component will be operated to show that it meets a basic level of functionality, as opposed to Testing, where a much more detailed level of performance data is gathered.
It’s important to always keep in mind that verification and validation are complementary steps and should be performed together. For each of the verification methods above, validation— that is, determining whether the system will meet the stakeholder’s requirements and actually solve the problem— also applies. It is a mistake to think that validation should only be performed once a system has been fully implemented out of a desire to cut costs or save time. The truth is that the earlier in the SDLC that validation is applied, the easier it will be for the team to keep the project moving in the right direction and design a system that not only functions well but is actually useful.
When utilizing MBSE, the models must support the whole SDLC, and especially the V&V process. The requirements and models should trace to the specific simulations, tests, etc. that you plan to run, because the detailed data provided by V&V can be used to improve and refine the models for future use.
To learn more about how MBSE can help you eliminate miscommunication, reduce costs and consistently produce better systems engineering results, check out of our free helpful eBook covering the basics of Model-Based Systems Engineering.