output可以是完整的交付结果也可以是某一个组成部分，可以采用滚动迭代的方式不断细化调整，最终交付最终版本。

输出可以是新创建的，也可以是对输入进行加工转变。

Monitoring：比较实际效果和期望的差距，经验教训的总结和分析。

每个领域是由一组task构成的。

每个task含有input和output

task指的是BA中一个相对独立的工作，有些是正式的有些是非正式的

analyze current state现状分析

policy & rule

goal & object  

广义角度讲，所有stakeholder都有可能参与其中，或者受到影响。

项目经理同步制定项目计划，BA可能与项目经理共同协作完成规划工作。

Solution Scope：具体解决方案的范围

Scope of Solution Space：获取所有解决问题的方案和方法

Objective 要满足 SMART原则

Specific

Measurable

Achievable

Relevant

Time-Bound

需求的来源：

Top-Down

Buttom-Up

External-Drive

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