What a Requirement Is, the Definition Most Engineers Use Wrong
Most documents labelled as requirements are actually early design decisions wearing a different name. That mislabelling is what causes the traceability and verification problems that show up much later.
A requirement should come from genuinely understanding the need. Too often it comes from something else entirely, a mental picture of what the eventual product will probably look like, written down as if it were the need itself. This is backwards, and it is the actual root cause of requirements documents that are full of design decisions wearing a different label.
Why the mislabelling happens
An engineer sitting down to write requirements rarely starts with a blank understanding of the need. They usually already have some idea of what the design will end up being, based on experience, on precedent, or simply on what has worked before. That mental picture then quietly shapes the requirement itself. Instead of writing what the system must achieve, the requirement ends up describing a particular component, a particular material, or a particular configuration, because that is what the imagined design already uses.
The requirement has now stopped being a requirement. It has become an early design decision, sitting in a requirements document, wearing the wrong name.
What a requirement actually is
A properly derived requirement states what the system must do or achieve. It says nothing about how. It stays true regardless of which design eventually satisfies it. Two completely different designs should be able to both claim compliance with the same well written requirement, because the requirement never constrained the solution in the first place, only the need.
The test
There is a simple way to check whether a statement is really a requirement or a design decision in disguise. Ask whether the statement would still make sense if the eventual design turned out completely different from what anyone currently expects. If the statement would no longer apply, or would need to be rewritten to fit the new design, it was never a requirement. It was a description of one particular solution, written too early and labelled incorrectly.
Why requirements must not shift during design
A properly derived requirement needs to hold firm once it is set. It should not be quietly adjusted as the design develops, and it should not be altered in the run-up to design freeze to better match whatever the design has already become.
This happens more often than it should. A requirement proves inconvenient partway through design. Rather than resolving the tension by changing the design, someone changes the requirement instead, bringing it into line with what the design already does. At that point the requirement has stopped functioning as a requirement at all. It is no longer protecting the original need. It has become a retrospective description of the design, adjusted after the fact to remove any apparent conflict.
How a stable requirement protects design intent
A requirement that was correctly derived from the actual need, and held stable through the design process without being quietly reshaped, does something important. It acts as a protective boundary around the original intent. It holds the design accountable to what was actually needed, even when schedule pressure, cost pressure, or simple convenience later make it tempting to relax or reinterpret what was originally asked for.
This is the real purpose of writing requirements down in the first place, not to describe a design that has not been chosen yet, but to fix the need clearly enough that the design can be tested against it honestly, at any point in the programme, without the target quietly moving to match whatever has already been built.
What happens when this discipline is absent
When a requirement has drifted into describing the design rather than the need, verification against it proves very little. The design is checked against a requirement that was shaped by the design itself. It passes, because it was always going to pass. What verification should be proving, that the original need has actually been satisfied, never gets tested at all. The gap stays invisible until the system is in service and the real need, the one the requirement was supposed to protect, turns out not to have been met.