Hello! Welcome to your second lesson.
In our first session, we established that a Business Analyst's core function revolves around eliciting, analyzing, and managing requirements to ensure a project delivers real value. Today, we'll dive into the heart of that function by learning how to classify those requirements.
Your goal for this lesson is to be able to distinguish between business, stakeholder, solution, and transition requirements. This isn't just theory; it's the fundamental framework BAs use to structure their thinking, guide conversations with stakeholders, and create clear documentation. Mastering this classification is essential for both excelling in a BA role and confidently answering key questions in your job interviews.
The Requirements Hierarchy: From "Why" to "How"
Before we look at each requirement type individually, it's crucial to understand that they are all connected in a logical hierarchy. Think of it as a pyramid or a top-down flow: you start with a single, high-level business goal at the top and progressively break it down into more detailed and numerous requirements.
This hierarchy ensures traceability—the ability to link a very specific feature in a software system all the way back up to the original business objective it's meant to achieve. As a BA, this is one of your most important responsibilities.
Now, let's explore each of these categories in detail. We'll start with a video that gives a clear overview.
What are the different requirement types in Business Analysis? Classification Schema | BABOK Study
This video, 'What are the different requirement types in Business Analysis?' from Business Analysis Excellence, provides a clear, BABOK®-aligned explanation of the requirements classification schema. It uses a helpful metaphor of building a house alongside a practical business example.
Please watch the introduction from 00:38 to 01:31 to understand why having a standard classification is so important.
As the video explains, using a standard set of terms ensures that everyone on a project—from executives to developers—is speaking the same language.
1. Business Requirements: The "Why"
Everything starts here. Business requirements define the high-level goals, objectives, or outcomes the organization wants to achieve. They answer the fundamental question: "Why are we doing this project?"
These requirements are not about software or systems; they are about business value. In your project management experience, you've likely worked with project charters or business cases that outlined these top-level goals.
What are the different requirement types in Business Analysis? Classification Schema | BABOK Study
Let's continue with the video to see how business requirements are defined.
Watch from 01:31 to 02:22. Notice how the requirement is a high-level goal, like 'transform the way they manage employee payroll processing'.
- Definition: A statement of a goal, objective, or outcome that describes why a change is being initiated.
- AdTech Example: An advertising platform's business requirement could be: "Increase customer retention by 10% over the next fiscal year by improving the campaign analytics tools."
2. Stakeholder Requirements: The "What"
Once the "Why" is clear, you need to understand what different stakeholders need in order to achieve that business goal. Stakeholder requirements bridge the gap between the high-level business vision and the specific solution. They answer the question: "What do our users need to be able to do?"
These requirements describe the needs of a particular stakeholder or group of stakeholders.
What are the different requirement types in Business Analysis? Classification Schema | BABOK Study
Now, let's see how stakeholder requirements connect to the business requirement.
Watch from 02:22 to 03:59. Pay attention to how the examples are from the perspective of a specific role, like 'As a payroll professional...' or 'As an employee...'
- Definition: The needs of stakeholders that must be met to achieve the business requirements.
- AdTech Example: Building on our previous example, a stakeholder requirement from a Media Buyer might be: "As a Media Buyer, I need to be able to compare the performance of different ad creatives side-by-side so that I can quickly reallocate budget to the best-performing ads."
3. Solution Requirements: The "How"
This is where we get specific about the solution itself. Solution requirements describe the capabilities and qualities of a system that will meet the stakeholder requirements. They answer the question: "How will the solution actually work?"
Solution requirements are divided into two crucial sub-categories: Functional and Non-Functional.
Functional Requirements
These describe the behavior and capabilities of the solution—what the system must do.
What are the different requirement types in Business Analysis? Classification Schema | BABOK Study
Let's explore what makes a requirement 'functional'.
Watch from 03:59 to 06:33. Notice that functional requirements describe specific actions or information the solution will manage, like 'add a new employee report' or 'print my payslip'.
- Definition: The capabilities the solution must have in terms of its behavior and the information it will manage.
- AdTech Example: To satisfy the Media Buyer's need, a functional requirement would be: "The system shall provide a 'Compare' button that opens a modal displaying the key performance indicators (KPIs) for selected ad creatives in a table format."
Non-Functional Requirements (NFRs)
These describe the qualities of the solution and the conditions under which it must operate—how the system must be. They are often called "quality of service" requirements or the "-ilities" (e.g., usability, reliability, scalability).
What are the different requirement types in Business Analysis? Classification Schema | BABOK Study
Now for the other side of the coin: non-functional requirements.
Watch from 06:33 to 08:13. These requirements aren't about specific actions but about qualities like performance, security, or availability.
- Definition: Conditions under which a solution must remain effective or qualities that a solution must have.
- AdTech Example: For the same analytics feature, NFRs could include:
- Performance: "The creative comparison report must load in under 3 seconds."
- Availability: "The campaign analytics dashboard must have 99.9% uptime."
- Usability: "A new user must be able to generate a comparison report with no more than 5 clicks."
4. Transition Requirements: The "How to get there"
Finally, transition requirements describe the temporary capabilities needed to move from the current state to the future state. They are essential for a smooth rollout but are no longer needed once the new solution is fully operational. They answer the question: "What do we need to do to make this change happen?"
What are the different requirement types in Business Analysis? Classification Schema | BABOK Study
Let's finish with the last category: transition requirements.
Watch from 08:13 to 09:24. The key idea here is that these requirements are temporary, like training or data migration.
- Definition: The capabilities and conditions needed to facilitate the transition from the current to the future state, which are not needed once the change is complete.
- AdTech Example:
- Data Migration: "Historical campaign performance data from the last 12 months must be migrated from the old database to the new analytics system before launch."
- Training: "All Media Buyers must complete a certified training module on the new analytics dashboard before their access is enabled."
Putting It All Together: A Practical Example
Understanding the definitions is one thing; seeing them work together is another. Let's look at a practical case study that ties all these concepts together.
BABOK: Requirements Classification Schema
This article, 'BABOK: Requirements Classification Schema' by Bandhavi Silveri, provides an excellent real-world example from a diagnostic laboratory project. It clearly shows how a single business goal cascades down into stakeholder, solution, and transition requirements.
Please read the section starting from 'A practical example of business requirements from the project I had earlier worked on' to the end of the article. As you read, trace the path from the high-level business goal down to a specific non-functional requirement.
Test your understanding!
Imagine your AdTech company wants to launch a new, AI-powered feature for automatically optimizing ad campaign bids. Below are several statements that have come up in initial meetings. Classify each one into the correct requirement type: Business, Stakeholder, Functional, Non-Functional, or Transition.
- "We need to increase the average client campaign ROI by 25% within six months of launch."
- "As a campaign manager, I need to be able to set a maximum daily budget for the AI to use, so I don't overspend."
- "The system must process bid adjustments in real-time (under 500 milliseconds)."
- "The system shall provide a toggle switch to enable or disable the AI optimization for any given campaign."
- "We need to migrate the bidding rules from our old rules-engine into a format the new AI can understand before we switch it on."
Show answer
- Business Requirement: This is a high-level, measurable business goal (increase ROI by 25%). It's the "Why."
- Stakeholder Requirement: This describes a specific need from a user's perspective ("As a campaign manager..."). It's the "What."
- Non-Functional Requirement: This describes a quality or performance constraint (speed). It's part of the "How."
- Functional Requirement: This describes a specific capability or action the system must perform (a toggle switch). It's also part of the "How."
- Transition Requirement: This is a one-time activity (data migration) needed to move to the new system. It's the "How to get there."
Conclusion
Congratulations on completing this lesson! You now have a solid, industry-standard framework for thinking about and categorizing requirements. This skill is foundational to every other business analysis activity.
Here are your key takeaways:
- Requirements have a hierarchy: They flow from Business (Why) -> Stakeholder (What) -> Solution (How) -> Transition (How to get there).
- Business Requirements are the high-level goals that drive the project.
- Stakeholder Requirements capture the needs of users to meet those goals.
- Solution Requirements detail the specifics of the system, split into Functional (what it does) and Non-Functional (how it performs).
- Transition Requirements are the temporary steps needed to implement the change.
Being able to correctly identify and articulate these different requirement types will make you a more effective BA and a more compelling candidate in interviews.
Preview of the Next Lesson:
We started at the top of the pyramid today with Business Requirements—the "Why." But how do you take a vague problem and turn it into a clear, actionable business requirement? In our next lesson, we will focus on exactly that. You will learn how to apply a problem statement framework to articulate business problems clearly, setting a solid foundation for any project.