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