Mathieu Gouanou's Foreword:
Tasks (IIBA® BABOK® v2.0)
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:
Purpose:
Each task has a purpose. Th purpose is a short description of the reason for a business analyst to perform the task and the value created through performing the task.
Description:
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 benefice 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. Th 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 defied 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.
Input:
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. Th 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.
Requirements:
Requirements are a special case as an input or output, which should not be surprising given their importance to business analysis. Thy 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 fist, 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.
Elements:
Th format and structure of this section is unique to each task. Th elements section describes key concepts that are needed to understand how to perform the task.
Techniques: (IIBA® BABOK® v2.0)
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 of the IIBA® BABOK® v2.0). 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 of the IIBA® BABOK® v2.0)
Stakeholders:
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 filed 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 fi into each of these generic roles are provided in the Generic stakeholders Figure below. In most cases, there will be multiple stakeholder roles found within each category. Similarly, a single individual may fill more than one role.
The 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. Th 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.
Generic stakeholders Figure:
Output:
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. Th 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.
Source for Business Analysis Tasks and Techniques: IIBA® BABOK® v2.0 or IIBA® BABOK® v3.0. For additional information, please visit http://www.theiiba.org.
IIBA® is a trademark owned by International Institute of Business Analysis.
Business Analysis Body of Knowledge® and BABOK® are registered trademarks owned by International Institute of Business Analysis.
No comments:
Post a Comment