软件需求分析中，用例会表会给人一个清晰的功能描述。一个开发组可以使用用例来制定软件设计任务，以保持用例映射的及时性。设计任务步并不与用例单元整齐对应，所以一项设计任务产生的业务对象或者行为能同时用于多个用例。在制定粗略的系统功能图时需要首先对系统采用的叙述方式达成共识；然后对应用领域达成共识，并集中讨论系统主执行者和系统目标；再编写系统描述并汇总。然后对功能图精确化，首先对格式达成共识，然后编写用例继而进行审核。把应用描述作为用例编写开始之前的练习，并把用例概述作为项目概要的一部分。
用例只是需求文档的行为需求，它们不包括系统性能需求、业务规则、界面设计、数据描述、优先级以及其他状态，这些需求会以文档的形式附在用例上，并且可以根据重要性进行调整相关内容。数据需求通常会被分为信息别名、域列表或数据描述、域的细节和域校验三个精度级别。数据格式不是用例的一部分，但是用例指明了数据的需求，所以可以在用例和数据之间建立超链接。
项目相关人员是对用例的行为具有特定利益的人和物。每个主执行者都是一个项目相关人员，但是一些项目相关人员尽管有权关心系统的行为，却从来不与系统进行直接交互，例如：系统拥有者，公司的董事会和调控主体。这种未直接出现的项目相关人员也可以叫做沉默的执行者，加强对这些人的注意可以大大提高用例的质量，他们的利益在系统执行的检查和确认中、创建的日志中、以及在系统执行的动作中得以体现。
用例，做为规范行为的契约，捕获了与满足项目相关人员利益相关的所有行为，并且仅限于此。为了满足项目相关人员的利益，需要描述三种行为：（1）两个执行者之间的交互（为了促进一个目标），交互过程中可能会有信息的往返传递（2）确认（为了维护某一项目相关人员的利益所进行的确认）（3）内部状态变化（代表项目相关人员）。
列出所有的项目相关人员和他们的利益，并用这个列表仔细的检查以确保用例体中没有任何内容被遗漏。然而，这个微小的改动却能对用例的质量产生重大的影响。
设计任务步并不与用例单元整齐对应，所以一项设计任务产生的业务对象或者行为能同时用于多个用例。在制定粗略的系统功能图时需要首先对系统采用的叙述方式达成共识；然后对应用领域达成共识，并集中讨论系统主执行者和系统目标；再编写系统描述并汇总。然后对功能图精确化，首先对格式达成共识，然后编写用例继而进行审核。