Module 2: The SE Lifecycle
The V-model, lifecycle stages, and technical processes that MBSE supports — setting the stage for methodology.
Prereq: MBSE Module 1The V-Model
If there is one diagram every systems engineer has seen, it is the V-model. It is the most widely used lifecycle model in systems engineering and provides a clear, visual framework for understanding how a system goes from an initial concept to a verified, validated product.
The V-model gets its name from its shape. The left side of the V represents decomposition and definition — the process of breaking a system down into smaller and smaller pieces, defining requirements and architecture at each level. The right side represents integration and verification — the process of building those pieces back up, testing at each level to confirm they work correctly.
Figure 1 — The V-model: decomposition on the left, integration and verification on the right
Reading the left side from top to bottom:
- System Requirements — what the whole system must do.
- Subsystem Requirements — what each major subsystem must do to satisfy the system requirements.
- Component Requirements — what each individual component must do.
- Implementation — the actual building, coding, or manufacturing of each component (the bottom of the V).
Reading the right side from bottom to top:
- Component Verification — does each component meet its component-level requirements?
- Subsystem Verification — when components are assembled into subsystems, do they meet subsystem requirements?
- System Validation — when everything is integrated, does the full system satisfy the original stakeholder needs?
The critical insight is that each level of decomposition on the left has a corresponding verification or validation level on the right. You do not wait until the very end to discover that something is wrong — you test at every level.
Think of planning a wedding. The left side of the V is decomposition: you start with "plan the perfect wedding" (system requirement), then break it down into sub-tasks — book a venue, hire a caterer, find a photographer (subsystem requirements), then into component-level details — select a menu, choose floral arrangements, design invitations.
The right side is integration and verification: first you check each component individually (taste the food, review the invitation proofs), then you do a dress rehearsal combining multiple elements (rehearsal dinner), and finally the wedding day itself is the "system validation" — does the whole thing come together as intended?
ISO/IEC/IEEE 15288 Technical Processes
The V-model gives us the shape of the lifecycle, but the international standard ISO/IEC/IEEE 15288 gives us the vocabulary. It defines a set of technical processes that any systems engineering effort should address. Think of it as a recipe book — it tells you what dishes (processes) exist, not the order in which you must cook them.
| Technical Process | Purpose | Typical MBSE Artifact |
|---|---|---|
| Stakeholder Needs Definition | Identify who the stakeholders are and what they need | Stakeholder model, use case diagrams |
| Requirements Analysis | Transform stakeholder needs into precise, testable requirements | Requirements model, requirement diagrams |
| Architecture Definition | Design the system structure (components, interfaces, allocation) | Block diagrams, internal block diagrams |
| Design Definition | Detail the design of each component | Parametric models, detailed part models |
| Integration | Assemble components into subsystems and systems | Integration plan models, interface matrices |
| Verification | Confirm the system meets its requirements ("built the thing right") | Test case models, verification matrices |
| Validation | Confirm the system meets stakeholder needs ("built the right thing") | Scenario models, simulation results |
| Transition | Deliver the system to operators and support sustained use | Deployment models, training plans |
ISO/IEC/IEEE 15288 is a standard, not a mandate. It describes what processes exist, not how you must execute them. Your organisation is free to tailor, combine, or reorder these processes to fit your project. The standard gives a common language so that engineers across organisations and industries can communicate effectively.
Verification vs Validation
A common source of confusion:
- Verification asks: "Did we build the system right?" — does the product meet its specified requirements?
- Validation asks: "Did we build the right system?" — does the product actually satisfy the stakeholder's real needs?
You can build a perfectly verified bridge (meets all engineering specs) that fails validation (it was built in the wrong location). Both are essential.
Where MBSE Lives in the Lifecycle
A critical misconception to clear up right away: MBSE is not a lifecycle model. It is not a replacement for the V-model, the spiral model, or any other lifecycle framework. Instead, MBSE is a way of performing lifecycle activities using models rather than documents.
In a traditional (document-based) approach, each lifecycle activity produces a document — a stakeholder needs document, a system requirements specification, an architecture description document, a test plan, and so on. In an MBSE approach, those same activities produce models:
- Stakeholder Needs Definition → Stakeholder needs model (use cases, scenarios, operational context)
- Requirements Analysis → Requirements model (structured, linked requirements with traceability)
- Architecture Definition → Architecture model (structural decomposition, interfaces, allocations)
- Design Definition → Behaviour and parametric models (state machines, activities, constraints)
- Verification & Validation → Verification model (test cases linked to requirements, simulation results)
The key advantage: because all of these models live in the same modelling environment, they are connected. A requirement can be traced to the architecture element that satisfies it, to the test case that verifies it, and to the stakeholder need that motivated it — all through live, navigable links rather than cross-references between static documents.
When someone asks "Should we use MBSE or the V-model?", the answer is "both." The V-model (or whichever lifecycle you choose) tells you what to do and when. MBSE tells you how to capture and manage the information — using models instead of documents. They are complementary, not competing.
Iteration and Recursion
Real-world systems development is never a single, clean pass down one side of the V and up the other. Two important concepts make the lifecycle realistic: iteration and recursion.
Iteration
Iteration means repeating a process or set of processes within the same level to refine the result. For example, you might go through several rounds of architecture definition before the design stabilises — each round producing a more mature, more detailed model. Think of a sculptor: the first pass gives rough shape, the second pass adds detail, the third pass polishes. Each pass iterates over the same process.
Recursion
Recursion means applying the same set of processes at different levels of the system hierarchy. The same processes you use to define the system (stakeholder needs, requirements, architecture, verification) are applied again at the subsystem level, and again at the component level.
Think of Russian nesting dolls (matryoshka). Open the outermost doll (the system) and inside is a smaller doll (a subsystem), which contains an even smaller doll (a component). Each doll has the same shape and the same painted features — just at a different scale. In systems engineering, each "doll" goes through the same lifecycle processes (requirements, architecture, verification), just at a different level of abstraction.
This is precisely why models are so valuable in systems engineering. A well-structured model can represent multiple levels of abstraction in a single, coherent framework. You can zoom out to see the system-level architecture, or zoom in to see how a specific component is designed — and the traceability links between levels are maintained automatically. With documents, managing this multi-level consistency is extraordinarily difficult. With models, it is built in.
The spiral within the V
In practice, most modern projects combine the V-model structure with iterative spirals. At each stage of the V, teams may go through multiple iterations (spirals) to mature their work products before moving on. MBSE supports this naturally: models are inherently incremental. You do not write a model "once and done" — you evolve it continuously, adding detail and refinement with each iteration.
Concept of Operations (ConOps)
Before you can define requirements or design architecture, you need to understand how the system will be used. This is the purpose of the Concept of Operations (ConOps) — a description of the system from the user's perspective, in the user's language, focused on operational scenarios.
The ConOps is typically the starting point of any MBSE effort. It answers three fundamental questions:
- Who are the users and stakeholders?
- What do they do with (or expect from) the system?
- What scenarios must the system handle?
Example: Smart Home System
Consider a smart home security system. A ConOps model would capture:
Actors (who):
- Homeowner — primary user, arms/disarms the system, monitors alerts
- Guest — limited access, can enter with a temporary code
- Maintenance Technician — performs updates and repairs, needs diagnostic access
- Monitoring Service — external service that responds to alarm events
Operations (what):
- Arm the system (full mode, away mode, night mode)
- Disarm the system (via keypad, app, or voice)
- Monitor cameras and sensor status
- Configure automation rules (e.g., "if motion detected after 11pm, turn on lights")
- Receive and acknowledge alerts
Scenarios (what if):
- Normal operation — homeowner leaves, arms system, system monitors sensors, homeowner returns, disarms
- Alarm triggered — sensor detects intrusion, system sounds alarm, notifies monitoring service, homeowner receives alert
- Power failure — system switches to battery backup, reduces non-essential functions, notifies homeowner
- False alarm — homeowner cancels alarm within grace period, system logs event
Why ConOps matters: Without a clear ConOps, engineers often jump straight into designing components without truly understanding how the system will be used. This leads to technically impressive systems that fail in practice — the classic "solution looking for a problem." In MBSE, the ConOps model becomes a living reference that the rest of the model traces back to: every requirement should link to an operational need, and every test case should trace to an operational scenario.
Bridge to the Pillars
In this module, we explored the systems engineering lifecycle — the V-model, the ISO/IEC/IEEE 15288 technical processes, how MBSE supports (but does not replace) the lifecycle, the concepts of iteration and recursion, and the importance of a Concept of Operations.
But understanding the lifecycle is only the beginning. To actually practise MBSE, you need three things working together:
- A modelling language — a precise, standardised way to express system information (e.g., SysML, SysML v2).
- A method — a systematic process that tells you what to model, in what order, and at what level of detail (e.g., OOSEM, MagicGrid, Harmony).
- A tool — a software environment that supports the language and method, enabling you to create, manage, and analyse models (e.g., Cameo, Rhapsody, Capella).
These three elements are often called the three pillars of MBSE.
Think of a three-legged stool. The seat is MBSE — it is what you sit on, what you actually use. But it cannot stand without all three legs: the language leg, the method leg, and the tool leg. Remove any one leg and the stool topples over. A brilliant tool is useless without a language to express your models. A powerful language is impractical without a tool to manage complexity. A language and tool together are directionless without a method to guide you.
In the next three modules, we will examine each pillar in depth: Module 3 covers Language, Module 4 covers Method, and Module 5 covers Tool.