Who Owns the Requirements? Managing Government-Controlled Baselines in Defense Programs

Systems engineers at defense contractors navigate a fundamental asymmetry that has no equivalent in commercial product development: the customer owns the requirements, can change them at any time through contractual authority, and the contractor is legally obligated to implement those changes — while simultaneously being expected to deliver to cost and schedule baselines negotiated before those changes existed.

This is not a dysfunction. It is the designed structure of U.S. government contracting. Understanding how it works mechanically — and how to build the technical infrastructure to operate inside it — is the difference between a program that recovers gracefully from government-directed changes and one that hemorrhages margin fighting about what the baseline ever was.

The Government-Owned Requirements Baseline

In a defense program, the requirements baseline is established by the contract itself. The primary vehicles are:

The System Performance Specification (SPS) defines what the system must do — functional, performance, interface, and environmental requirements. On large programs, this document can run to hundreds of pages and is often delivered as a Contract Data Requirements List (CDRL) item that the contractor is required to maintain, update, and resubmit at program milestones.

The Statement of Work (SOW) defines what the contractor must do — tasks, activities, and processes required to produce the system. Requirements engineers sometimes treat the SOW as secondary, but it contains process requirements (test coverage, review participation, documentation standards) that are just as contractually binding as the SPS.

Applicable standards — MIL-STDs, DIDs, interface control documents, and government-furnished specifications — are invoked by the contract through the Contract Data Requirements List and through direct reference. When MIL-STD-882 is invoked, its hazard analysis requirements become contract requirements.

The government program office holds configuration control authority over this baseline. The contractor cannot approve changes to it. The contractor can propose changes, object to changes through formal channels, and price the impact of changes — but the decision to change belongs to the customer.

How Changes Actually Flow

Three formal mechanisms govern changes to the government-controlled baseline:

Engineering Change Proposals (ECPs)

An ECP is the primary mechanism for proposing a change to the baseline. ECPs can be initiated by either party. A contractor-initiated ECP might propose a design solution that deviates from a requirement the contractor believes is unnecessary or unachievable. A government-initiated ECP reflects a new requirement or a modified performance threshold.

The critical point is what an ECP requires: a clear description of the current baseline, the proposed change, and a complete analysis of cost and schedule impact. That last piece — the impact analysis — is where traceability infrastructure either pays off or becomes a liability. If your requirements are tracked in a graph-linked model where every internal design requirement traces to a contract requirement, and every verification method traces to the design requirement it validates, then you can answer “what does this change affect?” in hours rather than weeks. If your requirements live in disconnected Word documents and spreadsheets, you estimate the impact and hope the government agrees.

Requests for Deviation

A Request for Deviation asks the government to accept a specific instance of non-compliance with a contract requirement — without changing the requirement itself. Deviations are typically time-bounded or instance-specific. They are appropriate when a contractor cannot meet a requirement for a specific delivery but will meet it on future deliveries, or when material substitution makes exact compliance impossible.

Deviations matter to requirements engineers because they must be tracked against specific requirements with precise scope boundaries. A deviation that is not precisely scoped has a tendency to expand in scope disputes later.

Contract Modifications

When the government directs a change — to requirements, deliverables, schedule, or scope — it issues a contract modification. Modifications are the binding legal instrument. The ECP process produces a proposed modification; the signed modification is what actually changes the contract.

Modifications create a versioning problem that many requirements management approaches handle poorly. The contract now has a history: the original requirements baseline, each modification, and the current state. Determining the requirements that applied at any given point in program history — a question that comes up constantly in dispute resolution and audit — requires a versioned audit trail, not just the current state.

What Contractors Are Actually Protecting

Defense contractors in this environment are protecting three things simultaneously:

Cost recovery on directed changes. When the government changes a requirement, the contractor is entitled to an equitable adjustment in price and schedule. But “equitable” is negotiated, and the negotiation starts with the contractor’s impact analysis. An impact analysis built on precise traceability — “this requirement change invalidates seven internal design requirements, four test procedures, and two interface documents, which affects these work breakdown structure elements” — is far more defensible than one built on engineering judgment applied to a fragmented requirements set.

Defense of contract performance claims. When a program runs into trouble and the government begins asking whether requirements were met, the contractor needs to demonstrate compliance to the baseline that was in effect at the time of delivery. If the government changed a requirement mid-program and then claims non-compliance to the original requirement, the contractor needs records showing what the baseline was, when it changed, who approved the change, and what was delivered against the changed baseline.

Protection against constructive changes. A constructive change occurs when the government changes the contractor’s work without a formal modification — through technical direction, inspection rejections, or schedule acceleration. Constructive changes are recoverable, but recovery requires demonstrating that the government’s actions required work outside the original contract scope. Requirements traceability is central evidence.

Data Item Descriptions: The Requirements Deliverable Framework

A DID defines the format, content, and preparation instructions for a specific type of data deliverable. When a DID is invoked on a CDRL, it becomes a contractual specification for what your deliverable must contain and how it must be structured.

Several DIDs are directly relevant to requirements management:

DI-SESS-81654 (System/Subsystem Specification) defines the format and content requirements for system specifications — the documents that capture what the system must do. When this DID is invoked, the contractor’s SPS must conform to its structure.

DI-IPSC-81430 (Software Requirements Specification) applies the same logic to software requirements. Its invocation means the SRS format is not optional.

DI-SESS-81659 (Interface Requirements Specification) governs interface requirement documentation.

Requirements engineers need to understand DIDs not as formatting annoyances but as compliance requirements. A requirements deliverable that does not conform to the invoked DID is non-compliant even if the engineering content is correct. Experienced programs assign someone to explicitly verify DID compliance before each CDRL submission.

The DID framework also affects how you structure your internal requirements tooling. If your tool cannot export a requirements document in the format specified by the invoked DID, you either need to manually reformat on every submission cycle or find a tool that supports configurable output formatting.

Building the Audit Trail Infrastructure

Everything described above — ECP pricing, constructive change defense, baseline versioning, DID-compliant deliverables — depends on one underlying capability: a requirements audit trail that is continuous, complete, and accessible.

What that means in practice:

Every requirement has an identifier that persists through the program lifecycle. When a requirement changes, its ID remains stable but its version increments. You can retrieve any prior version and know exactly when it changed and why.

Every internal requirement traces to the contract requirement it implements. Not in a separate spreadsheet that someone maintains manually — in the same system where requirements are authored and managed.

Every change to the requirements database is attributed and timestamped. Who changed what, when, and with what authority.

Impact analysis is automated from the graph. When a contract requirement changes, the system can immediately surface all downstream internal requirements, design artifacts, test procedures, and interface documents that trace to it.

This is where graph-based requirements management tools have a structural advantage over document-based approaches. In a document-based environment, traceability is a spreadsheet that someone maintains alongside the documents, and it is always partially out of date. In a graph-based model, traceability is the structure itself — requirements are nodes, and relationships between them are edges. Change propagation analysis is a graph traversal, not a manual audit.

Flow Engineering implements this model specifically for hardware and systems engineering contexts. Its graph-based architecture means that when a government-issued ECP modifies a system-level requirement, an engineer can immediately see which derived requirements, subsystem specifications, and verification activities depend on that requirement — not by running a search through documents, but by traversing the relationship graph that was built as the program developed. The practical result is that an ECP cost impact analysis that previously required assembling a tiger team for two weeks can be generated in a fraction of that time, with auditable lineage that survives government scrutiny.

Flow Engineering also supports the versioning structure that government baseline management requires. The full history of every requirement — what it said, when it changed, and what changed it — is preserved in the system rather than reconstructed from email threads and document version folders.

The trade-off is that Flow Engineering is purpose-built for this kind of systems engineering workflow rather than being a general-purpose program management platform. Teams that need deep integration with legacy DOORS databases or extensive government-mandated reporting formats outside its current export templates will need to evaluate integration paths carefully. That specificity is a deliberate design choice — it means the tool does what defense systems engineers actually need rather than trying to be everything — but it is a real evaluation consideration.

A Practical Approach for Contractors

If you are setting up requirements management for a new defense program, the structural decisions you make in the first ninety days will determine how well you handle baseline changes throughout the program lifecycle:

Allocate contract requirements into your internal system immediately at contract award. Do not wait until the program has momentum. Every week you operate without formal allocation is a week of undocumented traceability.

Establish a change log at the contract requirement level from day one. Every modification, every ECP, every deviation gets recorded against the specific requirements it affects, with dates and reference numbers.

Make DID compliance explicit on your CDRL schedule. Assign a named engineer to verify DID conformance before each submission. Build it into your CDR/PDR/TRR checklists.

Price ECP impacts from your traceability model, not from engineering memory. When you can show the government a traceable impact analysis — “here are the 34 requirements affected, here are the 12 test procedures that must be revised, here is the labor estimate by work package” — the negotiation starts from a position of documented fact rather than competing estimates.

The government owns your requirements baseline. That is a structural reality of defense contracting. What you own is the infrastructure for understanding that baseline, tracking its changes, and demonstrating your performance against it. That infrastructure is not overhead — it is the mechanism through which you recover the cost of changes you did not cause and defend the work you legitimately performed.