Where Requirements Come From

Before a team can build anything, it has to answer a deceptively hard question: what should this software actually do? That knowledge — the set of things the software must do — is called the requirements. And it almost never arrives neatly written down. It starts scattered across users, customers, and half-formed ideas, and someone has to dig it out.

Finding and clarifying requirements is its own skill, often called discovery or requirements gathering. Done well, it's the difference between building the right thing and building the wrong thing beautifully.

Picture an architect before drawing a house. They don't start sketching; they interview the family — how many children, how they cook, whether they work from home. The drawings come after understanding the real needs. Requirements gathering is that interview, for software.

The Sources

Requirements come from many places at once: the users who'll actually use the software, the customers or business paying for it, the company's goals, support tickets and complaints about what exists today, and the wider market. No single source has the whole picture — part of the job is gathering from all of them and reconciling what they say.

Discovery Techniques

Teams have well-worn ways to draw requirements out: interviews with users and stakeholders, observing people doing the task today (watching often reveals what they forget to mention), quick prototypes to react to, and repeatedly asking "why" to get past a surface request to the real need beneath it. The goal is always to understand the underlying problem, not just transcribe the first solution someone names.

Stakeholders

A stakeholder is anyone with a stake in the outcome — users, the business, management, sometimes legal or support. They rarely want exactly the same things: a salesperson wants more features, a support lead wants fewer bugs, finance wants lower cost. Good requirements work surfaces these competing wishes early and balances them, rather than discovering the conflict halfway through building.

Turning Wishes into Requirements

The real craft is translation: turning a vague wish into something concrete and testable. "Make it easier to stay on track" is a wish — you can't build it or check whether you did. "Send users a reminder at a time they choose" is a requirement — specific, buildable, and you can tell when it's met. Moving from the first to the second, again and again, is what this whole phase is about.

When Priya starts on Cadence's next big improvement, she doesn't guess. She interviews a dozen early users and watches how they use the app. She expects to hear "add more habit types", but what she actually learns is that people simply forget to open the app at all. The real need isn't more features — it's a nudge. That discovery reshapes what the team builds next, and no amount of clever coding would have revealed it.