用例的前置条件声明了启动该用例之前系统必须满足的条件。由于该条件由系统负责实施，并要求确保为真，因此在用例执行过程中，不必再对该条件进行检查。通常，前置条件是指该条件已经通过其他用例的执行进行了设置。如我们说“创建订单”依赖于“已经登录”这个前置条件，则应去查找是哪个用例设置了这个前置条件（这里应寻找“登录”用例）。
在编写前置条件时通常容易犯一个错误是，把经常是正确的但是不是必须的条件写入前置条件。
假设我们正在编写用例“索要保险赔偿金总额”，主执行者是申请人。我们可以假设在索要保险金总额之前，申请人至少已经提交了一个申请或账单。然而，情况并不是总是这样，系统不能保证这个假设的正确性，实际上这不是一个必要条件。申请人应该能在任何时候索要他们的保险金额，因此诸如“申请人已经提交了一个账单”这样的前置条件是错误的。
最小保证是系统向系统项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。当然，在目标被满足的情况下它们仍然成立，但是当主要目标被放弃时它们就成为人们真正关心的事情。多数情况下，两个或更多的项目相关人员必须在最小保证中被提及，例如可以有用户、提高系统的公司，还可能有政府管理部门。不必在最小保证中不厌其烦地列举用例的所有失败情况。最常见的最小保证是“系统将其执行进度情况记入日志”。最小保证被写成一些简单的断言形式，无论用例如何被执行，这些断言最终都应为真。它表明每一个项目相关人员的利益都得到了满足。在目标遭遇失败的情况下，项目相关人员认可他们的利益得到保护，这是最下保证是否成功/失败的测试标准。
成功保证说明了用例成功结束后项目相关人员的哪些人员得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。成功保证通常是作为最小保证的添加内容。
触发事件指明了启动用例的事件。有时，用例执行过程中的第一步紧接着触发事件发生，有时触发事件就是用例中的第一步操作。
用例集是一个可以不断展开下去的故事，有主执行者需要实现的目标组成。每一个用例都显示了系统完成目标或放弃目标相互交织的情节。故事的主线表示为一个主成功场景，一些场景片段作为主线的扩展。每一个场景或场景片段都从一个触发条件开始，这个触发条件指明了什么时候场景开始执行，并一直执行到完成目标或放弃目标。就像我们所看到的，目标大小虽然各不相同，但我们可以使用相同的编写格式在不同的场景级别上描述各种大小不同的目标。
首先编写一个自顶向下的描述，这个描述总包含一个容易理解的相当典型的场景，在该场景中，主执行者完成了目标，所有相关人员的利益都被满足了。这个场景就是主成功场景。其他的成功场景和所有的错误的处理，都会在主成功场景的扩展中进行描述。
每个场景或片段被描述为由不同执行者完成目标的活动序列。
执行步骤是对用例的补充，并且都有统一的语法形式，在一个简单活动中，执行者完成任务或向另外的执行者发送消息。
在主成功场景下，对于因为特别条件而出现行为分支的每个地方，写出分支的条件以及处理分支的步骤。大多数扩展以重新与主成功场景汇合而结束。
扩展实质上是一个从主用例中被拆分的用例。扩展开始于一个与它相关的条件。它包含了一个执行步骤的序列，该序列描述了在这个条件下发生了什么。扩展以完成或放弃扩展目标作为结束。使用这种方法，为了处理多个条件和转移，可能会遇到扩展中又包含扩展的情况。
扩展条件是为了描述系统在不同情境下完成不同的动作。包括成功和失败。
扩展说明了系统所完成的目标是不同的，但有时需要表达“有多种不同方法来完成相同目标”。系统所完成的目标是相同的，但是怎么做可能不同。通常是因为技术的变化或输入数据的不同。应该报这些变化写到“技术和数据变化”列表中，而不是写到扩展部分。