MBSE METHOD BRIEF · SysML-based, INCOSE-sponsored

Object‑Oriented Systems Engineering Method

OOSEM is a top-down, scenario-driven approach to model-based systems engineering that treats a system as a set of interacting objects — allocating behavior to structure through a repeated, iterative cycle rather than a single pass of decomposition.

Originated 1998 · developed jointly by Lockheed Martin and the INCOSE OOSEM Working Group · modeled in SysML

01 Needs analysis 02 Requirements analysis 03 Logical / physical architecture 04 Design synthesis 05 Verification & validation Trade studies & analysis iterate as the design matures

Simplified from INCOSE's OOSEM activity model — the method cycles through these activities repeatedly rather than completing them once in sequence.

01 — What it is

An object-oriented method for systems, not just software

OOSEM applies object-oriented analysis and design concepts — long established in software engineering — to the broader practice of systems engineering. It is a tool- and vendor-neutral methodology: no single company owns an OOSEM product, and it can be carried out with any SysML-capable modeling tool paired with a requirements management tool.

The method covers the core activities any systems engineer would recognize — needs analysis, requirements analysis, architecture definition, trade studies, and verification — but organizes them around objects and their interactions rather than a purely functional decomposition. That framing is meant to ease integration with object-oriented software development, hardware development, and test processes downstream.

OOSEM was developed starting in 1998 as a joint effort involving Lockheed Martin engineers and what became the INCOSE Object-Oriented Systems Engineering Method Working Group, predating SysML itself — the method was later re-expressed using SysML once the language was standardized by the OMG.

02 — How it works

Top-down, scenario-driven, and iterative

OOSEM starts from operational scenarios and works down: black-box behavior is defined first, then allocated to a logical architecture of interacting objects, then refined into a physical design. Each pass through the cycle decomposes objects further, allocates more detailed behavior, and produces requirements specific enough to hand to implementers.

The approach shares its top-down, scenario-driven character with methods such as the Harmony process and the Rational Unified Process for Systems Engineering (RUP SE), and it draws on techniques including causal analysis, logical decomposition, node distribution analysis, control strategy definition, and parametrics to handle different kinds of system concerns as they arise.

03 — Core activities

What the cycle actually contains

  1. 01

    Needs analysis

    Establish the problem the system must solve and the stakeholders whose needs define success, before any solution language enters the picture.

  2. 02

    Requirements analysis

    Translate needs and operational scenarios into black-box system requirements, capturing required behavior without presupposing a design.

  3. 03

    Architecture & logical decomposition

    Allocate behavior to a logical architecture of interacting objects, then decompose those objects into a physical architecture of components.

  4. 04

    Trade studies & analysis

    Compare candidate architectures and parameter sets against measures of effectiveness to justify design decisions.

  5. 05

    Design synthesis

    Refine the physical architecture into a design specific enough to be implemented, tested, and integrated.

  6. 06

    Verification & validation

    Confirm the delivered system satisfies its requirements and, ultimately, the original stakeholder needs — feeding lessons back into earlier activities as needed.

04 — INCOSE resources

Where to go for the source material

OOSEM is stewarded by INCOSE's Object-Oriented Systems Engineering Method Working Group. These are the primary places to find current working-group activity, charters, and background material.

WORKING GROUP

OOSEM Working Group home

Current charter, scope, and ongoing activity for the group that maintains and evolves OOSEM — including work to align it with SysML v2.

incose.org/group/object-oriented-se-method-working-group →
CHARTER (PDF)

Working Group charter

The working group's founding charter document: purpose, scope, history, and how OOSEM relates to methods like Harmony and RUP SE.

incose.org — WG charter PDF →
TRAINING

Introductory OOSEM & SysML tutorial

An INCOSE Chesapeake Chapter tutorial introducing OOSEM alongside SysML, built around A Practical Guide to SysML. A good entry point before reading primary papers.

incose-cc.org — tutorial page →
REFERENCE WIKI

OMG MBSE Wiki: OOSEM entry

A reference summary of OOSEM maintained on the OMG-hosted MBSE wiki, with a bibliography of the foundational papers and books.

omgwiki.org — MBSE:OOSEM →
INTERNATIONAL WORKSHOP

IW 2019 working-group brief

A marketplace summary from an INCOSE International Workshop covering the working group's history, product roadmap, and planned inputs to the SE Handbook and SysML spec.

incose.org — IW2019 brief PDF →
ORGANIZATION

INCOSE home

The International Council on Systems Engineering — for the Systems Engineering Handbook, chapters, certification, and the full list of working groups beyond OOSEM.

incose.org →

06 — Community & tooling

Where OOSEM meets open-source MBSE

OOSEM is method-only — it doesn't prescribe a tool. These are the open-source communities building the SysML/KerML tooling and model management infrastructure it's commonly practiced with.

COMMUNITY

OpenMBEE

The open-source Model-Based Systems Engineering environment, including Model Management System (MMS) tooling for storing and serving system models.

openmbee.org →
COMMUNITY

OpenSysML

The community forum and resource hub for SysML v2 and KerML, covering the transition from SysML v1 and the surrounding open ecosystem.

opensysml.org →

07 — Further reading

Foundational papers & texts