业务用例的设计范围是业务运作不涉及技术问题，系统用例的设计范围就是要设计的计算机系统涉及技术问题。可以用图标来区分业务用例和系统用例或者在用例本身包含的系统内部放置一幅系统的图画。人们在开发时经常会犯得错误会反映最重要的问题，这一点在很多领域都是成立的。用例的每一句话都描述了一个要实现的子系统；还要从系统的外部看待整个系统，然后以一个较高的姿态进行描述用例；用力的可读性必须要强否则会失去它存在的意义；而且一个用例在不同时间可能会被用到不同的地方，要学会迁移；系统通常会被看作黑盒，否则会难以阅读；在主成功场景之后需要选择正确的路径；要学会接受改变因为改变在整个过程中是必须的；优势细化功能和用例是非常必要的，需要自己把握；用协作图代替文本可以提高可读性。用例的提示是很重要的，无论是哪个阶段都有必要去考虑完全。
用例的前置条件声明了启动该用例之前系统必须满足的条件。通常，前置条件是指该条件已经通过其他用例的执行进行了设置。在编写前置条件时通常易犯的一个错误是，把经常是正确的但不是必须的条件写入前置条件。最小保证是系统向项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。在目标遭遇失败的情况下，项目相关人员认可他们的利益得到了保护，这时最小保证是否成功/失败的标准。
成功保证说明了用例成功结束后项目相关人员的哪些利益得到了满足，用例可以通过执行主场景获得成功，也可以通过执行可选路径获得成功。成功保证通常作为最小保证的添加内容：最小保证被满足以后，并且一些附加条件为真；附加条件中至少包括用例标题中声明的目标。
项目相关人员认可他们的利益得到了满足，这是成功是否成功/失败的测试标准。找到成功保证的最好方法是问这样一个问题：“在用例结束时，什么事会使项目相关人员感到不高兴？”这个问题通常很容易回答，然后写出答案的反面回答。根据主执行者担当的角色来对它们进行分解。创建一个“执行者—角色”表，在表中列举出在任一用例中充当主执行者的所有不同的人和系统，以及他们担当的所有角色。在主执行者域使用角色名称。使用“执行者—角色”表将用例与现实世界中的人和系统对应起来。 这种策略能使编写者不必顾及错综复杂的工作头衔，而只专注于继续用例的编写工作。有些人，或许是用户界面设计者或软件打包人员，会利用“执行者—角色”表来将用例同其最终用户对应起来。可选策略1带来的一个不便之处是需要单独维护和阅读一个列表。
可以考虑使用与描述场景扩展相同的机制，但这里是创建新用例。新用例称为扩展用例它除了是独立的用例之外，其他都与场景扩展相同。扩展用例从一个条件开始，在基用例中该条件可能满足的地方被引用。应将所有的条件都放到模板的触发事件部分中