2.3 Requirements Classification Schema
For the purposes of the BABOK® Guide, the following classification schema describes requirements:
- Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.
- Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.
- Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:
- functional requirements: describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage, and
- non-functional requirements or quality of service requirements: do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
- Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.
2.4 Stakeholders
Each task includes a list of stakeholders who are likely to participate in the execution of that task or who will be affected by it. A stakeholder is an individual or group that a business analyst is likely to interact with directly or indirectly. The BABOK® Guide does not mandate that these roles be filled for any given initiative. Any stakeholder can be a source of requirements, assumptions, or constraints.
This list is not intended to be an exhaustive list of all possible stakeholder classifications. Some additional examples of people who fit into each of these generic roles are listed in the definitions below. In most cases there will be multiple stakeholder roles found within each category. Similarly, a single individual may fill more than one role.
For the purpose of the BABOK® Guide, the generic list of stakeholders includes the following roles:
- business analyst,
- customer,
- domain subject matter expert,
- end user,
- implementation subject matter expert,
- operational support,
- project manager,
- regulator,
- sponsor,
- supplier, and
- tester
2.4.1 Business Analyst
The business analyst is inherently a stakeholder in all business analysis activities. The BABOK® Guide presumes that the business analyst is responsible and accountable for the execution of these activities. In some cases the business analyst may also be responsible for performing activities that fall under another stakeholder role.
2.4.2 Customer
A customer uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet.
2.4.3 Domain Subject Matter Expert
A domain subject matter expert is any individual with in-depth knowledge of a topic relevant to the business need or solution scope. This role is often filled by people who may be end users or people who have in-depth knowledge of the solution such as managers, process owners, legal staff, consultants, and others.
2.4.4 End User
End users are stakeholders who directly interact with the solution. End users can include all participants in a business process, or who use the product or solution.
2.4.5 Implementation Subject Matter Expert
An implementation subject matter expert is any stakeholder who has specialized knowledge regarding the implementation of one or more solution components.
While it is not possible to define a listing of implementation subject matter expert roles that are appropriate for all initiatives, some of the most common roles are: project librarian, change manager, configuration manager, solution architect, developer, database administrator, information architect, usability analyst, trainer, and organizational change consultant.
2.4.6 Operational Support
Operational support is responsible for the day-to-day management and maintenance of a system or product.
While it is not possible to define a listing of operational support roles that are appropriate for all initiatives, some of the most common roles are: operations analyst, product analyst, help desk, and release manager.
2.4.7 Project Manager
Project managers are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project’s objectives are met while balancing the project factors including scope, budget, schedule, resources, quality, and risk.
While it is not possible to completely define a listing of project management roles that are appropriate for all initiatives, some of the most common roles are: project lead, technical lead, product manager, and team leader.
2.4.8 Regulator
Regulators are responsible for the definition and enforcement of standards. Standards can be imposed on the solution by regulators through legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency. Alternate roles are government, regulatory bodies, and auditor.
2.4.9 Sponsor
Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed and control the budget and scope for the initiative. Alternate roles are executive and project sponsor.
2.4.10 Supplier
A supplier is a stakeholder outside the boundary of a given organization or organizational unit. Suppliers provide products or services to the organization and may have contractual or moral rights and obligations that must be considered. Alternate roles are providers, vendors, and consultants.
2.4.11 Tester
Testers are responsible for determining how to verify that the solution meets the requirements defined by the business analyst, as well as conducting the verification process. Testers also seek to ensure that the solution meets applicable quality standards, and that the risk of defects or failures is understood and minimized. An alternate role is quality assurance analyst.
2.5 Requirements and Designs
Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of business analysis. However, it is important to recognize that business analysts are also responsible for the definition of design, at some level, in an initiative. The level of responsibility for design varies based on the perspective within which a business analyst is working.
Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle.
The classification as a requirement or a design may become less significant as the business analyst’s work progresses to a greater understanding of and eventual fulfillment of the need. The tasks in the BABOK® Guide such as Trace Requirements (p. 79) or Specify and Model Requirements (p. 136) may refer to requirements, but the intent is to include designs as well.
Business analysis can be complex and recursive. A requirement (or set of requirements) may be used to define a design. That design may then be used to elicit additional requirements that are used to define more detailed designs. The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the designs. Whether it is the business analyst or some other role that completes the designs, the business analyst often reviews the final designs to ensure that they align with the requirements.
The following table provides some basic examples of how information may be viewed as either a requirement or a design.
| Requirement | Design |
|---|---|
| View six months sales data across multiple organizational units in a single view. | A sketch of a dashboard |
| Reduce amount of time required to pick and pack a customer order. | Process model. |
| Record and access a medical patient’s history. | Screen mock-up showing specific data fields. |
| Develop business strategy, goals, and objectives for a new business. | Business Capability Model. |
| Provide information in English and French. | Prototype with text displayed in English and French. |
Table 2.5.1: Requirements and Design
Stakeholders may present a need or a solution to an assumed need. A business analyst uses activities found in Elicitation and Collaboration (p. 53), Strategy Analysis (p. 99), Requirements Analysis and Design Definition (p. 133), and Solution Evaluation (p. 163) to transform that request into a requirement or design. Regardless of the focus of the stakeholder, the importance of the role of the business analyst lies in continuously asking the question “why?”. For example, “Why is either the requirement or design necessary to provide value to an enterprise and to facilitate the realization of an enterprise’s goals and objectives?”
