用例就像是一个不断展开的故事，顶级用例调用最外层用例，最外层用例再展开为用户目标用例或海平面用例。设计范围比较容易引起混乱，人们对系统的边界往往会有不同的观点。重要的是要清楚：业务用例的设计范围是业务运作不涉及技术问题，系统用例的设计范围就是要设计的计算机系统涉及技术问题。可以用图标来区分业务用例和系统用例或者在用例本身包含的系统内部放置一幅系统的图画。人们在开发时经常会犯得错误会反映最重要的问题，这一点在很多领域都是成立的。用例的每一句话都描述了一个要实现的子系统；还要从系统的外部看待整个系统，然后以一个较高的姿态进行描述用例；用力的可读性必须要强否则会失去它存在的意义；而且一个用例在不同时间可能会被用到不同的地方，要学会迁移；系统通常会被看作黑盒，否则会难以阅读；在主成功场景之后需要选择正确的路径；要学会接受改变因为改变在整个过程中是必须的；优势细化功能和用例是非常必要的，需要自己把握；用协作图代替文本可以提高可读性。用例的提示是很重要的，无论是哪个阶段都有必要去考虑完全。
需求与用例之间的关系：用例确实是需求。如果用例编写恰当，可以准确地对系统必须做什么进行详细的描述。用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。用例只是收集了所有需求中的一部分。
如何编写一个好的用例？想学会如何阅读用例是很容易的，但是学会编写一个好的用例却不容易。编写者必须掌握三个概念：1、范围：真正被谈论的系统是什么？2、主执行者：谁有要实现的目标？3、层次：目标的层次是高还是低？
编写有效用例需要注意的一些细节问题：每个用例易于阅读，不考虑GUI用户界面设计，项目相关人员的需要的保证（最小保证和成功保证），设置合理的前置条件，对用例进行通过、失败测试。注意业务范围和系统范围，控制用例集中的质量问题。处理用例注意扩展到多少个用例才合适，执行者扮演什么角色。
用例作为需求来编写，请谨记以下两点：(1) 用例确实是需求。不必将用例转变成行为需求的其他形式。用例不是所有的需求。用例不详细地描述外部接口、数据格式、业务规则和复杂公式。
用例仅仅是行为需求，并且是所有的行为需求。
最小保证是系统向项目相关人员作出的最低承诺，尤其是在主执行者的目标不能被满足的情况下。在目标遭遇失败的情况下，项目相关人员认可他们的利益得到了保护，这时最小保证是否成功/失败的测试标准。