当对业务过程进行建模时，在重组 前需要通过用例对其系统进行文档化，通过用例创建符合设计要求的外部行为需求，设计之后使用用例对信新过程文档化。在自上而下的分析法中，需要清楚组织行 为中的项目相关人员，外部主执行者，组织需要响应的触发事件，组织提供的服务以及项目相关人员的成功结果。业务设计过程可以采用黑盒用例进行描述，此阶段 会充分发挥技术的作用，创新资源组和新过程。但是随着技术的更新，会使用白盒用例，这其中不涉及技术，因为计算机完成的事人也可以完成。
软件需求分析中，用例会表会给人一个清晰的功能描述。一个开发组可以使用用例来制定软件设计任务，以保持用例映射的及时性。设计任务步并不与用例单元整 齐对应，所以一项设计任务产生的业务对象或者行为能同时用于多个用例。在制定粗略的系统功能图时需要首先对系统采用的叙述方式达成共识；然后对应用领域达 成共识，并集中讨论系统主执行者和系统目标；再编写系统描述并汇总。然后对功能图精确化，首先对格式达成共识，然后编写用例继而进行审核。把应用描述作为 用例编写开始之前的练习，并把用例概述作为项目概要的一部分。
顶级用例调用最外层用例，最外层用例再展开为用户目标用例或海平面用例。设计范围比较容易引起混乱，人们对系统的边界往 往会有不同的观点。重要的是要清楚：业务用例的设计范围是业务运作不涉及技术问题，系统用例的设计范围就是要设计的计算机系统涉及技术问题。可以用图标来 区分业务用例和系统用例或者在用例本身包含的系统内部放置一幅系统的图画。人们在开发时经常会犯得错误会反映最重要的问题，这一点在很多领域都是成立的。 用例的每一句话都描述了一个要实现的子系统；还要从系统的外部看待整个系统，然后以一个较高的姿态进行描述用例；用力的可读性必须要强否则会失去它存在的 意义；而且一个用例在不同时间可能会被用到不同的地方，要学会迁移；系统通常会被看作黑盒，否则会难以阅读；在主成功场景之后需要选择正确的路径；要学会 接受改变因为改变在整个过程中是必须的；优势细化功能和用例是非常必要的，需要自己把握；用协作图代替文本可以提高可读性。用例的提示是很重要的，无论是 哪个阶段都有必要去考虑完全。
虽然UML工具可以是我们在图形中获得很多 信息，但是文档的重要性是必须的。图形是一个二维的助记根据，是以认知为目的的。包含关系是来源于程序设计语言中的子程序调用，需要各种参数辅助完成 作用。在有“用户采取了某种行动”时可以考虑使用泛化，有时泛化仅仅包含特殊操作。在此书中有很多细节上的东西，在平常的小实验中自己根本不会注意到，以 后一定要逐渐规范自己的工作流程。