在使用实例的方法中应注意如下的陷阱：
• 太多的使用实例如果你发现自己陷入使用实例的爆炸之中，你就可能不能在一个合适
的抽象级上为之编写文档。不要为每一个可能的说明编写单独的使用实例。而是把普通
过程、可选过程以及例外集成起来写入一个简单的使用实例。也不要把交互顺序中的每
个步骤看成一个单独的使用实例。每一个使用实例都必须描述一个单独的任务。你将获
得比业务需求多得多的使用实例，但你的功能需求将比使用实例还多。每一个使用实例
都描述了一个方法，用户可以利用这个方法与系统进行交互，从而达到特定的目标。
• 使用实例的冗余（duplication accross） 如果相同的函数出现在多个使用实例中，那么
就有可能多次重写函数的实现部分。为了避免重复，可以使用“包括”关系，在这一关
系中，将公共函数分离出来并写到一个单独的使用实例中，当其它使用实例需要该函数
时，可以请求调用它。
• 使用实例中的用户界面的设计使用实例应该把重点放在用户使用系统做什么，而不是
关心屏幕上是怎么显示的。强调在执行者和系统之间概念性的对话的理解，而把用户界
面的细节推迟到设计阶段。任何屏幕上的画面和用户界面机制的影响只是使执行者—
系统交互的可视化，而并不作为主要的设计说明。
• 使用实例中包括数据定义我见过一些包括数据项和数据结构定义的使用实例，可以在
该使用实例中操纵这些数据项和数据结构，包括数据类型、长度、格式和合法值。这个
方法使项目的参与者难于找到他们所需要的定义，因为使用实例中说明它所包含的每一
数据定义是不明显的。这也可导致冗余的定义，当一个使用实例改变时，其它的没有改
变，但破坏了同步性。应该把数据定义集中在适用于整个项目范围的数据字典中（第9
章讨论），以便在使用这些数据时减少不一致性。
• 试图把每一个需求与一个使用实例相联系使用实例可有效地捕捉大多数所期望的系统
行为，但是你可能有一些需求，这些需求与用户任务或其他执行者之间的交互没有特定
的关系。这时你就需要一个独立的需求规格说明，在这个规格说明中可以编写非功能需
求文档、外部接口需求文档以及一些不能由使用实例得到的功能需求支持。
