Requirements Classification: Business, Stakeholder, Solution, Transition
In short The BABOK® Guide sorts requirements into four types: business, stakeholder, solution (split into functional and non-functional) and transition. Tagging each requirement with its type shows you what is missing and makes the chain from business goal to system feature traceable.
Based on: IIBA, BABOK® Guide v3, section 2.3; IIBA, Global Business Analysis Core Standard, ch. 1; K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 1 (for comparison).
On this page
Key ideas#
The classification schema first appeared in version 2.0 of the BABOK Guide and was kept in version 3. It sorts requirements by purpose and level of detail.
Business requirements#
These say why the change is happening: the goals the organization wants to reach and the results it expects. They can cover the whole organization, one business area or a single initiative, and they rarely mention a system.
Stakeholder requirements#
These describe what each stakeholder group must get, or be able to do, if the business requirements are to be achieved. They act as a bridge: business goals on one side, solution capabilities on the other.
Solution requirements#
These describe what the solution itself must do, and how well, so that stakeholder requirements are satisfied. The BABOK Guide splits them in two:
- Functional requirements cover behavior: the actions the solution performs and the data it works with.
- Non-functional requirements (also called quality of service requirements) cover qualities rather than behavior: how fast, how secure, how easy to use and how available the solution must be, and in what conditions it must keep performing.
Transition requirements#
These cover what is needed only while moving from the old way of working to the new one: converting data, training people, keeping the business running during cutover. Once the change is done, they expire. This type is the easiest to forget, because nobody will use it after launch.
Other ways to slice requirements#
The BABOK Guide is not the only classification. Wiegers and Beatty use business, user and functional levels plus non-functional requirements and business rules (see Levels and Types of Requirements). Other authors offer more detailed schemes (see A Conceptual Model of Requirement Types). The labels differ, but the idea is the same: separate why, what for whom, and what the solution must do.
How to apply it#
- Add a type field to every requirement. Use five values (business, stakeholder, solution-functional, solution-non-functional, transition) in your backlog, spreadsheet or requirements tool.
- Start at the top. Write business requirements first, even if only three or four. Without them you cannot judge whether a solution requirement is worth building.
- Link each level to the one above. Every stakeholder requirement should support at least one business requirement; every solution requirement should support at least one stakeholder requirement. Orphans are candidates for removal or a sign of a missing business goal. See Requirements Traceability.
- Check each stakeholder group. For each group on your stakeholder list, is there at least one stakeholder requirement? If not, you probably have not talked to them.
- Run a separate pass for non-functional requirements. They rarely come up unprompted. Use Non-Functional Requirements Analysis as a checklist.
- Plan transition requirements early. Ask: what data moves, who needs training, what happens on cutover day, how do we fall back?
Example#
The analyst at The Workshop, a fictional chain of 12 bike-repair workshops, tags the first set of requirements:
| ID | Type | Requirement | Traces to |
|---|---|---|---|
BR-1 |
Business | Halve front-desk phone calls about repair status within six months of launch. | — |
BR-2 |
Business | Reduce repairs delayed by missing spare parts. | — |
SR-1 |
Stakeholder (customer) | Customers can find out the status of their repair without phoning. | BR-1 |
SR-2 |
Stakeholder (mechanic) | Mechanics can update a job’s status in seconds from the workshop floor. | BR-1 |
SR-3 |
Stakeholder (manager) | Managers see which jobs are waiting for parts. | BR-2 |
FR-1 |
Solution, functional | The system sends a message to the customer when a job changes to “ready for collection”. | SR-1 |
NFR-1 |
Solution, non-functional | Status updates reach the customer within 5 minutes. | SR-1 |
TR-1 |
Transition | Open jobs on paper job cards are entered into the new system before go-live. | — |
TR-2 |
Transition | Front-desk staff in all 12 workshops are trained before go-live. | — |
Tagging shows a gap at once: there is a stakeholder requirement for mechanics (SR-2) but no functional requirement that implements it yet.
Pitfalls#
- Mixing levels in one statement. “Reduce calls by sending SMS from the booking system” is a business goal and a solution in one sentence. Split it.
- Skipping stakeholder requirements. Jumping from business goals straight to features loses the “who needs what” layer, and with it the ability to check coverage.
- Treating non-functional requirements as optional extras. Performance or security failures can sink a solution that is functionally complete.
- Forgetting transition requirements. Data migration and training are real work with real effort and risk.
- Arguing about labels. The type is a tool for completeness, not a debate topic. If a requirement fits two types, pick one and move on.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Section 2.3 (requirements classification schema).
- IIBA. Global Business Analysis Core Standard. International Institute of Business Analysis. Ch. 1 (same schema, condensed).
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 1 (an alternative classification).