Saab: Systems Engineering at a Full-Spectrum Defense Integrator

Saab AB is not a household name outside defense and aerospace circles, but within them it occupies a position that larger primes might envy: it is the sole developer and integrator of a frontline fighter aircraft, an advanced submarine, an airborne early warning platform, and a portfolio of ground-based radar and surveillance systems—all from a country of ten million people. That breadth, achieved without the headcount of Lockheed Martin or BAE Systems, makes Saab one of the more instructive case studies in systems engineering under resource constraint.

The challenge is not that any single Saab program is uniquely complex. It is that running all of them simultaneously, with shared engineering talent, shared supply chains, and shared tooling investment, forces the kind of cross-domain systems engineering discipline that many larger organizations talk about but do not practice.

The Portfolio and What It Demands

Saab’s major product lines span four distinct physical domains, and the engineering demands of each are not simply additive—they are structurally different.

Gripen is the flagship. The JAS 39 Gripen is a lightweight multirole fighter currently in its E/F variant, with active operators including Sweden, Brazil, South Africa, Czech Republic, and Hungary, and ongoing negotiations with several others. The aircraft is purpose-designed for export: its relatively modest unit cost, low operating burden, and the offset-and-technology-transfer packages Saab offers have made it competitive against aircraft with larger development budgets. But that export orientation creates a specific systems engineering problem. Each customer nation arrives with its own operational requirements, its own regulatory environment, its own weapons integration priorities, and—critically—its own political expectations about what “their” variant will include. Managing the requirements delta between a Swedish Air Force baseline and a Brazilian or South African variant requires a traceability architecture that can distinguish clearly between core platform requirements, variant-specific requirements, and customer-specific interface requirements. Doing that badly produces integration failures and cost overruns. Doing it well requires tooling and process discipline that goes beyond a shared document library.

The A26 submarine represents the opposite end of the program lifecycle. While Gripen variants are in active production and continuous upgrade, the A26 is a new-build program for the Swedish Navy designed to replace the aging Gotland class. Submarines have operational service lives measured in decades—thirty to forty years is typical—which means requirements established today will constrain maintenance, upgrade, and combat system decisions well into the 2060s. The traceability problem here is temporal: how do you ensure that a requirement written in 2018 for a system that enters service in 2027 can still be traced, interpreted, and changed-managed in 2045 when the engineering team that wrote it is retired? Document-based approaches to that problem have a poor track record. The submarine domain also involves deep integration with suppliers who themselves operate at high classification levels, which complicates any cloud-based tooling strategy.

GlobalEye and the ERIEYE radar family sit in a different competitive space. Saab’s airborne early warning and control system, GlobalEye, integrates multiple sensor systems—radar, maritime surveillance, ground surveillance—into a single airframe. The radar technology itself, the ERIEYE AESA, is a core Saab competency. These programs require managing requirements across the interface boundary between Saab-developed sensors and third-party airframes (the GlobalEye uses a Bombardier Global 6000 business jet as its platform), which means Saab must maintain rigorous interface control documents and trace requirements to both sides of a boundary they only partially control.

Ground-based surveillance and command systems—including the Giraffe radar family and the integrated air defense and command solutions Saab provides to multiple nations—represent a portfolio where software-intensive systems engineering is increasingly central. The shift from hardware-dominant to software-dominant systems in this segment is ongoing, and it accelerates the requirements volatility that engineering teams must manage.

Requirements Management Across Export Variants

The Gripen’s export model is worth examining in more detail because it illustrates a structural requirements management challenge that is common in defense but rarely addressed honestly.

When Brazil committed to the Gripen NG under the F-X2 program, the agreement included significant technology transfer to Embraer and the establishment of Brazilian industrial capability. This is standard for high-value defense exports. But from a systems engineering standpoint, it means that the Brazilian variant—eventually designated F-39—required a parallel requirements baseline that could diverge from the Swedish baseline on specific subsystems while remaining synchronized on core avionics and flight control architecture. Maintaining that synchronization without a structured approach to variant management is effectively impossible above a certain scale of divergence.

The Gripen E program itself introduced a new avionics architecture, a new electronic warfare suite, and a new active electronically scanned array radar (the Leonardo ES-05 Raven). Each of these brought new suppliers, new interface specifications, and new verification requirements. For a program that simultaneously supports multiple national operators at different upgrade levels, the requirements database is not a static artifact—it is a living graph of interdependencies that changes with every software release, every national variant decision, and every supplier component update.

Saab has historically used a combination of IBM DOORS and internal documentation systems for requirements management. DOORS, particularly DOORS Classic, has deep penetration in established defense programs because it was the standard for NATO-adjacent contractors for two decades. It handles large requirement sets and supports module-based organization, which maps reasonably well to a variant architecture if the module hierarchy is designed carefully. The limitation is that DOORS Classic’s link management is linear and difficult to query across a complex variant tree. Teams that need to ask “which Gripen E Brazilian requirements are affected if we change the EW suite interface specification” are often doing that analysis manually or through custom scripts rather than through native tool capability.

DOORS Next Generation (now IBM Engineering Requirements Management DOORS Next) improves on this with better web-based access and richer linking, but the migration path from DOORS Classic is notoriously difficult, and many programs that nominally run DOORS Next are still maintaining Classic modules in parallel during transition.

Digital Engineering: Uneven but Real Progress

Saab has publicly committed to model-based systems engineering as a strategic direction, and that commitment is visible in the Gripen E program’s later development phases and in the A26 program’s design infrastructure. But “committed to MBSE” covers a wide range of actual practice.

The mature interpretation of MBSE—where system models are the authoritative source of system architecture, interface specifications flow from the model, and requirements trace to model elements rather than to document paragraphs—requires significant investment in tooling, training, and process change. It also requires that suppliers operate at compatible modeling maturity levels, which is rarely the case for all suppliers simultaneously.

In practice, Saab’s MBSE implementation is likely strongest in the subsystems where Saab has direct engineering control and newest in the programs where greenfield design choices were available. The A26, as a clean-sheet program, offered more opportunity to implement model-based workflows from the start than legacy Gripen variants, which carry forward requirements and interface documentation conventions established in the 1980s and 1990s.

The radar and surveillance divisions, where product refresh cycles are shorter and software content is higher, may have more agile tooling practices than the aircraft programs, simply because shorter cycles demand faster requirements iteration. A ground-based radar system with a three-year development cycle tolerates requirements management inefficiency less than a fighter program where requirements volatility is absorbed over a decade.

The Legacy Integration Problem

Saab’s engineering organization must bridge two worlds that are genuinely difficult to connect: the legacy documentation and requirements baselines of programs that started before digital engineering existed as a concept, and the modern tooling and process expectations of new programs and new hires.

This is not unique to Saab—it is the defining tension in mature defense engineering organizations globally—but Saab’s relatively compact size makes it more acute. A large prime can, in principle, maintain separate engineering cultures for legacy and new programs and staff them differently. Saab’s engineering talent pool is smaller, which means the same engineers often work across both. An engineer who spends part of the week on A26’s model-based design workflow and part of the week maintaining DOORS modules for a Gripen variant upgrade is absorbing context-switching costs that reduce productivity in both domains.

The tooling investment question is also sharper. When IBM DOORS licensing costs and MBSE tooling costs compete for the same digital engineering budget, program priorities and customer contractual requirements often determine which wins—not which approach is technically superior.

What Coherence Looks Like in Practice

The organizations that handle this kind of portfolio complexity well tend to share a few characteristics. They treat requirements management as an engineering discipline, not an administrative function—meaning requirements engineers have domain knowledge, not just tool proficiency. They invest in traceability infrastructure early in programs rather than retrofitting it when audits or failures make it urgent. And they maintain a consistent logical model of what a “requirement” is, what distinguishes it from a design decision, and how change propagates through the system model.

For Saab, the practical starting point for improving coherence across the portfolio is probably not tool standardization across all divisions—the programs are too different, and contractual constraints on tooling are real. A more achievable target is consistent traceability practice: ensuring that regardless of which tool a program uses, the logical connections between stakeholder needs, system requirements, subsystem requirements, and verification evidence are maintained in a queryable, auditable form.

Modern requirements management platforms that use graph-based data models rather than document-hierarchies handle this kind of cross-program, multi-variant traceability more naturally than document-centric tools. The ability to query impact of a change across a requirement graph—rather than navigating a module tree manually—is the capability gap that causes the most real engineering pain in complex variant programs like Gripen.

Honest Assessment

Saab is doing serious systems engineering on serious programs. The Gripen E is a competitive frontline aircraft. The A26 is, by available technical indicators, a capable submarine design. GlobalEye has won export customers against strong competition. These outcomes do not happen with negligent engineering practice.

The honest critique is that Saab’s digital engineering transformation, like that of most established defense primes, is running behind its ambition. The investment is real, the direction is correct, and specific programs show genuine MBSE maturity. But the portfolio-wide coherence that would let Saab exploit its cross-domain engineering depth—reusing architectural patterns, sharing requirement models across programs, systematically capturing institutional knowledge—is not yet fully realized.

The competitive pressure to achieve that coherence is increasing. Export customers are becoming more sophisticated about systems engineering artifacts as deliverables, not just hardware. Sweden’s domestic defense expansion following NATO accession will stress engineering capacity. And the software content of every product line is growing faster than headcount can grow to manage it manually.

The organizations that solve this problem first will have a durable engineering advantage over those that manage it through heroic individual effort. Saab has the technical foundation to be among the first. Whether the tooling and process investment keeps pace with the ambition is the open question.