当满足如下要求时，才算完成任务。
已经命名了与系统相关的全部主执行者及其用户目标。
捕获了系统的全部触发条件，既包括用例触发条件，也包括扩展条件。编写了所有用户目标用例及必要的概要用例和子功能用例。每个用例描述得足够清晰，使得:
投资方确认他们能够区分这个用例是或不是实际上要提交的用例。用户确认用例表达了他们的要求，或者能接受这些用例作为系统的行为。
开发人员确认可以实现所有用例表示的功能。
投资方确认用例集覆盖了他们所有的需求。
全部主执行者及其用户目标。通过全部主执行者及其用户目标，可以确定系统的实现范围。由于除了需要人头脑中的系统构想外，没有其他信息来源可与主执行者及用户目标列表进行比较，因此我们无法知道怎样对其进行处理。只能凭猜测来处理，因而有必要采用集体讨论的方式对主执行者及其目标列表进行多次检查。
全部触发条件。这些触发条件表示系统边界的微调，系统必须对它们进行响应。在用例中，一些触发事件以用例触发形式出现，例如，用户把卡插入槽中、客户对保险合同增加或删减条款、用户选择更新或安装软件等。另一些触发事件则作为场景扩展条件，例如，用户单击取消按钮，系统检测电源中断等。
有一个方法可以对系统触发条件集进行重新检查，即通过识别系统中所有具有生命周期的元素并重新审查它们的生命周期，寻找所有改变它们生命周期状态的事件。
概要用例和子功能用例。概要用例建立了用户目标用例的环境。它们回答了一个经常被问及的问题，"所有这些(用户目标)用例如何组装在一起?"事实上，每个用户用例都处于其上层用例中，如此一级一级上升，直到单个根用例。根用例是一张目录表，不再有层次结构。新读者会发现有一个单一的起点很有用处，他们能够从这出发对系统中每个用例进行访问。
子功能用例为用户目标用例提供支持。只有被多个其他用例调用或者分离一个复杂行为时，子功能用例才有存在的必要。
用例的确认。只有投资方和应用专家阅读这些用例并认为用例表达了他们所有的需求，系统开发人员阅读这些用例并认为他们能够根据用例描述开发符合需求的系统时，才能认为这些用例合格。但这是非常艰难的挑战，是编写需求的挑战。
关于"正在完成"
短语"正在完成"给人的印象是在开始设计任务之前，就应该从头到尾编写所有用例。须知情况并非如此。参考17.1节"用例在项目组织中的作用"，其中对开发一个可以部分交付用例的项目开发计划进行了讨论。还可以参考Surviving Objecl-Oriented Projects (Cockbum，1998)对增量式开发进行的详细描述, 文章 VW-Staging (http://members.aol.com/acockburn/papers/vw-stage.html)对增量和迭代式开发进行的简短讨论。
不同的项目组根据其不同的实际情况，通常采用不同的策略。一些项目组也许是为了对项目投标，一开始就草拟了所有用例。但他们必须清楚这样编写的用例在项目过程中需要不断修改。一些项目组则只草拟执行者和用户目标，按适当的增量开发方式，开始用例的详细设计。还有一些项目组则花6~9个月时间创建用例，直到这项工作快结束时才开始讨论所有其他需求。还有项目组在每开始一轮工作之前才编写必需的用例。当然，上述每种策略都有其可取之处。