The Customer’s Role in System Requirements: Responsibilities, Overreach, and Where It Breaks Down

Ask a systems engineer where requirements come from, and the textbook answer is: the customer. That’s partially true, and partially the source of a lot of failed programs.

Customers bring domain knowledge, operational context, and funding. They also bring assumptions, organizational politics, institutional memory of previous failures, and — occasionally — a complete solution sketched on a whiteboard that they’d like you to justify with engineering. Understanding the distinction between what customers are legitimately responsible for specifying and what crosses into engineering territory is one of the most practically important skills in systems engineering. Most frameworks describe it in principle. This article addresses what it looks like in practice.

What Customers Are Actually Responsible For

The clean version of the answer: customers own the problem space, engineers own the solution space.

The customer’s legitimate domain covers:

Operational needs. What the system must enable the user to do, in what environment, with what frequency, and under what conditions. A military customer saying “the vehicle must maintain communications in contested electromagnetic environments at ranges up to 50 km” is specifying an operational need. That’s their job.

Constraints that are genuinely external to the engineering team. Budget ceilings, timeline gates, regulatory requirements, interface standards imposed by external systems, geographical or environmental operating conditions — these are real constraints that engineering cannot dissolve, only design within.

Measures of effectiveness (MOEs). How success will be evaluated from the customer’s perspective. Detection probability, mission completion rate, mean time between failures in operational context, operator workload — these are the customer’s measures, not performance specifications the engineer derived.

Acceptance criteria. What observable behavior, under what test conditions, will cause the customer to accept or reject the delivered system. This is the customer’s explicit right. It is also the exact boundary they should defend, because acceptance criteria translate directly into contractual obligation.

What falls squarely outside customer responsibility — and causes compounding problems when customers venture into it anyway — is the implementation. How the system achieves its required behavior is an engineering decision. The customer choosing an architecture, mandating a specific technology, or specifying internal component parameters without bearing accountability for the resulting design tradeoffs is overreach.

When Customers Over-Specify Implementation

Over-specification doesn’t usually happen because the customer wants to micromanage. It happens because:

  • The customer had a bad experience with a previous contractor and is trying to prevent recurrence by specifying what that contractor got wrong.
  • A customer technical representative knows the domain deeply and has genuine opinions about how the problem should be solved.
  • The customer is implicitly assuming a legacy system architecture and writing requirements that only make sense inside that architecture.
  • A previous vendor proposed a specific solution and the customer wrote that solution into the requirements before competitive procurement.

The problem with customer-specified implementation is that accountability doesn’t follow the specification. If a customer requires a specific processor family for a real-time control application, and that processor family creates thermal management issues that degrade reliability, the engineer cannot disclaim responsibility for the reliability outcome — even though the upstream constraint originated with the customer. The customer has constrained the solution space without accepting ownership of the resulting risks.

The practical response to over-specification is to push back at requirements review, not at delivery. When a requirement reads like a design decision — “the system shall use a dual-redundant fiber optic backplane” rather than “the system shall maintain signal integrity under [defined fault conditions]” — the engineer’s job is to surface that distinction explicitly. Propose a performance-based restatement. If the customer insists on the implementation specification, document the tradeoff: what engineering decisions are now constrained, what risks follow from that constraint, and who owns them.

This sounds procedurally simple. In practice it requires organizational willingness to have an uncomfortable conversation with the entity writing the checks. That conversation is easier to have at requirements review than after integration.

When Customer Requirements Are Actually Goals

The opposite failure mode is under-specification: customers providing aspirational statements that feel like requirements but contain no testable content.

“The system shall provide superior situational awareness.” “The interface shall be intuitive.” “The platform shall be future-proof.”

These are goals. They describe a desired outcome without specifying the conditions, measures, or thresholds that would distinguish success from failure. Goals belong in concept documents and marketing materials. Requirements, by definition, need to be verifiable — someone has to be able to say, under defined test conditions, whether the system does or does not comply.

The danger isn’t just engineering ambiguity. The danger is contractual. When a goal-as-requirement becomes part of a contract, the engineer is obligated to something that cannot be measured, which means the customer retains permanent interpretive authority over whether you’ve met it. That’s not a requirements relationship. That’s litigation.

Converting goals to requirements is not the customer’s problem to solve alone. It’s a collaborative process, and engineers are responsible for driving it. “What would you see in operational use that would tell you situational awareness was sufficient?” “What would an untrained user be able to do in the first session that would demonstrate the interface is intuitive?” These questions don’t undermine the customer’s goals — they make them achievable.

The output of that conversation needs to be written down, attributed to both parties, and connected to the formal requirements baseline. Otherwise the next program milestone will surface the same ambiguity.

Contractually Binding but Technically Wrong

This is where the problem becomes genuinely difficult. A requirement that was over-specified, under-verified, or simply wrong has been baselined, signed, and incorporated into contract. The engineer discovers, during design or integration, that the requirement as written cannot be met — or worse, that meeting it as written will violate another requirement.

There are three common sources of this situation:

  1. Physical impossibility revealed by analysis. A requirement that seemed reasonable at the time of writing turns out to violate a physical constraint — thermal limits, communications bandwidth, material strength — that wasn’t quantitatively evaluated during requirements development.

  2. Requirements conflict. Two requirements, each reasonable on its own, are mutually exclusive in practice. Meeting the signal power budget violates the EMI emission limit. Meeting the response time specification violates the fault detection threshold.

  3. Changed operational context. The external environment or interface assumptions changed between requirements definition and delivery, making previously correct requirements incorrect.

In all three cases, the engineer’s obligation is the same: surface the problem immediately, in writing, with technical justification, through the formal change request process. Hoping to engineer around a contractually wrong requirement is not a strategy. It produces a system that nominally complies with a requirement that shouldn’t have existed, or a system that demonstrably doesn’t comply and needs to be explained at delivery.

The customer’s obligation, reciprocally, is to treat the change request as an engineering input, not a scope complaint. A change request that says “Requirement 4.3.2 as written requires X, which is physically incompatible with Requirements 4.1.7 and 4.2.9 as written, for the following technical reasons” is the engineer doing their job. The customer ignoring it and insisting on contractual compliance with all three requirements simultaneously is not a technical position.

This situation is resolved through formal requirements change management — tracked modifications with rationale, technical justification, and impact analysis. What it is not resolved by: verbal agreements, email threads that aren’t linked to the requirements baseline, or assumptions that the problem will resolve itself during integration.

Making Customer Contributions Explicit and Traceable

The systemic fix for all of these failure modes — over-specification, goal-as-requirement, and contractually wrong baselines — is the same: the requirements process needs to make customer contributions and engineer responses visible, attributed, and connected to each other.

“The customer wrote this” and “engineering recommends changing it to this, for these reasons” need to be distinct, traceable records — not merged into a document that obscures who said what and when. Without attribution, requirements reviews become negotiations over document language with no accountability for the original source. Requirements changes become undocumented accommodations. Contractual disputes become arguments about what was intended, not what was agreed.

Modern requirements tools handle this with varying degrees of rigor. Tools like IBM DOORS Next and Jama Connect provide versioning and change history, which is meaningful — you can see what a requirement said at each baseline and who approved the change. What they don’t do natively is structure the customer-engineer dialogue itself: the review comment from the customer, the engineering response, the disposition, and the resulting requirement change, all linked in a way that makes the reasoning retrievable later.

Flow Engineering approaches this problem differently. Its requirements review workflows are built to make customer contributions and engineering responses explicit steps in the process, not annotations in a document. When a customer submits an operational need, the engineer’s response — including proposed requirement statements, technical rationale, and open questions — exists as a structured, traceable artifact connected to the resulting requirement. When a requirement changes because of a customer-initiated modification or an engineer-identified conflict, the change carries its origin. This matters most not during development, but during integration, test, and any downstream dispute about what was agreed and why.

That level of structured traceability is especially valuable in programs where the customer is a large organization — a government agency, a prime contractor — with multiple stakeholders who may have contributed to requirements at different times with different levels of technical depth. The ability to say “this requirement originated from this stakeholder input, was modified for this technical reason, and was accepted by this reviewer” is not a bureaucratic nicety. It is the audit trail that resolves disputes and prevents them from recurring in follow-on programs.

Practical Starting Points

None of this requires a large program or a complete tooling overhaul to implement. Three practices make the biggest immediate difference:

Separate need capture from requirement writing. Customer inputs and engineer translations should be distinct artifacts. Never let a customer-submitted paragraph become a requirement without an explicit engineering step that converts it to verifiable form and records the translation.

Surface over-specification at the first requirements review. Implementation constraints in customer requirements should be flagged, logged, and either converted to performance requirements or accepted with documented risk attribution. Not at PDR. At requirements review.

Use change management for technically wrong requirements, immediately. The moment an engineer identifies a requirement that cannot be met or conflicts with another, the clock starts on a formal change request. Verbal acknowledgment from the customer is not a baseline change. Written, traced, approved change requests are.

The customer’s role in requirements is legitimate and necessary. Customers bring the operational context that engineers cannot manufacture. But that role has a boundary, and both sides of the boundary need to be maintained actively — not assumed to exist because the process documentation says it does.