The Defense Electronics Modernization Push: How Programs Are Evolving Systems Engineering for Software-Defined Hardware

The F-35’s software sustainment costs now exceed its hardware sustainment costs. The Navy’s next-generation surface combatant is designed around the assumption that its combat system will receive major capability upgrades while the ship is still commissioned. And the Army’s IVAS program has delivered multiple hardware revisions built around a software architecture that must remain backward-compatible across fielded units.

This is not the defense acquisition model that produced the requirements management practices most programs still use.

For decades, defense systems engineering treated hardware and software as parallel tracks that converged at integration. Requirements decomposed downward through a system hierarchy into hardware specifications and software requirements specifications, which were then managed largely independently until the verification phase forced them back together. This worked tolerably well when the hardware-software boundary was stable, the system was delivered once, and post-fielding changes were exceptional events requiring formal modifications.

None of those conditions hold for modern defense electronics programs.

What MOSA Is Actually Demanding

The Modular Open Systems Approach is not simply a preference for open standards. The FY2017 NDAA and subsequent DoD policy made MOSA a statutory requirement for major defense acquisition programs, and the specifics matter for systems engineers.

MOSA requires that critical technology elements be isolated in modules with well-defined interfaces. It requires that those interfaces be based on widely supported, non-proprietary standards. And it requires that the government retain sufficient technical data rights to compete sustainment and modification work. Each of these requirements has direct implications for how programs must structure their requirements.

The isolation requirement means that functional requirements can no longer flow arbitrarily across the hardware-software boundary. If a capability is allocated to a software module, the interface between that module and the hardware it runs on must be explicit, documented, and conformant to a standard. The word “explicit” is doing heavy lifting there. In traditional defense systems engineering, many interface requirements lived in informal agreements between subsystem engineers or in the margins of interface control documents. MOSA eliminates that option for anything touching a critical technology element boundary.

The technical data rights requirement is particularly consequential for how programs structure their requirements hierarchy. If the government cannot access the internal architecture of a supplier’s module — because they haven’t acquired the rights — then the government-side requirements must be specified entirely in terms of interface behavior, not internal implementation. This is formally correct systems engineering practice that most programs have historically honored more in theory than in practice. MOSA enforces it.

FACE and SOSA: Interface Standards as Requirements Inputs

The Future Airborne Capability Environment (FACE) standard and the Sensor Open Systems Architecture (SOSA) technical standard are frequently described as interoperability frameworks. That’s accurate but incomplete from a systems engineering perspective. They are also structured requirements inputs that programs must decompose and allocate.

FACE defines a software reference architecture with specific conformance requirements at each segment boundary. A FACE-conformant avionics system must provide defined interfaces between the Operating System Segment, the I/O Services Segment, the Platform-Specific Services Segment, and the Portable Components Segment. These aren’t guidelines. A program claiming FACE conformance has specific verifiable interface requirements that must trace through the system hierarchy.

SOSA defines hardware and software interface standards for sensor systems, including specific requirements for hardware form factors, signal interfaces, and software abstraction layers. The SOSA Technical Standard references hundreds of individual standards, and programs must determine which apply to their architecture, how they flow down to subsystems, and how conformance gets verified.

The requirements management challenge this creates is significant. FACE and SOSA requirements don’t originate in the traditional customer requirements document — they originate in external standards maintained by the Open Group. They must be imported into the program’s requirements hierarchy, allocated to specific components and interfaces, and traced to verification events. When the standard revises, the impact on program requirements must be analyzable.

Document-based requirements tools handle this poorly. Linking a paragraph in a system requirements document to a specific clause in FACE Technical Standard 3.1 and then tracing both to an interface control document and then to a test procedure is the kind of multi-hop relationship that spreadsheets and word processors cannot maintain reliably. It’s also exactly what program offices and auditors will ask for during technical reviews.

The Post-Fielding Update Problem

Traditional defense acquisition assumed that requirements were substantially stable after Preliminary Design Review. Changes happened — sometimes dramatically — but they were exceptions requiring formal change proposals, configuration control board review, and updated contractual documentation. The system you delivered was the system, until someone decided otherwise through a deliberate process.

Software-defined systems break this model in two related ways.

First, the fielded hardware must now accommodate future software capabilities that haven’t been fully defined at program inception. This means hardware requirements must explicitly include headroom — processing margin, memory headroom, interface bandwidth that’s not fully utilized at initial fielding. These aren’t performance requirements in the traditional sense. They’re architectural requirements that can only be written if you have a clear model of which hardware functions might be replaced or augmented by software in the future.

Second, software updates don’t go through the same change process as hardware modifications, but they can change system-level behavior in ways that affect system-level requirements. An algorithm update to a software-defined radio’s waveform library can change the system’s electromagnetic compatibility profile. A new capability in a software-defined sensor can create new electromagnetic interference sources. Requirements that were verified during initial testing may not remain valid after a software update.

Programs managing this well are developing what some program managers call “living requirements architectures.” Rather than a static requirements baseline that’s updated through formal changes, they’re maintaining a versioned requirements model where the relationship between hardware interfaces, software behaviors, and system-level properties can be queried at any configuration state. When a software update is proposed, impact analysis starts with the requirements model — which requirements does this change potentially affect, and which verification events need to be revisited?

This approach requires requirements tooling capable of maintaining that kind of versioned, queryable model. It also requires that the requirements model reflect the actual architecture — hardware modules, software modules, and the interfaces between them — rather than a document hierarchy that mirrors the contractor’s organizational structure.

How Prime Contractors Are Responding

The prime contractors who are ahead of this curve share a few practices worth examining.

Interface-centric decomposition. The traditional systems engineering decomposition pattern moves from system requirements down to subsystem requirements down to component requirements. The new pattern treats interface conformance requirements as a parallel decomposition stream. FACE segment boundaries, SOSA interface requirements, and program-specific ICDs each generate their own requirements that then cross-link to functional and performance requirements. This produces a richer requirements model but requires tooling that can manage the cross-linking without losing human readability.

Supplier conformance as a system requirement. Rather than treating FACE and SOSA conformance as a supplier-side quality matter, leading programs are placing conformance requirements at the system level and tracing them explicitly to supplier specifications and contract data requirements lists. This ensures that conformance isn’t assumed — it’s specified, allocated, and verified.

Configuration-aware traceability. For systems that will receive post-fielding updates, programs are structuring their requirements so that each requirement is explicitly associated with the hardware configuration, software configuration, or both. A requirement that’s satisfied by the initial software load but must be re-verified after any waveform library update is marked as such. This allows configuration management and systems engineering to stay aligned rather than diverging after fielding.

Early hardware-software boundary definition. The programs that struggle most with MOSA implementation are those that defer the hardware-software boundary definition to the subsystem contractors. By the time the boundary is clearly understood, the system architecture is locked and the interface requirements are being written against existing designs rather than shaping them. Programs that define the boundary early — as a system-level architectural decision with explicit interface requirements — give themselves more freedom in supplier selection and more flexibility for future modifications.

The Toolchain Gap

The requirements management tools most defense programs still use were designed for a model of systems engineering that’s becoming obsolete for software-defined systems. IBM DOORS, even in its Next generation, is fundamentally a document-management system with traceability links added on top. It handles linear requirement hierarchies well. It handles the multi-dimensional relationship models that MOSA-compliant architectures demand with considerably more effort, typically requiring significant database customization or parallel spreadsheet-based processes to compensate.

Jama Connect and Polarion offer more modern interfaces and better collaboration support, and Polarion’s built-in SysML modeling capabilities are genuinely useful for interface-heavy architectures. But the underlying model in most of these tools still reflects a document-centric view where requirements live in specifications and links connect document items.

Tools built around graph-based models — where requirements, interfaces, components, standards clauses, and verification events are all nodes with explicit typed relationships — handle MOSA-style architectures more naturally. Flow Engineering takes this approach explicitly for hardware and systems programs: requirements, test events, design elements, and interface definitions all exist as graph nodes, and the architecture can be queried across relationship types. For a program tracking how a SOSA interface requirement flows through a hardware specification, a supplier ICD, and a test procedure — and needs to identify everything affected when the SOSA standard revises — that graph structure is a functional advantage, not a cosmetic one.

Flow Engineering’s current focus is on upstream systems engineering rather than the full DOORS-replacement workflow some large programs need, which is a genuine scope limitation for primes running large multi-contractor programs. But for the specific problem of managing requirements across hardware-software boundaries in modular architectures, the model-first approach is better suited to what MOSA programs actually need than document-first tools with traceability links added afterward.

Honest Assessment

The defense electronics industry is in a period where the engineering requirements are evolving faster than the standard processes and tooling. MOSA, FACE, and SOSA are creating genuine new demands on how requirements are structured, traced, and maintained across post-fielding updates — demands that the practices developed for single-configuration hardware-centric programs don’t fully address.

The programs that are navigating this well share a willingness to treat the requirements architecture as a first-class engineering artifact, not administrative documentation that follows the real engineering decisions. They’re defining hardware-software boundaries as system-level design decisions with explicit interface requirements. They’re importing external standard requirements into their traceability models rather than referencing them by pointer. And they’re building configuration-awareness into their requirements structure from the start rather than trying to retrofit it when the first software update creates a verification question.

The programs that are struggling are largely doing so because their requirements processes are organized around their contractors’ organizational charts rather than their systems’ architectures. MOSA won’t change that by itself. The pressure to actually restructure around interfaces rather than organizations has to come from within the program’s systems engineering leadership, supported by tooling that makes interface-centric requirements modeling practical to maintain.

The DoD’s modernization push is real, the standards are serious, and the programs that treat requirements modernization as a parallel investment to hardware modernization are going to have a significant advantage as these systems evolve after fielding. Those that don’t will find that their requirements baselines become progressively less useful as the systems they describe diverge from the documents that supposedly specify them.