《编写有效用例》读书笔记三

第十七章：用例在整个过程中的作用

用例在项目组织中的作用：用例为管理者指明应提交给用户的系统功能。用例的标题指明主执行者的需求，同时系统也必须支持这些需求而用例描述则说明系统需要什么功能以及将提供什么服务。通过用例标题进行组织，采用规划表进行规划、评估、划分优先级并尽可能减少用例集。用例表清晰显示系统对整个业务的价值，用例名列表为基于优先级的工作和时间表提供了依据。还有跨版本处理用例，交付完整场景。从用例到任务或特征列表，指定软件设计任务。用例仅提供了设计所需要的所有黑盒行为需求，这些需求仅描述系统行为而不对设计者进行任何限制，只是帮助设计者利用他们掌握的技巧完成复核系统需求的“好”设计。需求与设计都不是要去满足用例。用例和功能分解。面对对象设计者需要注意考虑利用场景设计，命名域概念等。从用例到用户界面设计，从用例到测试用例等。

实际用例编写应制定一份粗略的系统功能图：1对系统采用的叙述方式达成共识2对应用领域达成共识，并集中讨论系统主执行者和系统目标3编写系统描述4收集各种系统描述。制定详细的用例视图：1集中研讨用例编写2对用例编写格式达成共识3编写用例4审核用例（个人）5审核用例（开发组）。注意用例需要的平均时间，从大型团队中收集用例。

 

第十八章：用力概述和极端编程

极端编程指开发组不需要编写软件详细需求而只记录下“用户的故事”作为有约束力的备忘录以便将来能围绕这些功能讨论需求。

 

第十九章：错误改正

在编写用例时，最常见的错误是遗漏句子主语、假定用户接口及目标编写过于详细等。大致错误有：没有系统，没有主执行者，过多的用户接口细节，过低的目标级别，目标和内容不符，用户接口描述过多的改进实例等。

 

第三部分：对忙于编写用例的人的提示

 

第二十章：对每个用例的提示

1每个用例都是一篇散文，既要采用单调的写作方式又要富有完美的表达能力。

2使用例易于阅读要求文档短小简明。

3仅用一种句型，现在时态的句子，在主动语态中用主动东西，描述执行者成功到大的目标这些目标推动了整个过程的前进。

4“包含”子用例

5谁控制球也就是执行者明确

6正确地得到目标层，确保使用用例的目标层正确地标记用例。

7不考虑GUI，确定抓住了执行者的真正意图而不仅仅是操作用户界面的动作。

8两个结局：成功或失败。

9项目相关人员需要的保证，系统执行项目相关人员之间契约上的协定。

10前置条件

11对用例进行通过/失败测试

 

第二十一章：对用例集的提示

12一个不断展开的故事，顶级用例和其不断扩展用例和子用例。

13业务范围和系统范围。业务用例的设计范围是业务运作，通常以白盒方式来编写描述公司中个人和部门之间的相互作用。业务用例描述了业务的内部情形而系统用例描述了计算机系统外的情形。

14核心价值和变化：核心价值包络所基于的目标、从系统外部的观察角度、可读性。用于多个目标、黑盒需求、在主成功场景之后的选择路径、不要太费精力；适当的改变包括编号的步骤与简单的分段、非正式与完整正式、有或没有用例的优先级业务建模、用例图与执行者-目标列表、白盒用例与协作图、主成功场景中的条件语句、用顺序图代替用例文本、功能规格说明中的GUI。

15用例集中的质量问题：每个用例都是来源于对最高层到最底层目标的展开吗？对每个主执行者在最外层的设计范围内都可能存在一个与设置语境相关的，最高层的用例吗?这就是所要开发的全部内容吗？

 

第二十二章：处理用例的提示

16仅仅是第三章：用例只是整个需求收集工作中的一小部分，是需求文档的“第三章”

17首先向广度上努力

18十二步秘诀

19认识错误的代价：降低用例质量所带来的开销。

20喜欢蓝色牛仔服，使用层次较高的低精度目标并且采用简单的故事形式。

21处理失败情况

22前期和后期的工作标题

23执行者扮演角色

24大的图画恶作剧：显示高层用例和低层用例的关系。

25大型工具的争论，使用什么工具来描述用例，文本用例方式还是图形用例方式。

26使用标题和简介的项目计划：用例计划表，交付部分用例。