Most software requests arrive as features: add a dashboard, add notifications, add an export button. Each one sounds like a requirement. None of them is. They are proposed solutions, and the problem that produced them has been left out of the sentence.
The difference
A requirement states what must be true for the business to work. A feature is one possible way of making it true.
- Feature: "We need a dashboard."
- Requirement: "The operations manager needs to know by 9am whether yesterday's orders were all fulfilled."
The second version admits solutions the first one hides — a scheduled summary message, an exception report that stays silent when everything is fine, or an alert that fires only when something is wrong. All are cheaper than a dashboard, and any of them may serve the actual need better.
Why building the feature as stated is risky
A feature delivered without its requirement can be built perfectly and still fail. It gets used twice and abandoned, and nobody can say why — because the condition it was meant to satisfy was never written down, so nothing can be measured against it.
Ask what becomes possible once this exists. If the answer is only "the feature exists", the requirement has not been found yet.
Getting from one to the other
Three questions usually recover the requirement behind a feature request: who needs this, what decision or action does it enable, and what happens today in its absence. The last one matters most — it reveals the workaround currently in use, and the workaround describes the real requirement more honestly than the feature request does.
This is how we build.
Cresslink engineers software products and custom systems for businesses. The principles we write about are the ones we work to.