完成估算 estimation任务的方法：

1 自上而下 对整体依据经验粗略估计

2 自下而上 详细分解工作，准确度较高，适合对详细非常了解的情况

3 参数法 根据指标（比如用例数量/页面数量）估计工作量级

4 拍脑袋 Rough order of magnitude

5 rolling wave 刚开始粗颗粒度，随着推进用更准确的估算方法

6 delphi 向专家收集信息，经多轮达成一致认可

7 pert 三点情况，估算最好/最差/最可能的情况，做计算。三种情况的权重不同，例：

估值=（最好+最差+最可能*4）/6

估算的准确性

不同的方法，有不同的准确性。自下而上的准确性最高，拍脑袋的准确性最低

估算信息的来源

1. 组织架构的知识库，经验教训

2.领域专家（内/外部）

3.自身过往经验

估算的精确度可靠性

1.一个方法的多次估算的结果差异是否小，如果小则精确度高

2.借助不同的方法估算，或者不同人分别评估。如果评估出的值相似，则准确度高

估算的人员

1.团队内部 比如项目经理

2.外部专家

完成经验教训任务的方法：

这个任务可以参考的工具：

访谈？？

组织规范/标准流程

专家判断

方法论/框架

干系人分析方法 了解干系人

需求分析工作计划

1.可交付的成果/工作成果

a. 定义：制定计划时，某个时间，向某个人干系人交付的成果

b. 围绕交付内容，具体分析需要的活动

2.确定每一项工作需要的时间/资源

a.干系人/团队人员的时间安排

b.优先级

c.预算

3.复杂性和风险

a.人员数量

b.变化规模

c.地理位置/文化差异/时区

d.技术复杂度

e.BA的风险

   BA的经验/领域知识

   干系人的沟通经验/态度/分配的时间

   文化不同

   影响力

   3.制定的计划

计划不仅影响到BA，也影响提供信息/知识的人，需要把计划告知到所有参与到BA活动的干系人，然后把BA工作结果告知到干系人，干系人可能需要批准。

总结瀑布方法论和敏捷方法论

预测型方法论 瀑布

适合情况： 需求已经有了正式批准

风险：提前分析风险

周期：长期交付

进度模式：一步一步完成

文档：正式，详细

需求变更：正式变更流程批准

沟通：正式会议

适应性方法论 敏捷

适合情况：在开始的时候对需求没有充足的了解，在过程中增项提升去达到现状的期望。

风险：高

周期：适应短期/快速交付

进度模式：迭代

文档：最少，概况

需求变更：需求变更是正常情况，非正式流程

沟通：非正式会议

3.1 plan business analysis approach 和 3.2 plan stakeholder engagement 同步进行

3.1 plan business analysis approach

输入：needs

输出：BA approach

Planning approach分成两类

predictive aprroaches预测性方法

比如说瀑布形的项目需要提前预测

adaptive approaches适应性方法

快速型交付价值，迭代式完成价值交付

瀑布模型 the waterfall model

需求=》设计=》实施=》验收=》维护

螺旋模型 the spiral model

每个迭代是个小型的瀑布

The Unified Process 介于瀑布和迭代模式

用例驱动：用于功能性需求的分析，测试验证

分析背景目标=》详细分析=》解决方案构建=》移交

agile methodologies-scrum 敏捷

角色：

产品负责人更解决BA

开发团队

敏捷教练 保证整个团队以敏捷的方式完成项目

工件：

产品未完项表，需求列表

冲刺列表 每次冲刺在1到4周

增量成果 直接让用户用或演示

燃尽图 了解当前项目的进展情况 用来衡量剩余工作的情况

仪式：

sprint planning meeting 当前sprint需要完成的工作/预算

daily scrum meeting 日会 总结前一天工作的情况/问题/难点

sprint retrospective 用户演示，团队回顾，经验教训总结

敏捷宣言：

个体及个体间的互动 而非流程

工作软件 而非文档

客户协作 而非合同谈判

应对改变 而非预先制定的计划

需求变更需要客户批准，邮件把需求变更发给客户，和客户沟通3天不回复，即默认同意

这个图是输入输出图，数据流向图

绿色箭头是输出

虚线箭头是指导方针

编号不是先后顺序

3.1 BA工作总体计划方法-》输出工作计划/考虑（可能是非实体输出）

3.2 干系人沟通计划 什么时间什么方式沟通

3.3 BA计划决策方式  比如说需求优先级 谁/以什么标准划分需求优先级，需求变更的流程/依据/批准人

3.4 BA信息管理 需求重用/需求依赖关系

输入的定义：开始一项任务需要具备的，转化为输出的条件。把输入改头换面后变成输出。是另外一项任务的输出。

可能来自于BA工作的以内和以外，包括用户的顾虑，干系人的态度。

以外：solution

输入可能是不完整，足够开始启动任务的要求即能启动任务。所有输入完整后，任务才能结束。

输出的定义：每项任务的结果，可能是在任务中新创建的，也可能是对输入的改头换面。

干系人：

BA

客户

业务专家

终端用户

实施专家

运维

项目经理

法律法规的制定人/监管机构，比如PMO

赞助人/主导人

供应商

测试

六大知识领域：

1. 战略分析：定义问题/设定目标和范围。

2. 需求分析和设计定义：前置步骤1，解决方案的输入。

3. 解决方案评估：前置步骤2，前提条件是已有解决方案。在评估过程中可能会发现问题，需要讨论问题，解决问题。流程回到步骤1战略分析，重复步骤1到3。

4.发掘和协作：持续进行的工作。发掘需求，和干系人沟通收集信息，步骤1到3都涉及到发掘和协作。

5.需求生命周期管理：持续进行的工作。需求批准/需求变更管理，需求优先级划分，需求重用

6.需求规划和监督：持续进行的工作。对实际效果进行监控，用经验教训分析偏差。

Knowledge area tasks

1.任务的定义：一个相对独立的工作，有一个输出

2.按一定顺序/同步的执行任务

3.BABOK没有规定任务执行顺序，BABOK不是方法论，是一个工具箱

4.需求分析可以是对现状做分析(战略分析领域)/衡量解决方案的效果（解决方案评估）

需求分类

business requirement : 事情的目标。应用到整个企业或业务领域的业务/商务需求。

stakeholder/user requirement: 哪些人会用到或受到影响，他们具体的要求是什么。敏捷项目利用用户故事呈现，包含actor/action。瀑布性项目需要方案，涉及业务流程，用户体验的设计。

solution requirements: 业务解决方案所有的细节，包含功能/属性。理论上实施团队依靠此实现需求，但实际可能还有需要确认的方面。

需求收集和分析的过程不是一步完成的，需要迭代完成以上三个步骤。建议初步调研时不要调研的特别细节

Transition requirements: 转换/过渡需求，在解决方案部署前的过渡方案（人员培训解决方案/数据迁移）。特点：有一定时效性

解决方案在使用阶段仍产生作用，比如某些需求是持续性的（用户在线率）。在使用解决方案过程中对功能做调整是正常情况。

前三个在解决方案前完成，最后一个在解决方案后完成。

solution requirements:

分成

1. functional requirements 功能性需求

2. non - functional requirements 性能/可用性/安全性，影响需求方案的被接受程度，如果不能满足需求可能导致整体解决方案失去价值

例：

1. 比如12315功能性满足，但性能不满足

2. 登录后的页面数据加载量大，导致用户登录后系统加载慢，用户体验差，导致客户体验差。原因是服务器在外国，国内显示慢。后来在需求方案中加了性能要求即非功能性需求。

Requirements & Design(what & how)

需求是解决方案的团队的输入，解决团队也会做输出（比如测试用例）给BA确认。

六大领域：

Needs:  重点问题或机会

Change：针对某个问题或可开发机会，在组织层面应对，所以需求改变

Contexts:  组织内外部结构/人员影响因素的总和

Solutions: 考虑到内外部因素的解决问题的方案

Stakeholders:  干系人

Value：问题解决产生的价值，解决方案是否能产生足够的价值（需要考虑各个因素和组织架构）

Business Analysis Information

系统介绍课程

需要记忆每个领域包含的任务名称，及输入输出

领域的相关方/技巧等重在理解

需求分析的旧版定义：一组任务和技术如何应用到工作中的组织架构/流程/运作方式等分析，在分析中发现问题，提供解决方案解决问题，为组织带来价值 。

课程分成12个单元，基本参考BABOK书籍

第一单元对应第一章

介绍背景/结构/重要概念

第二单元对应第二章

介绍重要概念：需求/干系人

第三到第八章

需求分析的六大领域，每个领域有任务，任务的输入输出是什么

第九章

基本能力：沟通/协调

第十章

六大领域工作中需要的方式方法：interview

考试实际占了比重

第十一章 视角

在特别行业的应用：IT 敏捷 业务流程管理 商业智能 商业架构

第十二单元

不是BABOK书内容，是考试指导 

Agile-iteration-just enough, just in time

Prective-requirement are define at a rather early stage-deliverables at the final stage

Interfaces-departmental

Roles and permission matrix

use case

Crud: create read update delete

Variance-root cause analysis

Data mining

Define, validate

focus group: qualitative measures

current

Acceptance (one solution, pass/fail) and evaluation (multiple solutions, assign different weights, ranking) criteria