避免用例驱动的坑

一、什么是一份好的用例

能和客户达成需求共识，就是一份好的用例！

• 从用户的角度，用例比模棱两可的功能点描述要清晰，也更直白。
• 从开发团队角度，RUP的核心方法论之一---用例驱动，明白人自然明白它的妙用。
• 设计人员的设计手段：“用时序图分析用例的实现，在描述过程中确定构件或类，分配它们的职责和方法”，通过对用例覆盖率的追踪，需求与设计之间的信息损耗这个巨大问题会大大降低。

二、避免用例驱动的常见坑

1.客户没有能力阅读用例

解决方法：放弃编写用例，改回用户容易看的传统方式。例如做原型图

2.团队没有能力实现用例驱动

如果开发团队在设计与测试时，根本不依照用例细节驱动，那用例对开发团队就只是个摆设，花瓶。

解决方法：对设计、测试人员进行用例驱动的培训，如果事不可为就干脆放弃，怎么省事怎么做。换用户故事？

3.在用例中描述系统内部工作

开发人员常把用例当作设计文档来写，如“系统将销售信息写入数据库”，实际上应该写的是“系统记录销售”。

解决方法：站在客户的角度，把系统视为黑盒，删除所有内部设计描述。

4.在用例中描述界面

如果在意用户信息包括了姓名和密码，可以在词汇表里记录，而用例写成--显示<用户信息>。

5.在用例中越出系统边界描述整个业务流程

要建立的系统只是整个业务流程里的一部，善良的需求人员为了大家清楚来龙去脉，将系统外的处理步骤也写进了用例的情景。

解决方法：开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。

6.过多的扩展事件和异常事件流

即使是受过训练的程序员，2a,3b1看多了也要晕掉，记住阅读者是人而不是机器。

解决方法：

1.如果逻辑不多，可以一句话讲完，不影响主场景的，不建议新起一个事件流。

2.可以使用活动图来辅助说明。在RSM7.0的模版里，每个用例都会带上一个活动图。

7.过多的关系

“不要花一个月的时间去讨论应该include还是extend”。大家对include,extendandgeneralize都不熟悉，那就干脆都不要用了。