Module 6: OOSEM

OOSEM — the Object-Oriented Systems Engineering Method — was developed by Sanford Friedenthal, Alan Moore, and Rick Steiner, the same team behind the widely-used reference text A Practical Guide to SysML. The method emerged from the recognition that while object-oriented thinking had transformed software engineering, systems engineering lacked a comparable, structured approach that fully exploited the power of modelling languages like SysML.

Core philosophical principles

OOSEM brings several fundamental ideas from object-oriented thinking into the systems engineering domain:

• Encapsulation — each system element hides internal complexity behind well-defined interfaces, so teams can work on subsystems independently.
• Abstraction — the method deliberately separates what the system must do (logical architecture) from how it does it (physical architecture). This separation is the single most important concept in OOSEM.
• Hierarchy and decomposition — systems are broken down into progressively smaller, manageable elements, each modelled with the same rigour as the whole.
• Reuse — definitions (types) are created once and instantiated many times, promoting consistency across the model.

Why "object-oriented" matters for SE

Traditional systems engineering often followed a purely functional decomposition — breaking the system into functions, then allocating functions to components. OOSEM adds the object-oriented dimension: the system is also decomposed into objects (logical entities) that own both structure and behaviour. This dual perspective — functional and structural — produces architectures that are more modular, more traceable, and easier to evolve when requirements change.

OOSEM organises the systems engineering effort into five main activities. Although they are presented in sequence, the process is fundamentally iterative — you will revisit earlier activities as understanding deepens.

1. Analyse Stakeholder Needs — Identify who cares about the system and what they need. Capture needs in a structured form.
2. Define System Requirements — Transform stakeholder needs into precise, verifiable system requirements that constrain the design.
3. Define Logical Architecture — Decompose the system into logical subsystems based on functionality. This is the "what it does" view, independent of technology choices.
4. Synthesise Candidate Physical Architectures — Map logical functions onto physical components. Generate multiple candidate solutions.
5. Optimise and Evaluate — Conduct trade studies to select the best candidate architecture against requirements and constraints.

The running example: Home Security System

Throughout the remaining sections, we will apply OOSEM to a Home Security System. This system must detect intrusions, alert the homeowner, and optionally notify law enforcement. It is simple enough to fit in a tutorial but rich enough to illustrate every OOSEM activity.

The first OOSEM activity is to understand who cares about the system and what they need. This is not just a formality — stakeholder needs are the ultimate source of truth against which every design decision will be validated.

Identifying stakeholders

For our home security system, the key stakeholders are:

• Homeowner — the primary user who wants to feel safe and be alerted to intrusions.
• Security monitoring company — the organisation that monitors alerts 24/7 and dispatches police if needed.
• Installer / technician — the person who physically installs, configures, and maintains the system.

Capturing needs and deriving requirements

Each stakeholder has needs expressed in their own language. The systems engineer must translate these into formal, verifiable requirements. The table below shows this mapping for our example:

Once requirements are established, OOSEM asks you to design the logical architecture — a decomposition of the system into subsystems based purely on what the system does, not on how it is physically built. This is the heart of OOSEM's "separation of concerns" philosophy.

Logical subsystems for the Home Security System

Analysing the requirements from Section 3, we can identify three primary logical functions:

• Detection function — responsible for sensing unauthorised entry events (doors, windows, motion).
• Alert function — responsible for notifying the homeowner and the monitoring company when an intrusion is detected.
• Control function — responsible for arming/disarming the system, managing sensor states, and coordinating the detection and alert functions.

Notice that at this stage we say nothing about cameras, motion sensors, sirens, or cloud servers. We only describe capabilities. The detection function detects; the alert function alerts; the control function coordinates. This is deliberate.

Why separate logical from physical?

The logical architecture acts as a stable backbone. Physical technologies change — today's motion sensor may be replaced by a radar module next year — but the logical function "detect intrusion" remains the same. By anchoring requirements to logical functions first, you ensure that:

• Requirements traceability is clean — each requirement maps to a logical function, and each logical function maps to one or more physical components.
• Technology changes only affect the physical layer, not the entire architecture.
• Multiple candidate physical architectures can be evaluated against the same logical baseline.

With the logical architecture defined, the next OOSEM activity is to synthesise candidate physical architectures. This means mapping each logical function to concrete, implementable components — and then evaluating which combination best satisfies the requirements.

Mapping logical to physical

For our Home Security System, the "detection" logical function could be realised by several physical technologies: passive infrared (PIR) motion sensors, door/window magnetic contact sensors, security cameras with video analytics, or a combination. Similarly, the "alert" function could use a local siren, a cloud-based push notification service, a direct cellular link to the monitoring centre, or all three.

OOSEM encourages generating multiple candidate architectures and then conducting a trade study to select the best one. Below is a simplified trade study comparing two candidates:

In this example, Candidate B scores higher overall because the improved detection accuracy (reducing false alarms and enabling visual verification) outweighs the additional cost and privacy considerations. The trade study makes the rationale explicit and traceable.

OOSEM provides a comprehensive, well-documented method for applying object-oriented thinking to the full systems engineering lifecycle. Let us summarise its strengths, weaknesses, and ideal use cases.

Strengths

• Comprehensive coverage — OOSEM addresses the entire path from stakeholder needs through logical and physical architecture to trade-study-based selection.
• Well-documented — the method is thoroughly described in A Practical Guide to SysML, with worked examples and templates.
• Language-independent — although originally presented alongside SysML, OOSEM's activities and artefacts are not tied to any specific modelling language. It can be applied with SysML v1, SysML v2, or even domain-specific languages.
• Strong traceability — the clean separation of logical and physical layers creates natural traceability chains: Stakeholder Need → Requirement → Logical Function → Physical Component.

Weaknesses

• Heavyweight for small projects — the full five-activity process with formal trade studies can be overkill for small systems or rapid prototyping efforts.
• Learning curve — teams unfamiliar with object-oriented concepts may struggle with the logical/physical separation initially.
• Less prescriptive on diagrams — OOSEM tells you what to produce at each stage but is less specific about which diagram types to use (unlike MagicGrid, which prescribes a specific matrix of views).

When to use OOSEM

OOSEM is best suited for:

• Large-scale, complex systems where the separation of logical and physical architecture pays off in managing complexity.
• Programmes with multiple candidate solutions where formal trade studies are needed to justify architecture decisions.
• Organisations adopting MBSE for the first time — the book-length reference and worked examples make it a practical on-ramp.
• Multi-disciplinary teams that need a shared, technology-neutral framework before committing to physical design.