Many people struggle to tell the difference between business, stakeholder, and solution requirements. People keep asking for examples of a business requirement or a stakeholder requirement, so they can see the difference.

I’ve always found it most helpful to think of these as definitions that focus on a particular set of concerns. It’s not the way you state or model a requirement that makes it a business or stakeholder requirement. What matters is the audience.

A business requirement describes the concerns of people who fund the development of a solution. It’s not any requirement from a business user (those are stakeholder requirements). They tell a sponsor or senior executive what they are getting for their money. They care about:

  • what business outcomes you expect to deliver;
  • how the solution will deliver those outcomes (features and capabilities);
  • the business value you’ll generate or the risks you will address.

A stakeholder requirement describes the concerns of people affected by the solution. They may use an application, support a business process, or have to work with those who will. They tell those people how the solution will help them do their jobs and what they’ll be able to do that they can’t do today. They care about:

  • the capabilities and features of a solution;
  • how their business processes will change;
  • how the solution will get used.

A solution requirement describes the concerns of the people who will build and deliver the solution. It tells those people what the functional and non-functional requirements for the solution will be and how the solution will deliver on the business and stakeholder requirements. They want to know:

  • what they have to build;
  • where tradeoffs and alternatives to the envisioned solution are possible.

Don’t get hung up on categorizing your requirements and what type a particular requirement should be. Worry about what these different groups need. The classification will take care of itself.