|Published (Last):||19 November 2005|
|PDF File Size:||19.26 Mb|
|ePub File Size:||16.55 Mb|
|Price:||Free* [*Free Regsitration Required]|
No challenge to the status or ownership of these or any other trademarked terms contained herein is intended by the International Institute of Business Analysis. Any inquiries regarding this publication, requests for usage rights for the material included herein, or corrections should be sent by email to bok theiiba.
The Body of Knowledge Committee was formed in October of to define and draft a global standard for the practice of business analysis. That version included an outline of the proposed content and some key definitions.
Following the publication of version 1. Their comments were used to plan the scope of this revision. The content included in this release has been verified through reviews by practitioners, surveys of the business analysis community, and consultations with recognized experts in the field. Any set of practices must be tailored to the specific conditions under which business analysis is being performed.
As such practices become generally accepted, and as data is collected to verify their effectiveness, they will be incorporated into future editions of this publication. It serves as a baseline that practitioners can agree upon in order to discuss the work they do and to ensure that they have the skills they need to effectively perform the role, and defines the skills and knowledge that people who work with and employ business analysts should expect a skilled practitioner to demonstrate.
It is a framework that describes the business analysis tasks that must be performed in order to understand how a solution will deliver value to the sponsoring organization. The form those tasks take, the order they are performed in, the relative importance of the tasks, and other things may vary, but each task contributes in some fashion, directly or indirectly, to that overall goal. Chapters 2 through 7 define the tasks that a business analyst must be capable of performing.
Chapter 8 describes the competencies that support the effective performance of business analysis, and Chapter 9 describes a number of generally accepted techniques that support the practice of business analysis. Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.
Business analysis involves understanding how organizations function to accomplish their purposes, and defining the capabilities an organization requires to provide products and services to external stakeholders. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the courses of action that an organization has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact.
Business analysis may be performed to understand the current state of an organization or to serve as a basis for the later identification of business needs. In most cases, however, business analysis is performed to define and validate solutions that meet business needs, goals, or objectives.
Business analysts must analyze and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. It may correspond to the boundaries of an organization or organizational unit, as well as key stakeholders outside those boundaries and interactions with those stakeholders.
The scope of the solution is usually narrower than the scope of the domain within which it is implemented, and will serve as the basis for the scope of a project to implement that solution or its components.
Most solutions are a system of interacting solution components, each of which are potentially solutions in their own right. Examples of solutions and solution components include software applications, web services, business processes, the business rules that govern that process, an information technology application, a revised organizational structure, outsourcing, insourcing, redefining job roles, or any other method of creating a capability needed by an organization.
Business analysis helps organizations define the optimal solution for their needs, given the set of constraints including time, budget, regulations, and others under which that organization operates. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability as in 1 or 2.
As implied by this definition, a requirement may be unstated, implied by or derived from other requirements, or directly stated and managed.
One of the key objectives of business analysis is to ensure that requirements are visible to and understood by all stakeholders. Many of these debates focus on what should or should not be considered a requirement, and what are the necessary characteristics of a requirement. Requirements include, but are not limited to, past, present, and future conditions or capabilities in an enterprise and descriptions of organizational structures, roles, processes, policies, rules, and information systems.
A requirement may describe the current or the future state of any aspect of the enterprise. Much of the existing literature on business analysis is written with the assumption that requirements only describe an information technology system that is being considered for implementation. Other definitions may include future state business functions as well, or restrict the meaning of the term to define the ends stakeholders are seeking to achieve and not the means by which those ends are achieved.
Similarly, we do not assume that requirements are analyzed at any particular level of detail, other than to say that they should be assessed to whatever level of depth is necessary for understanding and action. In the context of a Business Process Management initiative, the requirements may be a description of the business processes currently in use in an organization. On other projects, the business analyst may choose to develop requirements to describe the current state of the enterprise which is in itself a solution to existing or past business needs before investigating changes to that solution needed to meet changing business conditions.
They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis.
They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements. They are developed and defined through requirements analysis. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.
They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined.
They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation. Business analysts are likely to perform tasks from all knowledge areas in rapid succession, iteratively, or simultaneously. Tasks may be performed in any order as long as the required inputs are available.
In principle, a business analysis effort may start with any task, although the most likely candidates are Define Business Need 5. Knowledge areas are not intended to represent phases in a project. It is certainly possible and permissible to proceed from performing enterprise analysis activities, to requirements analysis activities, to solution assessment and validation activities, and treat each as a distinct phase in a project. Business Analysis Planning and Monitoring Chapter 2 is the knowledge area that covers how business analysts determine which activities are necessary in order to complete a business analysis effort.
It covers identification of stakeholders, selection of business analysis techniques, the process that will be used to manage requirements, and how to assess the progress of the work. The tasks in this knowledge area govern the performance of all other business analysis tasks. Requirements Management and Communication Chapter 4 describes how business analysts manage conflicts, issues and changes in order to ensure that stakeholders and the project team remain in agreement on the solution scope, how requirements are communicated to stakeholders, and how knowledge gained by the business analyst is maintained for future use.
Enterprise Analysis Chapter 5 describes how business analysts identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. This knowledge area describes problem definition and analysis, business case development, feasibility studies, and the definition of solution scope.
Requirements Analysis Chapter 6 describes how business analysts prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders.
It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.
It also describes how business analysts assess deployed solutions to see how well they met the original need so that the sponsoring organization can assess the performance and effectiveness of the solution. Underlying Competencies Chapter 8 describes the behaviors, knowledge, and other characteristics that support the effective performance of business analysis.
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. 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.
Some ordering of tasks is inevitable, as certain tasks produce outputs that are required inputs for other tasks. 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.
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. 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. 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. 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.