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

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

3.3， 问输入3.2 31 AB都对

share ownership 分享参与

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

BA是 solution scope

 

=

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

 

 

 

 

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

a 描述的未来

B描述的CS

c。performance measure在将来定义

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

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

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

a不描述解决方案

b要看的到actor

d不确定的做不做不行

性能问题问题是8.3 内部问题评估solution limitations 用着用着系统就不给力了 ， 问输入是什么

考的少

maintain R 的 SH =  SME  support reulator  tester 

 

 

 

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

27合并 公司， 两家公里方案不同，需要合并系统领导愿意现状分析，  了解现状有助于合规

PM 不参与plan ba info 34规划BA info management

 

重用= Plan BA info / Maintain Requirment

phase-- predict预测性

迭代 - 自适应

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

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

 

53 54 共有输入 R

评估变更的输出是：

elapsed-全部时间

 

 

 

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

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

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

 

 

53 排序

basis- 风险

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

8scope将来方向解决方案告诉我们是什么 solutionscope=new capabilit = current VS Furniture新增加的东西-

project vision将来目标没有new capability新增加的东西-- 要有现在将来的分析比较

34 如何获取的方法途径approach option

111 建模因素71 考虑建模目的， 听众， 环境因素行业规范

为需求建模要考虑的因素= 目的+听众+内容

12 流程图比文字直观对不同语言用户友好

不同地点人所以文字不好图片好

并不一定需要formal， textual use Case都是文字不好

process model是图片会好点

14评估变更考虑因素是什么好处， 成本， 影响， 日程， 紧急度

C都太高层次而不是具体的每一个变更

118***绩效衡量， 指标设定由3 个考虑因素， reliable数据可信度不可以太波动，validity有效性可以准确反映所以要相关， timeliness数据时效性。 

1数据可靠度 有一致性

2 有效性， 能有相关性去反应

3 数据收集延迟等时间性

C时效性不强所以不reliable收集 品读不对

A BD是有效性的问题

题目显示valid没事儿所以在reliability和时间

 

22artifact = 输出

当遇到问题要怎么处理， 要在哪一个任务的输出找到。 

C是个TECH 不是一个产物artifact

一个顾客可以下多少订单， 一个实体与另一个实体之间关系是cardinality基数

对商品描述的属性= claSs, 类图包含操作， 包含关系UML

cost and benifits of doc = business case 

39可能不靠谱的信息-在打高尔夫的时候知道的 ， 还是先搞一下现在的，如果不行才是C

41

approve 可以不正是， 预测的在结束和批准会。 适应性在迭代结束的时候/正式开始之前

批准要看SH engage approve 表

45

data model 数据商业规则

概念模型名词动词去体现关系与业务规则

数据模型列出实体数据具体规则定义

46guideline tools= 输入

48DM= ERD+Class Diagram

 

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

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

选择 A business Need 因为是SA分析

 

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 成功增加

选择 D 

315+55+19除以450  因为说的是额外的建议， 所以文件的建议还在

6

 

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

 

dependable可靠

trustworthiness值得信任

23business plan  不在 business Case 里面

 

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

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

notation表示法

35 SE input 

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

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

 

40 ISME， customer， end user, sponsor and pm 排序，DSME 不排序

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

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

追踪在什么程度A

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

A 培训

题目要的是interact 所以survey不行

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

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

 

encountered遇到

pilot

51PV +sol performance =8.2 analysis

56mind map - 识别分类信息

 

做BBBBBBBB identify business requirments做现状分析只说了elicitation其他都没说

6443

 

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

 没成本模型

 

  66项目完成了去回顾= LL

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

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

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

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

72confirm EL 用到的 74唯一的改进成本高于实施10被- 那么就不改变= CCCCCCCCCCCCCCCCC

 继续现有的

75BN 有了但是solution design无法达成共识， 技术沟通都挺好的那有可能是需求的展示方式太难看懂了interpretedAAAAAAAAAAAAAAAAAAAAAAAAAAAA

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

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

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

 

77likely to be unhappy - risk  

78

90考试不考

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

 

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

SHcommunity plan 是通用的不够针对

 

100需求不稳定 实现往后放

 

110-有些需求和监管冲突，　trisk averse 通知SH监管需求优先

 

企业》 组织

 

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

都说是针对现状的

2组织构成提供的产品服务

组织内部现状分析- BArch

B是A的一部分

C是组织外部的

D文章都是内部

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

AB是project所以不是BA 是PM

project= PM

BA做价值衡量

d 不是BA的范围

4提升成功率

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

第一个＜　７５要改进

Doc被拒绝的多所以要有个ｌｉｓｔ　检查 去排除问题

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

6

7

8

 

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

８一年内销售增加１５％　客户增加１０％

按照保险费为金融价值

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

用了衡量指标，　还有决策分析

问题是验证所以还是用衡量指标比较符合

因为用了衡量指标。去确认期望结果是否达成

一个是收入增加15 用户10% 

 

9确保每个人加入进来了－－　SH

只有A是对SH的

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

 

retension

premium

11 要做改变优缺点　是做影响分析

　查看

12饮料制造商，　有季节性波动，平常6０　吨　高峰季节无法满足顾客需求１００　吨　

限制是从经济角度无法增加卡车和驾驶人员数量

交付流程有四步

结果有五个因素

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

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

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

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

14提出什么建议消除浪费

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

A提前让他知道

B提前做准备－　不全面

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

15主要目标－　满足顾客再高峰时期

D和绩效无关是

市场波动，　还要尽可能满足需要

16改进解决问题address issue？ root cause

A没解决

C 没改进

17优先考虑量化原因--客观

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

depenable -可靠 不对

subjective 主观

互相指责

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

D让他冷静下来

19同时多任务协调能力 person org

 

dependable

trustworthiness

23business plan  不在 business Case 里面

25品牌声誉组织内部资产

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

28原始和复合数据元素

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

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

views填充实际内容

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

LL工作结束了

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

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

notation表示法

35

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

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

37

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

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

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

distinguish

40

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

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

追踪在什么程度A

42谁想要什么= user story

use case有很多交互细节

A是组织层次

B更直接谁想要什么

C太细致了

D包含什么不包含什么

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

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

43 huigu

interact了解一群人信息- workshop

A 培训

题目要的是interact 所以survey不行
44  45

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

avoid是完全不见了

mitigate降低可能

47

一天取3次- business rule 

不满意- data mining 

 

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

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

 

encountered

pilot

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

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

56

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

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

60 rational 模型分类五：ABD71 没成本模型

diagram 

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

graphic

focusedgroup 收集看法

哪个是同意想法

统计抽象方法去搜集数据= 多久和时间是做统计必要的

FA不一定， BD不是tech

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

 

  66项目完成了去回顾= LL

67每周新产品， 面一样料不一样，需求重用是面dough

topping会变

所以重用的是dough面团

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

可测试不是关系

74 requirement architecture 有不同视角但需要有关联， 所以检查视角

高质量是针对某一条testable

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

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

75无法达成共识决策机制没确立

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

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

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

 

77 

interpret

articulate

81 verify结束， 确保validation

A Verify

D validation

82 评估变更

85输入

87

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

88ll= 回顾

89

90考试不考

91

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

93方法论改变

商业分析时间改变

C影响不大

AD无关

94评估变更管理

96需求分类 需求与发布建立关联确保实现

时间和价值

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

97 

pertain 

hamper

tracibility/ item track /trace R

99

100需求不稳定 实现往后放

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

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

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

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

109风险评估输入

117

SA是持续进行的活动

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

1234 6 78 9 10

retension

premium

11 12 13 14 15 16 17 19

dependable

trustworthiness

23 25 27 28 29 31 32 33 35 36 37  38 39

distinguish

40 41 42 43 huigu 44  45 46 47

encountered

pilot

52 53 56 58 59

60 rational

diagram 

graphic

65  66 67 69

72 74 75 76 77 

interpret

articulate

81 82 85  87 88 89 90 91 92 93 94 96 97 

pertain 

hamper

tracibility/ item track /trace R

99

100 101 107 108 109

117 120

1. Difference between open-ended & unstructured: interview usually start with open-ended questions and close with closed-ended questions.

35

37. First step for survey/questionnaire

40 environmental requirements

prototyping

52

60

40 bring  the project back on track ???

1. Predictive Approach should be care for the detailed information which will be concerned at the beginning;
2. how to store the information involves taking into consideration ghe type and amount of information to be collected, the stakeholder's access and usage needs, and the size and complexity of the change ( think about work flow)\
3. (29): traceability management is a predominant feature of requirements management system.
    
4.  Organization lays' pro consider to answer with delete methods which finds the same lays  and different lays.
5. (35???)

left to

wrongly answered questions:

#4,5,8,9,11,12,14,16,17,19,20,24,25,27,30,31,33,34,39,40,42,48,50,52,55,58,59,61,62,65,72,73,78,83,88,91,94,95,96,97,100,112,114,120

 

questions with highlight:

#19,23,24,33,34,40,42,47,52,58,59,65,80,82,88,94,102,104,110

questions to be remarked:

#2

wrongly answered questions:

#3,5,7,10,12,18,26,29,31,33,36,38,41,43,51

 

questions highlighted:

#5,7,10,18,31,33,38,43

 

Note:

#46: 要计算投资回报（ROI），所以option 4的投资回报更高

wrongly answered question:

#1,3,6,8,9,10,13,14,15,28,30,34,35,37,39,40,44,46,50,61

 

Questions to revisit:

#9,14,15,30,39,40,50,59,61,

 

#50: option D: 'constraints' means the limitation while opting the solution approaches

wrongly answers questions:

#1,2,7,15,21,23,33,34,38,40,42,43,45,47,48,49,54,56,57,60,61,62,63,67,68,69,70,74,75,76,78,79,81,83,91,97,100,101,109,110,112

 

questions to be reviewed:

2, 7,9, 33,42,45，56, 62, 63,64, 69, 72, 74 , 76, 77,79,89,90,91,96, 101,107,110,119

 

#63 - cannot be 'group interview' as the interview technique is commonly used for req elicitation, in this case, the req and design already delivered, it is only to seek the potential value of this req and design, hence need to hold a 'Focus Group', which is to gather more subjective perception from the attendees.

 

#101, the question already address 'conforms to org structure', which implies indicative issue of the org chart has been consider, hence, the only factor that may not be considered is 'informal relationships'

 

#119, 'Data mining' usually used for solution measure analysis. this question already implies that this product is alreadt being used.

 

Sep/23: 

questions with highlights；

#2,23,42,49,58,62,63,66,72,75,78,96

4

9

11

16

36A不一定吧？

57B

4

25

26回看3.5

31

35

42

44

47

49

 

14

19
23

24

20

20

22

39

 

28

30

32

5

6 

21 and 29 and040  52 

 

36