PMBOK 2.0：敏捷扩展的业务分析知识体系指南

需积分: 7 45 浏览量更新于2024-07-24 收藏 2.07MB PDF 举报

《PMBOK Study Guide v2.0》是国际业务分析专业协会（International Institute of Business Analysis, IIBA）于2009年发布的第二版官方指南，专为项目管理专业人士（Project Management Body of Knowledge, PMBOK）扩展了商业分析领域的知识体系。该版本在原有PMBOK框架基础上，结合敏捷方法论，对商业分析实践进行了更新和完善。在本指南中，核心内容围绕“商业分析知识体系”（Business Analysis Body of Knowledge, BABOK）展开，强调了在现代项目管理环境中，商业分析师的角色与职责，以及如何有效地进行需求分析、战略规划、决策支持、沟通协调等工作。新版特别关注了与敏捷方法的集成，反映了在快速变化的商业环境中，灵活性和适应性的重要性。版本2.0包含了全新的内容和改进，旨在提升商业分析师的技能，使他们能够在不同类型的项目和组织中应用最新实践。此外，该指南引用了The Software Requirements Memory Jogger一书的部分词汇表，由Ellen Gottesdiener所著，经许可使用，为理解软件需求提供了额外的资源。封面图像来自iStockphoto.com/Damkier Media Group，展示了本指南的专业形象。版本的发布历史表明，从最初的1.0到2.0，经历了多次修订和完善，以保持与行业发展的同步。值得注意的是，读者在个人、职业或教育用途下可以复制这份文档，但只有购买了IIBA许可的用户才能转让所有权。对于IIBA会员而言，他们的免费副本不得转让。该指南主要作为教育工具提供，IIBA并不保证其适用于其他目的，并且不对文档的适用性做出任何明确或隐含的担保。《PMBOK Study Guide v2.0》是商业分析师必备的参考资料，它不仅巩固了传统项目管理的理论，还引入了敏捷思维，帮助分析专业人士在不断变化的商业环境中更好地支持项目成功。

A Guide to the Business Analysis Body of Knowledge®

Introduction

Tasks

Requirements would mean that the business requirements may be in any possible state

(e.g. veried, prioritized, stated, or combinations thereof).

States may also be combined in some cases. For example, Requirements [Prioritized

and Veried] should be read to indicate that the requirements have been both prioritized

and veried. Requirements [Prioritized or Veried] means that the requirements may

be prioritized, veried, or both.

In general text, the state will be written rst, followed by the classication (e.g. stated

requirements, veried business requirements, etc.) Again, if no state or classication

is indicated, it means that the requirement is not restricted to any particular state or

classication.

Elements1.5.4

e format and structure of this section is unique to each task. e elements section

describes key concepts that are needed to understand how to perform the task.

Techniques1.5.5

Each task contains a listing of relevant techniques. Some techniques are specic 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).

Stakeholders1.5.6

Each task includes a listing of generic stakeholders who are likely to participate in the

execution of that task or who will be aected by it. A generic stakeholder represents a

class of people that the business analyst is likely to interact with in a specic way. e

BABOK® Guide does not mandate that these roles be lled for any given initiative. Any

stakeholder can be a source of requirements, assumptions, or constraints.

is list is not intended to be an exhaustive list of all possible stakeholder classications,

as it would simply not be possible to compile such a listing. Some additional examples of

people who t 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 ll more than one role.

Business Analyst

By denition, the business analyst is a stakeholder in all business analysis activities. e

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. e 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.

BABOK® Guide, Version 2.0

Introduction

Tasks

Customer.2

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.

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. is role is often lled by people who will

also be end users or people who will be indirect users of the solution, such as managers,

process owners, legal sta (who may act as proxies for Regulators), consultants, and

others.

End User

End users are stakeholders who will directly interact with the solution. e 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.

Implementation Subject Matter Expert (SME)

Implementation subject matter experts are responsible for designing and implementing

potential solutions. e 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 dene a listing of implementation subject matter expert roles

that is appropriate for all initiatives, some of the most common roles are:

Developers/Software Engineers

Developers are responsible for the construction of software applications. Areas of

Figure 1–3: Examples of Generic Stakeholders

Generic Stakeholder Examples and Alternate Roles

Business Analyst Business Systems Analyst, Systems Analyst, Process Analyst,

Consultant, Product Owner, etc.

Customer Segmented by market, geography, industry, etc.

Domain SME Broken out by organizational unit, job role, etc.

End User Broken out by organizational unit, job role, etc.

Implementation SME Project Librarian, Change Manager, Conﬁguration Manager,

Solution Architect, Developer, DBA, Information Architect,

Usability Analyst, Trainer, Organizational Change Consul-

tant, etc.

Operational Support Help Desk, Network Technicians, Release Manager

Project Manager Scrum Master, Team Leader

Supplier Providers, Consultants, etc.

Tester Quality Assurance Analyst

Regulator Government, Regulatory Bodies, Auditors

Sponsor Managers, Executives, Product Managers, Process Owners

A Guide to the Business Analysis Body of Knowledge®

Introduction

Tasks

expertise among developers or software engineers include particular languages or

application components. Good software development practices will signicantly 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

System architects are responsible for dividing a software application into components

and dening the interactions between them. Areas of expertise among system architects

include understanding of methodologies and of solutions oered by specic vendors.

Good system architecture will facilitate rapid development of solutions and reuse of

components in other solutions.

Trainers

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 eectively. Areas of expertise among trainers

may include classroom-based or online education. Eective training will facilitate

acceptance and adoption of a solution.

Usability Professionals

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.

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.

Tester

Testers are responsible for determining how to verify that the solution meets the solution

requirements dened by the business analyst, as well as conducting the verication

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.

Regulator

Regulators are responsible for the denition 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 dened by organizational centers of

BABOK® Guide, Version 2.0

Introduction

Techniques

competency.

Sponsor.9

Sponsors are responsible for initiating the eort to dene a business need and develop

a solution that meets that need. ey authorize work to be performed and control the

budget for the initiative.

Supplier

.10

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.

Output1.5.7

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. e 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

nal state. e input or output only needs to be suciently 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.

Techniques1.6

Techniques provide additional information on dierent ways that a task may be

performed or dierent forms the output of the task may take. A task may have none, one,

or more related techniques. A technique must be related to at least one task.

e BABOK® Guide does not prescribe a set of analysis techniques that must be used.

e techniques described in this document are those that have been demonstrated

to be of value and in use by a majority of the business analysis community. Business

analysts who are familiar with these techniques are therefore likely to be able to perform

eectively under most circumstances that they are likely to encounter. However, these

techniques are not necessarily the best possible ones to use in any given situation, nor

are they necessarily able to address every situation eectively. Similarly, it is unlikely

that a business analyst will be called on to demonstrate expertise with every technique

dened in the BABOK® Guide.

A subset of the techniques in the BABOK® Guide can be described as being in widespread

use. ese techniques are in regular use by a majority of business analysts and see

occasional use by the vast majority of practitioners, and it is likely that many if not

most organizations will expect business analysts to have a working knowledge of these

techniques. e techniques that fall into this category are:

剩余270页未读，继续阅读

david027

粉丝: 0
资源: 9

PMBOK 2.0：敏捷扩展的业务分析知识体系指南

PMBOK指南第5版：项目管理核心知识

PMBOK指南：项目管理知识体系第4版解析

PMBOK 2008版PMP强化记忆手册详解

PMBOK_Guide6th_Chinese（中文无密码）_PMBOK_中文无密码_

PMBOK_GUIDE_5

PMBOK_Guide5th_Chinese

PMBOK.rar_PMBOK_pmbok project_project management_projectmanageme

PMBOK_Guide_第五版 和 第六版_中文高清合集

PMBOK.rar_PMBOK_project

PMBOK_2012_V5英文版

最新资源

PMBOK_Guide_第五版和第六版_中文高清合集