1. 六大领域有30个Task.

2. BA approach，意思是整体规划，比如方法论制定。

3. BA governance, 比如谁批准什么，走什么流程。。比如优先级划分怎么处理，走什么流程。比如需求变更怎么处理，走什么流程。

4. 实际工作中3.1，3.2，3.3，3.4这几个task可能同步进行，而后有一份输出。

5. 3.5定义的绩效考核的目标有两方面，第一，来源于3.1的定义外部

1. 输入不一定一开始就是完整的，如果不完整，需要滚动迭代处理

2. 输出不一定是一次性的，可能滚动迭代的。

3. Guideline/Tool: 完成任务当中，用到的指导方针，策略，包括最佳实践，或者辅助工具。目的：提供效率，收到更好效果。但是这个guideline/Tool不是必须的。

4. 任何干系人都可能是需求的来源，也可能是constraints.

5. Customer≠ End user. End user - 实际使用者。Customer - 可能是出钱的人。

6. Domain SME： 特定业务领域专家。

Implementation SME: 解决方案领域专家

1. Elicitation - 挖掘，发掘。这个词比gather 或collect要好很多，说明这个动作是复杂的。

2. 每个知识领域由一组Task组成，建议记住Inputs/Outputs。Guidelines&Tools和Stakeholders&Techniques，不必记，稍微理解逻辑便可。

3. Elements, 列出步骤或过程。

4. Discrete - 独立的，离散的。

5. BABOK更像一个工具箱，而不是一个方法论。

6. 开始BA工作的第一项任务，可以是分析现状(Analysze Current State)，或者Measure Solution Performance

6. Solution Requriements中功能性需求会被客户重点提到，而非功能性需求被有意无意忽略。比如饭店番茄炒蛋，番茄/蛋/炒熟是功能性的。餐厅环境/上菜速度/。是非功能性的。

7. 非功能性描述也是要可衡量的。

8. Requirements和Design，并没有清晰界限。左图示意的从需求过渡到设计，很好的说明了Requriements和Design有没有清晰界限。

9. Design有可能是领域专家负责解决。

10. 左图示意的从需求过渡到设计，很好的说明了Requriements和Design有没有清晰界限。

1. 掌握Concept Model整个模型图。

2. Elicitation = 引出

3. Requirement = What. Design = How. 

一般理解，BA重要工作在于Requirement，而不是Design. 实际操作中，比较模糊。比如HMI，难以界定，这个是Requirement还是Design. 

所以BABOK中，Design被归入。这里的Design可被理解为业务领域的设计，而不是技术领域的设计。

4. 理解各个Key Terms。 

5. Initiative = 动议

6. Enterprise( ＞ Orgnization

1. BABOK中，Perspective并没有覆盖所有领域，而知识以样例呈现。

2. CBAP, 案例方式，每个案例1到1页半。120题，3.5小时。

3. 老师2016实考经验分享：

- 不是所有都是case study（案例分析）。 

- 11个案例，每个案例跟着3-4个问题。

- 1/3是case study. 2/3是Scenario-based，也就是2到4个句子描述一个场景，跟着一个问题。

4. 机考，随便什么时候考。

1. BA三大类：Generalist-通才。Specialist-专才。Hybrid:-复合型人才。

1. 每个领域的任务(task)，及inputs/outputs，需记住。利于判断，即便考虑“现有考试，更多结合现实案例。”。

2. Techniques侧重于理解便可，不必死记硬背。

3. Needs是问题或者机会，它是模糊的，不清晰的，需求调研研究分析。

4. 可以这么理解，Needs是BA工作的输入，而Requirements是BA工作的输出。

5. Recommending ≠ Providing. （BA不处理Solution的完成）。

6. Value的价值要大。BA重点关注点！和项目

1. Unit11无需看。

2. Unit12 报名需注意。

3. Unit 3 - Unit 8: 六大知识领域。

4. Unit 9: 基本能力描述，涉及题不多。

5. Unit 10: 

10.26 Item Tracking

10.32 Organization Modeling 

10.43 Stakeholder List, Map, or Personas

-remember input & output;

-understand stakholders & techq

• definition of Business Analysis;

这一章还需要认真再听一遍

requirements Classification Schema

需求分类】

business requirements 业务需求、商业需求【总体目标

stakeholder requirements 干系人需求【user 】

首先干系人分析，那些人能用到系统，那些人收到相关影响

solution requirements 解决方案

transition requirements 转换需求、过渡期需求 

企业

组织

计划

风险

分析已有文档：

1. 查找都有哪些文档

2. 记录，核实文档内容

3. 报告给干系人

plan tracebility approach 如何理解

第7章 Business Analysis 考题占30%

Verify requirements: 验证需求是否正确，无前后矛盾，别人能够理解

Validate Requirements: 验证是否符合业务价值

6领域，30 tasks

箭头表示输入输出