本章是6大知识领域的第一部分：商业分析计划和方法

概览：

3.1 要初步规划这个事情怎么做

3.2同不要做干系人的计划，识别一些干系人

3.1和3.2是可能并行的

3.3和3.4，是需求管理活动的规划，在定义过程的方式方法，在3.1和3.2的基础上

3.5 在BA工作当中，发现和BA规则、目标不一样的地方进行完善

详细：

3.1Purpose目标：规划：要完成哪些工作，工作范围是什么，在工作当中需要哪些资源，时间的要求，做一些答题的预计，就是本项工作的一些输出，更重要的是决定采用什么样的方法来完成我们的工作，会对包括后续会走的流程和参与的人员形成一些影响

3.1 输入是Need，输出是BA Approach，可以是一些详细的工作计划，也可以是针对问题的一些抽象和思考

常见的方法论的类型：

1、预测性的方法：聚焦先制定计划，先分析一下这个事情要怎么做，具体要完成那些活动，详细的计划，罪域要完成的工作进行一些预测，对即将会遇到的问题，语先做一些分析和预案，在这个基础上来完成我们的工作，例如传统的IT回进行一些BA工作量、成本、时间等等，缺陷是有可能是计划赶不上变化，项目刚开始的时候可能没有办法做详细的设计，那么在后期可能会出现做一些返工，会造成一些浪费，所以在开发的时候吧所有需求完全搞清楚是会产生大量的确定的问题

2、Adaptive approaches，适应性的方法：在项目过程中会产生一些变化，所以要快速的交付价值，通过迭代的方式实现一部分价值，逐步实现价值，

总结：实际上在工作钟要结合1和2之间，有些事情要按照1的方法，有些事情要按照2的方法

The Water Model： 瀑布模型

1、Requirement，

2、design

3、Implementation

4、Verification

5、Maintenance

The sparcial Model：迭代模型

1、determine Objectives

2、Identify and resolve risks

3、planthe next iteration

4、development and test

The Unified Process：统一进程（介于前两种模型之间）：1、 开端 2、 精化  3、 建筑  4、 过渡

1、Inception

2、Elaboration

3、Construction

4、Transition

几个关键词：

Use Case Driven，用例驱动的方法论，文字形式的模型，针对某一些功能，进行的分析，也可以作为输出的方式

Agile methodlogies - Scrum敏捷方法：一组方法论的组合

首先由三种角色：

1、Product Owner 产品所有人，更接近于BA的角色，负责产品需求相关的一些问题，对产品的需求做收集和管理，通过Backlog的方式

2、Development Team 开发团队，这里并没有是说专指开发人员，包括需求人员、开发人员，以及与需求相管的人员都算

3、Scrum Master 敏捷教练，保证团队按照敏捷的理念和方法执行敏捷的方法，排除在使用敏捷的方法过程的障碍和问题，给到一些指导，主持一些敏捷过程中的会议

Artifacts：工件

1、Product Backlog 产品的需求列表，按照优先级别来实现，需要Product Owner要识别有哪些需要实现的功能和需求，在对这些需求和功能进行排序，其中有可能出现一些需求的变更

2、Sprint Backlog 冲刺/迭代，快速的完成工作，例如1-4后完成一轮工作，相比较一般的迭代方法，迭代的周期比较短，更加频繁的沟通和确认，从而得到一些反馈，又回到需求的表中，然后进行下一阶段的需求的整理，

3、Increment：每个迭代交付的结果，也叫Product Increment，这些增量有可能去给用户交付和使用，或者 给用户去使用，从而收到到实际的反馈

4、Burndown Chart：通常用来了解项目和工作的，剩余的工作的量，相当于滚动统一下设呢关于的工作内容，那么只呢个长的情况下，剩余工作的曲线是越来越低的，

Meetings：仪式/会议

不管发生什么情况都要进行的会议，包含

1、Sprint planning meeting：在每个Sprint开始的时候，在Product Backlog当中，Owner会决定哪些内容需要在的当前的Sprint当中要完成的，有多少工作量

2、Daily Sprint：在每天工作结束的时候，总结一下当天的工作内容，以及需要团队成员进行帮助，非常高效的讨论一下遇到的问题和需要的帮助

3、Sprint Review：把Sprint的结果给用户去用，获得用户的反馈

4、Sprint Retrospective：在每次Sprint完成后进行讨论和总结，总结经验和方法

其他敏捷的方法：

XXXXXXXXX

敏捷当中那些是重要

1、Individual and Interactions, 个体的互动大于Processes and tools流程和工具

2、Working software可操作的软件的方式，大于写详细的文档Comprehensive documentation

3、Customer Collaboration通过和客户的协作符合客户的需要，大于Contract negotiation根据一个固定的合同内容来执行固定的合同

4、responding to change依据变化的需求，大于Following to plan 要与跟随一个计划

ensure

monitor

向外发送信息

dev package to convey info:

-formal documentation

-informal documentation

-presentation

communication platform:

group collaboration

individual collaboration

email or other non-verval methods

Solution Evaluation：对于解决方案做评价，本Task的关注点不是需求，而是解决方案，意味着觉方案的团队根据需求完成了相关的一部分工作，存在一个完整或者部分的解决方案，那么本章对于解决方案进行评估

本章前提是：已经有解决方案

8.1Measure Solution Performance：前提是搜集一些解决方案的数据，量化的数据，或者一些定性的反馈，比如说一些访谈的用户，搜集用户使用解决方案的体会和感想，一些定性的反馈或者数据，所以输入为Implemented Solution（实施方案并不是BA团队的输出），解决方案的实施的结果，包括纸上的方案，也许只是其中的某一个方案，可以作为评估的对象，External就是说实施团队，不是BA团队，另外要根据之前设定的业务目标Business Ojectives进行评估，输出就是收集到的可量化的实施绩效，

8.2 分析效果衡量，需要考虑价值情况6.2的输出潜在的价值的预期作为输入，输出是经过分析后得到的结果，

8.3 针对解决方案本身的一些问题，例如可能会发现问题出在共嫩不够强大、解决方案的一些问题和组成部分，然后对解决方案进行补充和完善

84.除了方案本身的问题，也有可能问题出现在组织的层面，比如提供相应的培训，或者对流程和岗位分工进行一些改变，使得解决方案交付更大 的价值

8.5 汇总8.3和8.4的解决方案，给出一些建议，但不是决定，输出对于方案的一些补充和完善，甚至否定现有的方案，可能回到战略层面重新定义我们的目标，或者确认现有的方案达成目标的要求

conduct elicitation:

collaborative

research

experiments

document analysis

preparation->document review&analysis

->record findings

prepare for elicitation:

understand scope

select techniques

set up logistics

secure supporting material

prepare stakeholders

elicitation&collaboration

elicitation

key performance indicators KPI

metric = a quantifiable level of an indicator

=specific point, a threshold, a range

structure

reporting

1. business analysis: change

BA performance improvements

-analyzing performance

-determing assessment measures

-analyzing results

-recommending improvement actions:

preventive

corrective

improvement

BA info management:

-determining level of abstraction (breadth and depth of information being provided)

-planning traceability approach

-planning requirement reuse

-deciding on storage and access (repository)

-determining requirements attributes

item tracking

item record

governance:

• define decision making roles
• determine change control process
• planning prioritization approach
• planning approvals

estimation:

方法：

top-down

bottom-up

parametric estimation

rough order of magnitude(ROM)~top-down

rolling wave

Delphi:combining expert judgment

PERT: Optimistic+Pessimistic+(4 times Most Likely)/6

==============

Accuracy?

Sources of information:

Analogous Situation

Organization History

Expert Judgement

Precision and Reliability???

chapter 8

chapter 7

比重较高 30%

chapter 6

6.1 analyze current state

6.2 define future state

6.3 assess risks

6.4 define change 

知识领域

strategy analysis: 战略分析，定位问题

requirements analysis & design definition: 业务分析

solution evaluation:

前三者循环

===========

后三者同步进行

elicitation & collaboration：和干系人协作

requirements life cycle management: 需求管理

BA planning & monitoring

第七章 需求分析& 设计定义

一共里一个Task，第七章在本书和考试的比重超过30%

重要的是7.1，使用到了很多的模型，图文并茂的方式会更有效，输入是4.2、4.3收集到的原材料，输出是明确 的需求定义

7.2和7.3，Verify核实需求和Validate确认需求都有验证的意思，Verify审查需求，确保输出的需求符合质量的标准，符合组织的需求，也符合业界的标准，不要出现前后矛盾的情况，避免出现不准确的措辞等等，Validate确认需求的目的是从价值的角度确保需求是有业务价值的，这两项一不同的形式来进行，前者检查质量，后者有可能需要和需求的所有者进行探讨，确认需求的价值是否在解决方案的范围内，这两项有可能同时在做。

7.4 目的是为了输出的需求定义格式和形式，比如说有的干系人是需要文档，有的干系人需要流程图，每一种需求可以称为View，或者分析模型，加入到需求文档中

7.5和7.6 基于前边输出的需求进行设计的相关的活动，

7.5根据所确定的需求寻找备选的方案，与6.4不同的是。6.4的输出的内容也要考虑不同的解决方案（新的软件和新的流程），但是站在更高的维度和战略层面，但是7.5是站在更详细的维度更细节的设计层次，但是7.5也要以6.4的输出为输入内容，另外7.3确认的需求也作为输入内容，还有5.3中需求的优先级划分作为参考，输出的话呢，包括有哪些满足需求的备选方案和设计

7.6对备选方案和设计进行评估，那就需要备选方案，6.2中需要达成的最大的价值，这个时候也不是BA能够排版的，这个时候需要组织的管理层和干系人进行决定，注意到这里的7.6 的输出只是一个建议，而不是最终的决定