What Is a System of Interest?
In systems engineering, almost every other concept depends on this one — yet it often goes undefined in actual program documentation. The system of interest (SOI) is the entity whose development, acquisition, or modification is the specific focus of a given engineering effort. It is the thing you are building, not the thing it connects to, not the organization delivering it, and not the broader operational environment it lives in.
That sounds simple. In practice, it is one of the most consequential and underspecified decisions on any program.
The Hierarchy Around the SOI
The system of interest does not exist in isolation. ISO/IEC/IEEE 15288 and the INCOSE Systems Engineering Handbook both define it within a hierarchy of system concepts that clarify what falls inside the boundary and what does not.
Enabling systems are the systems required to produce, deploy, or sustain the SOI — test benches, manufacturing equipment, ground support systems, launch infrastructure. They are not the SOI. A satellite is the system of interest. The launch vehicle that places it in orbit is an enabling system. They have an interface, and that interface must be managed, but the launch vehicle’s internal architecture is not your problem to own.
External systems (sometimes called interacting systems) are the operational peer entities that exchange information, energy, or matter with the SOI in use. An aircraft flight management system receives inputs from navigation databases, ATC data links, and pilot interfaces. Those external systems define constraints and interface requirements, but they are outside the SOI boundary.
The context system — or system context — is the full operational environment in which the SOI functions: the physical environment, the regulatory environment, the humans interacting with it, and all the external systems together. The context system defines the operational concept, but it is not what you are building.
Getting these distinctions wrong has immediate practical consequences. Treating an external system as part of the SOI inflates scope and generates requirements you have no authority to impose. Treating an internal subsystem as external externalizes interface risk onto someone who may not be positioned to manage it.
How the Boundary Gets Established
The SOI boundary is not discovered by analyzing physics. It is decided — typically by program management, systems architecture, and customer negotiation — and then documented as a structural constraint on requirements decomposition.
The primary inputs to that decision are:
Contractual scope. What has been acquired? A prime contractor may be responsible for the integrated vehicle system; a supplier is responsible for the avionics suite within it. The SOI boundary often tracks the contract boundary, though not always cleanly.
Operational concept. What does the system need to do, and in what context? The operational concept establishes the external interfaces the SOI must satisfy, which in turn defines what must be inside the boundary to satisfy them.
Authority and accountability. Who controls the design? The SOI boundary should map to where a team has actual design authority. A boundary that places elements outside a team’s control inside their SOI creates a requirements management problem that no process will solve.
In aerospace, a useful example: a commercial aircraft program treats the aircraft as the SOI at the vehicle level. The airframe, propulsion, avionics, and cabin systems are all within the boundary. The airline’s operations software, ATC infrastructure, and airport ground systems are external. But a supplier developing the integrated modular avionics platform defines their SOI differently — the avionics platform is their SOI, and the aircraft is now the context system. The same physical hardware appears inside different SOI boundaries depending on which engineering effort you are describing.
In automotive, a similar dynamic plays out in the development of advanced driver assistance systems (ADAS). An OEM defines the vehicle as their SOI. The ADAS controller supplier defines their domain controller as the SOI. The camera module supplier defines the sensor assembly as theirs. Each definition is correct for its engineering effort. The integration risk lives at the boundaries between them, precisely because each team optimized requirements management for their own SOI.
Why the Boundary Shifts Across Program Phases
This is where programs get into trouble. The SOI boundary is not a static property of a system — it is a modeling decision that changes as a program matures, and those changes need to be tracked explicitly.
Early concept phases: The SOI boundary is broad and preliminary. Systems engineers are working at a high level of abstraction, and the boundary may be deliberately fuzzy while stakeholder needs are being captured. Allocating requirements in this phase is provisional.
Preliminary design: The boundary sharpens. Subsystems are being defined, supplier work packages are emerging, and interface control documents begin to take shape. The SOI for each supplier work package becomes a sub-element of the top-level SOI.
Detailed design and verification: The SOI for a given team may now be a specific assembly or software component. Traceability must link requirements back up through the decomposition hierarchy — from component-level verification results back to the system-level requirements that motivated them.
If the boundary was never formally recorded, each phase transition forces teams to re-argue about scope. Requirements that should have been allocated to a subsystem remain floating at the system level. Interface requirements that belong to the boundary between two subsystems get assigned to neither. Verification gaps emerge at integration because nobody owned the boundary behavior.
The failure mode is not dramatic. It is a slow accumulation of ambiguity: requirements that reference “the system” without specifying which system, interface control documents that lag behind the design, and integration tests that reveal behaviors nobody required because nobody agreed they were inside the boundary.
Practical Consequences of Boundary Ambiguity
Two specific failure patterns recur across programs:
Requirements orphaning. A requirement is written at the vehicle level referencing an external system’s behavior (“the system shall respond within 200ms of receiving the navigation update”). When the vehicle SOI is decomposed, nobody allocates this requirement because it references something external. It sits in the top-level requirements document unverified.
Interface gap. Two subsystems are each defined as separate SOIs with an interface between them. Requirements are written for each SOI in isolation. The interface behavior — latency, error handling, data formats under degraded conditions — belongs to neither SOI requirements set. It surfaces as a defect during integration.
Both failure patterns are ultimately SOI definition failures. If the boundary had been explicit, with interface requirements formally assigned to the interface itself or to one side of it by convention, the orphan and the gap would not form.
How Modern Tools Represent the System of Interest
Document-based requirements management tools — IBM DOORS, DOORS Next, Jama Connect, and similar platforms — do not have a native construct for the system of interest as a structural element. You can create a module called “System Boundary Definition” or add a custom attribute called “SOI Level,” but the tool does not enforce or reason about it. The boundary is implicit in how you name your modules and structure your folders. That implicitness is exactly the problem.
Graph-based, model-connected tools approach this differently. In Flow Engineering, the system of interest is represented explicitly as a node in the systems graph — a first-class entity with defined relationships to its context. The boundary is not a convention in a document; it is a structural boundary in the model that requirements, interfaces, and functions are allocated against.
When a systems engineer defines an SOI in Flow Engineering, they are establishing the scope against which stakeholder requirements are validated. Stakeholder needs that reference entities outside the defined boundary surface as out-of-scope items — flagged for explicit decision rather than silently absorbed into the requirements set. Interface requirements are allocated to the boundary node, making them traceable to the relationship between systems rather than buried inside either system’s requirements module.
When the SOI shifts between program phases — a common occurrence as a vehicle-level program decomposes into supplier work packages — Flow Engineering’s graph structure makes that shift a model operation rather than a documentation convention. The subsystem node becomes the active SOI for a given engineering effort; its parent context and its external interfaces are inherited from the graph, not re-entered by hand.
This matters practically for two reasons. First, it eliminates the manual boundary re-documentation that typically happens at each phase gate. Second, it provides a traceable record of how the boundary evolved, which is critical for audits, certification, and supplier integration.
Where to Start
If your program does not have an explicit SOI definition, start with three questions:
- What is the entity we have design authority over? Draw the boundary there first.
- What are the entities this system exchanges energy, information, or matter with in operation? Those are external systems; their internal behavior is a constraint on your interface requirements, not your requirements.
- What are the systems required to produce, deploy, test, or sustain our system? Those are enabling systems; they need their own requirements and their own SOI definitions.
Write the answers down in a place that is connected to your requirements decomposition, not in a separate concept document that will be last updated at program kickoff.
The system of interest is not a philosophical concept. It is the answer to the question every requirements engineer asks every day: what is this requirement about? If that answer is not structurally embedded in your requirements model, you are managing scope through informal agreement — and informal agreement does not survive a supplier change, a design review, or a team transition.