Kinds of requirements

In short: BABOK sorts requirements into four kinds: business (why), stakeholder (what a group needs), solution (what the system does and how well) and transition (how to get from the old to the new). Constraints are not needs but limits.

Problem

Everything in one list

After the meeting with the owner the notes look like this:

1. Repeat orders up by 15 %.
2. The customer can see their old orders.
3. An "Order again" button next to each order.
4. The page opens fast.
5. Old orders are moved over from the current system.
6. Ready by 1 December.

Everything is a "requirement". But the first is checked six months later with a sales report, the third with a test of the screen, the fifth once and never again, and the sixth with a calendar. Mix them up and you will not know which to check when, or how.

The idea

What a requirement is

A requirement is a need someone has, or a capability or property the system must have to meet it. It is written so that it can be checked later.

Both parts matter. "A need" means there is a person and a reason behind every requirement. "Can be checked" means there will be a moment when someone says "yes, it is met" or "no".

More precisely, if you are curious

IREB CPRE gives a three-part definition: a requirement is (1) a need perceived by a stakeholder; (2) a capability or property that a system shall have; (3) a documented representation of (1) or (2). The BABOK Guide v3 calls it a usable representation of a need. Both say the same thing: the requirement is the bridge between someone's need and the solution.

The idea

The four kinds in BABOK

BABOK sorts requirements from "why" down to "how exactly":

Kind	Answers	In the shop
Business requirement	why we make the change	Repeat orders grow by 15 % by the end of the year.
Stakeholder requirement	what one group needs	The customer easily finds what they ordered before.
Solution requirement, functional	what the system does	The customer sees their previous orders and reorders with one button.
Solution requirement, non-functional	how well it does it	The list of orders opens in under 2 seconds with 200 orders.
Transition requirement	how to get from the old to the new	Orders from the last two years are moved over before the new system goes live.

You already know functional and non-functional. They are the two halves of solution requirements. BABOK also calls non-functional requirements quality of service requirements.

Transition requirements are temporary: after the launch they are gone. That is why they are easy to forget, and without them the new system starts without the old data and with a support team that does not know the new screen.

More precisely, if you are curious

In the notes from the start: 1 is a business requirement. 2 is a stakeholder requirement (the customer's). 3 is a functional solution requirement, and really a proposed solution for 2. 4 is non-functional but has no measure yet: "fast" needs to become a number. 5 is a transition requirement. 6 is a constraint.

Other sources split things differently. IREB CPRE has three kinds: functional requirements, quality requirements (the non-functional ones) and constraints. "User requirement" is a common phrase at work. It usually means the stakeholder requirement of whoever uses the system.

Try it

Which kind is it?

1. Repeat orders grow by 15 % by the end of the year.

Solution requirementStakeholder requirementBusiness requirement

2. Accounting needs to see the total discount per promo code for the month.

Stakeholder requirementBusiness requirementTransition requirement

3. The system refuses a promo code the customer has already used in a paid order.

Solution requirement: non-functionalConstraintSolution requirement: functional

4. The monthly report opens in under 5 seconds when it holds a full year of orders.

Solution requirement: functionalBusiness requirementSolution requirement: non-functional

5. The open orders from the old system are moved to the new one before it goes live.

Stakeholder requirementSolution requirement: functionalTransition requirement

6. Support is trained on the new order cancellation screen before it goes live.

Solution requirement: non-functionalBusiness requirementTransition requirement

7. Payments go only through the bank the shop has a contract with.

ConstraintBusiness requirementSolution requirement: functional

Check

The idea

Constraints

Some statements do not say what someone needs, but what the solution has to fit into:

• deadline and budget: by 1 December, for 20,000 €;
• law: the 14-day right of return from receipt, the protection of personal data;
• contract: payments go only through the bank the shop has a contract with;
• existing systems: the courier accepts the address only in its own format.

This is a constraint. It is usually not up for negotiation: it was there before the project started. But it is checked too, it is forgotten too, and so it is written down.

The idea

Goal versus solution

In the previous lesson the accountant asked for an Excel button, and the need was the monthly report. The same happens with every kind of requirement.

A goal says what must be achieved and can be checked without saying how. A solution says how. "The customer understands how much delivery will cost before paying" is a goal. "A "Delivery" line in the cart, above the "Pay" button, with the amount in bold" is a solution.

Solutions are not forbidden. At some point someone has to decide. It is dangerous when the solution is written down instead of the goal:

• the goal gets lost, and nobody can check whether the solution reaches it;
• better solutions are ruled out before anyone has seen them;
• the tester checks the button, not the need.

The check is simple. For every requirement ask "why?". If the answer is another requirement on the list, this one sits lower in the chain. If there is no answer, either the requirement is unnecessary or you have missed the goal.

Try it

Goal or solution?

1. "We want a red banner with a countdown to the end of the sale."

SolutionGoal

2. "The customer understands before paying how much delivery will cost."

GoalSolution

3. "The delivery cost is calculated in the browser, so it is faster."

SolutionGoal

Check

Exercise

The chain

1. From the goal to the screen. Solution requirements serve business requirements. Which serves which, and what else needs asking?

1. The business requirement is "Repeat orders grow by 15 % by the end of the year". Which solution requirement serves it?

The label is printed when the order is paidThe customer sees their previous orders and reorders one with a single buttonThe discount report is sent to accounting every month

2. The developer suggests that "order again" also puts products that are no longer available into the cart. Which requirement do you ask about?

A solution requirement: what happens to a product that is no longer availableA business requirementA transition requirement

Check

Test

Check yourself

1. What are the four kinds of requirements in BABOK?

Business, stakeholder, solution, transitionUser, system, test, productFunctional, non-functional, business, technical

2. What is true about transition requirements?

They are non-functional requirementsThey apply foreverThey are temporary: needed only while moving from the old to the new

3. "The shop must go live by 1 December, with a budget of 20,000 €." What is this?

A stakeholder requirementA functional requirementA constraint

4. Why does a business requirement have a number and a deadline?

So that after the launch you can check whether the change reached its goalTo look seriousBecause the developer wants it

Check

Start the lesson over

Related lessons

• Builds on: What quality is · Who has a say · How requirements are elicited
• Continues in: The good requirement · When a table is clearer · What a story is · The traceability matrix
• Tasks on this topic: Requirements