Types of Requirements: One Messy Kickoff List, Sorted Into Four Levels

There are four types of requirements in business analysis. Here they are as the BABOK Guide sorts them, each with one example from the project this series follows, FlexWell Gyms adding online cancellation to its member portal:

• Business requirements say why the project exists, as an outcome you can measure. FlexWell: cut bank-mandate cancellations from 31% to under 10% within two quarters of launch.
• Stakeholder requirements say what one group of people needs. FlexWell: members know their end date and final payment before they confirm.
• Solution requirements say what the system does (functional) and how well (non-functional). FlexWell: show the end date before confirmation, and render that screen within 2 seconds for 95% of visits under normal load.
• Transition requirements say what is needed only until the old way is switched off. FlexWell: load every frozen member's unfreeze date into the portal before launch.

The names are the easy part. The hard part is that nobody at a kickoff says which type they mean. At FlexWell's, "notice is 30 days" and "brief the branches" came out within a minute of each other. The first is a business rule, which is not a requirement at all. The second is a transition requirement that expires eight weeks after launch. Neither is something the developers build.

Below is the full kickoff list, thirteen lines in the order people said them, sorted line by line, then the four questions that sort any statement you meet.

The project in one paragraph

FlexWell Gyms runs 40 branches. Members cancel by phoning their branch or by cancelling their bank mandate, and bank cancellations, 31% of the total, leave the gym chasing failed payments. The fix is self-serve cancellation in the existing member portal, with one save offer before the member confirms. Retention owns the offer, and finance needs a clean final-payment calculation.

Written badly: the kickoff list

At the kickoff, the business analyst asks everyone in the room what the project needs and writes it all down. Retention, finance, branch operations and IT each add a few lines. This is the list at the end of the hour, in the order people said it:

1. We need to get bank cancellations down.
2. Members should be able to cancel without phoning anyone.
3. Show the member their final payment before they confirm.
4. Every member who tries to leave sees one offer. Not zero, not two.
5. The page has to be fast.
6. Notice is 30 days.
7. If billing is down, the cancellation still has to go through.
8. Brief the branches so they stop handling cancellations by phone.
9. Finance can't keep fixing final payments by hand.
10. Build it in the member portal we already have.
11. What happens to people who phoned to cancel before launch?
12. Freeze end dates only exist in the branch system.
13. Update the membership terms.

Nothing on this list is wrong. Every line is something someone in the room needs. The trouble is that the lines sit at different levels, and a list that mixes levels causes three kinds of problem.

• Each audience stops reading. A developer can't test line 1, and a director doesn't care about line 3. Put them in one list and both skim past half of it.
• The links between lines disappear. Line 7 exists because of line 9: finance can't fix payments by hand, so a billing failure has to be flagged for them, not left half-done. In a flat list nobody can see that, so when finance changes line 9, nobody knows line 7 has to change too.
• Some lines are not requirements at all. Line 6 is a rule the business already has. Line 13 is a task. Left in the list, they get estimated, prioritized and argued about like features.

Sorting the list fixes all three.

The four types of requirements

The BABOK Guide is the business analysis standard published by the IIBA. Other books use other names for the same four levels (Karl Wiegers, for example, calls the second one user requirements). Here is each type with the kickoff lines that belong to it.

1. Business requirements: why the project exists

A business requirement states the outcome the organization wants, in a form you can measure. It answers why anyone is spending money on this. It says nothing about screens, systems or features.

FlexWell has one:

BO-01: Reduce the share of cancellations arriving through bank-mandate withdrawal from 31% to under 10% within two quarters of launch, by giving members a self-serve online cancellation that is easier than cancelling at the bank.

Line 1 of the kickoff list becomes BO-01. "Get bank cancellations down" is a wish. BO-01 says from what, to what, and by when, so a year after launch someone can check whether the project worked.

A note on the labels in this series. We write business requirements as business objectives, with the prefix BO. The prefix BR is already taken: in this series BR means business rule, such as BR-01, the notice period. Both appear in every part, so it is worth fixing the difference now.

2. Stakeholder requirements: what each group needs

A stakeholder requirement states what one specific group needs from the change so that the business requirement can be met. Each one names who needs it. It still describes a need, not how the system meets it.

FlexWell has four:

SR-01: Members must be able to cancel online, know their end date and final payment before they confirm, and never need to phone.

SR-02: Retention must get exactly one save offer in front of every eligible member before the cancellation is final, never zero, never two.

SR-03: Finance must receive a final payment calculated per the notice-period rule, with no manual correction and no partial states.

SR-04: Branch operations must see fewer bank-mandate cancellations and fewer failed-payment chases.

Lines 2, 4 and 9 of the kickoff list become SR-01, SR-02 and SR-03. SR-04 is the branches' own version of BO-01: the same goal, stated in terms of their daily work.

Notice what these four do not say. None of them mentions a screen, a button or a service. "Know their end date before they confirm" is a need. How the portal shows it is the next level down.

3. Solution requirements: what the system does, and how well

Solution requirements describe the solution itself, and they split in two.

Functional requirements state what the solution must do: a behavior, observable from outside, that a tester can confirm. FlexWell has twelve, FR-01 to FR-12, written in full in the functional requirements post. Two of them come straight from the kickoff list:

• Line 3 becomes FR-03: before the member confirms, the system displays the membership end date, the final payment amount and date, and the date on which access ends.
• Line 7 becomes FR-09: when the billing service does not acknowledge the final payment in time, the system still completes the cancellation, flags the account for finance review, and tells the member that payment details will follow within one business day.

Non-functional requirements state how well the solution must do it: how fast, how available, how secure, under what load. Line 5, "the page has to be fast", becomes NFR-01: the consequences screen (FR-03) renders within 2 seconds at the 95th percentile under normal load.

The difference between line 5 and NFR-01 is a number and a condition someone can test. "Fast" can't fail a test. "2 seconds at the 95th percentile under normal load" can. Part 4 of this series writes FlexWell's full set of non-functional requirements.

The two halves also work together. FR-09 says what happens when billing is slow. NFR-03 says how slow counts as too slow: a proposed limit of 5 seconds for the billing service and 3 seconds for the offer service. Neither is complete without the other.

4. Transition requirements: needed only until the change is done

A transition requirement describes what it takes to move from the current way of working to the new one, and nothing after that. Its defining feature is that it expires. Once the old process is switched off and the data is moved, it is done, and nobody needs it again.

Three lines from the kickoff list become transition requirements:

TR-01: Cancellation requests received by phone or at a branch before go-live are completed through the existing branch process. The online flow handles only cancellations started after go-live.

TR-02: Before go-live, every branch receives a one-page briefing and a phone script that directs members to cancel in the portal, used for the first eight weeks after launch.

TR-03: Before go-live, the scheduled unfreeze date of every currently frozen membership is loaded from the branch system into the member portal, so that frozen members get a correct end date from the first day.

TR-01 answers line 11, TR-02 answers line 8, and TR-03 answers line 12. Without TR-03, the first frozen member to open the flow on launch day would see a wrong end date, because FR-12 calculates it from an unfreeze date the portal doesn't have yet.

Line 13, "update the membership terms", looks like it belongs here, because it has to happen before launch. It doesn't. The updated terms stay true for as long as online cancellation exists, and transition requirements expire. Updating the terms is a task in the project plan, owned by legal.

That gives you a quick test for any "before launch" item: if it is still true a year after launch, it is not a transition requirement.

What is not a requirement type

Three lines from the kickoff list don't fit any of the four types, and that is correct.

Business rules

Line 6, "notice is 30 days", is a business rule:

BR-01: Notice period is 30 days from confirmation, or from the unfreeze date for frozen memberships.

A business rule is true whether or not the project exists. FlexWell's notice period applied when members phoned their branch, and it will apply after the portal flow ships. The BABOK Guide treats business rules separately from the four requirement types for exactly this reason.

Requirements refer to rules instead of repeating them. FR-03 shows the end date "per BR-01". If FlexWell changes its notice period to 28 days, one rule changes and every requirement that cites it stays correct. Copy the 30 days into five requirements instead, and someone will update four of them.

FlexWell has two more rules: BR-02, at most one save offer per member per rolling 12 months, and BR-03, the final payment is pro-rated to the end date per the standard rate card, with frozen periods billed at the frozen rate.

Constraints

Line 10, "build it in the member portal we already have", is a constraint. It doesn't describe a need. It limits the ways the needs can be met. Record it once, as C-01, so nobody spends a week designing a separate cancellation site.

Tasks

Line 13 is a task, as covered above. It goes in the project plan, not the requirements.

Written well: the sorted list

Here is the kickoff list again, with each line's type, the requirement it became, and what that requirement traces to.

The last column lists each requirement's direct parent. The full trace, down to the use case steps, is in the specification PDF from the functional requirements post.

Read the last column and the flat list turns into a tree. BO-01 sits at the top. The four stakeholder requirements hang under it. The functional and non-functional requirements hang under the stakeholder requirements they serve. The transition requirements hang under whatever they protect on launch day. The rules sit to one side, cited wherever they apply.

That tree is what makes a requirements set maintainable. When finance changes SR-03, you follow it down and find every functional requirement that has to change with it. When someone proposes a new feature, you follow it up: if it doesn't trace to BO-01 through some stakeholder requirement, it isn't part of this project. Part 11 of this series turns the tree into a full traceability matrix.

Four questions that sort any statement

You won't always have a tidy kickoff list. Statements turn up in emails, workshop notes and support tickets. Ask these four questions in order, and the first yes tells you the type.

1. Does it state a measurable outcome the organization wants? Business requirement.
2. Does it state what a named group needs, without saying how the system does it? Stakeholder requirement.
3. Does it state what the system must do, or how well it must do it? Functional or non-functional requirement.
4. Will it stop being needed once the old way is switched off? Transition requirement.

If all four answers are no, it is something else: a business rule (true with or without the project), a constraint (limits the options), an assumption (believed but not confirmed), or a task (work to do, not a need). Write those down too, just not in the requirements list.

Mistakes that show up in real documents

A business requirement written as a feature. "BO-01: Provide online cancellation" describes the solution, not the outcome. If online cancellation ships and bank-mandate cancellations stay at 31%, the project has failed, and an objective shaped like a feature can't tell you that.

Stopping at the stakeholder level. SR-01 is a good requirement and a bad thing to build from. "Members must be able to cancel online" leaves every hard question open: who is eligible, what they see, what happens when billing fails. The functional requirements post needed twelve functional requirements to answer those questions.

Non-functional requirements written as adjectives. Fast, secure, user-friendly, scalable. None of them can fail a test, so none of them will be met on purpose. Every non-functional requirement needs a number and a condition.

Rules copied into every requirement. The 30-day notice period appears in the end date, the final payment, the confirmation message and the frozen-membership case. Write it once as BR-01 and cite it everywhere.

No transition requirements at all. They are the type most often missing, because nobody thinks about the old process until launch day. Then the first frozen member sees a wrong end date, and three branches are still taking cancellations by phone.

If you want more practice spotting the lines nobody says out loud at a kickoff, the requirements you will miss on your first BA project covers the questions that catch them.

Get the sorted inventory

Frequently asked questions

What are the four types of requirements in business analysis?

The BABOK Guide uses four: business requirements (the outcome the organization wants), stakeholder requirements (what each group needs), solution requirements (what the system does and how well, split into functional and non-functional), and transition requirements (what the change needs only until it is complete).

What is the difference between business requirements and functional requirements?

A business requirement states why the project exists, as a measurable outcome. A functional requirement states one thing the system must do, in a form a tester can confirm. FlexWell's BO-01 is a business requirement. FR-03, showing the end date and final payment before confirmation, is a functional requirement. Between them sit the stakeholder requirements that connect the two.

Are user stories a type of requirement?

No. A user story is a format, not a type. A story can carry a stakeholder need or a functional requirement, depending on how detailed it is. Part 9 of this series writes FlexWell's requirements as user stories with acceptance criteria.

Is a business rule a requirement?

Not in the BABOK sense. A business rule is true whether or not the project exists, such as FlexWell's 30-day notice period. Requirements cite business rules instead of repeating them, so a rule change is made in one place.

What is an example of a transition requirement?

FlexWell's TR-03: before go-live, the unfreeze date of every frozen membership is loaded into the member portal so frozen members get a correct end date from the first day. Once the data is loaded, the requirement is done for good, which is what makes it a transition requirement.

Next in the series

The functional requirements post takes the stakeholder requirements and writes the twelve functional requirements behind them, first badly and then well. Part 1, coming next, goes one step earlier: from FlexWell's problem to BO-01. The series overview lists every part.

Module 1 and your first Case Lab case are free. No card needed.