Business Analysis is the practice of enabling change in an enterprise by defining needs and recomending solution that delivery value to delivery stakeholders. 

Defining the needs/ Recommend the solution that delivery value to delivery value to the stakeholders. enterprise- organisation including the customer/suppliers/external parties. First to unerstand the problem/opportunites Nees is input understanding the why then generate the requirements as output as business requirements. Then based on the business requirements recommending solutions to the stakeholders solution evaluation via providing some recommendation. Solutions not only a software but also process enhancement/structure enhancements. Business focus on the value and requirements. 

收集信息方式：

Affinity Map 亲和力图

Fishbow 鱼缸

Focus Group 焦点小组

    pre-qualified participants 预先经过挑选的参与人员

    qualitative research 定性研究

    homogeneous

    hetrogeneous

Interview 访谈

affinity map 亲和图

fishbowl   鱼缸

assumption 假设

reveal 显示、揭露

encourage 鼓励

reserve   保留

participant  参与者

observer 观察者

moderator   主持人、调解人

vocal  直言不讳的

sway   影响

1.strategy analysis 战略分析

定义问题

2.requirements analysis & design difination 需求分析与设计定义

3.solution evaluation 方案评估

前提：已完成解决方案。BA不提供解决方案，给解决方案提建议，例如修改组织架构。了解解决方案的使用情况等。

4.elicitation & collaboration 启发（挖掘需求）与协作

5.requirements life cycle management 需求生命周期管理

6.business analysis planning & monitoring 业务分析计划与监控

对工作实际效果监控，规划工作预期

knowledge area tasks包括：

inputs（必须有），outpus，guidelines & tools（非必须，着重理解，不用背），stakeholders，techniques，elements

characteristics of a task

模块化，顺序，迭代，不是方法论，没有流程，类似工具箱，提供工具

transition requirement过渡需求

Data Mining：书上简单介绍了而已。没深入。

Supervised：有指导的。（设定某些规则）

Unsupervised: 无指导的。（通过学习，找出规则）

1. 理解左图（书中的图）

Acceptance Criteria对一进行验收，结果通过或失败

Evaluation Criteria对多个方案评价，结果排名。

Solution Evaluation：不单单是对最终的交付物进行评价。把书中的“In Use”理解为Existing更好。 

此章4个知识点： 

1. Expected Benefits

2. Expected Costs. 注意考虑机会成本。

3. Determine Value.

4. Assess Design Options and Recommend Solution， 考虑组织的资源，预算，时间，需求间相互依赖关系，和潜在供应商关系，其它进行的项目，公司文化，现金流。

1. RFT: T是Tender.非常正式的，一般是政府发的。

2. 各种RFx本身就是一种需求。

1. 了解Viewpoint(一组规范，定义需求呈现方式，不同呈现方式之间的关联关系）定义。单个Viewpoint是不够的。

2. 每个Viewpoint包含的内容就是Views. 

Validate Requirements的三件事：

1. Identify Assumption

2. Define Measurable Evaluation Criteria

3. Evaluate Alignment with Solution Scope.

Validate强调

1. 需求的价值

2. 其在解决方案的范围之类。

Reviews：

1. 了解左图各个review的方法。

2. 各个review有正式的，也有非正式的。都有不同优缺点。

Ad hoc: 临时的。

需求的特征：其中Atomic 原子性，意味不可分割的，不用好几个需求错杂在一起。

User Stories 用户故事

1. 一个简短的描述，1-2句话。看左图例子（作为顾客，我可以使用商品查询，以快速找到所需的商品）。其中Why - 体现价值。

2. 和Use cases的区别，use cases非常细节的定义了，开发人员可以直接开发了。User Stories，没有足够细节，适合敏捷方法论，短小简略，可测试的，实现快速迭代，对开发人员能力需求高。

State Modelling - 状态模型。

比如说一个订单，在生命周期类，有几个状态。各状态中间怎么转换。

非功能性需求分析，更多以文本方式表现。

1. 了解非功能性需求的分类及各单词意思。

2. 各项需求达成目标所衡量的目标要清晰定义。要不就无意义了。

使用事项：如果非功能需求满足太过苛刻，会带来巨大投入需求，要避免这种情况。

Data Modeling: 数据模型

1. 分类： 概念数据模型，逻辑数据模型，物理数据模型。

2. Diagrams图分为：实体关系图ERD和 Class Diagram类图

3. 使用事项：

3.1提供多层次的展现，比如有时只需要概念数据模型。

3.2对非IT背景人员来说不易用。

P.S.:

1. 了解ERD和Class Diagram图的样式。

2. 了解概念数据模型，逻辑数据模型和物理数据模型图的样式。

Business Rule: 业务规则

Policy:  指令，要求。宽泛的。（比如客户是上帝）。 

Rule: 具体和明确的规则。为某条Policy服务的。

左图例： 用决策表方式定义了Business Rule. 

规则分两类：Definition Rules（定义型规则）. Behavioral Rules. (行为型规则）。

Scope Modelling:  范围建模（范围模型）。

常用的有： 

1. Context Diagram: 系统交互图（环境图）

2. Use Case Diagram: 用例图

P.S.： 可细节的了解下范例讲解。