How Do You Know When You Have Enough Requirements to Start Detailed Design?
There is a debate that happens at almost every program review, usually in the last twenty minutes, always uncomfortable. Someone from the design team wants to start detailed design work. Someone from systems engineering thinks the requirements aren’t ready. The program manager wants to make a decision but doesn’t have data to make it. So the room argues about confidence levels, and eventually the loudest voice wins.
This is the wrong conversation. Not because the underlying concern is wrong—it isn’t. Starting detailed design against incomplete or ambiguous requirements is genuinely expensive. But framing the question as “are requirements complete?” guarantees the debate goes nowhere, because 100% completeness is never true, everyone in the room knows it, and the argument becomes about whose incomplete is acceptable.
The right question is: Do we have enough of the right requirements to proceed without incurring unacceptable design risk? That’s answerable. This article explains how to answer it.
Why “Complete Enough” Is the Wrong Frame
Requirements completeness, as a concept, implies a ceiling you can reach. In practice, requirements on real hardware programs evolve continuously. Customer needs clarify during development. Interface partners update their specifications. Regulatory bodies publish revised guidance. A system that was “requirements complete” in January may have three open items by March that weren’t foreseeable in January.
Chasing completeness as a gate criterion does two things, both harmful.
First, it creates a false binary. Either requirements are complete—and design can start—or they aren’t, and everyone waits. Programs that take this seriously enough to enforce the gate often find themselves in analysis paralysis: systems engineers keep working the requirements, the design team sits partially idle, schedule slips, and at some point the program manager forces a start anyway under worse conditions than if they’d started with explicit risk awareness three months earlier.
Second, it obscures what actually matters. The dangerous thing isn’t having open requirements on the power connector pinout. The dangerous thing is starting a thermal architecture without having resolved how much heat the high-power processor module needs to dissipate, or starting a structural layout without knowing which components will be subject to shock and vibration qualification requirements. Completeness treats every open requirement as equally unresolved. Readiness criteria treat them differently.
The Four Readiness Criteria That Actually Matter
Rather than measuring completeness, engineering leads should assess readiness against four specific coverage areas. If all four are in acceptable shape, detailed design can start—with managed risk on what remains open. If any of the four have significant gaps, proceeding will cost you more than waiting.
1. Key Interfaces Are Defined
Interface requirements don’t need to be perfect. They need to be stable enough that two independent design teams building toward the same interface will produce hardware that can be integrated. This means electrical interfaces have voltage, current, timing, and connector type defined. Mechanical interfaces have coordinate systems, envelope constraints, and mounting patterns defined. Software interfaces have protocol, data rate, and message format defined at least at the functional level.
An interface requirement that is “TBD pending customer input” is not defined. An interface requirement that has a working baseline with a change process is defined. The distinction matters because the design team needs a stake in the ground to design against, not a final answer.
How to assess it: Walk every external interface and every internal interface at the major subsystem boundary. Mark each as defined, baselined-but-open, or undefined. Start detailed design only when undefined count is zero or when undefined items have no design consequence for the immediate work scope.
2. Safety Requirements Are Allocated
Safety requirements get special treatment in readiness assessment because the cost of a late-discovered safety allocation gap is higher than almost any other requirements issue. If you find at CDR that a safety-critical function has no verification approach, you may be rebuilding hardware. If you find it now, you’re writing requirements.
Allocation completeness for safety requirements means: every identified hazard has a mitigation requirement, every mitigation requirement is allocated to a specific subsystem or component, and every allocated requirement has an owner on the design team who knows they own it.
This does not require that the design solution for every safety requirement is known. It requires that the requirement exists, it lives somewhere specific in the architecture, and a human being is responsible for it. Unallocated safety requirements going into detailed design are a program risk that should be surfaced explicitly, not buried in a completeness percentage.
3. High-Risk Functions Are Covered
Every program has a short list of functions where the design problem is hard, the technology readiness is lower, or the performance margin is thin. These are the places where an ambiguous or missing requirement will cause a design decision to be made by a mechanical engineer trying to finish a drawing, rather than by a systems engineer who has thought through the tradeoffs.
The definition of “high-risk function” varies by program, but on most hardware programs it includes: functions with tight thermal budgets, functions using immature components or processes, functions at the edge of the performance envelope, and functions that interface with external systems not fully under your team’s control.
Readiness criteria for high-risk functions: requirements exist, they are specific enough to be testable, and the design team has read them. That last part is not a joke. Requirements documents that exist but have not been read by the engineers who will implement them are not functional requirements.
4. Verification Approaches Are Identified
The question “how will we verify this requirement?” should be answerable before detailed design starts, at least at the method level. Not because you need a fully developed test procedure—you don’t—but because the verification approach often constrains the design approach, and discovering that constraint after the design is done is expensive.
A thermal requirement verified by analysis needs a thermal model. A structural requirement verified by test needs a test configuration. An EMI requirement verified by qualification test needs margins built into the design. None of these constraints can be efficiently incorporated after the detailed design is complete.
Verification approach identification means: for every derived requirement and every flowed-down requirement in the detailed design scope, someone has answered the question “test, analysis, inspection, or demonstration?” If that column is empty, the requirement isn’t ready for design.
The Cost of Starting Too Early
Starting detailed design before the four criteria above are in reasonable shape doesn’t save schedule. It moves schedule risk forward while converting it to cost risk.
The specific failure mode: design engineers make assumptions to fill in undefined requirements. They document the assumption in a drawing note or a design memo, or they don’t document it at all. Requirements come in later that contradict the assumption. The design has to be reworked. The rework touches downstream drawings, which have to be revised. Interface partners who were designing against your output interface have to be notified. The integrated schedule impact of one unresolved interface requirement discovered at the integration phase is measured in weeks, not days.
Programs that are honest about this dynamic know the pattern. The argument for starting early—“we’ll capture the assumptions and iterate”—is usually true about the intent and false about the execution. Iteration happens when someone is forcing it. Under schedule pressure, assumptions calcify into design decisions, and design decisions become very expensive to change.
The Cost of Starting Too Late
The opposite failure is real too, and it gets less attention in systems engineering literature because systems engineers tend to be the ones writing the literature.
Analysis paralysis on requirements is most common on programs with experienced systems engineering teams, because those teams have seen the cost of starting too early and have overcorrected. The result: requirements reviews extend, action item lists grow, every open item gets the same treatment regardless of design consequence, and the design team sits idle or—worse—starts working on the parts of the design that feel safe without a formal start, which means the high-risk work gets done last.
The cost here is real schedule. A detailed design team that starts a month late on a twelve-month design phase has either lost a month of schedule or has to compress the final phases. Neither is free.
Readiness criteria solve this problem by making the go/no-go decision specific. The answer isn’t “requirements aren’t complete.” The answer is “interface ICD-003 is undefined and it affects the power architecture; everything else is ready.” That’s a manageable statement. It leads to “let’s assign someone to close ICD-003 in two weeks and start the rest of design now,” which is a program management decision, not a requirements argument.
Answering the Question With Data
The four readiness criteria above are useful only if you can actually assess them without spending three weeks doing it. In practice, this means your requirements management environment needs to support a few specific queries:
- Which requirements have no allocation to a subsystem or component?
- Which safety-tagged requirements have no verification method assigned?
- Which interfaces have requirements in a TBD or undefined state?
- Which high-risk functions have requirements that haven’t been reviewed or baselined?
In a legacy document-based environment—a Word-based requirements set or a managed DOORS module without structured attributes—answering these questions requires manual review. Someone reads through the document, marks up a spreadsheet, and produces a snapshot that is out of date by the time it’s presented at the program review.
This is where graph-based, AI-native requirements tools change the practical workflow. Flow Engineering structures requirements as a connected graph where allocation, verification method, and status are attributes of every node, not fields in a separate tracking spreadsheet. An engineering lead can pull a live view of allocation completeness for safety requirements across the entire system architecture—not a PDF from last week’s export, but a current query against the actual requirements state.
More practically: Flow Engineering surfaces coverage gaps automatically. If a function node in the system architecture has no allocated requirement against it, that gap is visible without someone manually auditing the document set. If a safety-tagged requirement has no verification method, it shows up in the readiness view as an open item, not buried in a 400-row spreadsheet that the systems engineer maintains separately from the actual requirements.
This matters at program reviews because the readiness question becomes answerable in the meeting. Not “I think we’re about 85% ready”—which is an intuition dressed as a number—but “we have four undefined interfaces, three unallocated safety requirements, and two high-risk functions with no verification method assigned.” That’s a different conversation. It has specific action items, specific owners, and a specific path to a go decision.
A Practical Starting Point
If your program is approaching a detailed design readiness decision and you don’t have this infrastructure in place yet, here is a minimum viable approach:
Week one: Define your four readiness criteria explicitly, tailored to your program’s risk profile. Write them down. Get the systems engineering lead and the design leads to agree on what “acceptable” means for each.
Week two: Do a structured audit against each criterion. Use whatever tool you have, but be structured—requirements attributes, not document impressions.
Week three: Produce a readiness statement with specific open items, consequence of each open item for design, and a closure plan for each. Present this at the program review instead of a completeness percentage.
The programs that handle this well are not the ones that have perfect requirements. They are the ones that have honest visibility into what’s missing, who owns it, and what happens to the design if it doesn’t close.
That visibility is what readiness looks like in practice.