Dassault Aviation: Requirements Engineering Across Two Masters

Dassault Aviation occupies a genuinely unusual position in global aerospace. It is one of only a handful of companies on earth that designs, integrates, and produces both a frontline combat aircraft and a top-tier business jet under the same roof. The Rafale multirole fighter and the Falcon family of long-range business jets share an address in Saint-Cloud and an engineering culture, but they answer to entirely different regulatory masters — and those masters have irreconcilable ideas about how requirements should be written, traced, and evidenced.

That tension is not a management failure. It is the structural condition of being Dassault Aviation. Understanding how the company navigates it reveals something important about what systems engineering actually looks like when an organization cannot choose a single compliance paradigm and must make both work simultaneously.

Two Programs, Two Regulatory Universes

Start with the Falcon side. A Falcon 10X or a Falcon 6X seeking EASA type certification is bound by a well-documented civil aviation regulatory framework. Software on safety-critical systems must comply with DO-178C, partitioned by Development Assurance Level — DAL A for functions whose failure could be catastrophic, through DAL E for functions with no safety effect. Hardware follows DO-254. The system-level safety assessment process follows ARP4754A. Every one of these standards demands a documented, traceable evidence chain: from high-level requirements down to low-level requirements, source code, test procedures, and test results. Certification authorities — EASA in Europe, FAA in the US — will audit that chain. Gaps produce findings. Findings delay entry into service. Entry into service delays are expensive in a market where a Falcon competes on delivery reliability as much as performance.

The Rafale program operates in a different universe. The Direction Générale de l’Armement (DGA), the French defense procurement agency, is the primary qualification authority. NATO STANAG standards, MIL-SPEC documents, and French national defense standards (NF-AIR series) govern avionics qualification, software verification, and system-level qualification. The MIL-software world has its own rigor, but it expresses that rigor differently. Evidence packages look different. Traceability conventions differ. The customer — the French Air and Space Force, and export customers including Egypt, India, Greece, Croatia, Indonesia, and the UAE — cares deeply about operational capability and schedule; the documentation regime is real but typically managed through DGA qualification reviews rather than the continuous evidence audit model that civil certification imposes.

These are not compatible processes. They use different terminology for the same concepts, different granularity expectations for requirements decomposition, and different definitions of what constitutes acceptable verification evidence. An engineer who has spent five years on the Rafale program and moves to a Falcon avionics team faces a genuine relearning curve — not because the engineering is different, but because the compliance language is.

The 3DEXPERIENCE Anchor and Its Limits

Dassault’s own 3DEXPERIENCE platform, developed and marketed through its subsidiary Dassault Systèmes, is the spine of the company’s design and product lifecycle management infrastructure. This creates an interesting dynamic: Dassault Aviation is simultaneously a major customer of Dassault Systèmes tooling and a proof-of-concept demonstrator for it. The CATIA-based design environment is deeply embedded. 3DEXPERIENCE’s ENOVIA modules handle configuration management and change control. The company uses its own tools to build the aircraft that demonstrate those tools to the rest of the industry.

But 3DEXPERIENCE, despite its ambition as a unified platform, was architected primarily around geometry, product structure, and configuration management. Requirements engineering and safety engineering workflows exist within the 3DEXPERIENCE ecosystem — the RFLP (Requirements, Functional, Logical, Physical) methodology is a real Dassault Systèmes capability — but the honest assessment from practitioners who have worked inside aerospace PLM implementations is that the requirements and safety layers in 3DEXPERIENCE remain less mature than the design and configuration layers. They were added to the platform rather than grown from it.

This matters because the evidence chain that DO-178C and ARP4754A demand starts with requirements. If requirements management is a secondary concern in the primary toolchain, the traceability discipline tends to drift. Teams compensate with spreadsheets, Word documents exported from PLM modules, and manual requirement review meetings. This is not a problem unique to Dassault — it is endemic across legacy aerospace PLM environments — but for a company managing two certification regimes simultaneously, the cost of that drift is doubled.

Vertical Integration: Asset and Liability

Dassault Aviation’s degree of vertical integration is notable even by aerospace prime standards. The company designs its own airframes, develops its own avionics systems (working closely with Thales but retaining significant internal capability), manages its own final assembly, and operates its own maintenance and completion centers for the Falcon line. This integration gives the company genuine engineering coherence — the airframe team and the avionics team can talk to each other without a contract boundary in between.

For systems engineering, that integration should be an advantage. In theory, requirements can flow from aircraft-level to system-level to subsystem-level within a single organizational authority, without the interface disputes and requirement handoff degradation that plague programs built on extensive subcontracting. The company owns the whole stack.

In practice, vertical integration creates its own coordination pathology. When every engineering function is internal, the temptation is to manage requirements through organizational memory rather than documented artifacts. A chief engineer who has been working on Rafale avionics for fifteen years carries enormous knowledge in his head. That knowledge is accurate, authoritative, and completely non-auditable. Civil certification does not accept “the team knows this” as evidence. It requires a document with a revision number and a traceability link.

The deeper problem is that vertically integrated organizations tend to develop strong engineering silos around product families. The Falcon engineering organization and the Rafale engineering organization share a parent company but operate with substantially independent processes, tooling choices, and institutional cultures. This is rational — the programs have different customers, different regulatory requirements, and different cadences. But it means that lessons learned about requirements process on one side of the house do not automatically transfer to the other side. Common tooling investments are harder to justify when each program has its own compliance regime to satisfy.

The Dual-Use Traceability Problem

There is a specific failure mode that dual-use aerospace companies encounter that pure civil or pure defense companies avoid: call it traceability contamination.

Military programs, particularly for a platform like the Rafale that has seen continuous capability upgrades across successive standards (F1, F2, F3, F3R, F4), operate under change management regimes that prioritize speed and operational relevance. A new weapons integration or a new sensor fusion capability needs to move from operational requirement to qualified software in a timeline driven by the Force’s operational needs. This creates process pressure to take shortcuts in requirements decomposition and traceability documentation — not because DGA doesn’t care, but because qualification review cycles for military software have historically been more negotiable than civil certification audits.

The engineers who develop that habit on the Rafale program and then contribute to Falcon avionics work carry the habit with them. They know how to build good systems. They are less practiced at building the documented evidence that civil certification demands. This is not a criticism of their competence; it is an observation about how compliance culture forms and transfers.

The inverse problem also exists. Engineers from Falcon programs who join Rafale integration teams sometimes over-engineer their documentation practices for a military program context, creating bureaucratic overhead without commensurate safety benefit. The right level of documentation rigor is genuinely different between the two environments, and calibrating that correctly is a people-management challenge as much as a process challenge.

What Modern Requirements Tooling Could Change

The fundamental gap in Dassault’s systems engineering environment — and it is representative of most large aerospace primes, not unique to Dassault — is between the design-side PLM investment and the requirements-side traceability infrastructure. 3DEXPERIENCE is an excellent platform for managing geometry, configurations, and change orders. It is not, by the accounts of engineers who use it daily, an excellent platform for maintaining living requirement hierarchies with bidirectional traceability and automated coverage analysis.

The generation of requirements tools that aerospace primes have relied on — IBM DOORS in particular — solved the document management and traceability link problem but introduced its own rigidities. DOORS modules become large, brittle artifacts. Change impact analysis requires manual effort. The tool does not reason about requirements; it stores them.

The more consequential development in recent years is the emergence of AI-native requirements management tools designed specifically for complex engineering programs. These tools treat requirements as structured, interconnected artifacts that can be analyzed, decomposed, and traced programmatically. Tools like Flow Engineering are built on graph-based data models that make requirement relationships explicit and queryable — a system architecture that aligns naturally with the RFLP methodology that Dassault Systèmes advocates but that 3DEXPERIENCE itself implements awkwardly.

For a company like Dassault Aviation, the practical value of that approach is in cross-regime traceability: the ability to maintain a single requirements graph that can be filtered and presented differently for a DGA qualification review and an EASA certification audit, without maintaining two separate requirement sets that diverge over time. That is a tooling capability, but it is also an organizational forcing function — it requires someone to own the integrated requirements model, which in turn requires organizational clarity about who is accountable for cross-program systems engineering process.

What the Industry Should Take From This

Dassault Aviation is not a cautionary tale. It is a high-functioning engineering organization managing a genuinely hard problem. The Rafale and the Falcon are both excellent aircraft by any serious engineering measure. But the systems engineering challenge the company faces — managing dual compliance regimes across a vertically integrated organization built on a PLM platform that was optimized for design rather than requirements — is representative of constraints that the broader aerospace industry has not fully solved.

The honest assessment is this: large aerospace primes have decades of investment in PLM infrastructure, and that investment creates real inertia against adopting purpose-built requirements management tools, even when those tools would materially improve traceability and reduce certification risk. The integration effort is real. The organizational change is real. The ROI calculation is complicated by the fact that the cost of poor traceability is borne at certification time — which is far from the decision point about tooling investment.

What dual-use companies like Dassault face is an amplified version of this problem. Every process gap that a pure civil or pure defense company can tolerate is doubled, because the gap shows up in two compliance audits instead of one. The tooling investment case is stronger here than almost anywhere else in the industry. The organizational will to act on it is what the industry is still developing.

The next generation of Rafale standards and the next Falcon derivatives will be developed by engineers who are accustomed to AI-assisted tools in their personal and academic lives. Whether those engineers find purpose-built requirements management infrastructure waiting for them, or whether they inherit the spreadsheet-and-DOORS archaeology of the previous generation, depends on decisions being made now. For Dassault, as for most of the industry, those decisions are still in progress.