第六章，为整个BA的工作设定方向

４个Task，为后续的工作的输入或者Guideline指导方针

6.1 第一个回去执行的活动，定义问题，对现状进行分析的过程当中，发现目前村子啊的问题、瓶颈、缺陷，首先需要分析Needs，另一个输入是4.3是一些概括续期的分析收集到一些原材料，6.1是一个隐含的需求分析。6.1则侧重从整个组织角度需要解决的问题和达成的目标，6.1输出Business Requirements，包含现状分析、现有的流程、组织架构、操作的方式，这里可以用到流程呢个模型、结构模型进行分析，另外显著那个的描述包括文字形式、图表的形式，最重要的一点是在现状的分析过程呢各种要发现要解决什么问题

6.2 在定义将来达成的期望状态。6.1和6.2配合起来，希望通过差别达成组织的改变，和达成的目标，例如需要达成成本较少多少，收入增加多少，输出包括三个：将来期望状态的描述，希望达成的目标，能够带来的价值是什么，例如用户满意度，收入增长，或者哪种方案能够带来更多的价值等等，后续很多领域第八章对解决方案做评价，第七章针对备选的方案进行筛选，都需要参考希望达成的目标为输入

6.3做风险的评估，在61.和6.2中涉及到的改变涉及到很多不确定因素，来自于本身BA工作目标达成带来的，也有来自于内外部的，比如监管机构的新的要求规定和改变，客户的新的要求，竞争对手的新的策略，都是一些不确定因素，Risk的输入时最多的

6.4定义解决问题的总的策略，2.0讲的是商业论证，通常是是一些潜在的解决问题的投入是否值得，可能还有多个投入的机会，在立项的时候把这个商业论证作为可行性研究的输入，可能会开发一个产品或路线图或服务，或者希望为组织定义新的业务模式，重新分析业务架构，以及长期规划的形式来呈现，或者企业层面的战略规划

总体来看，6.4是把前边所有的分析的结果做一个汇总，那么这个结果包括希望达成的商业目标、项目要解决的问题是什么、有哪些备选的方案、针对备选方案的可行性和成本效益的分析，基于这些分析给到建议，建议那种法案去解决问题，协商也论证的时候就要包含这些内容

6.4 的输出包括解决方案的策略或者战略，还有解决方案的范围，作为很多后续工作的输入或者guideline指导，看图

第五章　５个task

这五个任务基本上同步进行的，在需求管理中持续进行的活动，3章里边的输出作为本章的输入，这五个Task都包含需求和设计

5.1 Trace Requirements跟踪需求，还要关心需求和需求之间的关联关系，这个关联关系存在于需求和需求所在的其他团队的工工作内容，架构人员、开发人员、测试人员对于自己工作的内容与需求的关系，这些人也会跟踪需求，在项目过程当中，跟踪会有广义的含义，可以需求跟踪矩阵的建立和维护

5.2Maintain Requirement 需求维护，，需求方案如何做保存，Word和EXCEL

5.3需求可能得到有效的管理和维护，通过项目管理工具来查看需求的详细情况，查看优先级情况

5.4Assess Requirements 需求变更的评估，BA评估变更的价值大小，是否需要去批准，由谁来批准，当然这个规则是由3.3中规定出来，变更的评估会被提交到决策者来决定是否变更

5.5Approve Requirements批准需求，在3.3肿痛要制定了批准的流程、标准，比如通过邮件方式，以及正式和非正式的形式

第四章 一共5个Task

Elicitation包括4.1到4.3，还是按照执行顺序来工作的，涉及到很多Task，在手机需求的时候涉及到的访谈、问卷调查、需求研讨会、教练小组、原型观察方法，每一个方法在使用当中，都会使用到三部曲：4.1访谈准备工作，4.2访谈过程考虑 因素，4.3访谈后那些跟进的工作

4.1为进行的收集活动做准备，输入时了解Needs，很多药和干系人沟通，所以把3.2的作为输入

4.2为某次访谈计划列出的目的、范围、参与人员、需要问的问题，在执行当中可以做笔记、录音录像、白板记录等内容，这个结果的状态是未确认的状态，

4.3要完成把需求发给干系人进行确认，获得确认的结果，当然这个结果会作为后续分析的输入

4.4需求的沟通交流，保证在完成需求后，很多团队成员例如开发、测试，能够理解需求，所有干系人对需求的理解一致，它的输入包括BA Information和3.2干系人沟通的计划，广义的理解来说4.1到4.3来说更侧重从干系人获得信息，4.4更侧重给予干系人信息

4.5是说完成干系人的沟通计划，比如在某个时间点开始进行的讨论是否按时参加了，该干系人批准的是否批准了，以及干系人的态度发生变化，要分析和采取措施，解决干系人的问题，它的输入是要根据3.5实际BA的绩效来参考

总体看一下Task有哪些

在每个领域总有哪些Task(图)

need

为整个BA工作选择方法论，和整个工作的计划，前提条件是需要解决的问题是神恶魔，包括问题的特点导致我们采用什么样的方法

Approach可能是一个工作的计划，输出应该就是工作的计划，哪些工作，顺序是什么，应该由谁来完成，规划的范畴是BA的范畴，意味着有可能是详细的计划，也许是一个在头脑中的计划或考虑，未必有一个详细的输出（文档）

3.2、3.3、3.4都是在做计划

3.2要判断哪些干系人，要制定干系人然沟通计划，和干系人相关的活动，他的输入是BA Approach，输出干系人预计沟通工作计划

3.3BA计划的管理和控制，在规划过程前线要考虑BA计划的批准，批准人是谁，优先级的划分，谁参与优先级的划分，判断依据是什么，有可能会出现干系人的一些冲突，因此需要一个规划，另外包括需求变更，设计到需求相关的工作，那么如何进行，谁批准

第五章是生命周期管理，5.3、5.3、5.5这三个Task需要在执行过程中将3.3 Govemance Plan所制定的方法、流程或者标准

3.4 BA Information对需求管理的过程呢个进行规划，与3.3的差别是需要作业写批准判断的决策，3.4不需要做判断，，确定在什么地方对需求进行保存、分享、版本控制、需求的重用，做准备，在日常的管理当中，例如5.1和5.2需求跟踪和维护，例如需求变更导致的需求以来关系等等

3.2、3.3、3，4都需要3.1作为输入，就叫做需求管理计划的输入

3.2干系人需求管理沟通协作计划

3.3、3.4输出需求管理计划

3.5 对于BA工作的实际情况进行监督，并且在过程中发生的问题进行改进，需要3.1的输入，另外场外需要绩效考核目标的输入，如果出现问题需要进行分析，看看怎样解决实际的BA绩效的问题。3，5的输出作为3.1到3.4工作中的Guideline工具，指导每一项Task的改进。

输入：开始一项Task的时候需要用到的内容，有可能是其他Task的输出，也有可能BA工作的范围以外，比如风险信息，例如用户的担心、用户的并行工作导致的延迟等等的问题，每个章节都有输入输出，例如Solution，没有任何一个Task会输出这个内容，而是整个BA工作事对解决方案进行评价，或者需求

再开始一项工作前有输入才能开始，所以要确认开始前输入是存在的，但是并不要求这个输入完整，但是并不是完全收集完才能开始分析工作，足够启动分析的要求即可

输出：每项工作在执行当中执行的结果，可以是一个完整的交付成果（或者一个而文档），一次性的输出，也有可能采用滚动的方式，后续进行进一步的细化，有可能是新创建的，也有可能是对输入的加工

Guidelines and tools：在完成Task过程中的使用到的指导方针、策略、最佳实践、辅助工具，也许在过程中这些辅助工具不是必须的，但是最大的区别是输入必须有的

Stakeholders：有可能是个人或者一些人的类别，可能是影响我们工作的一些人，或者被我们工作影响的一些人，或者叫利益相关的人，虽然每个Task都有的stakeholds，但是再实际工作中，这些stakeholders必须出现，例如外部的供应商不是在每个环节都要出现的，而是是有可能出现的，所以根据实际的情况进行判断，再例如和预算假设相关的干系人

有以下类型的干系人：

1、BA   

2、客户（也许出现的人）、

3、Domain subject matter expert（SME）业务领域的专家，也许是某个部门的需求提供者 

4终端客户

5、implementtation subject matter expert实施端的主题专家（SME）包括开发人员、测试人员数据库管理者、培训人员、组织变革咨询顾问等等统称为实施端的主题专辑啊，如果不是一个软件项目甚至不只包括IT人员

6、Opeartional support，再实施方案的使用的情况下，一些运维人员，定期对系统进行维护和支持，例如呼叫中心

7、项目经理

8、regulator ：法律法规的制定者，比如本公司的法务部门、PMO等，外部的政府、银行、证监会等监管部门

9、Sponsor：发起人/赞助人，必要重要的作用，很多做决定例如批准需求的情况，就需要发起人

10、supplier：供应商

11、Tester：测试人员、或者质量控制人员

在实施过程中有可能语义上干系人打交道

其他的BA博客构成部分

1、基本能力，BA人员需要具备的技能、知识、方法

２、技术／方法，在工作中使用的方法

３、额外的参考，

六大知识领域，也是本书的核心内容

图，六大领域的相互关系，

1、Strategy Analysis战略分析，定义了问题的方向，非常重要

2、Requirement Analysis & Design Definition包括详细的需求的分析、定义，以及业务方面的设计和定义，无论项目层面和组织层面的，都是非常重要的内容

3、Solution Evalution：解决方案评价，需求变成实际的解决方案，需要一些架构人员和开发人员去识别和分析，这就存在一个问题，BA的界限，但是也要进行衔接，因为方案有可能遇到问题，导致问题又回到战略分析进行迭代分析和定义

4、同步进行的工作：Elicitation Collaboration，收集需求，这里是说因为再需求收集过程中，干系人也不清楚需求到底是什么，因此要对需求进行挖掘，和对干系人深入的识别、协作，进行就是说再进行1、2、3步的时候需要与感谢人同步沟通，

5、Requirement Life Cycle Management：在、1、2、3过程中都有可能产生新的需求以及改变旧有的需求，比如需求的批准，需求优先级的划分，就要考虑哪些先考虑，由谁参与优先级的划分，划分的标准，需求的重用怎样进行管理等等

6、Business Analysis Planning & Monitoring这里说的规划不只是工作或者项目刚开始阶段，随着工作的深入，进入下一步工作之前进行详细的规划，并且对效果进行详细的监控，评价规划的实际的绩效预期的差别，再使用方法帮助我们进行改进

-----------------------------------------------

在每个领域中有一组Task、目标是什么，描述是什么，指导办法、最佳实践和工具是什么（内容较多），输入、输出是什么，用到哪些方法，什么情况下使用到这个方法，Task的核心内容Elements，要记忆输入输出，更要想清楚之间的关系

Task：相对独立的工作，前期完成的工作完成后，后续的工作可以由另一个团队完成的，在规划的时候会有不同的考虑，并且是按照一定顺序，或者迭代的方式完成，或者同步的方式同时完成，但是没有严格意义的执行顺序，BABok并不是一个方法论，并不能按照死的步骤来完成工作，而是一个工具箱，按照合适的顺序或者选择来完成工作，但是输入输出是有一定先后关系的，但是有些工作也是同步进行的，考试里边可能会出现一类题，特定场景问下一步应该执行那一步操作，要根据上下文进行判断，Initiatives是说一个项目或者在组织中的以向任务，对现状的分析有可能是BA第一步工作，那么衡量一个方案的有效性也可能是BA工作的第一步

，

需求的分类：（四大类）

前三大类，需求的抽线程度

1、商务需求，整个企业和组织层面期望达成目标的所作的一个描述，不是某一个人或者某一类人所提的需求。

2、干系人需求，在了解整个组织的需求后，需要站在总体目标的前提下，进一步到具体组织和个人有哪些目的需要满足的，就是解决方案的用户。那不同的部门和干系人需要通力合作和协作。

关键按问题在于这类需求交付给开发团队，是否能够有成熟的方案直接实现，那么就存在以敏捷的方式还是瀑布的方式，瀑布的方式需要更详细的内容，包括用户业务流程

3.方案需求，解决方案的功能的能力和属性的总的集合，那么这样的方案交给实现团队，就能进一步实现需求的功能

前边的三个分类的界限在哪里，不好判断，视环境而变，最主要的是需求的收集、分析、定义不是一次性完成的，而是通过一种滚动、迭代逐步细化，最终完成一个详细的需求，刚开始可能是商业需求，例如刚开始收集需求的时候，如果过早的跳入到详细的解决方案的细节上面，就有可能之间树木不见森林，刚开始把关注点聚焦的整体的目标上，再进一步细化收集需求（干系人需求），再进一步分析方案需求

4、转换需求/过渡期需求：在解决方案的确认后，需要一些具体的方法，比如对人员进行一些培训，来适应设个方案，再例如一些数据的迁移的工作在解决方案的过渡过程中要实现的

4 的问题在于一般发生在转换和过渡后，后便再也不会用到，可以对一揽子过度需求进行打包，统一去实现

solution Requirement可分为：

功能性需求/非功能需求

----------------------------------------------

问题：需求/设计

Needs--Requirement<-->Designs--solution

Problem Owner--Business Analyst<-->Implementation SMEs--Solutions

例如：防盗系统接受密码输入，那么在设计过程中标表示成功，那么可以每输入一个数字是发出声音，这个声音有75赫兹，持续0.5秒钟

就是这样需求逐步过渡到设计，其中需求写到什么程度就算合适的标准，也要视情况而定

---------------------------------------------

需求作为设计的输入，但是在设计过程中也需要收集额外的信息，因此会产生一些迭代，实现团队也需要输出一些设计，再返回给BA进行确认，比如测试人员和开发人员在测试和开发设计的时候也会把输出成果反馈给BA进行确认，因此BA可能也需要一些技术背景，更好的理解开发设计和测试内容，不同的团队对于工作边界的定义不同

2.1 商务分析关键概念

核心概念模型，是说六个概念（图形表示），思考问题的基本的理念，思考问题的时候使用的系统化的思考，例如在有一个简单的问题并不是问题的本身，还会涉及到和这个问题相关的因素，

Needs一个问题或者机会

changes：针对问题，在组织层面去改变，去解决问题去开发和解决问题，在组织层面去应对，寻求某些改变

contexts：在考虑改变的过程当中，我们需要考虑相关的因素。包括内部和外部的因素，会影响到问题的解决，方案的选择，价值的交付

solutions：解决方案，在考虑内外部环境因素之后，用来解决问题也许是某一个特定的方法方式，当然在解决方案的过程中，考虑不止一个方案，需要进行评估

srakeholders：在工作中无论哪一个环节，都需要和我们的干系人进行协同和通过，在论问题的定义中，找到问题的所有者进行了解，要做一些改变，要是别要做哪些改变，在这些改变过程中给，哪些部门的干系人会受到影响或者施加影响，包括解决方案的设计和交付也会涉及到干系人，解决方案的提供也涉及到其他的干系人，另外组织内外部的很多人员和部门，以及部门构成也和干系人相关

Value：与其他的概念有很多关系，问题的解决要考虑价值的大小，解决方案也要考虑给予我们多大的价值，价值的交付是给不同干系人的，所以要考虑不同的干系人在衡量价值的有有不同的考虑问题的出发点，会有不同的分歧，同时价值的交付也考虑不同的因素

这个模型是需要在思考的过程中要考虑不同因素之间的影响和关系

关键点

商业分析信息

最重要的内容就是需求，3.0说不仅仅是信息了，elicitation results只是信息收集的内容，initiatives是经常看到的一个词，理解为行动，可能是在一个组织当中，或者一个项目当中，以及各种规格杨可能出现的情况，另外包含需求、设计、解决安敢选择、解决方案范围、改变策略。

比如BA信息的管理，

BA信息，BA信息的管理，适用范围更广

解决方案的设计

所谓设计的边界，在BA中按道理来说应该定义需求，而不是设计界面，但是也没有明显的分界，３.０版本中则需要设计，这里的设计是说更偏向业务层面的设计，但是技术方面的设计可能并不是很涉及到

需求

Needs是某个干系人的头脑当中，虽然它具体存在，但是并没有一个具体的呈现形式，如果你想把它作为解决方案设计和实施的输入，需要一个更具体的形式呈现出来，这个具体的形式可能是一个需求文档、故事形式、或者图表的方式呈现出来，就是Requirement

设计

更多的对于解决方案的架构设计、比如以文档、图形、模型的形式来呈现

Enterprice：一个或多个组织，那么这个组织是有一定的相关性，那么在目标的达成和工作过程有一定的需要一定的协作和发生一定关系，所以在在BA工作的时候，并不一定限于当前服务的组织，也包括组织以外的一些干系人和组织，也要考虑到

Plan：作为BA来讲，开始工作前，要考虑一些工作的依赖关系，以及需要的资源，使用到的一些方法，一般来说有详细的输出，保罗一些详细的列表和相关的计划信息，但是需要详细思考前后的先后顺序，第三章，会讲到是输出一个，严格意义上讲应该是，

Risk：在BA的过程中，在将来有可能发生的风险，或者叫风险，或者不确定问题，带来一些影响，这种影响可能是负面或者正面的，应该有不同的应对方法，3.0中认为Risk是负面的风险，正面的风险应该是opportunity机会

BABOOK的内容：

【商业分析领域的知识体系】

６大知识领域

目的：为这个领域提供一套被广泛接受的方法

CBAP　7500-10500工作经验 5+year

基于案例分析的试题

11个案例，3-4个问题，一共40多道题

1/3是案例题，2/3是基础知识题

AAC敏捷分析也包含在CBAP作为一部分较少的内容

机考

提交答案后即可出结果

在答题的时候，可以高亮部分阅读的内容，进行标记

考试前可以先熟练一下工具

3.5个小时

按照六个领域分别进行评分，然后再合计评估考试通过标准

系统性介绍BA book的内容

6大领域的输入输出,干系人,

商业分析或者叫业务分析

每个Task的输入输出，并且Task的干系人

BA是一些任务和技术，以及怎样应用到实际工作中，最终为组织产生价值，那么我们再要过程中发现问题，并且解决这些问题

6个核心概念

change：组织层面可能发生的一些改变，是因为需要利用某些机会或者解决某些问题

enterprice：组织，第二章详细解释，这个词超越了一般的组织，比如组织内和组织外，比如说供应商、顾客、竞争对手、行业监管机构等等，那么在解决方案中，这些因素都要考虑到

needs：需求或者需要，和requerment，是说在工作存在的客观的问题，或者某些机会，这些Needs需要我们需调研，那么需要和干系人进行询问问题，那实际上有些时候干系人所提的问题并不是真正的问题，那么就需要进行整理和梳理，进行详细的定义，画图或者画表格进行表述，让开发人员和项目组人员能够理解，并且进行讨论探讨，定义准确的需求

soluions：有了需求，我们需要针对需求设计实施我们的方案，另外一个recommending是指建议和推荐的意思，那么就是推荐方案，也就是说并不是实现和交付这个方案，而是只是为建议和推荐解决方案提供输入，也就是需求，可能有多个备选方案，那么要选出最佳的方案，并且在交付的结果中评估这个方案是否达到我们的目的，是否真的满足Needs，这个手也需要进行信息收集，进行比较，给到改进的建议，或者已经不满足当前的需要了，给出建议去淘汰或者更换方案，也是BA的工作内容，solutions，不仅仅是一个软件的解决方案，也许是一个流程的方案，或者部门岗位的定义，只要是用来解决问题就可以

value：不管是定义问题还是方案，都要体现一个价值的问题，价值足够大才能值得我们花费时间精力和资源去解决的，以及我们对不同方案进行评估的时候也要考虑 的问题。以及在BA过程中，项目经理和BA的任务不同，但是项目经理可能会考虑进度成本的因素，而BA可能考虑项目方案给客户带来的，以及本身提供的价值是否满足

stakeholders：干系人/相关方，比如在需求过程中打交道的各个方面的人员和部门，有课呢个会收到BA影响的，或者会影响BA工作本身的相关人员和部门，给我们提供资源和工作的支持的人员和部门

PBA和CBAP的差别：

PBA是吧BA纳入一个项目中，体现价值和过程写作的内容

二、BA有可能是项目中的BA，也有可能是组织当中的BA

三、BA的工作来说，涉及到组织的现状，以及将来达成的状态的分析，分析工作主要针对组织层面的流程、架构和运作方式进行分析

比如可以画流程图，用来分析现有的流程，或者来定义想来希望达成的流程

那么从现在到将来的这种改变就是所谓的change，BA来说，就是要定义这些改变需要在哪些领域需要发生，以及用那些方法来促进这些改变

第一单元：介绍基本背景

第二单元：介绍BA关键的内容

第三单元：

第六单元：战略分析

       先定义问题是什么，一项工作开始先要考虑的

第四单元：

第五单元：

从3-8单元为6大领域

第九章：基本能力，做好BA的动作，个人应该具备的能力（考题不多）

第十单元：篇幅较大，比较重要，比如说访谈，需要定义问题和发现问题，收集信息，会发现信息是有矛盾的等等

第十一单元：一种视角，作为BA可以参加到不同的团队，比如It团队，敏捷的方法，BI的领域，不同视角下对六大领域的裁剪，在特定领域完成BA的工作（篇幅较大，考题不多）

第十二单元：考试准备

干系人对优先级划分产生分歧

倾向于都划分为最高优先级

实施人员夸大技术难度，引入外部专家参与评判的过程

优先级划分持续性的过程

需求的变更

敏捷项目需求的优先级会变化频繁

评判的标准是什么？

标准可以随着过程的推进而变化

3.3 plan bussiness analysis governance

需求优先级的划分
 

适应型的会更加看重

（预测型的）

通常考虑的因素：

带来的业务价值，benefit

惩罚措施，penalty

成本（资源、工作量），cost 成本效益分析

风险（不能将风险高的留到最后，而应该优先分析和验证，实现，那么剩下的不确定会低，项目成功率大），risk 

有些技术风险是随着项目推进，逐步变小

有些是不变的

稳定性，会出现变更，稳定程度低的需求会往后一些

合规要求，带有时间限制，必须满足

干系人可以方便的获取到一致的需求

内容和属性进行管理

reuse需求，维护到需求仓库

保存和分享的机制，命名的方式

3.4的输出 information management approach 是5.1的 guidelines

业务规则作为独立的需求，在决策表中做详细定义，在需求中引用关联

功能分解、流程建模 =》不同抽象层次间需求的关联关系

实施团队

traced =》 加入了跟踪矩阵

validate requirements 有业务价值的，在解决方案范围内，可以通过trace来进行validation

减小scope creep 需求蔓延

Domain Subject Matter Exper (部门专家）

Strategy Analysis

Requirement Analysis & Design Definition

Solution Evaluation

Business Analysis | Planning & Monitoring

Requirement | Life Circle Management

Elicitation & Collaboration

Business Requirement: why a change has been initiated?

Stakeholders Requirement: a bridge between business and solution requirement.

Solution Requirement: capabilities and qualities of a solution that meets stakeholders' requirements.

--Fuctional Requirement

--Non-Fuctional Requirement

Transition Requirement:

BACCM-The Business Analysis Concept Model

Need--Change--Context--Solution--Stakeholders--Value

--Requirement (WHAT): A usable representation of a need.

--Design (HOW): A usable representation of a solution,

EX> User platform (Design) can be divers 

Enterprise>Organization

Risk: include uncertainty that brings negative outcome V.S. Opoortunity

from generalist to specialist to hybrid

"T" shape BA