在UML中，一个用例模型包括系统的用例图及用例描述，用例描述即用例规格说明。建立的用例模型中，用例图没有显示不同路径，只显示了行为者与用例之间的关系，无法知道其实际过程，因此需要为用例图配上结构化叙述的详细说明，对用例进行描述，使系统功能定义更加完整。
一个完整的用例模型描述包括用例名称、行为者、前置条件、场景和后置条件等，如图4－20所示。
图4－20 用例规格说明示意
场景是用例为了回应事件而采取的步骤，每一个场景由一系列业务事件流组成，事件流分为三种：基本事件流、备选事件流和异常事件流。
在需求分析时，用户往往会向分析人员描述多个不同的场景，而这些场景可能因为目的相同而被定义为一个用例，因此定义用例时要合理掌握用例的粒度。如果粒度太粗，则一个用例可能会包含太多复杂的场景，为系统后续开发增加不必要难度；如果粒度太细，一个场景甚至一个事件流也被定义为一个用例，会导致系统功能支离破碎。
为统一格式，一个项目应该使用统一的用例模板，表4－2总结了用例描述格式。
表4－2 用例描述模板(www.xing528.com)
用例模型描述需要达到以下要求：
（1）用例模型描述必须既能让业务人员看懂，又能让技术人员看懂，以便日后的业务确认和设计开发。因此，从业务人员的角度来说，不能使用过多的技术语言，而要从技术的角度详细清楚地表述各个功能的操作流程，用到专业的业务术语时需要对必要的业务术语进行解释。
（2）用例模型描述必须清晰准确地表达每一个业务需求，明确每一个术语、每一段描述，不能存在异议。
（3）用例模型描述必须从各个角度全面地反映客户对系统的期望。用例模型描述对业务需求把握得越全面越详尽，项目出现偏差和风险的几率就越小。
用例描述虽然看起来简单，但事实上它是捕获用户需求关键的一步。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
