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

箭头表示输入输出

记忆task的输入输出，purpose

非功能需求也需要被写入需求文档中，需要能被衡量和测试

glossary