What Is System of Systems Engineering (SoSE)?

When the US Air Force integrates a fifth-generation fighter, a space-based sensor network, a ground-based command system, and a logistics platform into a unified kill chain, they are not engineering a large system. They are engineering a System of Systems (SoS). The distinction matters enormously — because the methods, governance structures, and tools that work for a single complex system fail in predictable ways when applied to an SoS.

System of Systems Engineering (SoSE) is the discipline concerned with designing, integrating, and evolving collections of independent systems that collectively deliver capabilities no constituent system provides alone. Understanding what separates SoSE from conventional systems engineering is prerequisite to understanding why it is so operationally difficult — and why requirements management at the SoS layer is a distinct problem class.

The Defining Characteristics of a System of Systems

The canonical definition comes from Mark Maier’s 1998 paper in Systems Engineering, later refined by INCOSE and adopted across defense and civil frameworks. An SoS is not simply a large system with many components. It has structural properties that distinguish it:

Operational independence. Each constituent system (CS) can perform a meaningful mission on its own, independent of the SoS. A commercial aircraft has a useful function before it is integrated into an air traffic management SoS. A connected vehicle navigates before it participates in a cooperative intelligent transportation system. This independence is not a design flaw — it is the defining condition.

Managerial independence. Constituent systems are acquired, operated, and evolved by different organizations under different authorities. The program office integrating the SoS does not own the constituent programs. This is not a coordination challenge to be managed away. It is a structural reality that shapes every decision about interface control, requirements authority, and change management.

Emergent behavior. The SoS produces capabilities and behaviors that do not reside in any single constituent system and cannot be fully predicted from the specifications of the parts. A smart city traffic management network produces optimized flow patterns that emerge from the interaction of sensors, signal controllers, navigation applications, and enforcement systems — none of which “owns” the emergent outcome. This is the property that makes SoS both powerful and difficult to verify.

Evolutionary development. SoS evolve continuously. Constituent systems are upgraded on independent timescales, new systems are added, and old ones are retired — without the SoS ever having a stable baseline in the traditional program sense. A fixed requirements document written at program start will be architecturally obsolete before the SoS reaches initial operating capability.

Geographic distribution. Not universally agreed as a defining characteristic, but common: constituent systems are typically distributed across physical locations and organizational boundaries, which amplifies interface complexity.

Maier also offered a taxonomy — directed, acknowledged, collaborative, and virtual SoS — that is worth knowing. A directed SoS has a central manager with authority over constituent systems (closest to a large system; rarest in practice). An acknowledged SoS has a recognized integrating manager with limited authority. A collaborative SoS depends on voluntary cooperation with no central authority. A virtual SoS has no central management and no explicit integration purpose. The taxonomy matters because your engineering approach — and your traceability strategy — must be calibrated to which type you are dealing with.

Major SoSE Frameworks

Several frameworks have developed independently for SoSE, each shaped by its institutional context.

DAF SoS Guidance

The Department of the Air Force (DAF) has invested heavily in SoSE methodology, driven by the Joint All-Domain Command and Control (JADC2) initiative and the recognition that next-generation warfare is inherently multi-domain and multi-system. The DAF SoS Systems Engineering Guide (updated through the mid-2020s) treats SoSE as an adaptation of traditional SE processes — but with explicit acknowledgment that requirements at the SoS layer express capability needs and interface obligations, not full system specifications. The DAF framework emphasizes the Systems Engineering Technical Review (SETR) process adapted for SoS gates, with particular attention to Interface Control Documents (ICDs) as the primary contractual artifact between the SoS integrator and constituent program offices.

The DAF approach is strongest in directed and acknowledged SoS contexts — where at least one organization has formal authority to impose interface requirements on constituent programs. It is less prescriptive about the collaborative SoS problem, which is where most civil and coalition applications live.

NATO Approaches

NATO’s SoSE work, developed through the NATO STO (Science and Technology Organization) and reflected in STANAG and Allied Engineering Publications, faces an additional layer of complexity: constituent systems are owned by member nations, each with sovereign acquisition authority. The NATO SoSE approach consequently emphasizes interoperability standards and federated architecture over top-down requirements decomposition. NATO’s Federated Mission Networking (FMN) framework is the operational instantiation — a set of binding standards and profiles that allow nationally-owned systems to interoperate in coalition operations without requiring a single integrating authority.

The practical lesson from NATO’s approach is that in truly collaborative and virtual SoS, the primary engineering lever is standardized interfaces, not hierarchical requirements decomposition. You cannot write a shall statement that binds a member nation’s system unless that nation has signed up to a standard. Architecture and standards are the requirements.

INCOSE and Commercial Applications

INCOSE’s Systems Engineering Handbook and the companion Guide to the Systems Engineering Body of Knowledge (SEBoK) treat SoSE as a distinct subdiscipline with its own process model. The SEBoK taxonomy largely aligns with Maier’s characteristics but adds process guidance for SoS Architecture (SoSA) development and SoS verification, recognizing that traditional verification methods (test against a specification) are insufficient for emergent behavior.

Commercial SoSE applications are growing faster than defense frameworks can track. Two domains illustrate the range:

Connected and automated vehicles (CAV). A cooperative intelligent transportation system integrating vehicle-to-vehicle (V2V) communications, roadside units (RSUs), traffic management centers, and navigation service providers is a collaborative SoS. No single entity integrates it. The engineering challenge is ensuring that safety-critical emergent behaviors — like coordinated intersection management — can be verified against system-level safety goals when no organization has authority over all constituent systems. The SAE J3216 standard on Taxonomy for Cooperative Driving Automation is an attempt to address this through standardized behavioral definitions.

Smart infrastructure. Building management systems, power grid control, emergency response networks, and environmental monitoring in a smart city or campus environment constitute a virtual-to-collaborative SoS. The constituent systems were often procured independently, by different agencies, under different contracts. The SoSE challenge is retroactive: how do you define and verify system-level performance when the “system” was never designed as one?

Why SoS Requirements Traceability Is a Different Problem

Single-system requirements traceability follows a well-understood path: stakeholder needs decompose to system requirements, which decompose to subsystem requirements, which allocate to components, which are verified by tests. The hierarchy is clear. Authority over all requirements levels sits within one program. A traditional Requirements Traceability Matrix (RTM), however clunky in practice, is at least the right conceptual tool.

At the SoS layer, this model breaks down in three specific ways.

Authority fragmentation. The SoS integrator may define a capability requirement — the SoS shall detect, identify, and engage a target within 30 seconds of first sensor contact — but cannot unilaterally decompose this into shall statements on constituent systems without the cooperation of their program offices. Traceability from SoS-level requirements to CS-level requirements must cross organizational boundaries. Those boundaries are political as much as technical. The RTM is not a technical artifact; it is a negotiated contract between programs.

Emergent behavior is not traceable in the traditional sense. An emergent capability — one that arises from the interaction of constituent systems — does not trace to any single CS requirement. You can trace it to interface requirements and to the assumptions baked into each CS about the behavior of its peers. But the emergence itself lives in the white space between systems. Capturing that white space requires a model of system interactions, not a list of shall statements.

Evolutionary instability. When a CS is upgraded on its own schedule — new sensor suite, updated software baseline, revised interface — the SoS-level requirements that depended on its previous behavior may be silently violated. Traditional document-based RTMs have no mechanism to propagate change impact across system boundaries. The SoS integrator may not even know that a CS has changed until integration testing reveals a gap.

These three problems — authority fragmentation, emergent behavior, and evolutionary instability — define the SoSE requirements challenge. Any tool or method that doesn’t address all three is a partial solution.

How Modern Platforms Support SoS-Layer Traceability

The response to these challenges in practice has been a gradual shift from document-based RTMs to graph-based requirements models — where requirements, interfaces, assumptions, and system boundaries are all first-class nodes in a connected data model, rather than rows in a spreadsheet or sections in a Word document.

Flow Engineering implements this approach in a way that is directly applicable to SoSE contexts. Its graph-based architecture allows requirements to be structured not just hierarchically (parent-to-child decomposition) but relationally — so an SoS-level capability requirement can be connected to interface obligations, CS-level requirements owned by different teams, and the assumptions each CS makes about system context. This structure makes the “white space” of emergent behavior partially explicit: the interfaces and assumptions that must hold for the emergent capability to be realized are visible in the model, not buried in narrative.

The cross-boundary decomposition problem — where SoS-level requirements must be traced through to CS requirements owned by organizations with different toolchains — is addressed by Flow Engineering’s model-centric data representation, which allows external requirements to be imported, referenced, and linked without requiring every stakeholder to work in the same document. This is not a complete solution to the authority fragmentation problem (no tool is), but it removes the toolchain mismatch as a barrier to traceability.

For evolutionary instability, the graph model provides change impact analysis that flat RTMs cannot: a change to a CS interface requirement propagates visually and structurally through the connected model, surfacing which SoS-level capabilities are potentially affected. This is the difference between discovering integration gaps during testing and discovering them when a CS requirement is updated.

Flow Engineering’s deliberate focus is on the requirements and traceability layer — it does not attempt to be a full lifecycle management platform or a model-based systems engineering (MBSE) authoring environment. For teams that need SysML-level behavioral modeling, a dedicated MBSE tool remains appropriate. But for SoS-layer requirements management and cross-boundary traceability, the graph-based approach addresses the structural problems that legacy document-based tools cannot.

Practical Starting Points

If you are approaching an SoSE problem for the first time, three actions have high return on investment regardless of domain:

Classify your SoS type first. Directed, acknowledged, collaborative, or virtual — the answer determines what engineering levers you have. If you are in a collaborative or virtual SoS, do not invest in building a top-down requirements decomposition hierarchy you have no authority to enforce. Invest in interface standards and assumption documentation instead.

Separate SoS-layer requirements from CS-level requirements explicitly. SoS-level requirements express capability needs, interface obligations, and assumptions. CS-level requirements are the concern of CS program offices. Conflating them creates governance confusion and produces RTMs that no one trusts.

Treat interfaces as first-class engineering artifacts. In a single system, interfaces are implementation details. In an SoS, they are the primary technical contract between constituent systems and the primary location where emergent behavior is either enabled or broken. Interface Control Documents, or their model equivalents, deserve the same rigor as requirements documents.

SoSE is not systems engineering at larger scale. It is systems engineering under conditions of distributed authority, emergent behavior, and continuous evolution — conditions that require adapted methods, appropriate governance structures, and toolchains capable of representing cross-boundary relationships that a flat document cannot.