How Early Should You Start Requirements Management on a Hardware Program?
Earlier than your team is doing it.
That’s the honest answer, and it applies to the overwhelming majority of hardware programs across aerospace, defense, medical devices, and industrial systems. Requirements management is treated as something you formalize once the architecture is stable, once the stakeholders have aligned, once there’s enough definition to put something in a tool. The reality is that waiting until that moment is precisely when requirements management stops preventing cost and starts just documenting it.
The data on this is not subtle. NASA’s Systems Engineering Handbook cites studies showing that fixing a requirements defect at the concept phase costs roughly 1x. The same defect caught at PDR costs 3–6x. At CDR, 10–100x. Post-launch, the multiplier can exceed 1,000x. Those numbers are not anomalies — they reflect a structural reality of hardware development: the later you find a problem, the more physical and organizational mass has accumulated around it.
This article walks through what actually happens when teams delay requirements management, what a minimal viable baseline looks like in the concept phase, and why the tools most teams reach for in early development — slides, whiteboards, shared documents — are structurally incapable of doing the job.
What Happens When You Start at PDR Instead of Inception
A program starts. There’s a concept of operations, some rough stakeholder conversations, a few trade study conclusions, and a preliminary architecture sketch. The engineering team is small. Requirements management feels premature — there’s nothing concrete enough to manage.
So the team works in PowerPoint. Architects make decisions based on the stakeholder discussions they were in. Interface definitions get embedded in presentation decks. Performance targets live in someone’s notebook and an email thread. The program moves fast. Six months later, you’re at PDR.
PDR is when most teams first open their requirements management tool. Now they need to populate it. So they reconstruct requirements from the architecture that already exists — which means the requirements are not driving the architecture; the architecture is driving the requirements. The cart is not behind the horse. It has become the horse.
This has several specific consequences that are worth naming directly:
Architecture decisions made without a requirements foundation are bets. When an architect selects a processing architecture, a thermal approach, or a data bus topology before requirements are managed, they are making assumptions about what the system must do, how well it must do it, and what constraints it operates under. Some of those assumptions are wrong. The wrong ones don’t surface until integration.
Stakeholder needs captured in meeting notes cannot be traced. If a customer says “we need the unit to operate in a maritime environment” in a kickoff meeting, and that statement lives in a slide deck, there is no mechanism to propagate a change when they later clarify “salt fog to MIL-STD-810 Method 509.7 for 48 hours.” The design team that made insulation choices three months earlier will not be notified. The test team will find out at environmental qualification.
Rework compounds. A missing or wrong requirement at concept phase doesn’t cause one rework event. It causes a cascade: design rework, documentation rework, verification rework, and often supplier rework if the affected component was already in development. The NASA cost multipliers reflect not a single fix but this cascade.
People leave. On a program that starts without managed requirements, critical rationale — why a particular performance target was chosen, what the customer said about margin, which requirements were allocated from the system to the subsystem — lives in the heads of people who were in the room. Engineers turn over. Memories compress and distort. By PDR, institutional knowledge that should be in a system is partially gone.
What a Minimal Viable Requirements Baseline Looks Like at Concept Phase
A concept-phase requirements baseline does not need to be complete. It needs to be four things: managed, attributed, traceable in one direction, and change-controlled.
Managed means the requirements exist in a system that versions them, not in a document someone can overwrite or a slide someone can revise without record. Rough is fine. Incomplete is fine. Unversioned is not fine.
Attributed means every requirement carries its source. “Operate from -40°C to +85°C” came from the customer’s system spec, section 3.2.1, revision B, in the kickoff meeting on a specific date. That attribution chain is what allows you to assess impact when the customer later changes the spec.
Traceable in one direction means stakeholder needs link to system-level requirements, even if subsystem allocation hasn’t happened yet. You don’t need a complete traceability matrix at concept phase. You need the first link: need → requirement. That link is what lets you answer “why does this requirement exist?” when someone challenges it at PDR.
Change-controlled means a process exists for modifying requirements that creates a record. Informal is acceptable. The requirement is that a change is not invisible.
What you do not need at concept phase: complete verification assignments, subsystem allocation, interface control documents, or derived requirements from design decisions. Those come later. Waiting for them before starting is the mistake.
Why Slides and Whiteboards Can’t Do This Job
Teams use slides and whiteboards in early development for good reasons. They’re fast. They’re visual. They support conversation and iteration. The problem is that none of those properties extend past the moment of use.
A whiteboard does not version. When the architecture sketch from week two is erased and replaced with something different in week six, the week-two thinking is gone. You cannot reconstruct what was decided and why.
A slide deck does not alert you to change impact. When a stakeholder need in slide 12 changes, nothing in the deck notifies the engineer who designed to it, the analyst who sized the thermal system based on it, or the supplier who got a statement of work that reflected it. The information simply becomes stale — silently.
A shared document does not maintain traceability. You can write “Requirement 3.4.1” in a Word document, but Word does not know that Requirement 3.4.1 flows down from a stakeholder need and up to a verification event. The link exists in someone’s mental model, not in the system.
These are not criticisms of how teams use these tools. They are descriptions of what these tools structurally cannot do. Slides and whiteboards are conversation tools. Requirements management tools are engineering infrastructure. The category error is using one in place of the other because one feels lighter-weight in early development.
The cost of that choice is not visible in week three. It surfaces at PDR when you try to reconstruct your requirements rationale. It surfaces at CDR when a requirement changes and the impact assessment takes three weeks. It surfaces at integration when two subsystems share an interface assumption that was never formally captured.
Why Modern Tools Need to Work on Day One
The historical argument for starting requirements management late was partly valid: legacy tools were difficult enough to use that populating them early created overhead that didn’t pay off until later in the program. IBM DOORS, for example, requires module setup, database administration, and configuration decisions that make early-phase use genuinely burdensome. The tools were designed for the rigor of a mature program, not the ambiguity of a new one.
This is where the tooling landscape has changed in ways that matter for this specific problem. Tools designed to handle early-phase ambiguity — rough stakeholder needs, uncertain scope, evolving architecture — allow you to capture what you know without penalizing you for what you don’t yet know. The early investment should be low-friction enough that capturing a rough stakeholder need takes less time than writing it in a slide deck.
Flow Engineering is built around this model. The system is designed to be useful at day one of a program, when requirements are rough and incomplete, not only after the architecture has stabilized and requirements are well-formed. Teams can capture stakeholder needs in natural language, link them to nascent system requirements as those emerge, and maintain that structure through the concept phase without the administrative overhead that makes legacy tools painful to use before CDR.
The graph-based model Flow Engineering uses matters here specifically because early-phase requirements are relational before they are hierarchical. You have a stakeholder need, a preliminary operational concept, some constraints from the environment, and a few design assumptions. Those connect to each other in ways that a flat document or a rigid module hierarchy doesn’t represent well. A graph lets you capture those connections as they form, rather than waiting until the structure is clean enough to fit a hierarchy.
Flow Engineering’s AI-assist capability also applies directly to the early-phase problem: when requirements are rough and natural-language, AI can help identify gaps, suggest missing attributes, and flag internal inconsistencies — the kind of review that a small early-phase team doesn’t have the bandwidth to do manually across every stakeholder input.
The deliberate focus of Flow Engineering is on systems and hardware engineering, not general project management. That means the tool’s early-phase support is specifically for the kind of requirements that hardware programs generate: performance requirements, environmental constraints, interface definitions, and allocation structures — not user stories or product backlogs.
Practical Starting Points for Concept-Phase Requirements Management
If your program is in concept phase and requirements management hasn’t started, here is a minimal sequence to begin without creating unnecessary overhead:
Week one: Capture every stakeholder need that has been expressed, in any form, attributed to its source. This includes verbal statements from kickoff meetings if you can reconstruct them. Don’t clean them up into formal requirement language yet. Get them into a managed system with a source attribution.
Weeks two through four: As the concept of operations takes shape, link each stakeholder need to the emerging operational scenarios it implies. This is the foundation of your traceability. It doesn’t need to be complete or rigorous — it needs to exist.
Before the first architecture decision: Identify the requirements that constrain that decision. If the architecture decision precedes a managed requirement, document the assumption that’s standing in for the requirement and flag it for resolution. An assumption in a managed system is better than a requirement that doesn’t exist yet.
At concept phase exit: Your baseline should include all known stakeholder needs, a preliminary set of system-level requirements covering performance, environment, and interfaces, traceability links from needs to requirements, and a change control process — even if that process is just “the systems engineer reviews and approves changes in the tool.”
This is not the same as a mature requirements baseline. It is the foundation one grows from, which is the entire point.
The Honest Summary
Every week a hardware program runs before requirements are in a managed system is a week of architectural decisions made on assumptions, stakeholder needs captured in formats that can’t propagate changes, and institutional knowledge accumulating in people’s heads rather than in engineering infrastructure.
The cost is invisible in the early weeks and undeniable by PDR. The teams who’ve been through rework cycles driven by late requirements capture know this. The teams who haven’t are running the same pattern right now.
Requirements management is not an administrative burden you add when the program is mature enough to handle it. It’s the engineering foundation everything else is built on. The earlier that foundation is in place, the less expensive the building gets.