Requirement types explained, and when to use each one

Ask three analysts what a "requirement" is and you may get three answers. Much of the confusion is about level, not meaning: some statements say why the change exists, some say what a person needs, and some say what the system must do. This glossary puts the common types side by side, with one question to help you choose.

The examples use Northgate Bank, a fictional firm, and one change: warning customers before they pay a new payee.

Last reviewed: October 2026.

The three levels

Business requirement. Why the organisation is making the change, in terms of an outcome it wants. Use it when you need the sponsor to agree the purpose before anyone designs anything. Example: "Reduce losses from payments made to fraudulent new payees."

Stakeholder requirement. What a person or group needs in order to do their job or reach their goal. Use it when you are capturing needs from interviews and workshops, before you know the solution. Example: "The fraud team needs to see which payments were held and why."

Solution requirement. What the delivered solution must do (functional) or how well it must do it (non-functional, such as speed, availability or security). Use it when the developers and testers need something exact to build and check. Example: "The system holds a payment above £10,000 to a new payee for up to 30 minutes."

A good set of documents lets you follow one thread from the business requirement down to the solution requirement and across to the test that proves it.

Statements that shape requirements

Business rule. A policy or decision the organisation already has, which the solution must obey. Use it when the answer should not change just because the system does. Example: "A new payee is one the customer has not paid before." Record rules once, with an owner, and refer to them from requirements.

Constraint. A limit on how you may deliver, such as a fixed date, budget, technology or regulation. Use it when you need to explain why an option is off the table. Example: "The change must go live before the January release freeze."

Assumption. Something you are treating as true without proof. Use it to make a guess visible so someone can confirm or correct it. Example: "We assume the fraud rules engine can already read the new-payee flag."

Ways to write requirements down

User story. A short statement from one user's point of view: who, what and why, with acceptance criteria. Use it when the team works in small increments and can talk to the user. Example: "As a business customer, I want a warning before I pay someone new, so that I can stop a payment I did not mean to make."

Use case. A step-by-step description of how a user and the system interact to reach a goal, including alternative and failure paths. Use it when the sequence matters, or when several systems or roles take part.

Functional specification. A fuller document describing what each part of the solution does. Use it when a team or supplier needs a complete, reviewable statement to build from.

Acceptance criterion. A condition that must be true for a requirement or story to count as done, written so a tester can pass or fail it. Use it for every requirement you expect anyone to test.

Ways to test them

Test scenario. A situation to check, such as "a customer pays a new payee £12,500". Use it to plan coverage before you write detailed steps.

Test case. The exact steps, data and expected result for one scenario. Use it when someone who did not write the requirement has to run the test.

Choosing quickly

1. Is this about why we are doing it? It is a business requirement.
2. Is it what someone needs to get their work done? It is a stakeholder requirement.
3. Is it exact enough to build and test? It is a solution requirement, and it needs an acceptance criterion.
4. Is it a policy that exists whatever the system does? It is a business rule.
5. Is it a limit on how you deliver? It is a constraint.
6. Are you not sure it is true? It is an assumption, and it needs an owner who can confirm it.

If a statement seems to fit two types, split it. "Customers must be warned within two seconds" holds a solution requirement (the warning) and a performance target that needs its own acceptance criterion.

Keep the thread visible

Whatever labels your organisation uses, the habit that matters is the same: every requirement says where it came from, who decided it and how it will be tested. The free requirements traceability matrix example shows that thread in a table, and acceptance criteria examples shows how to write the pass or fail conditions.

The Starter toolkit includes a Business Rules and Decision Table, an Open Questions Log and a Trace Register that keep these types apart.

See the Starter toolkit