A team watches someone repeat the same edit across 200 records. The requirement becomes: “Add bulk editing.”
But that's a proposed solution, not yet a justified requirement.
The person needs to make the intended changes accurately, without affecting other records, and with less repetitive effort. Bulk editing might accomplish that. So might a reusable rule, an import, or a different workflow that eliminates the repetition.
The distinction matters because requirements shape which solutions we consider. How we frame the problem shapes which requirements we consider necessary.
Too often, teams collect feature requests, call them requirements, and hand them to builders. They specify too much, distinguish too little, and mistake the length of the list for the quality of the thinking.
Good requirements follow from an understanding of the situation, a judgment about what should improve, and the conditions a solution must respect. Each should have a reason: a need to satisfy, an outcome to achieve, or a constraint to honor. Different designs may satisfy the same requirements. Some may make the original problem disappear.
This isn't merely documentation. It's design work. It requires understanding causes, deciding what matters, considering alternatives, making trade-offs, and testing whether the chosen design produces the intended change. Following a proposed design through real situations can reveal missing requirements, unintended consequences, and better ways to solve the problem.
A product can satisfy every stated requirement and still fail. Sometimes the implementation is wrong. Sometimes the requirements were. Sometimes the team chose the wrong problem.
Two related articles develop the reasoning: Uncovering the Causes of Demand examines how we understand the situation and identify opportunities. Design as Functions examines how we derive requirements, evaluate candidate designs, and test whether they work.
The point isn't to write more requirements. It's to make better judgments about what must be true, and why.