我们通常都是用自上而下的方式来描述用例的，这通常会包括一个容易理解的典型场景，这其中会使所有项目有关人员的利益得到满足，而其他场景也都会由此产生或者扩展。主场景中包含的元素会有场景执行的条件和完成的目标，执行的步骤和结束条件以及其中的扩展。执行步骤会有一些有语法的限制，不管是复杂还是简单一些的用例，都需要遵行使用简单的语法来表述执行步骤以确保信息的完整性，避免丢失活动执行者或其他信息。其次要从系统使用者之外的开发人员的角度来编写用例，还要具有一定的灵活性；人机交互界面的描写不一定是实际需求，而仅仅是作者在某个时刻所想象的用户界面，所以应该让用户界面设计师来进行界面的设计；执行步骤的编写可以很灵活，允许采用不同的形式进行来描述；有些步骤的描述如果不甚准确的话，会出现一些偏差，所以要慎用词语；适当的时候也要有时间限制；“用户让系统A与系统B交互”，要比“用户点取按钮，从B获得数据”的表述要更准确；完整正式的用例格式需要进行编号。
接下来要对主成功场景里进行扩展，可以单独写出每一个场景，也可以使用条件句来进行扩展；但这两种分别有自己的缺陷，比较常用的是将主场景从开始到结束按时间的顺序写出来，然后再每个分支进行扩展。由于扩展区别于失败或者异常处理，所以扩展也要包括成功和失败两种条件。由于会有很多个扩展，所以为了可以编写的全面一点，避免丢失，要集中讨论所有可能的情况，包括快捷成功的路径、等待密码超时、无效密码、无效账号、响应超时、发现崩溃的事务日志等条目。扩展要有合理性，该合并的合并，该去掉的也要去掉。
当可以用不同的方法来完成相同目标是，就不能使用扩展了，这是需要将相关信息写到“技术和数据变化”列表中，比方说验证身份可以用身份证、指纹识别等方法。 如果执行步骤某个步骤中有标记就说明是一个子用例，有时两个用例之间也需要另一种类似扩展机制的连接。只有当有很多用户可能使用的异步服务或中断服务且不影响基用例的时候，或者为一个已经锁定的需求文档编写附加文档的时候才使用扩展用例。
用例格式可以是正式的或者非正式的，又有单列表格格式、双列表格格式、RUP格式、条件语句格式、Occam格式、图形方式几种格式，可以根据不同的情境使用不同的格式。书写时要了解需求，甚至包括用例根本不在最后的需求文档中使用的情况；业务过程建模，设计和量化系统需求；还要注意在一个短期高强度的项目中编写功能需求等。
只有在已经命名了与系统相关的全部主执行者及其用户目标、捕获了系统的全部触发条件（包括用例触发条件、扩展条件）、编写了所有用户目标用例以及必要的概要用例和子功能用例、每个用例描述足够清晰使投资方、用户、开发人员都确认相关信息之后才算完成任务。不同的项目组根据其不同的实际情况，通常采用不同的策略，一些项目组也许是为了对项目投标，一开始就草拟了所有用例，还有的是在快结束时，每一种都有可取之处。 对大量用例进行处理时，可以对每个用例进行简单说明或者把用例分为多个簇。第一种给每个用例单独命名时它就会作为第一级精度，对每个用例的描述就是第二级精度；第二种要创建用例簇的话可以按照执行者或按概要用例、开发组和版本号、主题域分类。 分析用例的核心业务时，要弄清在组织行为中的项目相关人员、必须满足其需求的外部主执行者、必须响应的触发事件以及该组织提供的服务和对项目相关人员的成功结果。业务用例与系统用例具有相同的特征，所以经常有人会把它们弄混，为了减少这种混乱用过在用例模板中标明用例范围及级别。 用例只是需求文档的行为需求，它们不包括系统性能需求、业务规则、界面设计、数据描述、优先级以及其他状态，这些需求会以文档的形式附在用例上，并且可以根据重要性进行调整相关内容。数据需求通常会被分为信息别名、域列表或数据描述、域的细节和域校验三个精度级别。数据格式不是用例的一部分，但是用例指明了数据的需求，所以可以在用例和数据之间建立超链接。同样，复杂的业务规则也不适合写入用例，但却可以在包含他们的实体之间建立一个连接。