本文来自笔者作为IBBA member自学BABOKv2的学习笔记：

----

第1章：简介Chapter 1:Introduction

1.1 What is the Business Analysis Body of Knowledge?

1.1 什么是业务分析知识体系指南？

“业务分析知识体系指南”是一个全球广泛认可的进行业务分析的实践标准。BABOK描述了业务分析的知识领域、相关的活动任务、以及有效执行这些活动任务的必备技能。

BABOK的主要目的是定义业务分析的专业标准。它作为业务分析工作者认可的一个标准，在此基础上，业务分析师们讨论他们的工作，确信他们自己具备有效承担业务分析角色所需要的知识和技能，也从业务分析师的同事及雇主的角度出发，定义他们所期望的一名娴熟的需求分析工作者展示出的知识和技能。BABOK是一个框架体系，它描述了业务分析要进行哪些必需的任务来帮助理解一个解决方案将如何为发起组织产生价值、使之受益。这些任务的构成形式、执行顺序、相应的重要性，以及其他特性，可能是灵活多变的，但是每个任务都在某些方面，直接或者间接地对总体目标做出贡献。

第一章提供对于业务分析领域关键概念的简介，描述BABOK指南其余部分的结构。第二章至第七章定义了业务分析师必须能够胜任执行的任务。第八章描述了能够进行高效能的业务分析的胜任资格，第九章描述了一系列被广泛接受的用于支持业务分析的技术。

1.2 What is Business Analysis?

1.2 什么是业务分析?

业务分析是一系列在相关干系人之间以联络者/桥梁方式开展工作的任务和技术的集合，从而让干系人能够理解组织的架构、政策和运营，并且提出能使组织达成其目标的解决方案。

业务分析包括理解组织是如何通过其具备的职能达成组织意图的，以及定义组织为了给外部干系人提供产品和服务，应该具备怎样的能力。它包括定义组织的战略目标、以及这些战略目标如何和具体目标相关联，决定组织应该采用什么样的行动路线来达成这些战略目标和具体目标，以及定义组织内外的各类组织单元和干系人是如何进行交互作用的。

业务分析可以被执行用来理解组织的现状，或者作为后续阶段识别业务需求的基础。然而在大多数情况下，业务分析被执行用来定义和验证解决方案是否符合业务需求、战略目标，或者具体目标。

业务分析师必须分析和综合由大量交互参与业务过程的人们提供的信息，例如客户、员工、IT专业人士、以及管理层。业务分析师要负责诱导、启发和获取干系人真正的实际需求，而不仅仅局限于他们表面上声称的愿望。在很多情况下，业务分析师的工作也能促进组织内各业务单元之间的沟通。特别地，业务分析师经常扮演一个中心角色，来整合业务部门的需求和信息技术部门的实际交付能力，以及在这两种部门之间充当“翻译员”。

一名业务分析师可以是执行业务分析活动的任何人，不论他们的头衔或者组织角色是什么。业务分析工作者不仅包括工作头衔是业务分析师的人，也包括诸如业务系统分析师、系统分析师、需求工程师、过程分析师、产品经理、产品拥有者、企业分析师、业务架构师、管理咨询顾问、或者其它任何执行在BABOK指南中提到的任务的人，包括执行相关工作的人，例如项目管理、软件开发、质量保证、以及交互界面设计师。

1.3 Key Concepts

1.3 关键概念

1.3.1 Domains 问题域

问题域是进行业务分析的领域，可能和组织或者组织部门的边界相对应，也可能包括在这些边界外的关键干系人，以及和这些干系人之间的交互活动。

1.3.2 Solutions 解决方案

一个解决方案是针对组织现状而做出的一系列变化的集合，从而使该组织能满足一个业务需要，解决一个问题，或者从某个机会中受益。解决方案的范围通常小于它被实施时所处的问题域的范围，它也作为实施该解决方案及其组件的项目范围的基础。

大多数解决方案是一个由交互作用的组件构成的系统,每个组件从其自身方面来说都是潜在的解决方案。解决方案和其组件的例子包括：应用软件、web服务、业务流程、业务规则(管理所辖业务流程)、信息技术应用、重组的组织机构、外包、内包、工作角色重定义，或者其他任何能产生组织需要的能力的方法。

业务分析帮助组织在其运营约束条件下(包括时间、预算、规章制度，等等)，定义针对自身需求的，最优化的解决方案。

1.3.3 Requirements 需求

所谓“需求”是：

1.3.3.1干系人为了解决某个问题或者达到某个目标而需要具备的一种条件或者能力。

1.3.3.2 为了满足合同、标准、规格，或者其他正式生效的文件，相应的解决方案或其组件必须达到或者具备的一种条件或者能力。

1.3.3.3 以文档化的形式对上述条件或者能力的陈述。

如同定义隐含的事实，一个需求不一定是明示的，可以由其他需求隐示或衍生出的，或者是被直接陈述和管理的。业务分析的关键目标之一就是确保所有的需求都是可见的并且被所有的干系人理解。

所谓“需求”这一术语，也是在业务分析业界中产生了众多讨论和争议的一个名词。很多争论集中在什么应该被当作需求，什么不应该被当作需求，以及一个“需求”所应该必备的特征属性是什么。当读者阅读BABOK指南时，不管怎样，从最广泛的共识出发来理解“需求”对你来说是至关重要的。需求包括但不限于企业中过去、现在和未来的条件和能力，以及组织架构、角色、过程、政策、规则、以及信息系统。一个需求可能描述企业现在和未来任何方面的状态。

大多数已有的关于业务分析的著作文献，都基于一个假设：所谓“需求”仅仅描述一个被考虑实施的IT系统。其它一些定义可能包括：业务功能未来的状态，或者将该术语的含义限制在干系人寻求达到的最终目标，而不是通过什么途径来达到这些目标。当然，所有这些不同的术语用途都是合理并且自圆其说的，BABOK指南对于“需求”这个术语的使用包括了上述含义，其实在这些文献里面“需求”的含义比在BABOK中对“需求”的用法更为狭小。

类似地，我们不假定“需求”应该被以何种特殊程度及细节加以分析，宁愿声称“需求”应该以能够被理解和行动的深度进行评估。在业务流程管理(BPM) 的语境中，“需求”可以是组织中在用的一个业务流程描述。而在其他一些项目上，业务分析师可能在研究满足变革业务现状所需要的方案之前，需要选择开发一种需求描述模型，来描述企业当前的状态(对于现有和过去的业务要求来说，这本身就是一个解决方案)。

1.3.3.3.4 需求分类模式

从BABOK指南的用途出发，我们把需求按照以下分类模式进行分类，以便描述：

>Business

Requirements 业务需求

业务需求是对目标，目的或者企业需求的较高层次描述。业务需求描述了一个项目启动的原因，项目将要达成的目标，以及如何衡量项目是否达成目标的指标。

业务需求从整体上描述组织的需求，而不是从组织内部的部分群体或者干系人的角度来描述需求。业务需求是通过“企业分析”过程来进行开发和定义的。

>Stakeholder

Requirements 干系人需求

干系人需求是一个或者一类特殊的干系人的需求的陈述。它描述了一个给定的干系人现在和未来，如何和解决方案之间进行交互的过程。干系人需求是业务需求和各式各样的解决方案需求之间的桥梁。干系人需求是通过“需求分析”过程来进行开发和定义的。

>Solution

Requirement 解决方案需求

解决方案需求描述了能够满足业务需求和干系人需求的一个解决方案的特征属性。解决方案需求是通过“需求分析”过程来进行开发和定义的。特别是当描述软件解决方案需求时，解决方案需求通常被分为一些子类：

>>Functional Requirements 功能需求

功能需求描述了解决方案将要管理的行为和信息。它们描述了系统在行为和

操作方面能够执行的能力-具体的IT应用的动作或响应。

>>Non-functional

Requirements 非功能需求

非功能需求用于描述并非和解决方案的行为或功能直接相关的条件，它用于描述系统在何种环境下仍然能够维持质量和有效性。它们也被认知为质量需求或者辅助需求。这些可能包括容量、速度、安全性、可用性，以及信息架构、用户界面展示友好性等。

>Transition

Requirements 迁移需求

迁移需求描述了解决方案必须具有的能力，用以促使企业从当前状态迁移到一个期望的未来状态，但是一旦迁移结束，迁移需求也就不复存在了。迁移需求和其他需求类型是不同的，因为它们总是临时性的，并且它们不等到现有解决方案和新解决方案都已经定义好，是无法被开发出来的。迁移需求的典型案例包括数据从已有系统转换到新系统，迁移后组织需要具备的新技能，以及为了达到期望的未来状态，其它需要做出的相关变化。迁移需求是通过“方案评估及验证”过程来进行开发和定义的。

（待续）

BABOK:业务分析知识体系指南（节选学习-01） BABOK:业务分析知识体系指南（节选学习-01）