用例和功能误区
用例是不是功能？如果不是的话，它是什么？从定义上说，能给使用者提供一个执行结果的活动，不就是功能吗？很不幸，这个理解是错误的！功能是计算机术语，它是用来描述计算机的，而非定义需求的术语。功能实际描述的是输入-> 计算->输出。这让你相当了什么？DFD图？这可是典型的面向过程的分析模式。因此把用例当做功能点的做法实际上载做面向过程的分析。抛开面向对象和面向过程不说，虽然功能和用例很类似，但是本质上来说功能和用例是完全不同的。为了解释这个问题，我们需要从描述事物的方法入手。
在描述一个事物的时候，我们可以从以下三个观点出发：
- 这个事物是什么？
- 这个事物能做什么？
- 人们能够用这个事物做什么？
使用者的观点才是真正的用例观点。
第一，功能是脱离使用者的愿望而存在的。我们通常说某某工具某个功能，它是描述工具的，而不是站在使用者的角度描述使用者的愿望的。功能用来描述某某东西能做什么，它与使用者的愿望无关，描述事物固有的性质。用例是描述使用者的愿望的，描述的是使用者对系统的使用要求，用用例来看待系统的团队，则是从使用者的校对出发，说明使用者将在系统里面做什么。
第二，功能是孤立的，给一个输入，通过计算就有一个固定的输出。用例是系统性的，它描述谁在什么情况下通过什么方式结果是什么。功能描述一个个点，如果要达成一个特定的目标，必须在额外交上一个顺序的过程，把点串起来才能完成一个系统性的工作。而用例描述一个系统性的工作，这个系统性的工作往往非常明确地去达成一个特定的目标。
第三，如果非要从功能角度解释用例，那么用例刻意解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现出不同的组合形式。并且，不是先有了这些“功能”才来组合成某个场景，而是先有了场景，才分解出“功能”，这时的功能之所以打引号是应为在UML里面没有功能这个词的，实际上场景分解出来就是对象，这些对象通过消息相互交流而完成场景。
目标和步骤误区
一个用例是参与者对目标系统的一个愿望，一个完整的事件。为了完成这个时间需要经过很多步骤，但是这些步骤不能够完整地反映参与者的目标，不能够作为用例。
这就是用例的完整性。
用例粒度误区
产生用例粒度错误的原因首先是分不清楚目标和步骤。分不清目标和步骤的另一个后果是用例的粒度过于细小。
产生这个错误的主要是建模者心中没有一个清楚的边界，我们知道用例决定参与者的完整期望，而参与者与边界是相生相灭的，所以一旦边界不确定，参与者就会混乱，进而导致用例粒度不一。
粒度大小如何决定，在同一个需求阶段，必须保持所有用例的粒度在同一量级！