What Is Configuration Management? A Systems Engineering Definition for Hardware and Software Programs
Configuration management is one of the most cited and least practiced disciplines in systems engineering. Every program of record references it. Most audits find gaps in it. The core idea is simple: you should know exactly what version of every artifact defines your system at any given point in time, who approved changes to it, and whether the physical or software product you built actually matches the documentation that describes it.
That idea sounds obvious. Executing it across a multi-year hardware/software co-development program — with distributed teams, evolving requirements, regulatory checkpoints, and parallel development threads — is not obvious at all.
This article defines configuration management as it applies to systems and hardware engineering programs: what the four core activities are, how they apply to different artifact types, what the major standards require, and what it looks like when modern tooling handles it well.
Definition: What Configuration Management Actually Means
Configuration management (CM) is the discipline of identifying, controlling, and auditing the functional and physical characteristics of a system throughout its lifecycle. A “configuration” is the documented, agreed-upon definition of a system at a specific point in time. CM is the set of processes that establishes that definition, controls how it changes, and verifies that what was built matches it.
Three distinctions are worth stating upfront:
CM is not version control. Git tracks source code changes. A CM system tracks what was approved, who approved it, what the impact analysis said, and whether the change propagated correctly across all affected artifacts. Version control is a CM-enabling tool, not CM itself.
CM applies to requirements, not just deliverables. Most engineers associate CM with drawings and software builds. But the requirement set is a configuration item too. When a requirement changes after baseline, that change requires the same formal treatment as a drawing revision — change request, impact analysis, approval, and propagation to all downstream artifacts that derived from it.
CM is a program-level discipline, not a tool feature. No tool automates sound configuration management. Tools support CM by enforcing process and maintaining records. The discipline is organizational.
The Four Core CM Activities
Every major CM standard — MIL-STD-973, EIA-649, DO-178C, ISO 26262 — structures configuration management around four activities. The terminology varies slightly; the underlying logic is consistent.
1. Configuration Identification
Configuration identification means selecting which artifacts are configuration items (CIs), assigning them unique identifiers, and establishing their structure and relationships.
On a hardware/software system, typical CIs include:
- The system requirements specification (SRS)
- Subsystem and component specifications
- Interface control documents (ICDs)
- Software requirements, architecture, and detailed design documents
- Source code and executable object code
- Hardware drawings, bills of materials, and assembly instructions
- Test procedures and test results
Identification is not just naming. It means defining the hierarchical relationship between CIs — which document is derived from which — and establishing the baseline against which future changes will be measured. A baseline is a formally reviewed and approved snapshot of one or more CIs.
The three classic baselines in defense programs are:
- Functional baseline: Approved at the conclusion of a Systems Requirements Review (SRR). Defines what the system shall do.
- Allocated baseline: Approved at the conclusion of a Preliminary Design Review (PDR). Defines how requirements are allocated to subsystems.
- Product baseline: Approved at the conclusion of a Critical Design Review (CDR). Defines the complete design ready for production.
These baselines are not just milestones. They are the reference points that make all subsequent CM activities meaningful.
2. Configuration Control
Configuration control is the process of managing changes to established baselines. Once a baseline exists, any change to a CI in that baseline must go through a formal change process — typically:
- A change request (CR) or engineering change proposal (ECP) is submitted
- Impact analysis is performed: what else does this change affect?
- A configuration control board (CCB) evaluates and approves or rejects the change
- Approved changes are implemented, and all downstream artifacts are updated accordingly
The CCB is the organizational mechanism that gives configuration control its teeth. Without a functioning CCB, changes get made informally, downstream artifacts drift out of sync with their upstream sources, and the system you built no longer matches the system you designed.
The most common failure mode: a requirement changes after PDR, the CCB approves it, the SRS gets updated — but the interface document, the verification matrix, and the test procedures do not. Three months later, no one can explain why a test is failing because the test is checking behavior that was superseded six months ago.
3. Configuration Status Accounting
Status accounting is the record-keeping activity of CM. It answers the question: what is the current approved configuration, and how did we get here?
A status accounting system maintains:
- The current approved version of each CI
- The history of all changes, including who requested, who approved, and when
- The status of open change requests
- The relationship between delivered items and the configuration documentation that defines them
Status accounting is what makes audits possible. Without it, you have a pile of documents and a system. With it, you have a traceable record connecting every artifact to its approval history.
4. Configuration Audit
Configuration audits verify that the product matches its documentation. There are two types:
Functional Configuration Audit (FCA): Verifies that the system’s functional performance matches its functional baseline. This is essentially verification: has everything been tested, and did it pass?
Physical Configuration Audit (PCA): Verifies that the as-built product matches the product baseline documentation — drawings, parts lists, software loads. This is often done before first production or formal delivery.
Both audits are gating events in defense and safety-critical commercial programs. Failing an audit does not necessarily mean the product is wrong; it often means the documentation is wrong, or that undocumented changes accumulated during development.
CM Across Artifact Types
The four activities apply uniformly, but their implementation looks different depending on what artifact type you are managing.
Requirements: Requirements are baselined at SRR, PDR, and CDR. Changes after baseline go through the CCB. Every derived requirement must trace to its parent. Status accounting tracks which requirements have been verified and which have open changes.
Design Documents: ICDs, hardware specifications, and architecture documents are CIs. They are version-controlled, change-controlled, and auditable. The product baseline is essentially the complete, approved design documentation set.
Source Code: DO-178C and similar standards require that every software CI — each source file, library, tool configuration — be uniquely identified, change-controlled, and reproducible. The concept of a “software load” as a CI means you must be able to regenerate exactly the same binary from exactly the same inputs.
Hardware Builds: The physical configuration includes part numbers, revision levels, material certs, and assembly records. A PCA on a hardware unit checks that the unit in front of you actually reflects the drawings, with the right parts at the right revisions. This is where informal substitutions and “build deviations” create audit problems.
What the Standards Actually Require
MIL-STD-973
MIL-STD-973 is the foundational DoD configuration management standard. It defines CM in terms of the four activities, specifies the ECP process in detail, and establishes the baseline structure (functional, allocated, product). It applies to defense acquisition programs and is contractually invoked by program offices. It requires a Configuration Management Plan (CMP) from contractors, formal CCB operation, and both FCA and PCA before product acceptance.
EIA-649
EIA-649 (ANSI/EIA-649C is the current version) is the commercial counterpart — broader and less prescriptive than MIL-STD-973, intended for any complex product. It describes the same four activities but allows more organizational flexibility in how they are implemented. Many aerospace and automotive programs use EIA-649 as a framework where military standards do not apply.
DO-178C
DO-178C (Software Considerations in Airborne Systems and Equipment Certification) does not use the word “configuration management” as a top-level section title, but CM is deeply embedded throughout. Section 7 defines software configuration management requirements: CI identification, baseline establishment, change control, reproducibility of the software load, and problem reporting. The standard requires that every software CI be reproducible from archived sources and that changes to baselined CIs go through a formal process with documented rationale. For DAL A software, the rigor of CM compliance is a primary concern of the DER during oversight.
ISO 26262
ISO 26262 (Road Vehicles — Functional Safety) addresses CM in Part 8 (Supporting Processes). It requires a configuration management plan, CI identification, version control, baseline management, and change management with impact analysis. The standard explicitly connects CM to safety by requiring that safety-relevant artifacts be version-controlled and traceable. For ASIL C and D items, the auditor will examine whether changes to safety requirements were properly controlled and whether the impact of those changes on the safety case was assessed.
The critical thread across all four standards: change control without traceability is not sufficient. Knowing that a requirement changed is not enough. You must know what design elements, tests, and safety arguments depended on it.
How Modern Requirements Platforms Support Configuration Management
The requirements layer is where most CM breakdowns originate. A requirement changes, the SRS is updated, but the downstream trace links — to design, to test, to hazard analysis — are not systematically updated or flagged. The CCB approves the change in the document; the engineering database does not reflect it.
Traditional requirements tools addressed this partially: DOORS and DOORS Next support baselines and change tracking, but the baseline mechanism is manual, the change impact is not computed automatically, and the audit trail is a separate artifact that someone has to maintain.
AI-native platforms like Flow Engineering approach this differently. Requirements are stored as a connected graph, not a document. When a requirement is modified after a baseline is established, the platform automatically flags all downstream items that trace to it — design nodes, test cases, safety claims — as potentially impacted. The CCB does not have to rely on an engineer manually identifying what changed; the system surfaces the impact set.
Baseline management in Flow Engineering is formal and versioned at the data level, not the document level. A baseline is a named, timestamped snapshot of the requirement graph — every requirement, every attribute, every trace link — that can be recalled exactly and compared against the current state. The delta between two baselines is computable: which requirements were added, deleted, or modified, and what changed in each.
This matters for audits. When an FCA or PCA asks “show me every change to the system specification since CDR and the approval record for each,” that question is answerable in minutes, not days.
Flow Engineering is purpose-built for systems and hardware engineering teams, not software project management teams. It does not try to replace a full enterprise CM system or PLM tool for hardware drawings. Its deliberate focus is the requirements and systems engineering layer — the artifacts that define what the system shall do and how requirements allocate across the architecture. For teams where that layer is the primary CM gap, that focus is the right tradeoff.
Practical Starting Points
If your program’s CM practice is immature, three interventions have the highest return:
1. Baseline before you build. If you do not have a formally approved, documented requirements baseline before detailed design begins, you have no reference point for change control. Every change becomes a comparison against an informal shared understanding. Establish the functional baseline at SRR, even if it is imperfect.
2. Make change impact visible. The CCB cannot approve changes responsibly without knowing what is affected. That means requirements must be traced to design, test, and (for safety-critical systems) hazard analysis artifacts. The impact analysis is only as good as the traceability structure that supports it.
3. Treat audits as rehearsals, not events. The teams that pass FCAs and PCAs cleanly are the ones that run internal audits quarterly, not the ones that prepare intensively for two weeks before the government audit. Status accounting has to be continuous, not retrospective.
Configuration management is not a bureaucratic overhead. On programs where requirements change, suppliers deliver wrong-revision parts, and software builds accumulate undocumented patches, CM is the mechanism that keeps the engineering record honest. The discipline is old. The tools that make it tractable at scale are newer, and they are getting materially better.