Estimation：估算

估算的方法：

Top-down：自上而下。把整个工作（项目）作为一个整体估计，依赖以前做过的工作，依据经验进行粗略的估计。

Bottom-up：自下而上。把工作进行分解，再对分解的组成部分进行估计，把底层估计结果进行汇总，是最后的估算值。相对top-down更精细，但是必须要对要完成的工作足够了解。在逐渐细化过程中也可以在足够了解项目的情况下开展Bottom-up估算，已得到更加准确的估算结果。

Parametric Estimation：参数估算法。参数作为衡量工作的一些指标。多少个页面，多少个对象实体等等。

Rough Order Of Magnitude(ROM)：拍脑袋。把整个工作进行估算，且在没有经验情况下，就是拍脑袋估算。

Rolling Wave：滚动式估算。 

Delphi：Delphi法。向多个专家搜集信息，以进行比较合理的估算。如果专家们在一起共同讨论，有可能更权威的人会影响其他人的意见，影响结果的有效性，准确性。所以Dephi方法就是在所有人不见面，独立的表达自己的意见。可以多轮评估，给出意见。

PERT：(最乐观+最悲观+4*最有可能出现) / 6得到一个平均结果，即为估计值。

Lessons Learned（经验总结）

如敏捷回顾会(restrospective)

Unit 3 Plan 

Unit 4 Preperation

Unit 5 Requirement manage

Unit 6 Strategy Analysis

risk-free interest of the period 

TCO  （Total Cost of Ownership）

PV （Present Value）

NPV（Net Present Value）

IRR （Internal Rate of Return ）

ROI （Return of Investment）

需求优先级定义的方法：MoSCoW 

Must

Should

Could

Want

需求是否被关注，是否在设计中体现，是否有解决方案，参与测试的进展如何

需求和需求之间的跟踪

需求和其他团队工作之间的跟踪

Business Requirements

Stakeholder Requirements

Solution Requirements

工作范围、工作要求，资源要求，方法论的选择（敏捷、瀑布式等）

方法论，BA Approach可以是一个非常详细的工作计划、也可以是针对解决问题的一些方法的抽象概括的考虑和思考。

Predictive approaches：预测型方法论（瀑布）

Adaptive approaches：适应性方法论（敏捷）

Spiral Model：螺旋模型

Unified Process：介于瀑布和迭代模式之间的方法论 

Agile methodologies - Scrum

Meeting——

Sprint planning meeting：迭代开始时

Daily Scrum：每天都进行

Sprint review：sprint结束时，把sprint所完成的工作给用户做展示，已确认是否打到用户需求，收集用户的反馈。

Sprint retrospective：sprint回顾会议。回顾迭代中用到哪些方式方法，优点、缺点、经验教训总结

The Agile Manifesto 敏捷宣言

Business Case 商业论证。在很多组织里去分析潜在的商业机会或问题的解决。确保实现的价值超过成本。立项前先编写商业论证，然后再根据这个论证结果进行立项

Change Strategy 解决方案交付策略，比较笼统抽象的名称。具体可以是商业论证，产品愿景或路线图，或企业的战略规划。

Conduct Elicitation techniques：(三部曲：Prepare-Conduct-Confirm and Present)

BrainStorm--get more opinion

Collaborate Games--get more opinion which are more detailed

Focus Groups--get more opinion that more speci than BrainStorm

Interview-- Private information

Observation--non vocal information

Prototyping--early solution design

Survey or Questionnaire--large scope of stakeholders

Workshops--achieve agreement

homogeneous

hetrogeneous

Techniques：

BrainStorm

Focus Groups

Collabrative Games   

Interviews

以下角色并不是全部的角色，只是一些重要的可能出现的角色

Business Analyst

Customer：未必是直接用户，可以是出资人，施加影响的某些人

Domain Subject Matter Expert(SME)：某个特定领域（特指业务领域）

End User：直接用户

Implementation Subject Matter Expert：解决方案实施专家

• Project Librarian, Change Manager, Configuration Manager, Solution Architect, Developer, Database Administrator, Information Architect, Usability Analyst, Trainer, Organizational Change Consultant

Operation Support：运营支持

Sponsor：发起人、赞助人、出资人

Project Manager

Supplier：供应商

Regulator：组织内部或外部，可能会出现的法律法规、规章制度的管理者，制定者，监管机构。

Tester

Underlying Cometencies——基本能力

六大知识领域

Business Analysis Planning & Monitoring：BA工作的规划和监督。涉及到所有领域工作的规划，跟所有领域都是平行的关系。也是持续性进行的活动。

Elicitation（搜集、挖掘、发掘） & Collaboration（协作）：与中间三个领域是平行关系。很多需求没有一个成行的状态或内容，很多干系人都不知道自己需要什么，需要BA使用各种手段把这些需求挖掘、发掘出来。

Requirements Life Cycle Management：需求的生命周期管理，与中间三个领域活动同步进行。需求如何批准

Strategy Analysis：战略分析，为后续工作定义问题方向，非常关键的领域

Requiremnts Analysis & Design Definition：详细的需求分析，业务方面的解决方案的分析、定义。BA核心的工作内容。

Solution Evaluation：对解决方案进行评价。前提是解决方案是以某种形式已经存在。因此BA是recommend solution，而不是provide solution。在评价中可能会发现问题，这就又可能回到问题收集重新开始循环开始BA活动

Task定义：

一个相对独立的工作，后续工作没有更多的依赖关系，一般都是输入输出关系。

按照一定顺序执行，或按照迭代方式、同步方式来执行。

BABOK并没有规定执行领域或任务的执行顺序。因此这并不是一个方法论，BABOK可以看作一个工具箱，具体到要完成某项工作时，自己去选择合适的工具，再选择一个合适的顺序，才能达到最好的效果。这个过程也是持续滚动执行的。

Task并不是就完全没有顺序，有输入输出的依赖，会有潜在的先后顺序的约束，有可能是滚动迭代或同步进行。

initiative这个概念，有可能是一个project，也有可能是组织中的一项任务或研究。BA工作很多时候第一步是Analyze Current State，或者Measure Solution Performance。换言之，从知识领域上来说，最后可能启动一个BA工作的是从Stragy Analysis或Solution Evaluation这两个领域开始

需求类型

Business Requirement：整个企业或组织层面所提出的总的目标和结果。

Stakeholder Requirements：反应某一个或某一群干系人在解决问题,，达成目标时，有哪些目标需要我们满足。也可以称作User Requirements。用户故事基本上可以认为是Stakeholder Requirements。敏捷可能在Stakeholder层次的需求就足够了。

Solution Requirements：解决方案所需要满足的所有的细节、条件或内容。交付给解决方案团队之后，解决方案团队是可以直接依照它进行设计和交付的（理论上）。

Stakeholder和Solution Requirement的区别并不好做。

答题时，区分前三类需求，最重要先看主语是什么，即谁提出的。基于描述方式进行判断。

传递一个理念：需求的收集、分析和定义并不是一次顺序执行完，可以不停的重复，细化。

Transition Requirement：转换或过渡期需求。在某个解决方案过度阶段。某些项目需要数据迁移 。特点：需求时效性，一般发生在过度期。必须以解决方案为前提。其他三类需求不需要确认解决方案，因为他们是解决方案的输入。

Requirements reuse：Business、Stakeholder和Solution Requirements需求被重用可能性较大

Requirement和Design是needs于solution之间的桥梁，他们也能出现循环

Requirements到Designs的划分，哪步是需求哪步是设计，较难有明显的区分

六个基本概念，思考问题时用到的系统性的思路

Changes：意味着在组织层面需要做出改变或应对

Needs：需要解决的问题，或可开发利用的机会。

Solutions：解决方案。在考虑环境之后，确定的一种或多种特定的方案

Contexts：环境。之前我们用到enterprise，需要考虑的组织内部外包的各种因素，他会影响问题解决，解决方案的选择

Value：价值

Stakeholders：干系人。

Key Terms

Business Analysis Information BA信息

requirements、elicitation results（信息搜集活动的结果）、designs（设计。很难完全分清楚requirement和design，这里design更偏业务层面）。即除了需求和需求以外，过程中涉及到的所有信息

iniative

need并没有一个具体的呈现形式，这个具体形式即使requirement，可能就是一个需求文档、原型、各种图表等。

Enterprise：一个或多个组织所组成的团体

风险：带有不确定性的对工作带来影响（负面或正面），正面风险又叫做oppertunity

Business Analysis Key Concept

Knowledge Areas

Underlying Competencies

Techniques

Perspective（目前5个perspectives，不是所有领域）

谁是Business Analyst

任何完成BA工作的人都可以称作Business Analyst，和你在组织当中的职务名称(title) 无关。 

人员分类

Generalist：通才，对所有活动方式方法都有基本了解，会使用，可以根据需要选择最合适的方法。所涉及的行业领域差别大，需要随时学习很多业务领域新知识。比如：外包咨询公司的专门顾问。

Specialist：针对某个特定领域或行业有比较深入专业知识或技能，但是其他领域不熟悉。

Hybrid：混合类型。在组织中，除了自己本身的角色，还要适当扮演BA角色。

IIBA商业分析能力模型

http://www.iiba.org

change

enterprise

needs：（作为BA，输入是needs，输出是requirements）

solutions：用recommending solutions推荐解决方案，BA是作为客户和解决方案团队之间沟通的桥梁。不负责实施交付，而是负责requirements的输入。为选择及解决方案提供建议、对已经完成的解决方案进行评估。可以给出改进建议，甚至建议淘汰或替换解决方案。

solutions并不仅限于IT解决方案，还有业务流程持续改进，组织架构、商业流程、商业划分、角色职责等等，需要思维拓展。

value：价值，价值足够大的问题才是值的我们投入资源去解决的。BA更多的是考虑价值，最终是否达成价值。

stakeholders：干系人、相关方。任何需要打交道的人或部门，有可能收到我们工作的影响，有可能影响我们的工作的人或部门(exp：sponsor)。

BA可能是项目内部的一个角色，或者是一个组织的BA，他不属于任何一个项目。

BA用各种工具去分析组织层面现状current state、也可以分析和定义未来期望达成的状态future state。现在到将来的变化就是需要做的改变，BA就是分析用哪种方式来实现这种改变

sunk cost 沉没成本

干系人分析：

Roles 

Attitudes

Decision Making Authority

Level of Power or Influence

Input：Needs，Business Analysis Approach

Output：Stakeholders Engagement Approach

Input: Need

output：Business Analysis approach

the ohter tasks：

plan stakeholders engagement 

plan business analysis governance

plan business analysis information management

plan business analysis performance improvement