用例怎么理解呢？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合
用例模型怎么理解呢? 用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用, 系统建模有许多种方法，每种建模方法可以满足不同的目的。然而，用例模型最重要的作用是将系统行为传达给客户或最终用户。因此，模型必须易于理解。
使用者怎么理解呢? 可能与该系统交互的用户和任何其他系统都是使用者。由于使用者代表了系统用户，它们协助界定系统并提供十分明确的系统用途说明(系统边界)。编写用例依据使用者的需求来进行。这样就确保该系统成为用户期望得到的系统。
用例是用来描述和挖掘用户需求的，是用来和相关人士交流的,但有些设计人员经常犯一些错误，比如：
1.用例的系统边界不明确
一个普遍的问题就是在一个用例中混合了很多边界（比如：商业边界，系统边界），也就是说系统的范围要明确。
2.用例命名问题
一个用例应该尽量描述系统要做什么以及系统使用者如何用系统的问题，用例应该描述功能以满足用户需求为目的，而不是描述去怎么完成功能！ 因此，用例名称一定要明确。
3.参与者命名问题
表现在同一角色有多个参与者描述,一个很好的解决办法就是在用例模型文档中附加字汇表
4.用例模型中的用例太多了，看得眼花缭乱。
用例应该反映用户的真正的需求，具体做法 (1) 合并偶然的或不重要的用例 (2) 祛除掉那些试图描述内部处理流程的用例。 当然如果一个用例很大的话我们可以把他分开，每个用例图只包括有限的用例（即用例分包）
5.参与者和用例之间的关系就象蜘蛛网一样
这个问题主要表现在 (1)用例和参与者之间关系太多(2)一个参与者和每个用例都有联系(3)一个用例和每个参与者都有联系。这样的问题主要在于角色的重叠，解决的最好的办法是：角色的泛化或特化关系表示，防止蜘蛛网的产生。
6.一个用例的描述太广
这样的用例让人很难理解，而一些短小明确的用例让人一看就明白是什么意思
7.用例描述叫人迷惑
用例没有上下文，描述不完整，因此最好在用例模型旁边描述一下该用例模型所处的大环境，还要注意不要过多的关注内部交互，
8.用例不能很好的描述功能,
有的用例包容的活动太多，这样的话就要进行适当的分解以使用例描述清楚，
一个用例是完整的。复杂的用例需要单独用一个文件来描述，主要是用例的前置条件、后置条件、基本事件流、扩展事件流，和用例的优 先级等。 简单的用例可以在用例图中用标签来描述。
另外，活动图和顺序图也是详细描述流程和功能的有利工具。随着用例功能的不断细化，这两种图会发挥更大的作用
9.客户不理解用例
有的时候，用户没有参与用例的制定，而你恰恰要用他和他们讨论。用户根本就不了解，因此这需要一个培训的过程。在和用户交流的时候要增加用例的的故事性，有的时候我们的想法可能和用户有偏差。因此在讨论时应该认真的听取他们的商业描述。
10.用例没有结尾
在实际的软件开发中用例是时刻在变的，就象需求一样，当设计变动时用例也要跟着变。当然因为有的需求我们是不知道或者是不清楚的。
ps:
不难发现，用例是一个很好的获取系统功能性需求的方法。但是对于非功能性需求，情况又如何呢？什么是非功能性需求，可以在何处获得它们？
非功能性需求通常分为可用性需求、可靠性需求、性能需求以及可替换性需求。它们通常是指定需要符合任意法律法规要求的需求。它们也可以是由于所使用的操作系统、环境平台、兼容性或所采用的任何应用标准等问题产生的设计约束。通常，任何不允许有一个以上设计选项的需求都可以认为是一个设计约束。
本文转自BlogJava 新浪blog的博客，原文链接：用例的十大缺陷，如需转载请自行联系原博主。
