向外发送信息

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 的输出只是一个建议，而不是最终的决定

第六章，为整个BA的工作设定方向

４个Task，为后续的工作的输入或者Guideline指导方针

6.1 第一个回去执行的活动，定义问题，对现状进行分析的过程当中，发现目前村子啊的问题、瓶颈、缺陷，首先需要分析Needs，另一个输入是4.3是一些概括续期的分析收集到一些原材料，6.1是一个隐含的需求分析。6.1则侧重从整个组织角度需要解决的问题和达成的目标，6.1输出Business Requirements，包含现状分析、现有的流程、组织架构、操作的方式，这里可以用到流程呢个模型、结构模型进行分析，另外显著那个的描述包括文字形式、图表的形式，最重要的一点是在现状的分析过程呢各种要发现要解决什么问题

6.2 在定义将来达成的期望状态。6.1和6.2配合起来，希望通过差别达成组织的改变，和达成的目标，例如需要达成成本较少多少，收入增加多少，输出包括三个：将来期望状态的描述，希望达成的目标，能够带来的价值是什么，例如用户满意度，收入增长，或者哪种方案能够带来更多的价值等等，后续很多领域第八章对解决方案做评价，第七章针对备选的方案进行筛选，都需要参考希望达成的目标为输入

6.3做风险的评估，在61.和6.2中涉及到的改变涉及到很多不确定因素，来自于本身BA工作目标达成带来的，也有来自于内外部的，比如监管机构的新的要求规定和改变，客户的新的要求，竞争对手的新的策略，都是一些不确定因素，Risk的输入时最多的

6.4定义解决问题的总的策略，2.0讲的是商业论证，通常是是一些潜在的解决问题的投入是否值得，可能还有多个投入的机会，在立项的时候把这个商业论证作为可行性研究的输入，可能会开发一个产品或路线图或服务，或者希望为组织定义新的业务模式，重新分析业务架构，以及长期规划的形式来呈现，或者企业层面的战略规划

总体来看，6.4是把前边所有的分析的结果做一个汇总，那么这个结果包括希望达成的商业目标、项目要解决的问题是什么、有哪些备选的方案、针对备选方案的可行性和成本效益的分析，基于这些分析给到建议，建议那种法案去解决问题，协商也论证的时候就要包含这些内容

6.4 的输出包括解决方案的策略或者战略，还有解决方案的范围，作为很多后续工作的输入或者guideline指导，看图

第五章　５个task

这五个任务基本上同步进行的，在需求管理中持续进行的活动，3章里边的输出作为本章的输入，这五个Task都包含需求和设计

5.1 Trace Requirements跟踪需求，还要关心需求和需求之间的关联关系，这个关联关系存在于需求和需求所在的其他团队的工工作内容，架构人员、开发人员、测试人员对于自己工作的内容与需求的关系，这些人也会跟踪需求，在项目过程当中，跟踪会有广义的含义，可以需求跟踪矩阵的建立和维护

5.2Maintain Requirement 需求维护，，需求方案如何做保存，Word和EXCEL

5.3需求可能得到有效的管理和维护，通过项目管理工具来查看需求的详细情况，查看优先级情况

5.4Assess Requirements 需求变更的评估，BA评估变更的价值大小，是否需要去批准，由谁来批准，当然这个规则是由3.3中规定出来，变更的评估会被提交到决策者来决定是否变更

5.5Approve Requirements批准需求，在3.3肿痛要制定了批准的流程、标准，比如通过邮件方式，以及正式和非正式的形式