检查点：用例

每个具体用例是否至少涉及一个主角？如果不是，则其中存在问题；与主角不进行交互的用例是多余的，您应该将它删除。有关详细信息，请参见指南：用例。
用例之间是否相互独立？如果两个用例总是以同样的顺序被激活，您可能需要将它们合并为一个用例。
所有用例是否都有非常相似的行为或事件流？如果有 - 而且您还希望它们的行为在将来也相似 - 您应该将它们合并为一个用例。这便于在将来引入变更。注：如果决定合并用例就必须包含它们的用户，因为与新合并的用例进行交互的用户可能会受到影响。
该事件流的一部分是否已被构建为另一个用例的模型？如果是，您可以让新用例使用旧的事件流。
此事件流的某一部分是否已经成为另一个用例的组成部分？如果是，您应该提取该分支流并让上述的用例使用它。注：如果决定“重新使用”分支流就必须包含这些用户，因为现有用例的这些用户可能会受到影响。
是否应该将一个用例的事件流插入另一个用例的事件流中？如果是，利用与另一个用例的扩展关系来建立此模型。
用例的名称是否具有唯一性、直观性和解释性，这样以后就不至于将它们混淆？如果没有，则更改它们的名称。
客户和用户是否都了解用例的名称和说明？每个用例名称必须说明其支持的行为。
用例是否满足明显支配其性能的所有需求？在用例特殊需求中必须包含要在对象模型中处理的任何（非功能性）需求。
主角和用例之间的通信顺序是否符合用户的期望？
是否明确说明用例的事件流开始及结束的方式和时间？
可能存在仅在未符合某一特定条件时才被激活的行为。是否说明未满足给定条件时将发生的事情？
是否有过于复杂的用例？如果要使用例模型易于理解，您最好将复杂用例进行分解。
用例是否包含完全不同的事件流？如果包含，最好将其分成两个或更多个单独的用例。包含完全不同的事件流的用例将难于理解和维护。
是否精确建立业务用例中的分支流的模型？
是否清楚地说明执行用例的对象？是否还清楚地说明用例的目的？
是否清楚地说明主角的交互和交换的信息？
简要概述是否清晰地描述了用例的概况？

Rational Unified Process