Why Requirements Written by Design Become Specifications, Not Requirements
Whoever writes a requirement naturally starts from what they already know how to achieve, not from what genuinely needs to be achieved. That is why requirements should not be written by the same function that will also design the solution.
Requirements should not be written by design. This is not a comment on competence. It is a structural risk built into who holds the pen. Whoever writes a requirement naturally starts seeing the solution space first, what can be achieved with the tools, methods, and approaches already familiar to them, rather than starting from what genuinely needs to be achieved. A design function drafting its own requirements is, almost without noticing, drafting requirements shaped by the solutions it already knows how to deliver.
Why client-provided requirements force real investigation
When the client provides the requirements, something different happens. The client is describing their actual need from their own position, without the design solution space design engineers already carry in their heads. This forces a genuine investigation into what issue is actually being resolved, because the requirement did not arrive pre-shaped by an assumed answer. It arrived as a description of a need, which is exactly what a requirement is supposed to be.
The distinction itself
A requirement states what must be achieved. A specification states how it will be achieved. These are different documents serving different purposes, and confusing who authors each one is what causes them to blend together into something that looks like a requirements document but has quietly become a specification wearing the wrong label.
Why requirements still drift, even from the right source
Requirements originating correctly from the client are not automatically safe from drift. If they are not weighted, treating every stated need as equally important, the requirements set can still miss what actually matters most to resolving the underlying issue. A client may state ten needs, but if none of them are weighed against each other for how central each one is to the real problem, the resulting design can satisfy all ten on paper while still failing to resolve what actually mattered. Weighting is not something design adds later. It has to be part of how the requirements themselves are understood from the outset.
The connection to understanding the need
This extends a point already established, that a requirement should come from genuinely understanding the need, not from a mental picture of the eventual design. Here, the same principle applies to a specific and practical question, whose hands does the requirement pass through first. A requirement authored by the function that will also design the solution has already passed through a filter shaped by what that function knows how to build.
What the resolved structure actually looks like
The client owns the requirements, describing what must be achieved and weighting those needs by how central each is to the actual issue. Design owns the specifications, describing how the solution will be achieved, but only after being checked and weighed specifically against those client requirements. This is not design working independently and retrofitting its output to look compliant afterward. It is design working from a requirement it did not author, testing its own specification honestly against a target it did not get to shape.
How to test whether the separation is holding
The same test already established for spotting a requirement that has quietly become a design decision applies here directly. Would this requirement still make sense if a completely different design solution were chosen. If the answer is no, the requirement was never really describing the client’s need. It was describing an assumed solution, most likely one that arrived from the design function that should never have been the one writing it in the first place.