What Is a System of Interest? Defining Boundary-Setting Concepts in Systems Engineering

Systems engineers define a lot of things with precision. Stakeholder needs, functional requirements, physical architectures — these get documented, reviewed, and baselined. The boundary of the system being engineered, the System of Interest, often does not. It lives in a program kickoff slide, gets assumed by everyone, and then quietly becomes the source of scope arguments three design reviews later.

The System of Interest (SOI) is one of the most load-bearing concepts in INCOSE systems engineering, and one of the least formally managed in practice. Getting it right early is not a theoretical exercise. It is the foundation on which everything else — requirements scoping, interface management, decomposition planning — is built.

Defining the System of Interest

The System of Interest is the specific system being engineered during a particular systems engineering effort. That qualifier — particular — matters. SOI definition is contextual, not absolute. A turbofan engine is an SOI during propulsion system development. The same engine becomes an external system — a neighbor, not the subject — when the aircraft program is the SOI.

INCOSE’s Systems Engineering Handbook places the SOI within a tiered structure of systems:

  • System of Interest: The system being designed, analyzed, and verified in this effort.
  • Enabling systems: Systems that help create, produce, test, deploy, or dispose of the SOI — manufacturing tooling, test equipment, training systems, support infrastructure. They are not being designed; they are being managed as dependencies.
  • Other systems in the operational environment: Systems the SOI interacts with during operations — adjacent platforms, ground systems, users, external data feeds. These define interfaces, not internal behavior.

The SOI is not the largest system in view. It is the system this team owns. Everything outside that boundary is either an enabling system or an environmental actor. Both categories demand interface definitions. Neither belongs inside the SOI’s decomposition.

Why SOI Misidentification Is an Expensive Problem

When engineers on a program disagree about where the SOI boundary sits — even implicitly — several failure modes follow.

Scope creep from boundary ambiguity. If the SOI boundary is not explicit, requirements that belong to neighboring systems bleed into the current effort. A radar program that hasn’t clearly excluded the antenna feed assembly from its SOI will inevitably write requirements for it, staff work to it, and then discover someone else already owns it. The costs are duplicated in the best case, contradictory in the worst.

Interface mismanagement. External systems don’t disappear because they aren’t in scope. They generate interface requirements: voltage levels, data formats, mechanical mounting loads, thermal exchange rates. If an external system is misclassified as internal, its interface requirements get lost or become internal design decisions rather than negotiated agreements. If an internal subsystem is misclassified as external, its requirements get under-specified. Both directions cause integration failures.

Requirements gaps at the boundary. Requirements that govern how the SOI behaves toward external systems — operational modes triggered by external events, fault responses to interface degradation, performance bounds under external load — are the most commonly missed requirements on hardware programs. They live at the boundary, and if the boundary isn’t drawn, they don’t get written.

Test scope confusion. Verification planning depends on knowing what is being verified. An undefined SOI makes it impossible to distinguish acceptance tests (does the SOI meet its requirements?) from integration tests (does the SOI function correctly with its environment?).

Context Diagrams as the Formal Tool for SOI Boundary Definition

The primary tool for making an SOI boundary explicit is the context diagram. A context diagram does one job: it shows the SOI as a single, bounded element, surrounded by everything it interacts with, connected by labeled interfaces.

A well-formed context diagram contains:

  • The SOI at the center, treated as a black box. No internal decomposition is shown. The context diagram is not an architecture — it is a boundary declaration.
  • External systems: Adjacent systems the SOI exchanges data, power, force, or material with during operations. Each is named. Each connection is labeled with what flows across it.
  • Enabling systems: Shown separately if relevant — they interact with the SOI during its lifecycle phases (manufacturing, test, training) rather than during operations.
  • Operational actors: Human operators, users, maintainers, and decision-makers who interact with the SOI directly.
  • Interface flows: Named, directional, typed. Not just lines. Power is not data is not mechanical load.

The discipline the context diagram enforces is important: every external actor must be explicitly named, and every interaction with every external actor must be explicitly labeled. If you can’t label the interface, you haven’t understood the boundary yet.

The context diagram is the precursor to requirements scoping, not a product of it. Teams that skip the context diagram and start writing requirements are scoping requirements to an undefined system. Some of those requirements will turn out to belong to something else. Some requirements that should exist won’t get written because the relevant external actor wasn’t on anyone’s mental model.

How SOI Definition Affects Requirements Scoping

Once the SOI boundary is drawn, requirements scoping follows a clear logic:

Requirements belong to the SOI if they govern the behavior, performance, or physical properties of the SOI itself — including how it behaves at its interfaces.

Requirements belong to other systems if they govern the behavior of external systems, even if the SOI’s correct operation depends on that behavior. Those become assumptions or interface control document (ICD) inputs, not SOI requirements.

Interface requirements are bilateral. The SOI has interface requirements that specify what it provides and what it requires from each external system. The external system has corresponding requirements on its side. These must be negotiated, not unilaterally written.

The SOI boundary also governs requirements decomposition. When the SOI is decomposed into subsystems, requirements are allocated to those subsystems. Requirements that come from or drive the SOI’s interfaces must be traceable to the interface source — a specific external system, a specific operational actor — not just to a higher-level parent requirement. Missing that trace is how interface requirements get orphaned and then missed at integration.

Verification requirements are similarly scoped. Each SOI requirement must have a verification method — analysis, test, inspection, demonstration — that can be executed within the SOI boundary or at its interfaces. Requirements that can only be verified at the system-of-systems level are a signal that the SOI boundary was drawn incorrectly.

Level-Shifting: When the SOI Changes

The SOI is not fixed across a program’s lifecycle. Systems engineering work operates at multiple levels, and the SOI shifts accordingly.

During preliminary design, the vehicle is the SOI. During subsystem design, a propulsion unit or avionics box becomes the SOI. During component qualification, a specific assembly becomes the SOI. Each shift redraws the boundary: what was an internal subsystem becomes the system under scrutiny, and the parent system becomes an external actor providing interface requirements.

This level-shifting is conceptually straightforward but operationally hard to manage in document-based environments. Requirements allocated from the vehicle level to the subsystem level need to travel with the boundary shift. Interface requirements from the vehicle-to-subsystem interface become the subsystem’s external interface requirements. If requirements are stored in documents rather than in a connected model, these relationships have to be manually reconstructed at each level shift — and they frequently aren’t.

How Flow Engineering Implements Formal SOI Boundary Definition

The gap between the conceptual clarity of SOI definition and the operational messiness of program execution is largely a tooling problem. Document-based requirements management tools — DOORS, Jama, Polarion — can store requirements, but they don’t have a native representation of a system boundary or a context diagram. SOI definition lives in a separate document, disconnected from the requirements database, and the relationship between the two has to be maintained manually.

Flow Engineering addresses this structurally. Built on a graph-based data model rather than a document hierarchy, it allows systems engineers to define the SOI as a formal node in the systems graph, with explicit boundary semantics. External systems are represented as separate nodes. Interface flows between the SOI node and external nodes are first-class model elements — not annotations in a diagram, but typed relationships that carry attributes and can be traced to requirements.

When requirements are captured in Flow Engineering, they can be anchored to the SOI boundary or to specific interface flows. A requirement that governs the SOI’s behavior at its power input interface is linked to that interface element, which is linked to the external system providing power. That trace exists in the model, not in a human’s memory or in a separate traceability spreadsheet.

Decomposition work in Flow Engineering inherits the SOI boundary. When the SOI node is decomposed into subsystem nodes, interface flows at the SOI boundary are candidates for allocation to specific subsystems. The tool makes visible which subsystems are responsible for which external interfaces — a question that, in document-based workflows, typically requires a dedicated interface management meeting to reconstruct.

Flow Engineering’s focus is on the front-end systems engineering work where SOI definition, context modeling, and requirements scoping happen. It is not a full program management platform or a lifecycle management suite. Teams that need integrated change management workflows spanning hardware release and manufacturing will need to assess how Flow Engineering fits alongside those systems. For the specific problem of getting the SOI boundary right before decomposition work begins, it is purpose-built for that task.

Practical Starting Points

If SOI definition is not currently a formal step on your program, the entry point is lower than it might seem:

  1. Name the SOI explicitly in program documentation. Write a one-paragraph SOI statement that defines what the SOI is, what lifecycle phase this engineering effort covers, and what is explicitly excluded.

  2. Draw a context diagram before the first requirements review. It does not have to be in a modeling tool. A whiteboard session with the systems engineering lead, the chief engineer, and the lead interface engineers is sufficient to find the boundary disagreements that are otherwise invisible.

  3. Audit requirements against the SOI boundary. For each requirement, ask: does this govern the SOI, an external system, or an interface? Requirements that govern external systems should be converted to interface assumptions. Requirements that govern interfaces should be linked to the relevant external actor.

  4. Document level-shifting decisions. When the SOI shifts from vehicle to subsystem, record what the new SOI is, what is now external, and which requirements travel with the shift.

The System of Interest is not a bureaucratic formality. It is the answer to the question every engineer on a program should be able to answer: what exactly are we building, and where does our responsibility end? Programs that answer that question explicitly, early, and formally spend less time in scope arguments and more time on engineering. That is the return on the investment.