How Do Defense Contractors Manage Requirements Across a 20-Year Program?

The F-35 program began its System Development and Demonstration phase in 2001. Engineers working on that contract today are, in many cases, not the engineers who wrote the original system requirements. Some of the tools those original engineers used have been deprecated. Some of the contracting vehicles have expired and been replaced. Some of the threat environments those requirements were written against no longer exist — and new ones do.

This is the baseline condition of large defense programs. Requirements management in this context is not a document control problem. It is a longitudinal systems engineering problem that spans careers, tool generations, and geopolitical shifts. The organizations that handle it well have something in common: they treat the requirements baseline as a first-class engineering artifact, maintained with the same rigor as the hardware it describes.

What a Requirements Baseline Actually Is

A requirements baseline is a formally agreed-upon, configuration-controlled set of requirements at a defined point in time. It is not the latest version of a spreadsheet. It is not the most recent export from a requirements tool. It is a contractually anchored artifact that represents what the customer and the contractor agreed the system would do — at the moment they agreed.

In defense programs, three baselines typically matter:

Functional Baseline (FBL): Established at System Requirements Review (SRR) or equivalent. Captures what the system must do at the mission and system level. This is the baseline the customer owns, usually the program office.

Allocated Baseline (ABL): Established after Preliminary Design Review (PDR). Requirements have been decomposed and allocated to subsystems. Engineering owns this. Every requirement has a home.

Product Baseline (PBL): Established at Critical Design Review (CDR) or First Article Testing. Requirements are fully traced to design solutions. This is the basis for production and sustainment.

On a 20-year program, all three baselines get touched repeatedly. A new threat capability emerges. An obsolete component is redesigned. A customer requirement changes because doctrine changed. Each of those events, if handled correctly, flows through a formal change process. If handled incorrectly — or informally — the baseline drifts from the as-built system, and no one knows what the requirements actually say anymore.

Baseline Evolution and the Engineering Change Proposal

The mechanism that keeps baselines from silently drifting is the Engineering Change Proposal, or ECP. An ECP is a formal request to alter an established baseline. It captures what is changing, why it is changing, what the technical and cost impacts are, and what downstream requirements or design elements will be affected.

On a major defense program, ECPs are not rare events. The F-35 program has processed thousands of them across its development and early production lots. The Virginia-class submarine has seen multiple block upgrades — each one requiring a structured change process that flows from the product baseline through design, production, and test.

The value of an ECP process is not bureaucracy for its own sake. The value is that every change to a baseline leaves a documented trail: who requested it, who approved it, what analysis was done, and what was verified afterward. Twenty years later, when an engineer asks “why does this requirement have this particular threshold value?”, the answer should be traceable through a chain of ECPs back to original intent — or to the specific program event that changed it.

What breaks this chain is informal change. An engineer modifies a requirement in the tool to reflect what was actually built, without raising an ECP. A design solution drifts from what the requirement specifies, and the discrepancy is never formally closed. The baseline says one thing; the system does another. In sustainment, that gap becomes a safety or certification liability.

Configuration Management: The Discipline That Makes It Work

Requirements management over decades is inseparable from configuration management (CM). CM is not just about controlling hardware part numbers. On modern defense programs, CM applies explicitly to requirements documentation, interface control documents, and the databases that store them.

The MIL-HDBK-61B standard defines the framework most prime contractors and their government customers operate under. It establishes four CM functions: planning, identification, change control, and status accounting. Applied to requirements, this means:

  • Every requirement has a unique identifier that does not change across the program’s life.
  • Every change to a requirement is tracked, versioned, and authorized.
  • The current approved baseline is always distinguishable from working drafts or proposed changes.
  • The history of every requirement — created when, changed when, by whom, for what reason — is preserved and auditable.

This sounds straightforward. The execution is not. Requirements databases on long programs grow to hundreds of thousands of items. They are maintained by rotating teams across multiple contractors and subcontractors. They span multiple tool instances, sometimes multiple tool generations. The discipline required to keep a 20-year database clean is substantial, and it rarely receives the organizational attention it deserves until something goes wrong.

The programs that do it well typically have a dedicated Chief Engineer for Systems Engineering and a standing Configuration Control Board (CCB) with real authority. The CCB reviews and approves changes to the allocated and product baselines. It includes representation from engineering, program management, the customer, and — on hardware-heavy programs — manufacturing and logistics. When the CCB is functioning, the baseline is defensible. When it has atrophied, the baseline is fiction.

Institutional Knowledge Loss: The Slow-Motion Risk

The most underestimated risk on a 20-year program is not technical. It is cognitive. It is the knowledge that exists in the heads of engineers who were there when the decisions were made — and who have since retired, changed jobs, or passed away.

Why does this requirement exist at this threshold? Why was this interface defined this way instead of the alternative? Why was this subsystem requirement allocated here instead of there? The answers to those questions are not always in the requirements database. Sometimes they are in meeting minutes from 2007. Sometimes they are in emails on a server that was decommissioned. Sometimes they are nowhere except the memory of someone who is no longer at the company.

This is not a failure of process. It is the natural consequence of long programs and human careers. The mitigation is architectural: build the rationale into the baseline.

Every requirement should carry not just a text statement and a verification method, but a rationale field that explains why this requirement exists and what analysis or constraint drove it. On well-run programs, this field is maintained with the same rigor as the requirement text. On most programs, it is filled in once, if at all, and never updated when the requirement changes.

Modern graph-based requirements tools make it easier to capture and preserve this context. Instead of a flat database row, each requirement node can carry relationships to the documents, analyses, and decisions that generated it. That network of connections is institutional knowledge made explicit — knowledge that survives personnel turnover because it is embedded in the system, not in someone’s memory.

The Tool Generation Problem

A 20-year program will, with near certainty, outlive at least one requirements tool. IBM DOORS Classic has been the dominant requirements management tool in defense contracting for over two decades. It is deeply embedded in legacy program baselines, government-furnished data deliverables, and contractual data requirements lists. It is also a product that has reached end-of-active-development, with IBM pushing customers toward DOORS Next Generation (DNG).

The migration from DOORS Classic to DOORS Next is not an upgrade in the software sense. It is a data migration between architecturally different systems — from a module-based, document-centric data model to an artifact-based, linked model. For a program with 200,000 requirements and 15 years of change history, that migration is a significant engineering effort in its own right. Programs that have attempted it without treating it as a formal project have lost data, broken traceability chains, and introduced baseline discrepancies they are still working to close.

The same is true for migrations to any modern platform. The legacy data has to be mapped, validated, and reconciled. Unique identifiers have to be preserved. Change history has to be carried forward or formally archived. Traceability links have to be re-established and verified. None of this is automatic.

Tools like Flow Engineering represent a different architectural starting point — graph-native data models, AI-assisted traceability analysis, and modern SaaS infrastructure — but they do not eliminate the migration challenge. They change its character. Migrating from DOORS Classic to a graph-based platform like Flow Engineering requires deliberate mapping of the DOORS module hierarchy to a node-and-edge model. Requirements that were connected implicitly through document structure now need explicit relationship types. That translation requires engineering judgment, not just a data import script.

What Flow Engineering offers that legacy tools do not is the ability to ask structural questions of a requirements baseline at scale. Which requirements lack verification methods? Which allocated requirements have no downstream design closure? Where are the orphaned requirements that have no traceability to a higher-level need? On a legacy DOORS database, answering those questions requires custom scripts or manual audits. On a graph-native platform, they are queries. That capability matters on a long program, where baseline entropy is a real and accumulating risk.

Treating Modernization as a Program, Not a Project

The central mistake organizations make when upgrading their requirements tooling mid-program is treating it as an IT project. It is not. It is a systems engineering program with its own requirements, risks, verification activities, and schedule dependencies.

A tool modernization on a major defense program needs:

A migration requirements baseline. What must be preserved from the legacy system? What traceability links are contractually required? What data can be archived versus what must be live in the new tool?

A formal verification plan. How will you confirm that every requirement migrated correctly? How will you detect link breaks or data corruption? Who is responsible for sign-off?

A configuration management transition plan. At what moment does the new system become the system of record? How is the old system kept read-only but accessible during the transition period?

Stakeholder and customer alignment. If the customer has data deliverable requirements tied to DOORS format, that has to be addressed contractually before the migration happens.

Programs that treat modernization this way complete it. Programs that treat it as a background IT task discover two years later that the new tool has half the requirements, the traceability links are wrong, and no one is sure which baseline is authoritative.

The Honest Summary

Managing requirements across a 20-year defense program is a continuous act of engineering discipline, not a one-time documentation effort. The baseline has to be treated as a living control artifact. Every change has to flow through a formal process. The rationale behind decisions has to be captured, not assumed. And when the tools change — which they will — the migration has to be treated with the same rigor as any other major engineering program activity.

The organizations that succeed at this are not the ones with the best software. They are the ones with the organizational discipline to maintain baselines under pressure, the process maturity to run ECPs without shortcuts, and the leadership to treat institutional knowledge capture as a program deliverable rather than a nice-to-have. The tools matter, but they are multipliers on that underlying discipline — not a substitute for it.