1、

negative impact 负面影响

6、

stem 产生

monetary 货币的

turnover 营业额

8、

solid 全部的

33、

maintenance 维护

50K是每年的维护成本，投资只有300K

ROI = 300/1300 = 333%

39、

总的维护成本

 

 

1: 是评估解决方案，应该是用success measures来评估

2: 分析现状包含business architecture and internal assets, this question description focuses on business architecture

4: documentation rejects are also eliminated

8: assess whether desired outcomes is achieved, should use KPI

9: Onion diagram is used in the technique of stakeholder list, persona

17: 审题不清，看错单词

31: view is a component of viewpoint

33: BPMN and UML are two different types of diagram

37: It's define solution measure, not analyze solution measurte

38: test一般不负责排序

43: B在A之前

55: B is organization knowledge

57: AB两项已经比较明确

58: 他一个人说的不一定是对的

69: A属于verify requirements

76: high level不一定能用，要考虑是敏捷还是预测型的方式

78: 目前还是企业级别的need

81: validate requirement

107: A是每个公司建一个repository，解决不了问题

 

 

 

 

 

11: D中use case diagram表示的是actor和行动之间的关系，不是实体之间的关系

85: C是输出，不是输入

101：目标不能衡量，只能是goal

102:其他的选择使用的技术比较局限

106：不太理解

112: B主要是在排优先级时的风险

 

3: 一个用例可以包含很多场景

9：文档分析用于搜集信息，不是evaluate

11: review不是agile过程

15: 没有提到要按一定步骤进行，所以不选A

16: B model map不是体现实际

18: use case specifications and use case diagram are two different methods and don't need to be uesd together

19: UML is not a state diagram, but a data diagram

33: D 不是不理解manage这个词，而是不知道具体指什么

57: B应该是stakeholder need，不是business need

 

 

1现状分析 ， 产品1 年后发布， 但衡量成功度量是BA 任务， 要去了解达成目标

问题已经了解解决方案也知道但是不知道如何衡量最终结果是否衡量= measure

SA-定义问题衡量达成状态设计方法策略， DF设定目标和衡量目标

SE 

2business architectural是组织构成提供的产品服务执行的只能能， 因为问题描述的是组织内部现状分析所以显示- business architectural

B assets是A business architectural的一部分

C

D 现状分析也有但是文章都是内部，选项是组织外部的

3因为目标是否达成在一年后， 要去报告的是期望的目标和价值******

AB是project所以不是BA 是PM

project= PM

BA做价值衡量

d 不是BA的范围

4提升成功率，改进成功率小于＜　７５％　的项目，　以下是３个月的数据，　有三个流程，　表格里面是总共交易数量，　和被拒绝的， 成功的和成功率。

因为第一个70＜　７５要改进

BA建议Doc被拒绝的多所以要有个check ｌｉｓｔ　检查 去排除问题=完全消除问题

如果verification降低50 % ， = 38 *0.5= 19 降低， 19 成功增加

 

6

7

 

8

 

应用ｄｏｃ　ｌｉｓｔ　，　从三个月改成每个月，处理能力增加５０％

８目标是一年内销售增加１５％　客户留存增加１０％

按照保险费为金融价值，给不同的折扣率

按照客户时间年限为真实度　给不同折扣率再第一个表基础上

 

在次基础上基于年限折扣折扣，只有高于5年才会拿到全部折扣。

BA用那种技术衡量期望结果。

用KPI 费用和年限衡量指标，　还有决策分析，但是问题是验证是否达成所以还是用衡量指标比较符合。 因为用了衡量指标。去确认期望结果是否达成，一个是收入增加15 用户10% 

 

9BA确保每个需要的人加入进来了－－　SH的TECH，只有A是对SH的

10已经过去了６　个月，顾客是增加了５　销售是增加了６　，　目标一年是１０　和１５　所以什么时候可以实现

 

retension留存率

premium保险费

11 要做改变， 那BA要衡量优缺点成本和印象， 那BA在做什么， 　是做影响分析

变更管理中BA要做的是影响分析提供决策建议做决策支持的工作

　
12饮料制造商，　平常可以但是有季节性波动，平常6０　吨　高峰季节无法满足顾客需求１００　吨　。限制是从经济角度无法增加卡车和驾驶人员数量。 交付流程有四步

perform结果有五个因素

１２　如果只考虑车的限制，　１２　辆车，每辆车每天２　趟，３０% 几率　是刚好到了就装车，剩下的是７０％要等一小时， 那每天浪费多少时间：

　１２　车＊　２　次＊　７０％　概率＊等待一小时16.8---17

13每小时０。６吨，　有１５个司机，　要交付１００　吨，　每个人工作多久

１００　吨／　（１５个人　＊　０.６吨一人一小时）=11.11-11

14 有浪费时间BA应该提出什么建议消除浪费：整个系统去协调 。 

等待那１　小时如何做准备减少等待概率时间　流程改进　协调起来

A提前让他知道

B提前做准备－　不全面

D雇佣仓储人员－　不一定是问题点

15主要目标－　满足顾客再高峰时期， 季节波动也是客户， 主要是跟上市场和客户

D和绩效无关是 业务市场波动，　还要尽可能满足需要

16工作上有variance没满足预期 ，address variance 改进解决问题address issue？ 要知道原因才能解决问题所以root cause 然后解决问题

A不一定是approach没解决

C 没改进

D对当前没改进

17衡量商业分析绩效有定量和定性， 优先考虑量化原因--客观

A未必可以确立， 也未必可靠

depenable -可靠 不对

subjective 主观

18经验教训来讨论中大家互相指责， 主持人要怎么办

a 直接指出的话可能更不冷静

D让他冷静下来

19同时多任务协调能力 person organ and time management 

 

dependable可靠

trustworthiness值得信任

23business plan  不在 business Case 里面

哪个不是财富分析涉及的

25品牌声誉组织是内部资产

27任何状态的需求是Arch的输入

28数据字典有两种元素原始和复合数据元素

29术语表-数据字典 的差异= 字典，  缩略语-术语表 字典-数据元素

31viewpoint考察需求的不同视角-框架

views填充实际内容

32POC - 工作开始阶段验证想法

LL工作结束了， 所以POC不能包含在LL里面

33活动图activity　diagram- 是ULM的流程process　diagram图： 描述用例usecase， 场景平行路径， 发现流程痛点

BPMN不同于ULM的标记法的流程图

notation表示法

35 SE input 

36***８.５　措施一个决策3 个部门给意见， 但是交流不多， 最后sponsor拍板

增加解决方案分类-降低接口复杂性

37BO　符合SMART　是KPI　源头

  38评估变更影响tester参与影响评估

39需求排序SH业务领域的人和ISME

排序的时候Project Team 不太用的描述， tester domain SME不排序

distinguish区分

 

40sponsor and pm 排序

 

41跟踪需求考虑什么不考虑

Depends-- relationship一种所以不在追踪里

追踪在什么程度A

42那种技术可以支持SH描述要完成的目标　，　谁想要什么= user story

use case有很多交互细节

B更直接谁想要什么

C太细致了

D包含什么不包含什么

４３　是否按照预期完成： 预期是什么，然后是指标然后是 实际是什么， 然后衡量。

所以要先B设置预期是什么 然后才是A设置尺度

4４ 通过交互的方式interact了解一群人信息- workshop

A 培训

题目要的是interact 所以survey不行
45PMBA用到的技术

46地滑- 穿防滑靴-- 降低发生可能

avoid是完全不见了

mitigate降低可能

47一天取3次- business rule 

但是发现不满意- data mining 

49流程分析担心流程遗漏= risk因为担心， 因为如果确定的就已经变成需求了。

那针对risk要进入到风险记录册里面

 

encountered遇到

pilot

51PV +sol performance =8.2 analysis

52评估的时候， 指标好但是还是去掉了这个解决方案， 因为方案不能解决业务问题， 没有业务价值所以就是没法解决问题所以去掉

53SH没用新流程回到老系统-- 信息不足够，没说原因 问什么没用 没法给方案

56mind map - 识别分类信息

BA要先做的是，　问题和达成目标都知道了，　现在20 个部门分别掌控合同current， 目的是用一个中心化方式管理合同futre，　下面要做SA， 显示别组织能接受那种改变， 然后衡量选择那种SA C是一种方式之后做， AB 做完了 

643define CS58只有一个人说了数据流， 下一步集合SH讨论确定值得认可才开始做 问题里面有数据流所以用数据流图表达 最终还是要大家一起确认

大家认可才能是需求只有一个人说不行

59 paraphrasing =active listening 复述 确认理解但是不全部100% 重复

60 rational 7.1模型分类五：ABDrational理智 capabilities people role

 没成本模型

diagram 描述范围层次结构分类

63对小部分人了解他们的主观态度价值并且讨论去拿到feedback= focus group

 

focusedgroup 收集看法

64 统计抽象方法去搜集数据= 考虑什么因素多久和时间是做统计必要的

FA不一定， BD是tech不是因素

65 销售下降因为竞争增加， 雇佣销售代表，但是没改变， 那该干啥， 所以原因找错了， 要从新找原因

 

  66项目完成了去回顾= LL

67每周新产品， dough面一样料不一样，需求重用是面dough， topping会变，所以重用的是dough面团

68 69***关系是看连个， 有必要的， 对的反应 ， 关联不含糊

在74 requirement architecture 有不同视角但需要有关联， 所以检查视角关系那么复合的标准是什么

高质量是针对某一条testable可测试不是关系

但是这里是一群的关系所以关系必要，准确反映， 不模糊 

72confirm EL 用到的 74唯一的改进成本高于实施10被- 没有改进要retire

75BN 有了但是solution design无法达成共识， 很有可能 approve决策机制没确立

76订单处理， 成熟的产品流程可以， 季节性产品每年不同， 确保季节性可以处理好不影响原有流程

季节产品和特殊需求SH挂钩

highlevel abstraction 高度概括需求是对敏捷类型开发模式但是成熟产品不太变化， 但是季节产品细节少无法确定方法论选了哪个

 

77likely to be unhappy - risk  

78 interpret

articulate

需求依赖关系影响到重排序

81 verify结束， 确保validation

A Verify

D validation

82 评估变更

85输入

87

除了confirm EL 其他的优先选confirmed！！！  

88ll= 回顾

89

90考试不考

91不同部门SH对需求有冲突， 单独看没事儿。 所以要吧需求与组织功能建立关联

92识别风险因素被记录更新

93方法论改变， 换成敏捷， 那哪一个影响最大，商业分析时间改变。 因为预测方法论在开始， 敏捷在一直都有。 

C影响不大

AD无关

94评估变更管理时候， 如何沟通finding和decision。 变更更管理的控制在governance approach里面记录。 

SHcommunity plan 是通用的不够针对

有些需求miss implemented which not support by R . BA 用什么发现了这个问题- TRACE　Ｒ　

96需求分类allocated，　在 ＤＤＯ　需求与发布建立关联确保实现。　要基于哪些因素去最大化价值。　时间和商业影响价值

C每个发布有多少能力， 但是不指导细节

97 

pertain 属于

hamper阻拦

tracibility/ item track /trace R

99

100需求不稳定 实现往后放

101组织问题没考虑到，那可能是informal的没考虑。  组织结构没问题。

 

reus＝maintain　R＝　info　management　approach

107 下属15 公司， 互相独立， 没有信息交换， 合作有问题。 --改进信息访问，建立统一平台实在确认之后才做的

Canvas- 用于发现问题， 问题已经发现。

D是个solution结果，　现在还在分析中

108有些自动有的人工 loading sorting， loading基于警报， sorting需要基于信息做判断。 那么loading最简单流程最好自动化

109风险评估输入

有些需求和监管冲突，　但是看罚款和实现简直高低

117

企业》 组织

SA是持续进行的活动

120 解决方案交付价值750 ， 成本500 ， 这个解决方案交付的价值=预期价值- 成本

performance = efficiency x效率性能

5

partially charge部分充电（扩展） 与全冲（基础功能呢）同层次需求。depend

满足： R- coDe开发i代码  不同层次需求

验证：R-test不同层次需求

衍生： 概括-详细上下层次

取决于：同一层级， 先一个实现在/印象另一个

6合作时间最短合作调研实验

7现状分析：两种view : capability view  组织能力/ process view组织流程瓶颈

重新用已有能力C

8

对超级用户定义是要像登录，都　是要先做一个２　步骤验证然后在做其他操作（改变系统参数和创建新的超级用户）。　有超级用户的权限才能发动邮件或者短信通知。那么这个两部验证的关系和（改变系统参数和创建新的超级用户）的关系是什么？

必须做的-include， 部分情况做的extend。 箭头指向被包含（一定要做的哪个） 被扩展（主题， 没被值得是辅助项目）

先做两步验证，在进行改变和创建新人 ：include关系。 因为这两个都需要做两步验证， 所以要去包含两步验证

箭头指向被包含， 被包含箭头被指的哪个是一定要做的

9有超权限的角色才能发送两种信息mail sms

send noti 是泛化， mail sms 是特例子

因为要是特权才能发消息，　没有权限就要申请，　所以权限实在发消息的功能基础上扩充的功能，　所以发消息是被扩充是的。

　如果已经是有权限那就不需要set　ｕｐ　所以不是include是extend。　因为有些情况需要有些不需要。　

因为要现有权限才能发送通知， 所以没有的话要先去申请权限， 所以实在发送通知下面扩展申请权限。 

扩展是可选择的关系，有些情况需要有些情况不需要。 

必须include做了A才能做B， A《- include B

先验证在登录， 登录包含了验证功能

可选关系是extend做A前需要额外做B， A <-extend B

发notification前要注册admin， admin-->extend notification 

 

A

 

internface= system communicate 

11用在线地图和GPS实时显示附近的可以提供服务的供应商的地点实时显示附近供应商地点吗，可以查询输入邮政编码查找供应商， 下载收费信息。 

 

 

subscriber , mediacal plan , service provider 实体对象， 有那些数据属性=数据模型data model

数据模型data model ： Erd +classdiagram 实体对象关系

用例图： 用户和执行操作， 但是不反应实体之间的关系和属性。　用例图是外部实体和操作的关系

emolition 废除

evisioned 

vicinity 

violate

12需求不完整，提到上一条需求， 原子性指 一条需求不应该查看其它需求但是这条需求要查阅上一条需求

13怎么查找下载费用信息， 没提供如何到现场，

15

SWTO 有什么好处在商业论证里面： 分析优缺，比较哪个CS优势大 

a 宏观不量化

d不量化 KPI

16借助以往做过的估算B= analogous situation 自己过往类似案例估算

expert judgment专家估算，， organization history组织历史项目估算，ROM是拍脑袋技术不是来源

17被给了一些业务决策对现有表现不好的解决方案

18需求批准stakeholder重要-业务领域，定义价值customer

19银行监管- 所以比较保守要预测模式b

AD没有这种方案

20管理层次要东西，但是技术信息没出来-- 所以不是管理层a不对， Bd没做， 

因为管理层不关心技术所以可以弄一个高层次报告

23在现状分析 建立了流程模型- 下一步发现问题去改进process analysis

先process model 再 process analysisi 

VSM , activity disgram 都是一种process model

不 vali 不符合或者没价值， 那就该删掉

24 

25在座的是verification 衡量输出格式和组织格式是否一致

sought prior 

perssue

procees model relationship with analist
 

变更影响评估是价值面向的不是需求关系

28****

不同图的展示不一致 R  那这事在需求架构里面决定所以选择info arch>= R arch 

29 适应性更需要优先级完全按照优先级来做事情

预测是按照计划但是适应按照优先级

30需求搜集数据识别再定义， 为什么改变， 对问题描述。现状分析任务 BR描述N

对现在分析（识别定义问题和机会）， 输出是BR，　输入是ER　（confirmed）

31创建和找到角色是depend　（necessity）必要性一定药有创建。

derive 不同层次

satisfy开发和需求

32LL发现问题解决＊＊＊＊＊＊＊＊＊＊＊＊？3.5correct 、preventaction针对已经发生的问题做改进

 

33无法衡量那个solution好　，　因为问题没定义business need unclear

34变更优先级排序， 不得不去做的法规监管必须做的时间敏感－－　合规=urgency

验收标准通过批准

39收到的实际效果和期望价值尺度准确性评估 82 衡量的是收到的数据绩效， 趋势， 与实际比较看差距

那一章节出现了penalty

A需求优先级

40思维导图协作时不利情况，每人想法都不一样不好沟通

A对所有都有这个问题：　与看brains Tome限制

 

42PM 指出有信息遗漏不一致和需求矛盾， BA viewpoint　矛盾， 不同的view之间没有建立关联　不矛盾。 accommodate requirement viewpoint确保关联和无冲突－－　不同view之间需要保持一致　　在需求架构中该考虑的arch－－－　

C template architecture 只能确保一个view是对的但不能确保多个没冲突

D solution scope是输入

43了解信息途径有限制，政府法规细节不了解文件没有， 所以去看看　找专家或者做过的项目。

A－　场景里面找不到人

B－　文件里没有

4SH两天有空不然就三周后，很多时间要讨论，是有争议的项目还要看材料，所以　纵然时间紧但是但是两天不够现在他也没准备好－－　所以三周后开让他们准备好不一定要所有人参加但是要准备好， 因为信息没读的话开了也白开

参与程度

48BA绩效衡量尺度： 准确完成只是有小时效性组织支持

效率不是，　有效是effect 组织标准不是

49吧头脑风暴

50现在将来分析完了，　正在做定义CS　６４　， 弄no idea of potential business安定特产ramifications 后果.. = risk . 所以可能没做的是risk

identify risk只是一步《 assess risk

51uncertainty= risk

52执行相关方分析， 哪个最不用

53********评估process and tool =企业是否接受。 

review process and tools with enterprise = operational assessment业务评估 = enterprise readiness assessment 企业就绪程度评估

A enterprise 和 原文不一样

54 识别SH 一堆人的特征= survey搜集现有信息

brainstorming 新想法

 interview个别深入

组织模型- 信息不够身份信息啊身份证啊

D= ABC

57SLA 服务协议在线率非功能=nonfunction r

58为什么考虑组织文化-- 是否和未来目标达成相关

组织本身和capability-centric  无关

deem

effectiveness 

efficience 

allivate

58capability-centric 

59语言沟通有效性衡量：冷静有礼貌去表达紧急情况

C文字沟通书面： 文字选择得当

d SH之间的one another =negotiation

60

baseline 是什么

对象 标准权重 投票打分

a 是输出

B是解释

D不需要

62 65remain 

endeabvor

61变更评估不考虑什么trace repository

trace 需求才考虑trace repository  用什么工具怎么保存追踪数据

change 考虑：

62 EL R结束了， Review活动刚被安排还没进行， 你现在有的是unconfirmed R

63 做SHcollaboration plan =32SH engaement =参与时间和频率 包含D

a 在33 批准决策活动

C是BA的不是SH的所以不在考虑SH怎么参与的时候去考虑， 要主动学习

65应该降低复杂

优化应该是减低复杂性但是B是提升

6５对两个团队印象不同， 所以分析不够SH

６６准确一致性-- maintain 需求 跟新维护

67只有技术知识哪个不是= maslows hierarchy need 

rational rose建模工具

oriented面向服务开发架构

mercury 测试工具

maslow需求阶梯理论 生理- 安全-心里需求

68 procedure 什么先做什么后做， 改进哪个步骤-process analysis

69年底前实施solution所以要考虑的是对组织影响最小的方式- 时间约束， 影响最小的方式

CD 太局限太具体不全面 并不只有开发团队泰国局限

71interface visually图的形式

context 解决方案与外部接口实体交换的信息

sequence 是描述解决方案内部调用那些操作功能

在EL之前需要做什么：N　+313234

D是41 输出但是问题问的是这之前准备什么

74永华不知道不知道这个功能， 所以要找用户去宣传搞一个培训

76商业论证好处-- benefit最好量化表达

时间节省通过减少问题

77需求reuse = detail= tightly associated

c越详细绑定特殊需求越强

78企业评估是否接受能否变化- B

79买或者自己建立

D书上没提

disruption

71 context？？

morale

readiness

merits

81**接口分析不提供商业流程信息

A优势

D优势， 避免analysis paralysis 分析太多投入大

82价值交付情况最重要， 其次才是performance。 所以KPI+ 组织目标。

数据收集对了不代表绩效好

数据+组织目标-=C

DB少一个

83无中生有brain 识别一个机会去改进现有identify opportunity= brainstorm

DB流程分析

6 sigma?

75 allocated R输入

 

a single whole = requiment architectue : 最不会考虑的是C是输出86能力缺失 要改变所以去定义CS

a已经定义了CS

B不全面 还可以improve

Ctransition已经有了

Design 也是BA 输出 有 r  就有 d

91*******有些流程自动化， 软件只是比部分 ， 剩下的不在软件但不一定超出解决范围所以还是要document分析。

D是refrain 阻止分析

92

94分析影响然后做决定是否更改

95

96preventive提前

correct问题出现了在处理

negagement

SPI《 1 进展慢了项目滞后= corrective

99

100

决定而非风险， 风险是不可控的

101

模糊不可量化-goal

objective可量化符合SMART原则

剩下都可衡量 br  pv 

102***现状分析了解原因c

a 估算方法pert杜撰的太局限

BD局限 某种tech

103不同training， teacher要让别人快速懂=沟通读写互动。

B lesson

c局限

104 ba approach31方法论组织标准， 每个公司有不一样的标准那应该遵守。

C不会就学不应该考虑BA会不会

105risk= 价值交付带来的影响

106 不同的员工状态= state model 

108BA是重用需求可能性最高的人因为管理需求

109

reuse价值

110guidelines是有可能需要的不是input

112  管理SH参与程度是怕他们忙别的去了不参与， 

选他们能理解的模型是specify model 考虑的

114价值一次性交付所有国家= 预测形态

看板不迭代一次性

115alter不由评估人做

competemcies

114 provem tailored ?

115

incentive

undergo

elaboration 

premise 

velocity 

116没用新的还用老的， 还不知道原因所以还没发solution所以信息还不全没法给solution

118context- 最高层

logic- 高层

physical-底-层

120评估变更目的-衡量应用重要性和影响

implication of proposed change拟议修改的影响

B应该是同时满足Cs 和SC 不应该有or 

d 已经应用做效果评估

 

 

 

demolition 

在哪个里面

evisioned 

5678911

vicinity 

violate

16 18 23 25

sought prior 

perssue

procees model relationship with analist

30 31 34

 

那一章节出现了penalty

39

42  48` 50 51 52 57

deem

effectiveness 

efficience 

allivate

58capability-centric 

60

baseline 是什么

62 65remain 

endeabvor

67rational rose

oriented

mercury 

maslow

 

68

 

disruption

 

71 context？？

morale

77??

78 readiness

merits

79

paralysis 81

 

6 sigma?

94 96 preventive negagement

99

101

110

competemcies

114 provem tailored ?

115

incentive

undergo

elaboration 

premise 

velocity 

 

1

workssjop = facilitator +participants +scribe+ timer 

Specify model 任何状态EL都可以！！有elicit 就可以开始分析了

specify +EC 是平行关系所以随时可以由信息就分析***

X惰性 Y自发性

3.3 ， 问输入3.2

share ownership 分享参与

因为是对工作做分解PM在所以是 project scope 

BA是 solution scope

题目里面说的是2 team所以不是个人是组织架构

regression test 由 开发人员完成而不是测试人员

conduct R 下一步是整合结果发出去确认

BA不能confirmEL

15current准确定义问题， 不然之后有冲突SH 难判断，先确定问题， 后期需求满足问题才做。

a 描述的未来

B描述的CS

c。performance measure在将来定义

两个公司处理方式不同， 因为国际地区法规不同， 高管认为现状分析浪费时间，只要安装软件达成将来状态就好。 

所以要证明current 分析目的， 定义问题不然方向错了后面白做。 则会出现冲突无法确定谁对。 不然不知道要满足的问题是什么。

16主谓宾，主动语态可量化测试是一个好的需求

a不描述解决方案

b要看的到actor

d不确定的做不做不行

解决方案范围= functional decomposition

19名称是doc analyst 不是 review

性能问题问题是8.3 内部问题评估， 问输入是什么

考的少

 

parking lot - 记录不太重要的

A不该让他来

B让他提醒

C会后提醒

D我自己记录--本职外

系统交互图 context是顶层数据流图

a 是底层数据图描述

B对的

C 不具体

D没点出顶层

 

maintain R 的 SH =  SME  support reulator  tester 

A都需要使用需求

S不全面

C组织角色

 D太具体

3.5书上没给出标准答案去衡量BA绩效， 因为每个组织都不一样

不愿意现状分析

人和系统， 系统和系统- 转递信息 interface 

d statue model 状态模型

34规划BA info management

 

reuse= plan ba info / maintain requirment 

d在当前迭代

什么是BA info 都可以

 

phase-- predict预测性

plan 都是必要的-- 所以 not essential 错的

预测形态的任务都在backlog里面无细节但是必要排序

53 54 共有输入 R

评估变更的输出是：

elapsed-全部时间

不能代表多数人workshop 局限， 一般都是人少所以C不对， 都会担心人太少

重要人没参加workshop则无法表达需求

risk analysis是分析， 但问题是document所以是iteamtracking

 

53 排序

basis- 风险

排序的好处是不对的，项目的好处可以of requirments 

 

1*温度感受器准确程度划分价格， 准确度地的产品需求量地， 提高准确率或者替代掉

满足条件最小改建

2*

3*单价增长高

4*成本35

3年3万件收回成本

6过海关

7*

比较痕量择优

9*SH会被影响

11*B 比C好， 因为C可能只说PM

23*80/20法则pareto's law 先解决加总》 80 的

 

24

 

25*响应速度的提升

26

27组织内部操作过程

33增加容量

A系统好用自然会买

34管理层沟通， pm 也是管理层

35新增加功能l不会降低成本， 但是会增加usibility

2*没谈过：将来状态约束和假设

4* 7.4 view- architecture不同SH不同视角描述需求架构

6*

10*范围设定那些做或者不做

17

21

23*容量变化， 以小组和大量数据出现问题

scalability伸缩性， 小组测试没问题， 但是更多的产品册hishi'fou'you

24非功能需求-scalability需求

25有多大么讲清楚

all

1

3用gap  analysis 去发现改变

4包括那些内容

5***

6***

第一年7 之后每年12

五年后114

算回报 但还没有其他数据除了财务之外的额

7+1.2*4=11。8

小于11。4

7有优化流程成机会 ， 员工数量减少30%， 但做这件事情要加10 ， 所以共减少20%

8*关闭新任务

A没理解预测到风险： 情况意料之中但下线觉得市场有信心

B知道并且接受了风险

9*最佳选择

 

10*

12*

14*

22其他都一样只有rpn不一样，而且是风险贾总

24

RPN不是保持不变的是变化的， 不同项目不同计算方法

25

26

27为什么改变

30

31*第一年支出300 之后50 

另一个收入200-3000-400-400

 

32*

收益800 但是还有其他支出 文中没有提供所以会小于800

33*回报率=收入/初始支出））/初始投入

 

34回报期== 持平年份

36真是实践价值， 不知道几年 信息少

38*至少五年的信息给了

给了什么假设

procurement采购

39波动-- 不会考

40*

 

 

 

1

 

2

1 BR 

2 Detail R -- relationship -> tarce R

可以是需求和成果关系

adress

4 开发阶段发现问题需求变更， 需求额与实施关联发下的是 backward，详细需求回溯找到上层需求， 去确认有价值的

与工作执行相关的顺序一致的是forward 把概括的拆分为详细的， 开发与成果管理

5.1 traceR 有两个方向

CS是整个变革， 而不是一个需求便更的实现方法

 

5reuse持续要满足， 通用需求，规则类

特定类不太宠用individual

13实施类人去评估某个改变成本比较合理

PM是项目级别的成本评估

DomainSME评估价值

15

ACD 没提到

24

AB无法判断

27

28

有forward， 但是没有back

CD没提到

32遇到变更-- 做调研和分析

35

36

Must》 should> could >have

 

1

3

4

6

25

27

28

29

30**process zhong 

33**还在准备阶段

elicitation result 

 

review 多种形式

34**只有第一个没提到

35**对现有分析

36界面分析- 

37第一步

38must have

41

 

2

3

4

变更措施

5

没衡量指标

 

没有b cd信息

7无证据是个假设

11

12

13

14立场分析， 加总分数

15

17sponsor影响力最大

20

21need reproduce 才会需要被追踪不然也修改不了

22

23

24

26

27

30

32****

37

38

39

40

41

42

43

45

48

51

52问题存在才去解决

54

55

60

63

 

1

2

3**

4

6

7***

8

9

10

11

12***DFD数据流图， 对数据的操作， 来自内外发送内外

13

14

16***

18

19

21

24

28

29***

31***

33d 不懂manage选不理解

35

36

41

43

46

12/4投资回报率

12/6

52

57

81

 

1

风险发生50% 的话价值

18-10  *0.5

3

4********

6

7

8

15

18***

可量化的

20

21

24

25

27

23

29***

a solution scope 具体到某一个解决方案的内容

b change strategy不同的方法

C solution space所有的备选方案集合

30

具体的细节描述如何实施

 

31***

 

ba 给信息sponsor做决策

32

35

36

37**

38

39**

41

44

46

48

50

51

52

56

57

58

60***

61***

 

2

3

4

5

6

7

8

10

12

13

14***

前三个都需要在绩效里

review- 实在需求确认的一项任务 

17

25

30

35

40

42

45

46

49

51

52

53

57

59

62

 

 

3prior 之前

4半天做准备没准备好

6

瀑布模型

需要why 信息

 

14

16

20

21

22

23

24

28

30

39

43

50

51

55

1，Objective need to meet SMART：

Specific 具体的

measurable 可评估的，可考核的

achievable 可达成的

relevant 与公司的VISSION & MISSION &GOAL相关

time-bounded 有时效性的

2，Change strategy :  from current state to future state, 商业论证（BUSINESS CASE) or roadmap

3，通过审批后，可以启动BA商业分析的工作

4，方法论选择：适应型还是预测型

5，制定BA的工作计划，同时也制作衡量BA工作的表现/绩效考核和改进计划，相辅相成

6，收集/发掘需求 - 未经确认的到经过确认的结果，这些是需求的原材料，然后正式输出需求（7.1-specified and model requirement)

7, 需求分析和确认

需求质量审查-verify，是或清晰，可量化等

需求价值审查-VALIDATE：BACKFORWARD TRACIBILITY，是否能回溯到顶层目标和战略上

8，解决问题的方法途径 - 备选方案：solution recoomandation

外包的话，那就得给出可选择外包供应商

9，BA不输出NEEDS & CONFIRMED SOLUTION( IM SME的 工作成果）

10，实施SOLUTION后，要进行解决方案表现考核和分析：TARGET VS ACTUAL

11, 找到ROOT CAUSE和改进建议，促使SOLUTION DELIVER TARGET, ACHIEVE THE GOAL；改进有可能=新的需求

Underlying competencies 

1，分析思考和解决问题

创新型思维

决策型思维

持续学习

解决问题思维

系统性思维

概念性思维

可视化思维

2，商业知识

商业头脑

行业知识

组织知识

解决方案知识：商业软件，使用方法，价格

方法论知识：SCRUM, RATIONAL UNIFY PROCESS

3,沟通能力

语言沟通

非语言沟通

书面沟通：留下记录，长时间保存

倾听能力：获取信息

4，协调/协商能力

策划组织者

领导/影响力

团队合作

谈判和冲突解决

讲课：保证对方理解传达的信息，尤其是需求沟通时，确保相关干系人理解该需求

5，行为特征

职业道德

可信度

可靠度

组织能力/时间管理

适应性

OFFICE工具和专业工具：visio

BA工具/专业性工具：o建模

沟通协作工具/专业知识：知识库，邮件，APP

 

50种技术

启发，沟通和合作

头脑风暴

合作游戏（LEGO GAME）

文件分析：收集信息常用的方法

焦点小组：针对一款产品在市场上用户对的观点是什么，可以邀请用户来进行小组讨论-定性研究分析的方法

采访/访谈：常用，结构化（预设结果）和非结构化（开放式）两种，一对一，多人，线上，线下

实地考察：操作流程观察收集信息，GEMBA,补充和校验其他渠道收集来的信息

原型：纸和笔去画草图，专业软件制作模型

抛弃型（低保真），进化型（原型变成解决方案）用户交互比较多的情况下使用

审查：WALK THROUGH, PASSROUND, DESK CHECKING, 

问卷调查：多地域，多语言，多时区

研讨会：多人参与讨论的方式，有分歧就一起来讨论最终达成共识，形成一致意见

分析技术

发现/识别问题

对标同类和市场分析

商业能力分析：实际和需要具备之间差距有多大，有多少

商业模式画板：9个维度

根本原因分析：鱼骨图，5WHYS

定义问题

商业论证（BUSINESS CASE)

范围模型：宏观层面，功能分解

人/组织分析

组织架构模型：OC

角色和权限矩阵：R & P matrix

干系人图/表/虚拟人物模型

数据/信息

数据字典：数据名称的注解合集

数据流向图：数据通路，data flow diagram，两种rotation

数据模型：数据实体对象描述的元素 ENTITY RELATIONSHIP DIAGRAM, CLASS DIAGRAM(类图); 概念性的数据模型，逻辑层，物理层需要更加专业

缩略语/术语表：GLOSSARY

接口分析：INTERFACE ANALYSIS，系统与系统之间的会有接口表：接口名称，传递什么数据，校验规则，接口触发机制；系统跟用户之间的交互，也在这个范畴内。优先定义的对象

状态模型

流程 process

流程分析

流程模型：UML，BPMN

时序图：类模型基础上，具体到某一个功能一个场景，需要调用哪几个类，获取哪些属性

决策 decision/rules

业务规则分析：规则目录，统一认知

决策模型：DECISION MODELLING， 决策表，决策树(DECISION TREE)

决策分析：具体做出一个决定的方法

FUNCTIONAL / NON-FUNCTIONAL REQ

functional decomposition: 功能分解/拆解

user cases/scenarios: 用例和场景

user story：用户故事：ACTOR/WHAT/WHY（VALUE) 符合敏捷理念

通用分析方法：

概念模型

数据挖掘：基于大量的数据，发掘趋势和特征，发现问题/原因/预测情况

脑图/思维导图：针对很多信息进行梳理和归类，形成直观和见解的关系图

设定目标和评估

验收和评价标准：针对某一个对象就是验收，针对某一些对象（多个）就是评价

积分卡：4个维度设置目标和衡量机制：战略层面到操作层面，四个层面都一致，SCORECARD

收益/成本领域

经验教训总结LESSON LEARNED

供应商评估

计划/规划

估算

跟踪和管理

未完项表 BACKLOG 

ITEM TRACKING: 风险，问题，

优先级：需求优先级排序，变更优先级排序

风险分析和管理：需求，解决方案相关的风险

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BA need to answer what and how, mainly "what" or "why".

Step 1: understand the needs.

Solution approach: possible solutions

 

 

1, MOE = KPI