Leif P. HeaneyAI/ML & Systems Engineer
Schedule Meeting

Field guide 01 / Lesson 03

Model-Based Systems Engineering

Use purposeful models, viewpoints, and traceability to connect needs, architecture, behavior, analysis, and verification.

52 minutes12 sections10 questionsUpdated
On this page
  1. 1. What is a model?
  2. 2. Document-centric and model-based work
  3. 3. Model, diagram, view, and viewpoint
  4. 4. What a system model can represent
  5. 5. MBSE through the life cycle
  6. 6. SysML 2.0 in context
  7. 7. Traceability explorer
  8. 8. Viewpoint explorer
  9. 9. Model quality
  10. 10. Worked model: emergency notification
  11. 11. Common MBSE misconceptions
  12. 12. From one system model to many independent systems
  13. Worked example
  14. Misconceptions
  15. Glossary
  16. Knowledge check
  17. References

Your destination

Learning objectives

  • Define a model and explain how it differs from the real system.
  • Compare document-centric and model-based work without treating them as mutually exclusive.
  • Distinguish model, diagram, view, viewpoint, metamodel, language, and tool.
  • Identify requirement, structure, behavior, interface, analysis, and verification information.
  • Explain bidirectional traceability and change impact.
  • Describe how models support life-cycle activities.
  • Interpret a small system model.
  • Trace a stakeholder need to verification evidence.
  • Recognize common MBSE misconceptions.

Before you begin

  • Systems Thinking
  • Modular Design Systems

1. What is a model?

A model is a purposeful representation, not a miniature truth machine.

  • Purpose: the question or decision the model supports.
  • Scope: what the model includes.
  • Abstraction: what detail it intentionally omits.
  • Assumptions: conditions taken as true for the model.
  • Fidelity: how closely selected characteristics represent the target.
  • Limitations: questions the model cannot answer reliably.
(SEBoK, 2026)

A transit map omits street geometry to reveal routes and transfers. An engineering model likewise selects information for a purpose—but the analogy ends there: engineering models may also encode constraints, behavior, parameters, and relationships that support analysis.

2. Document-centric and model-based work

MBSE changes how engineering information is connected; it does not make documents disappear.

Document-centered baseline

  • Requirements document
  • Architecture document
  • Interface spreadsheet
  • Analysis report
  • Test plan

Connected model baseline

  • Need and requirement elements
  • Structure and behavior elements
  • Interface and parameter relationships
  • Analysis and verification cases
  • Generated or synchronized views
(SEBoK, 2026)

Documents remain useful delivery and communication forms. In a model-based approach, structured model elements and relationships become a primary engineering information source, while documents can be generated, synchronized, or managed alongside the model. (SEBoK, 2026; International Organization for Standardization, 2023)

3. Model, diagram, view, and viewpoint

These terms solve different problems; treating them as synonyms creates confusion.

Information

  • Model: the represented elements and relationships.
  • View: selected model information addressing stakeholder concerns.
  • Diagram: one graphical presentation of information.

Rules and machinery

  • Viewpoint: conventions for constructing and using a view.
  • Metamodel: concepts and rules that define valid model structures.
  • Modeling language: notation and semantics used to express models.
  • Tool: software used to create, manage, analyze, or exchange models.
(International Organization for Standardization, 2022; SEBoK, 2026)

4. What a system model can represent

A useful system model connects several kinds of engineering information without forcing all of it into one picture.

  • Stakeholder needs and concerns.
  • System and subsystem requirements.
  • Functions, actions, states, and scenarios.
  • Logical and physical structure.
  • Interfaces, exchanges, and constraints.
  • Parameters and analysis cases.
  • Verification cases, results, and evidence.
  • Relationships that support traceability and impact analysis.
(SEBoK, 2026; Object Management Group, 2025)

The model should include enough information for its declared purpose. “Complete” is therefore relative to questions, decisions, stakeholders, and life-cycle stage—not an absolute amount of detail. (SEBoK, 2026)

5. MBSE through the life cycle

Connected information is useful long after the first architecture diagram is drawn.

  • Concept definition: compare system boundaries, missions, and alternatives.
  • Requirements analysis: connect needs, requirements, rationale, and constraints.
  • Architecture development: relate functions, structure, interfaces, and parameters.
  • Trade studies: record alternatives, assumptions, measures, and decisions.
  • Integration planning: expose dependencies and interface readiness.
  • Verification planning: connect requirements to methods, cases, and evidence.
  • Change impact: traverse upstream and downstream relationships.
  • Operations and sustainment: maintain configuration and decision context as the system evolves.
(International Organization for Standardization, 2023; International Organization for Standardization, 2024; Walden et al., 2023)

ISO/IEC/IEEE 15288:2023 provides a common process framework across conception, development, production, utilization, support, and retirement, while deliberately avoiding prescription of one modeling approach or technique. (International Organization for Standardization, 2023)

6. SysML 2.0 in context

SysML is one modeling language that can support MBSE; MBSE is the broader engineering approach.

The Object Management Group adopted formal SysML 2.0 in September 2025. It supports models of requirements, structure, behavior, analysis cases, and verification cases and is intended to facilitate multiple MBSE methods and practices. (Object Management Group, 2025)

OMG also identifies SysML 1.7, adopted in June 2024, and expects SysML v1 use to continue during transition. This lesson uses concept-level visuals rather than claiming a specific diagram is compliant notation for either version. (Object Management Group, 2025)

Common SysML v2 concepts

  • Requirements
  • Parts and connections
  • Actions and states
  • Analysis cases
  • Verification cases
  • Textual and graphical views

Version note

  • Use cases and the familiar nine-diagram taxonomy are strongly associated with SysML v1.
  • Do not blend v1 diagram notation into a v2 model without labeling the source version.
  • A tool’s support level must be verified separately.
(Object Management Group, 2025)

7. Traceability explorer

Traceability turns isolated artifacts into navigable engineering reasoning.

Selecting an element should expose what justifies it upstream and what depends on it downstream. Missing relationships are not automatically errors, but they are review questions: Is the requirement allocated? Is the interface verified? Does the result satisfy a verification case? (National Aeronautics and Space Administration, 2016; SEBoK, 2026)

Traceability explorer

Follow need to evidence

Select an element

Its upstream and downstream relationships will highlight here.

Text alternative

Need connects to requirement; requirement connects to function and verification case; function connects to component; component connects to interface; interface connects to verification; verification connects to result. Removing the requirement-to-verification relationship creates a visible evidence gap.

8. Viewpoint explorer

A view answers selected concerns; it should not pretend to show the whole model.

Requirements, functional, logical, physical, interface, and verification views can all draw from the same connected model. Each view reveals relevant elements and suppresses unrelated detail so a stakeholder can answer a specific question. (International Organization for Standardization, 2022; SEBoK, 2026)

Viewpoint explorer

One model, selected concerns

What must the system accomplish?

Requirements view

Need: warn occupantsREQ-01: two channelsREQ-02: delivery-time allocation
Text alternative

All six views draw from one emergency-notification model. Requirements emphasizes obligations; functional emphasizes behavior; logical emphasizes responsibilities; physical emphasizes realized elements; interface emphasizes exchanges; verification emphasizes evidence.

9. Model quality

A large model is not necessarily a useful model.

  • Correct enough for its purpose and evidence.
  • Complete relative to declared scope and decisions.
  • Internally consistent across connected elements.
  • Traceable where relationships support decisions and assurance.
  • Understandable to intended users.
  • At an appropriate level of abstraction.
  • Configuration controlled so users know which baseline they see.
  • Validated with stakeholders and subject-matter experts.
(SEBoK, 2026; National Aeronautics and Space Administration, 2016)

10. Worked model: emergency notification

Trace one stakeholder need to objective verification evidence.

  1. Need: campus occupants need timely, understandable warnings.
  2. System requirement: deliver an approved alert through at least two configured channels within the allocated time.
  3. Function: validate, authorize, distribute, and monitor the alert.
  4. Logical components: authoring, approval, routing, channel adapters, and status collection.
  5. Interface: versioned alert payload with audience, content, priority, and timestamp.
  6. Verification case: inject an approved alert under a defined load and measure channel delivery.
  7. Result: store timestamped evidence and exceptions against the verification case.
(National Aeronautics and Space Administration, 2016; Object Management Group, 2025)

Validation remains distinct: even a verified delivery-time requirement may fail stakeholder needs if messages are confusing or inaccessible in the real operating context. (National Aeronautics and Space Administration, 2016)

11. Common MBSE misconceptions

The fastest way to misuse MBSE is to confuse a tool output with engineering understanding.

12. From one system model to many independent systems

The next lesson changes the governance problem.

A model can connect information inside one program, but a system of systems includes constituent systems with useful independent missions, owners, roadmaps, and constraints. That independence changes how architecture, traceability, verification, and authority work. (Maier, 1998; International Organization for Standardization, 2019)

Put it together

Trace an emergency alert from need to evidence

A campus notification capability must deliver approved alerts promptly through multiple channels and make delivery status visible. (National Aeronautics and Space Administration, 2016; SEBoK, 2026)

  1. Capture the stakeholder need and operating scenarios.
  2. Derive a measurable system requirement with defined conditions.
  3. Allocate behavior to validation, approval, routing, adapter, and monitoring functions.
  4. Connect logical functions to components and interfaces.
  5. Define a verification case with load, timing, and observation conditions.
  6. Connect the result and exceptions to the case and requirement.
  7. Use stakeholder validation to check whether verified messages are understandable and usable.
Reflect: If the channel adapter changes, which requirements, interfaces, analyses, and verification cases should be reviewed?

Check the mental model

Common misconceptions

Myth: MBSE is drawing diagrams.

It uses connected formalized representations across engineering activities. (SEBoK, 2026)

Myth: SysML and MBSE are the same thing.

SysML is a modeling language; MBSE is a broader approach that can use different methods and languages. (Object Management Group, 2025)

Myth: The model is the real system.

A model is a scoped abstraction with assumptions and limitations. (SEBoK, 2026)

Myth: MBSE eliminates documents.

Documents can coexist with and be generated from model information. (SEBoK, 2026)

Myth: More detail always improves a model.

Detail should serve model purpose, scope, and decisions.

Myth: Digital engineering, digital thread, digital twin, and MBSE are interchangeable.

They overlap in practice but name different scopes and capabilities.

Remember this

Lesson summary

  • A model is a purposeful representation with scope, assumptions, and limits.
  • MBSE connects structured engineering information across the life cycle.
  • A diagram is one presentation; a view is governed by a viewpoint.
  • Traceability links needs, requirements, architecture, behavior, interfaces, and evidence.
  • SysML 2.0 is a current modeling language that can support MBSE; it is not MBSE itself.
  • Model quality is relative to purpose and includes correctness, consistency, traceability, usability, and configuration control.

Key language

Glossary

Model
A representation created for a purpose, with an explicit scope, assumptions, and level of abstraction. (SEBoK, 2026)
Abstraction
A purposeful simplification that keeps the characteristics needed for a question while leaving out detail that is not needed. (SEBoK, 2026)
Model-Based Systems Engineering
An approach that uses formalized system representations to support systems engineering activities across the life cycle. (SEBoK, 2026)
View
A representation of selected system concerns governed by a viewpoint; it reveals some model information while intentionally omitting other information. (International Organization for Standardization, 2022; SEBoK, 2026)
Viewpoint
A reusable set of conventions for constructing and using a view to address particular stakeholder concerns. (International Organization for Standardization, 2022)
Requirement
A statement of a needed capability, condition, or quality that can guide design and be verified. (National Aeronautics and Space Administration, 2016)
Traceability
The ability to follow relationships among needs, requirements, architecture, behavior, interfaces, and verification evidence in both directions. (National Aeronautics and Space Administration, 2016; SEBoK, 2026)
Verification
Confirmation through objective evidence that specified requirements have been fulfilled. (National Aeronautics and Space Administration, 2016)
Validation
Confirmation that the realized system fulfills its intended use and stakeholder needs in the operational context. (National Aeronautics and Space Administration, 2016)
Architecture
The fundamental concepts or properties of an entity in its environment, expressed through its elements, relationships, and principles of design and evolution. (International Organization for Standardization, 2022)
Interface
A defined boundary across which elements interact or exchange matter, energy, data, or control, including the assumptions and rules governing that exchange. (National Aeronautics and Space Administration, 2016)

Apply what you learned

Knowledge check

Answer all 10 questions, then submit for explanations and a score. You can retry as often as you like.

Question 1What makes a representation a useful engineering model?
Question 2MBSE requires eliminating documents.
Question 3Which statement correctly distinguishes a view from a viewpoint?
Question 4Which can be represented in a connected system model?
Question 5A requirement changes. What is traceability most useful for first?
Question 6Order the example from stakeholder concern to evidence.
Question 7Which SysML statement is current?
Question 8Which artifact is a view rather than the entire model?
Question 9A model is syntactically valid but stakeholders say it represents the wrong operating scenario. Which quality activity is most needed?
Question 10Why can excessive model detail be harmful?

Evidence

References

References are formatted to the project’s APA 7 conventions from structured source data.

  1. Systems Engineering Body of Knowledge authors. (2026). Model-based systems engineering (MBSE). Guide to the Systems Engineering Body of Knowledge (SEBoK), version 2.14. SEBoK. Retrieved July 16, 2026, from https://sebokwiki.org/wiki/Model-Based_Systems_Engineering_%28MBSE%29
  2. International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2023). Systems and software engineering — System life cycle processes. (ISO/IEC/IEEE 15288:2023). International Organization for Standardization. https://www.iso.org/standard/81702.html
  3. International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2024). Systems and software engineering — Life cycle management — Part 2: Guidelines for the application of ISO/IEC/IEEE 15288. (ISO/IEC/IEEE 24748-2:2024). International Organization for Standardization. https://www.iso.org/standard/84661.html
  4. International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2022). Software, systems and enterprise — Architecture description. (ISO/IEC/IEEE 42010:2022). International Organization for Standardization. https://www.iso.org/standard/74393.html
  5. Object Management Group. (2025). OMG system modeling language. (SysML 2.0). Object Management Group. https://www.omg.org/spec/SysML/2.0/About-SysML
  6. National Aeronautics and Space Administration. (2016). NASA systems engineering handbook (Rev. 2). (NASA/SP-2016-6105 Rev2). National Aeronautics and Space Administration. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  7. Walden, D. D., Roedler, G. J., Forsberg, K. J., Hamelin, R. D., & Shortell, T. M. (2023). INCOSE systems engineering handbook: A guide for system life cycle processes and activities (5th ed.). Wiley. https://www.incose.org/resources-publications/technical-publications/se-handbook/
  8. Maier, M. W. (1998). Architecting principles for systems-of-systems. Systems Engineering, 1(4), 267–284. https://doi.org/10.1002/(SICI)1520-6858(1998)1:4<267::AID-SYS3>3.0.CO;2-D
  9. International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2019). Systems and software engineering — System of systems (SoS) considerations in life cycle stages of a system. (ISO/IEC/IEEE 21839:2019). International Organization for Standardization. https://www.iso.org/standard/71955.html

Save your place

Finished this lesson?

Progress stays on this device. No account or tracking service is required.