Choosing a BA Approach and the Requirements Classification Schema
Key Takeaways
- Predictive approaches define detailed requirements up front and manage change through formal control; adaptive approaches allow requirements to emerge and evolve iteratively.
- A requirement is a usable representation of a need, while a design is a usable representation of how that need will be met by a solution.
- The requirements classification schema in the BABOK Guide defines four categories: business, stakeholder, solution, and transition requirements.
- Solution requirements are divided into functional requirements, which describe system behavior, and non-functional requirements, which describe quality-of-service conditions such as performance or security.
- Transition requirements are temporary, addressing the gap between the current and future state, such as data conversion and training, and are retired once the transition is complete.
Choosing a Business Analysis Approach
Before eliciting a single requirement, a business analyst must decide, in partnership with the project's sponsor and delivery team, how the work of business analysis will be planned and performed. The BABOK Guide describes this choice along a spectrum anchored by two poles: predictive and adaptive approaches.
Predictive approaches, sometimes called plan-driven approaches and associated with waterfall or V-model delivery, assume requirements can be substantially understood and defined early, before design and construction begin. Requirements are documented in detail, formally reviewed, base-lined, and changed only through a controlled change process. Predictive approaches suit initiatives with stable, well-understood needs, low tolerance for late-stage change (for example, regulated or safety-critical systems), and stakeholders who are available for concentrated, up-front elicitation.
Adaptive approaches, associated with Agile, Scrum, or Kanban delivery, assume that the full solution cannot, and should not, be fully specified up front. Requirements are captured at a high level early, then progressively elaborated in short, iterative cycles as the solution is built and stakeholder feedback is gathered. Change is expected and welcomed rather than tightly controlled. Adaptive approaches suit initiatives with evolving or poorly understood needs, high uncertainty, and stakeholders who can engage continuously throughout delivery.
Choosing between them, or blending elements of both, depends on factors such as organizational culture, regulatory constraints, the stability of the business need, the team's experience with each approach, and the risk tolerance of the sponsoring organization. Neither approach is inherently superior; the task is to select the approach that fits the initiative's context, and a BA is expected to be able to justify that choice.
Requirements vs. Designs
The BABOK Guide draws a precise distinction that recurs throughout the exam: a requirement is a usable representation of a need -- it describes what is required, without prescribing exactly how it will be delivered. A design is a usable representation of a solution -- it describes how the need will actually be met, once options have been evaluated and a direction chosen. Both requirements and designs can exist at the business, stakeholder, or solution level, and analysis work often moves back and forth between the two: a stated need is refined into a requirement, several possible designs are evaluated against that requirement, and the chosen design may in turn surface additional, more detailed requirements. Recognizing whether a given statement describes a need (requirement) or a way of meeting that need (design) is a recurring situational-question pattern on the ECBA exam.
The Requirements Classification Schema
Requirements are not all the same kind of thing, and treating them as interchangeable causes confusion about ownership, level of detail, and who must approve them. The BABOK Guide's requirements classification schema sorts every requirement into one of four categories:
| Category | Describes | Answers | Example |
|---|---|---|---|
| Business requirements | Goals, objectives, and outcomes that explain why a change is being initiated | Why are we doing this? | "Reduce customer onboarding time by 30% within one year." |
| Stakeholder requirements | The needs of a specific stakeholder or stakeholder group that must be met to achieve the business requirements; bridges business and solution requirements | What does this stakeholder need? | "Branch staff need to open a new account without re-keying customer data already on file." |
| Solution requirements -- functional | The capabilities and behaviors a solution must have | What must the solution do? | "The system shall auto-populate the application form from the existing customer record." |
| Solution requirements -- non-functional | The quality-of-service conditions a solution must satisfy: performance, security, usability, availability, capacity | How well must the solution do it? | "The form shall auto-populate within 2 seconds of customer lookup." |
| Transition requirements | Capabilities needed only to move from the current state to the future state | What's needed just to get there? | "Legacy account records must be converted to the new data format before go-live." |
Business requirements sit at the top of the schema and are the least detailed but broadest in scope; solution requirements sit at the bottom and are the most detailed and narrowly scoped. Stakeholder requirements act as the connective layer that ensures the detailed solution requirements, once satisfied, actually add up to the business outcome that was wanted in the first place.
Transition requirements are distinct from the other three categories in one important way: they are temporary. Data conversion routines, parallel-run procedures, and training programs are only needed during the window between the old state and the new state; once the transition is complete, these requirements are retired and have no ongoing relevance to the operating solution.
How Requirements Evolve
Requirements do not appear fully formed; they evolve in specificity as an initiative proceeds, a process governed by the Requirements Life Cycle Management knowledge area. A business requirement, such as "reduce onboarding time," is progressively decomposed into stakeholder requirements describing what branch staff, compliance, and customers each need, which are further decomposed into solution requirements covering functional behaviors and non-functional conditions the system must meet, while transition requirements are identified wherever a gap exists between the current and future state. Throughout this progression, requirements are traced back to the business requirement that justifies them, so that scope changes, priority decisions, and impact analysis can always be connected back to the original business objective.
Exam Takeaway
Expect situational questions that give a single requirement statement and ask you to classify it correctly, whether business, stakeholder, functional, non-functional, or transition, or that ask which approach, predictive or adaptive, best fits a described project context. The fastest way to classify a requirement is to ask what question it answers: why points to business, who needs what points to stakeholder, what must the system do points to functional, how well points to non-functional, and only-until-launch points to transition.
A business analyst is assigned to a project with well-understood, stable requirements, strict regulatory documentation requirements, and stakeholders who are available for a concentrated elicitation period before development starts but not throughout delivery. Which business analysis approach best fits this context?
During requirements analysis for a new claims-processing system, the statement "the system shall process 500 claims per hour without performance degradation" is captured. Using the requirements classification schema, this statement is best classified as a: