Book7-基于用例/场景模型展开用户需求获取

1. 相关新闻

1. 上市
   1. 千亿市值的泡泡玛特(12.11)
      1. 投资人对王宁的评价：学历平平，没正经上过班，说起话来表情平静，没感染力，团队也没有精英。
      2. 上市后：王宁性格沉稳，话不多，喜怒不形于色，拥有”消费创业者”的许多优秀品格。
   2. Airbnb上市(12.10)
      1. 12年，30-68-144(164)美元/股
      2. 国内：途家、小猪短租、美团民宿
2. 社区团购
   1. 京东入股兴盛，美团优选查贪腐
   2. 永辉超市彩食鲜获10亿腾讯投资：类似河马
3. B站跨年晚会
   1. 元气森林, TVB，武汉文旅，湖北广电
   2. 央视频(未来电视) 学而思 题拍拍
4. 宣传海报如下，包含了商业模式多种元素

1. 目标模型用于组织系统的目标、特性、任务等与业务需求相关的内容,目标分析过程是建立目标模型并验证其正确性、完备性、一致性的过程。
2. 用例/场景模型用于组织用户需求的相关内容，用例/场景分析是建立用例/场景模型的过程，但用例/场景分析无法完成对用户需求相关内容正确性、完备性、一致性的验证。
3. 面向对象分析模型或结构化分析模型用于描述软件解决方案的细节知识，组织和指导系统级需求的建立。面向对象分析或结构化分析是建立面向对象分析模型或结构化分析模型的过程，同时还能够验证用户需求相关内容的正确性、完备性和一致性。
4. 用例/场景模型不是保证用户需求相关内容正确性、完备性、一致性的的主要手段。
5. 用例/场景模型能够及时地将每次需求获取活动的进展组织起来，展现、提供给分析活动，并在得到分析结果后进一步指导后续获取活动，所以其是用户 需求获取活动中的主线索。

3. 场景/用例

3.1. 为什么需要”用例与场景”

1. 场景是更为基本的元素，用例是一种特殊场景，是需求工程师在组织需求是更喜欢使用的场景类型。
2. 获取笔录：权宜之计
   1. 用户需求+问题域特性
   2. 混杂、不清晰等特性
3. 用例与场景
   1. 场景为单位
   2. 问题域特性或者用户需求+问题域特性
   3. 组织清晰

3.1.1. 场景

1. [Zorman1995]将场景定义为对系统和环境行为的局部描述
2. [Plihon1998]将场景定义为对行为或者事件序列的描述，序列中的行为和事件是系统需要完成的一个任务的特殊示例。
3. [Jarke1996]认为场景包含有行为序列和行为发生的环境，环境描述了行为的主体、客体和上下文设置
4. 以上的描述都不足以作为场景的准确定义，人们也很难给场景下一个非常准确的定义[Rolland1998a]
5. 场景强调系统同外部环境互动以完成预期任务，具有重点描述真实世界(商业模式设计：讲故事->场景)的特征，它利用情景、行为者之间的交互、事件随时间的演化等方式来叙述性的描述系统的使用

3.1.3. 用例与场景

1. 以用例/场景为单位组织用户需求(和问题域特性)
2. 很受实践者欢迎
   1. 易于接受
   2. 易于使用
   3. 用例驱动！
3. 方法多样，差异性很大
   1. 也可以用来处理业务需求和系统级需求
   2. 还可以用来处理设计问题、测试问题……

3. 弱点
   1. 只考虑其他内容与功能需求之间的联系，却无法描述其他内容相互之间的联系，例如质量需求的相互依赖(目标模型)、界面需求的跳转(对外接口中的人机交互文档)、对外接口需求与质量需求的联系(IF作为主体承载目标实现)…
   2. 只考虑存在联系的事实，却无法分析联系的合理性，例如有无遗漏功能需求、数据需求及业务规则是否充分、质量需求是否可行(需求分析)
4. 所以，虽然用例/场景的优点非常明显，但它毕竟只是一种组织形式，不能寄希望于单凭用例/场景模型解决所有问题[Gottesdiener2002]，目标模型、面向对象分析模型或结构化模型等其他的模型形式仍然是必要的。

3.3. 用户/场景的层次性

1. 用户/场景是有层次性的，用来组织业务需求内容，如下图。

3. 可以用于组织系统级需求

3.4. 基于用例/场景进行软件开发

1. 以用例驱动的软件开发某种程度上就是需求驱动的软件开发。

4.1. 场景定位

4.1.1. 场景的形式：场景的表达模式

1. 描述(Description)
   1. 表示法的正规性
      1. 非形式化语言：完全自由、没有任何规则
      2. 半形式化语言：有一定规则但不严格
      3. 形式化语言：有形式化体系，完备的语法、语义和语义
   2. 媒介形式(Medium)：叙述性的自由文本、结构化文本、强限制文本(半形式化)、建议使用表格、图表、图像等非形式化语言。
2. 外观：场景被表达出来时的效果
   1. 静态外观(主)：展现为一个或者数个描述性的文本或者图片。
   2. 动态外观：以动态的方式展现出来，用户可以按照时序查看。
   3. 交互外观：用户可以一定程度上控制和改变场景的变化时序和效果。

4.1.4. 生命周期

4.3. 用例模型

4.3.1. 用例

4.3.3. 关系

4.3.3.1. 关联

1. 关联：用例和参与者之间的关系，描述了用例与参与者的交互。

4.3.3.3. 扩展

1. 不修改原用例，建立新需求的附加用例，使用附加用例扩展原有用例。
2. 执行附加用例前优先执行原有用例的流程。

4.3.3.4. 用例泛化

子用例继承了父用例的特征并增加了新的特征。

4.3.4. 系统边界

1. 基于前景与范围建立初始用例模型：依据系统用例图、目标模型建立初始用例/场景模型
2. (迭代)展开用例
   1. 据用例/场景模型指导获取，完善层次结构：选择合适的需求获取方法获得用例的详细描述，比如面谈、原型、头脑风暴、观察…
   2. 使用用例/场景组织获取内容
   3. 分析用例/场景发现仍需获取的需求内容
      1. 选择合适的模型分析用例描述
      2. 类图、顺序图、实体关系图、业务规则模型……
3. 验证场景/用例模型：评审用例描述
4. 维护用例/场景模型
   1. 用新组织或修正的用例/场景完善用例/场景模型
   2. 依据用例/场景模型组织需求分析模型

5.1. 依据系统用例图和目标模型建立初始场景/用例模型

场景的逐层展开不等于用例！

3. 具体用例中发现的模糊、不正确、不完备等细节内容需要再获取

5.3. 用新组织或修正的用例/场景完善用例/场景模型

5.5. 分析用例/场景发现仍需要获取的需求内容

1. 用例/场景没有验证内容正确性、完备性和一致性，我们需要使用分析技术来验证。

2. 最左图的交互不足，修正为改进一：无法绘制系统顺序图。
3. 改进一对于数据的描述不足，修正为改进二：无法建立概念类图。

5.6. 例子

1. 正常流程(触发条件，每天晚上)
   1. 车队报勤，包括人员报勤和车辆报勤
   2. 如果有新任务，新建用车计划。
   3. 根据用车计划，开具路单
   4. 为路单开具出门证。
2. 扩展流程
   1. 没有用车计划，也有可能开路单。
   2. 开路单的车辆选择也可能不算报勤车辆
   3. 没有路单，也有可能单开出门证。

展开用例	组织获取内容
用例展开	组织获取内容

3. 面谈报告：面谈对象：调度人员-车辆报勤

5.7.2. 交互明晰(信息传递)改进

5.8. 用例文档

6. 本章小结

1. 需求获取的展开过程是递进、迭代的，场景/用例模型在其中起着重要的作用
2. 场景/用例是需求的组织手段，是一种更为用户接受的需求线索表达方式
3. 在实践中，场景/用例模型有很大的差异性，要正确掌握和使用需求的场景/用例特点
4. 围绕场景/用例模型为核心，可以展开用户需求的获取活动

来源：SpriCoder