Each knowledge area describes the tasks performed by business analysts to accomplish the purpose of that knowledge area. Each task in the BABOK® Guide is presented in the following format:
Each task has a purpose. The purpose is a short description of the reason for a business analyst to perform the task and the value created through performing the task.
A task is an essential piece of work that must be performed as part of business analysis. Each task should be performed at least once during the vast majority of business analysis initiatives, but there is no upper limit to the number of times any task may be performed.
Tasks may be performed at any scale. Each task may be performed over periods ranging from several months in time to a few minutes. For example, a business case may be a document several hundred pages long, justifying a multi-billion dollar investment, or a single sentence explaining the benefit that a change will produce for a single individual.
A task has the following characteristics:
A task accomplishes a result in an output that creates value to the sponsoring organization---that is, if a task is performed it should produce some demonstrable positive outcome which is useful, specific, visible and measurable.
A task is complete---in principle, successor tasks that make use of outputs should be able to be performed by a different person or group.
A task is a necessary part of the purpose of the Knowledge Area with which it is associated.
The BABOK® Guide does not prescribe a process or an order in which tasks are performed. Some ordering of tasks is inevitable, as certain tasks produce outputs that are required inputs for other tasks. However, it is important to keep in mind that the BABOK® Guide only prescribes that the input must exist. The input may be incomplete or subject to change and revision, which may cause the task to be performed multiple times. Iterative or agile lifecycles may require that tasks in all knowledge areas be performed in parallel, and lifecycles with clearly defined phases will still require tasks from multiple knowledge areas to be performed in every phase. Tasks may be performed in any order, as long as the necessary inputs to a task are present.
The description of a task explains in greater detail why the task is performed, what the task is, and the results the task should accomplish.
An input represents the information and preconditions necessary for a task to begin. Inputs may be:
Explicitly generated outside the scope of business analysis (e.g., construction of a software application).
Generated by a business analysis task.
There is no assumption that the presence of an input or an output means that the associated deliverable is complete or in its final state. The input only needs to be sufficiently complete to allow successive work to begin. Any number of instances of an input may exist during the lifecycle of an initiative.
Figure 1-2: Task Input/Output Diagrams
Requirements are a special case as an input or output, which should not be surprising given their importance to business analysis. They are the only input or output that is not produced by a single task. Requirements can be classified in a number of different ways and exist in any of a number of different states. When listed as an input or output in this section of the task, the following format will be used to indicate the classification and state of a requirement or set of requirements:
Classification Requirements [State or States]. If no classification or states are listed, any or all requirements may be used as an input or output. For example, Requirements [Stated] means that the requirement may have any classification, whereas Business Requirements would mean that the business requirements may be in any possible state (e.g. verified, prioritized, stated, or combinations thereof).
States may also be combined in some cases. For example, Requirements [Prioritized and Verified] should be read to indicate that the requirements have been both prioritized and verified. Requirements [Prioritized or Verified] means that the requirements may be prioritized, verified, or both.
In general text, the state will be written first, followed by the classification (e.g. stated requirements, verified business requirements, etc.) Again, if no state or classification is indicated, it means that the requirement is not restricted to any particular state or classification.
The format and structure of this section is unique to each task. The elements section describes key concepts that are needed to understand how to perform the task.
Each task contains a listing of relevant techniques. Some techniques are specific to the performance of a single task, while others are relevant to the performance of a large number of tasks (and are listed in Chapter 9: Techniques). If a particular task can use both kinds of techniques, the ones found in Chapter 9 will be listed under a “General Techniques” subsection. If there are no subsections, then all techniques may be found in Chapter 9. For additional information, see Techniques (1.6).
Each task includes a listing of generic stakeholders who are likely to participate in the execution of that task or who will be affected by it. A generic stakeholder represents a class of people that the business analyst is likely to interact with in a specific way. 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, as it would simply not be possible to compile such a listing. Some additional examples of people who fit into each of these generic roles are provided in Figure 1-3. In most cases, there will be multiple stakeholder roles found within each category. Similarly, a single individual may fill more than one role.
Figure 1-3: Examples of Generic Stakeholders
Examples and Alternate Roles
Business Systems Analyst, Systems Analyst, Process Analyst, Consultant, Product Owner, etc.
Segmented by market, geography, industry, etc.
Broken out by organizational unit, job role, etc.
Project Librarian, Change Manager, Configuration Manager, Solution Architect, Developer, DBA, Information Architect, Usability Analyst, Trainer, Organizational Change Consultant, etc.
Help Desk, Network Technicians, Release Manager
Scrum Master, Team Leader
Providers, Consultants, etc.
Quality Assurance Analyst
Government, Regulatory Bodies, Auditors
Managers, Executives, Product Managers, Process Owners
.1 Business Analyst
By definition, the business analyst is a stakeholder in all business analysis activities. The BABOK® Guide is written with the presumption that the business analysis is responsible and accountable for the execution of these activities. In some cases, the business analyst may also be responsible for the performance of activities that fall under another stakeholder role. The most common roles to be assigned to business analysts, in addition to the business analysis role, are the Domain Subject Matter Expert, Implementation Subject Matter Expert, Project Manager, and Tester. Guidance on performing these additional roles falls outside the scope of the BABOK® Guide, as these roles are not part of the discipline of business analysis.
A customer is a stakeholder outside the boundary of a given organization or organizational unit. Customers make use of products or services produced by the organization and may have contractual or moral rights that the organization is obliged to meet.
.3 Domain Subject Matter Expert (SME)
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 will also be end users or people who will be indirect users of the solution, such as managers, process owners, legal staff (who may act as proxies for Regulators), consultants, and others.
.4 End User
End users are stakeholders who will directly interact with the solution. The term is most frequently used in a software development context, where end users are those who will actually use the software application that is being developed, but in the broader context of a solution they can include all participants in a business process.
.5 Implementation Subject Matter Expert (SME)
Implementation subject matter experts are responsible for designing and implementing potential solutions. The implementation subject matter experts will provide specialist expertise on the design and construction of the solution components that fall outside the scope of business analysis.
While it is not possible to define a listing of implementation subject matter expert roles that is appropriate for all initiatives, some of the most common roles are:
Developers are responsible for the construction of software applications. Areas of expertise among developers or software engineers include particular languages or application components. Good software development practices will significantly reduce the cost to build an application, the predictability of the development process, and the ability to implement changes in the functionality supported by an application.
Organizational Change Management Professionals
Organizational change management professionals are responsible for facilitating acceptance and adoption of new solutions and overcoming resistance to change. Areas of expertise among change management professionals include industry and cultural expertise. Good change management can help to create advocates for change within an organization.
System architects are responsible for dividing a software application into components and defining the interactions between them. Areas of expertise among system architects include understanding of methodologies and of solutions offered by specific vendors. Good system architecture will facilitate rapid development of solutions and reuse of components in other solutions.
Trainers are responsible for ensuring that the end users of a solution understand how it is supposed to work and are able to use it effectively. Areas of expertise among trainers may include classroom-based or online education. Effective training will facilitate acceptance and adoption of a solution.
Usability professionals are responsible for the external interaction design of technology solutions and for making those solutions as simple to use as is feasible. Areas of expertise among usability professionals include user interface designers and information architects. Good usability will increase productivity, customer satisfaction, and reduce cost in solution maintenance and training.
.6 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 constraints, including scope, budget, schedule, resources, quality, risk, and others.
Testers are responsible for determining how to verify that the solution meets the solution 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 of failures is understood and minimized.
Regulators are responsible for the definition and enforcement of standards. Standards may be those that the team developing the solution is required to follow, standards the solution must meet, or both. Regulators may enforce legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency.
Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize work to be performed and control the budget for the initiative.
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.
An output is a necessary result of the work described in the task. Outputs are created, transformed or change state as a result of the successful completion of a task. Although a particular output is created and maintained by a single task, a task can have multiple outputs.
An output may be a deliverable or be a part of a larger deliverable. The form of an output is dependent on the type of initiative underway, standards adopted by the organization, and best judgment of the business analyst as to an appropriate way to address the information needs of key stakeholders.
As with inputs, an instance of a task may be completed without an output being in its final state. The input or output only needs to be sufficiently complete to allow successive work to begin. Similarly, there may be one or many instances of an output created as part of any given initiative. Finally, the creation of an output does not necessarily require that subsequent tasks which use that work product as an input must begin.