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，解决不了问题

 

 

 

 

 

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 ， 这个解决方案交付的价值=预期价值- 成本