elicitation&collaboration

elicitation

key performance indicators KPI

metric = a quantifiable level of an indicator

=specific point, a threshold, a range

structure

reporting

1. business analysis: change

BA performance improvements

-analyzing performance

-determing assessment measures

-analyzing results

-recommending improvement actions:

preventive

corrective

improvement

BA info management:

-determining level of abstraction (breadth and depth of information being provided)

-planning traceability approach

-planning requirement reuse

-deciding on storage and access (repository)

-determining requirements attributes

item tracking

item record

governance:

• define decision making roles
• determine change control process
• planning prioritization approach
• planning approvals

estimation:

方法：

top-down

bottom-up

parametric estimation

rough order of magnitude(ROM)~top-down

rolling wave

Delphi:combining expert judgment

PERT: Optimistic+Pessimistic+(4 times Most Likely)/6

==============

Accuracy?

Sources of information:

Analogous Situation

Organization History

Expert Judgement

Precision and Reliability???

chapter 8

chapter 7

比重较高 30%

chapter 6

6.1 analyze current state

6.2 define future state

6.3 assess risks

6.4 define change 

知识领域

strategy analysis: 战略分析，定位问题

requirements analysis & design definition: 业务分析

solution evaluation:

前三者循环

===========

后三者同步进行

elicitation & collaboration：和干系人协作

requirements life cycle management: 需求管理

BA planning & monitoring

第七章 需求分析& 设计定义

一共里一个Task，第七章在本书和考试的比重超过30%

重要的是7.1，使用到了很多的模型，图文并茂的方式会更有效，输入是4.2、4.3收集到的原材料，输出是明确 的需求定义

7.2和7.3，Verify核实需求和Validate确认需求都有验证的意思，Verify审查需求，确保输出的需求符合质量的标准，符合组织的需求，也符合业界的标准，不要出现前后矛盾的情况，避免出现不准确的措辞等等，Validate确认需求的目的是从价值的角度确保需求是有业务价值的，这两项一不同的形式来进行，前者检查质量，后者有可能需要和需求的所有者进行探讨，确认需求的价值是否在解决方案的范围内，这两项有可能同时在做。

7.4 目的是为了输出的需求定义格式和形式，比如说有的干系人是需要文档，有的干系人需要流程图，每一种需求可以称为View，或者分析模型，加入到需求文档中

7.5和7.6 基于前边输出的需求进行设计的相关的活动，

7.5根据所确定的需求寻找备选的方案，与6.4不同的是。6.4的输出的内容也要考虑不同的解决方案（新的软件和新的流程），但是站在更高的维度和战略层面，但是7.5是站在更详细的维度更细节的设计层次，但是7.5也要以6.4的输出为输入内容，另外7.3确认的需求也作为输入内容，还有5.3中需求的优先级划分作为参考，输出的话呢，包括有哪些满足需求的备选方案和设计

7.6对备选方案和设计进行评估，那就需要备选方案，6.2中需要达成的最大的价值，这个时候也不是BA能够排版的，这个时候需要组织的管理层和干系人进行决定，注意到这里的7.6 的输出只是一个建议，而不是最终的决定

第六章，为整个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可能也需要一些技术背景，更好的理解开发设计和测试内容，不同的团队对于工作边界的定义不同