How Do You Manage Requirements When the Customer Doesn’t Know What They Want?

The customer who walks in knowing exactly what they want is the exception. In most programs — commercial avionics, defense electronics, autonomous ground vehicles, satellite payloads — the customer knows the problem they’re trying to solve. They don’t know how it translates into a specified system. That gap between “I need something that does X” and a coherent, stable requirements baseline is where most programs get hurt.

This is not a customer failure. It’s structurally normal. Customers are domain experts in their operational world. Systems engineers are experts in translating operational need into technical specification. The difficulty is that this translation can’t happen in a single meeting, and the customer can only fully evaluate what they want after they’ve seen something concrete — which may happen after you’ve already built something.

Managing this honestly means accepting two things: requirements will evolve, and your job is to make that evolution controlled rather than chaotic.

Why Customers Don’t Know What They Want (and Why That’s Your Problem to Solve)

Defense and commercial contexts differ in instructive ways here.

In defense programs, customers often have detailed operational concepts (CONOPs) and decades of acquisition doctrine behind them. The problem isn’t that they have no requirements — it’s that their requirements are written at the mission level, not the system level, and translating between the two involves decisions they haven’t yet made. A program office may hand you an MNS or CDD that specifies threshold and objective values for a dozen key performance parameters. What it doesn’t tell you is what happens when optimizing for one KPP forces a tradeoff against another, or which interfaces need to survive a future block upgrade.

In commercial programs, customers often have a vision of an end product and a set of business constraints. What they lack is experience with what systems engineering actually requires. A medical device startup that wants a continuous monitoring platform may have extraordinarily detailed clinical intuitions and almost no idea that those intuitions need to resolve into specific power budgets, wired vs. wireless tradeoffs, and FDA 510(k) pathway decisions that will determine their entire development timeline.

In both contexts, latent requirements — requirements the customer would agree to if asked, but hasn’t yet articulated — are the risk. The question is how to surface them before they surface on their own, usually at a CDR or during acceptance testing.

Elicitation: Three Tools That Actually Work

Workshops

A requirements workshop is not a meeting where you read a draft document to the customer and ask if it looks right. That format produces false confidence. Customers will approve language they don’t fully understand, and disagree with it nine months later when the implications become physical.

A useful workshop starts from operational scenarios — actual missions, use cases, or workflows — and walks customers through them step by step. For each step, you ask:

  • What does the system need to provide at this moment?
  • What does failure look like here?
  • What would “better than required” look like?

The last question is often the most valuable. Customers who can articulate their delight criteria are revealing their latent requirements more directly than customers who are asked to approve functional specifications.

For defense programs, red-team the scenario. Put an adversary in it. Ask: if someone wanted to defeat this system, what would they do? Requirements that don’t survive red-teaming weren’t real requirements — they were wishes.

Invite the right people. Operators and maintainers surface different latent requirements than program managers. End users who will live with the system daily have a completely different requirement profile than the acquirer who signs the contract. Both sets of requirements are real. Only one of them usually makes it into the document by default.

Prototypes

Prototypes reveal requirements that workshops can’t, because workshops operate in the abstract. A customer who enthusiastically approves a heads-up display layout in a requirements review will often immediately identify problems when they sit in front of a physical mock-up.

The key is to prototype early and cheaply, and to prototype specifically for requirements elicitation, not for design validation. These are different goals that call for different prototypes. A cardboard cockpit mock-up is appropriate for the first goal. A high-fidelity avionics rig is appropriate for the second.

For commercial programs, interactive software prototypes — wireframes with real interaction logic — are often the fastest path to latent requirements in user-facing systems. Show the customer a workflow. Watch where they hesitate. Ask what they expected to happen instead.

Document everything that emerges. Prototyping sessions that aren’t tied directly back to the requirements baseline generate institutional knowledge that disappears when people change roles.

Scenario Walkthroughs

Distinct from workshops, which tend to be customer-facing, scenario walkthroughs can also be internal. Walk your own engineering team through extreme cases: the lowest-power operating environment, the hardest maintenance task, the edge case that happens 0.1% of the time but results in a safety-of-flight condition.

These walkthroughs regularly surface requirements that no one thought to write, not because anyone was careless, but because the scenario hadn’t been considered. Off-nominal operations are particularly underspecified in early requirements. Customers specify what they want the system to do when everything is working. They rarely specify what they want it to do when it partially fails, or what information they need to make a decision under degraded conditions.

Writing Requirements That Are Stable Enough to Drive Design

The standard failure mode is writing requirements at too low a level of abstraction too early. A requirement that specifies a particular technology, interface standard, or implementation approach gives the customer something specific to react to — and they will react to it, often by changing their mind as they learn more. A requirement that specifies what the system must accomplish, without specifying how, gives the design team freedom and gives the customer fewer decision points to revisit.

This is not a call for vague requirements. “The system shall perform well” is not a requirement. “The system shall maintain track quality above threshold X in clutter conditions characterized by Y” is a requirement that specifies outcome without constraining solution space prematurely.

Three practices help:

Separate need from solution. For every requirement as drafted, ask: is this a statement of what the system must do, or what we currently believe the system should look like? The second category should either be elevated to a true functional requirement or moved explicitly to design documentation.

Use shall/should/may deliberately. “Shall” requirements are contractual obligations that drive design decisions. “Should” requirements are design goals that will be traded against cost and schedule. “May” requirements are options the design team can consider. Customers who don’t know what they want often write everything as “shall.” Part of your job is working with them to sort the list.

Anchor requirements to testable outcomes. A requirement that can’t be verified is a requirement that can’t be baselined. Before any requirement enters the formal baseline, the verification method should be identified. This discipline catches ambiguity early and often surfaces latent requirements: if you can’t describe how you’d test something, you probably haven’t fully specified it.

Protecting the Program from Churn

Requirements churn — the continuous modification of requirements by customers who are still figuring out what they want — is not a documentation problem. It’s a program management problem with documentation consequences.

The structural fix is formal change control, established early and applied consistently.

A baselined requirements set has a specific version at a specific date. Any proposed change is submitted as a change request, evaluated for impact across cost, schedule, and technical risk, and approved or rejected by a defined authority before it is incorporated. This is not bureaucratic friction — it is the mechanism by which requirements evolution becomes deliberate rather than reactive.

The discipline this creates for the customer is valuable in itself. Customers who understand that a proposed change will trigger an impact assessment before it’s incorporated tend to be more thoughtful about which changes they actually want. The change control process makes the cost of indecision visible. Without it, indecision is free — until acceptance testing.

For commercial programs with shorter cycles, lightweight change control is still change control. A two-column log with proposed change and assessed impact, reviewed weekly, is sufficient to make evolution visible. What matters is the habit of evaluating before incorporating.

For defense programs, the DoD 5000 framework provides formal mechanisms — contract modifications, engineering change proposals, and configuration control boards — that serve this function. The risk in large defense programs is not that these mechanisms don’t exist, but that requirements changes slip in informally through meeting notes and action items while the formal baseline stays artificially frozen. Keeping the formal baseline synchronized with what the team is actually building is non-trivial but critical.

Showing Customers What a Change Actually Costs

The most effective single intervention for reducing requirements churn is this: before the customer approves a proposed change, show them what it affects.

In a document-based requirements system, this is nearly impossible to do quickly. You can trace the change manually, update cross-references, and produce an impact report — but it takes time, and by the time you produce it, the customer has often already mentally committed to the change.

In a graph-based requirements model, the traceability is live. Every requirement links to the functions it allocates to, the design elements that implement it, the test cases that verify it, and the other requirements it’s coupled to. A proposed change to one requirement immediately reveals its downstream connections.

Teams using Flow Engineering can make this visible to customers directly. When a customer proposes modifying a requirement — say, changing a response time threshold or adding a new interface obligation — the engineering team can pull up the live traceability graph and walk the customer through exactly which design elements, verification cases, and downstream requirements are affected. That conversation changes the dynamic. The customer is no longer deciding whether they want a different requirement. They’re deciding whether they want a different requirement knowing that it touches fourteen allocated functions, three interface definitions, and a test procedure that’s already been written.

This doesn’t eliminate change. Change is legitimate. It makes change deliberate, which is the actual goal. Flow Engineering’s AI-assisted impact analysis accelerates this specifically — rather than a systems engineer spending two hours tracing dependencies manually before a customer review, the graph surfaces the impact in time for the conversation to happen when it matters.

Practical Starting Points

If your program is already underway and requirements are unstable, the recovery sequence is:

  1. Establish a baseline now, even if it’s imperfect. An imperfect baseline that’s formally controlled is more useful than a perfect document that everyone treats as a draft.

  2. Run a scenario walkthrough with operators and maintainers, not just the program office. Document what you learn as change requests against the baseline, not as informal updates.

  3. Establish change control with a defined authority and a defined impact assessment template. Make it lightweight enough that people will actually use it.

  4. Make the traceability visible before the next customer review. If customers can see what their requirements connect to, the conversation changes.

If your program is earlier — in the concept phase or early development — the investment is:

  1. Workshop first, write second. Don’t hand customers a draft requirements document in the first meeting. Run scenario-based elicitation before you draft anything.

  2. Prototype for requirements, not for design. Cheap, fast prototypes that put something in front of the customer earlier will surface more latent requirements than any document review.

  3. Build the traceability model from the start. Adding traceability to an existing requirements set is an expensive retrofit. Building it into the baseline from day one costs almost nothing in comparison.

Honest Summary

Customers who don’t know what they want are not a problem to be managed around — they’re the normal starting condition of most programs. The engineering challenge is creating the conditions under which their actual requirements can emerge deliberately, before they emerge as surprises.

Workshops, prototypes, and scenario walkthroughs are the tools for surfacing latent requirements. Writing at the right level of abstraction is the tool for stability. Formal change control is the tool for making evolution deliberate. And making downstream impact visible — to customers, before they approve changes — is the tool for making the cost of indecision concrete.

The programs that handle this well aren’t the ones that got lucky with a customer who knew what they wanted. They’re the ones that built the process to make requirements evolution something the program controls, rather than something that happens to it.