【系统架构设计】用例技术：需求分析的实用工具

文章目录

核心观点：用例技术就像写菜谱，有简单版（用例图+用例简述）和详细版（用例规约）之分。简单版适合快速了解"要做什么菜"，详细版适合精确描述"怎么做菜"。面对需求变更，用例图像菜谱目录一样稳定，用例规约像具体步骤一样易变。聪明的做法是：先写简单版，等需求稳定了再写详细版。对于复杂业务系统，用例建模不够，还需要流程建模来发现用例。

很多需求分析员对用例技术存在困惑：用例图、用例简述、用例规约、用户故事，这些到底有什么关系？什么时候用哪个？面对需求变更，哪个更稳定？用例建模够不够？流程建模要不要？

本文围绕六个核心问题展开：

用例技术有哪些？它们有什么区别？ 就像菜谱有简单版和详细版，用例技术也有不同层次。
用例图、用例规约、用户故事，这些技术有什么关系？ 它们处于需求的不同层次，用户故事和用例简述类似，都是轻量级描述。
什么时候用哪个用例技术？ 不同场景需要不同层次的用例技术。
如何应对需求变更？ 用例图稳定，用例规约易变，聪明的做法是推后细化。
如何应用？ 根据系统特点选择小型、中型或大型方法。
需求分析的三套实践论中，用例建模和流程建模的关系是什么？ 对于复杂业务系统，流程建模是发现用例的有效手段。

一、用例技术有哪些？就像菜谱有简单版和详细版

用例技术是一个"技术族"，包含用例图、用例简述、用例规约、鲁棒图四种技术。它们就像菜谱的不同版本：用例图像菜谱目录，用例简述像简单说明，用例规约像详细步骤，鲁棒图像做菜流程。

用例技术不是单一技术，而是一个"技术族"，由多种技术组成。就像菜谱，有简单版（告诉你"要做什么菜"）和详细版（告诉你"怎么做菜"的每个步骤）。用例技术也是如此，有不同层次，适用于不同场景。

用例图：菜谱的目录

用例图就像菜谱的目录，告诉你"系统要做什么菜"，但不告诉你"怎么做菜"。

用例图描述软件系统能为用户或外部系统提供的服务。就像菜谱的目录，它告诉你"这本菜谱有哪些菜"（系统有哪些功能），但不告诉你"每道菜怎么做"（每个功能的具体步骤）。

用例图最重要的元素是"参与者"（Actor）和"用例"（Use Case）。参与者是与系统交互的角色或系统，可以是用户，也可以是另一个系统。用例是系统能为外部参与者提供的功能。

例如，银行储蓄系统的用例图，参与者是"柜员"，用例有"开户"、"销户"。就像菜谱目录，告诉你"这本菜谱有宫保鸡丁、麻婆豆腐"，但不告诉你"宫保鸡丁怎么做"。

用例图的作用有两个：一是识别与系统交互的角色或外部系统，二是描述系统必须提供的功能。对系统开发而言，用例图从视觉上明确了系统范围内的所有功能。

用例简述：菜谱的简单说明

用例简述就像菜谱的简单说明，用简短文字描述"这道菜是什么"，适合快速了解。

用例图中的用例必须命名，但用例图本身提供的信息有限。因此，需要其他"用例描述技术"进行进一步说明。

用例简述是最简单、最实用的"用例描述技术"，用简短文字描述用例的功能。一般来说，用例简述应该包含成功场景的简单描述。

例如，银行储蓄系统"销户"用例的用例简述：帮助银行工作人员完成银行客户申请的活期账户销户工作，需客户提供证件和密码。就像菜谱的简单说明："宫保鸡丁：川菜经典，酸甜微辣，配米饭绝佳。"

很多敏捷方法，如极限编程（XP）的用户故事卡、特性驱动开发（FDD）的特性，都使用类似用例简述的技术来捕获和沟通需求。

用例规约：菜谱的详细步骤

用例规约就像菜谱的详细步骤，精确描述"怎么做菜"的每个环节，包括正常情况和异常情况。

用例规约是另一种用例描述技术，是详细描述，通常包括简要说明、主事件流、备选事件流、前置条件、后置条件、优先级等。

用例规约的主要目的是定义软件系统的行为需求（可以归类为业务需求、用户需求、行为需求）。行为需求是指软件系统必须执行的动作，以提供用户需要的功能。

例如，银行储蓄系统"销户"用例的用例规约，详细描述了销户的每个步骤：银行工作人员进入"活期账户销户"程序界面→用磁条读取设备扫描活期存折的磁条信息→系统自动显示该活期账户的客户资料信息和账户信息→银行工作人员验证申请人身份并确认销户→系统提示客户输入取款密码→客户使用密码输入设备输入取款密码→系统验证密码后计算利息、扣除利息税、计算最终销户金额并打印销户和利息结算单→系统记录销户交易流水及其分户账信息。

就像菜谱的详细步骤："1. 鸡胸肉切丁，用料酒、盐腌制10分钟；2. 花生米炸至金黄；3. 热锅下油，爆炒鸡丁..."不仅告诉你"做什么"，还告诉你"怎么做"、"什么时候做"、"如果出问题怎么办"。

用例规约的特点是"重"（详细），而用例简述是"轻"（简单）。用例规约以用户为中心描述系统行为，便于与用户交互。它既关注成功场景（由主事件流描述），也关注异常场景（由备选事件流描述），这促进了系统性思维，有助于识别异常情况，提高系统功能，增强可用性。

鲁棒图：做菜的流程图

鲁棒图就像做菜的流程图，描述"做菜需要哪些工具和食材，它们如何配合"，属于设计范畴。

用例实现是面向对象理论中的"协作"，多个对象通过交互来实现目标。鲁棒图用于对用例实现进行建模，说明实现用例功能需要的类及其交互。

例如，银行储蓄系统"销户"用例的鲁棒图，描述了销户功能需要的边界对象（活期账户销户界面、磁条读取设备、打印设备）、控制对象（销户、计算利息）、实体对象（客户资料、销户流水、活期账户、利息率、利息税率）以及它们之间的交互关系。

就像做菜的流程图："需要锅、铲、食材→先准备食材→再下锅炒→最后装盘。"它描述了做菜需要的工具和食材，以及它们如何配合。

鲁棒图（用例实现）是从功能需求到设计方案的桥梁，是"思维的纽带"。需要注意的是，用例是需求，鲁棒图已是设计。

二、什么时候用哪个用例技术？不同场景需要不同层次

不同场景需要不同层次的用例技术：需求捕获用用例图+用例简述，需求分析用用例规约，初步设计用鲁棒图。就像做菜，先看菜谱目录决定做什么，再看简单说明了解大概，最后看详细步骤精确操作。

4种用例技术，用于3种实践场景：

场景1：需求捕获和简单系统的需求分析

用例图+用例简述：既可用于需求捕获，又可用于业务不太复杂的系统的需求分析。

好处有二：一是覆盖面广，所有的功能需求都能被覆盖到；二是深入的细节不多，不易受到需求变更的冲击。

就像做菜，你先看菜谱目录（用例图）决定"要做什么菜"，再看简单说明（用例简述）了解"这道菜大概是什么"。如果菜谱很简单，这样就够了。

场景2：需求分析和需求规格定义

用例规约：用于需求分析与需求规格定义。

用例规约本身是一种思维工具，它围绕"为参与者带来价值的可见结果"展开，挖掘出各种处理场景、异常场景，使需求定义更加完善。需求分析的目的是得到明确和规范的需求定义，用例规约技术正堪其用。

就像做菜，如果菜谱比较复杂，你需要看详细步骤（用例规约），了解"每个步骤怎么做"、"如果出问题怎么办"。

场景3：初步设计

用例实现（鲁棒图）：用于初步设计。

用例是需求，鲁棒图已是设计。鲁棒图描述了实现用例功能需要的类及其交互，属于设计范畴。

就像做菜，详细步骤告诉你"怎么做"，但做菜的流程图（鲁棒图）告诉你"需要哪些工具和食材，它们如何配合"。

三、如何应对需求变更？用例图稳定，用例规约易变

面对需求变更，用例图像菜谱目录一样稳定，用例规约像具体步骤一样易变。聪明的做法是：先写简单版（用例图+用例简述），等需求稳定了再写详细版（用例规约）。

用例图和用例规约处于不同的"需求层次"（业务需求、用户需求、行为需求），导致对需求变更的"抵抗力"不同。

用例图：像菜谱目录一样稳定

用例图能稳定反映用户级需求，因为它只描述"要做什么菜"，不描述"怎么做菜"。

例如，1999年11月1日，中国开始对储蓄利息征收个人所得税。这个变化影响了"结息"功能，需要调整数据库结构和功能。

但开征利息税对包括"结息"在内的整个用例图没有影响。因为用例图只反映"储蓄系统必须有结息功能"，而不涉及"结息业务规则的变化"。就像菜谱目录，即使"宫保鸡丁"的做法变了，目录上还是"宫保鸡丁"，不会变成"宫保鸡丁2.0"。

这意味着用例图适合在项目早期使用，因为它不容易受到需求变更的冲击。

用例规约：像具体步骤一样易变

用例规约因为精确所以易变，需求变更往往发生在行为需求层面，这正是用例规约描述的内容。

开征利息税对"结息"用例的用例规约影响很大。主事件流需要新增步骤：系统计算此账户的利息税=利息×利息税率；系统计算出应付利息=利息-利息税。其他步骤也发生了变化。

这些重大变化发生在行为需求层面，反映在用例规约的主事件流和备选事件流中。就像菜谱的详细步骤，如果"宫保鸡丁"的做法变了，详细步骤必须修改。

这意味着用例规约适合在需求相对稳定后再详细编写，过早细化会增加需求变更管理的开销。

实践启发：推后用例细化，激发需求变更

为了更聪明地应付需求变更，应该"推后用例细化、激发需求变更"。具体而言：不是对软件架构起关键作用的用例，可以推迟到要实现该用例所定义的功能之前才进行细化。

正如前面所述，需求变更对用例图和用例简述的影响比较小，而对用例规约的影响很大。因此我们应该"推后用例细化、激发需求变更"。

推后用例细化。 不是对软件架构起关键作用的用例，可以推迟到要实现该用例所定义的功能之前才进行细化。过早地为这些用例制定用例规约会增加"需求变更管理"的开销，使需求变更的影响增大。

就像做菜，你不用一开始就把所有菜的详细步骤都写出来。先写菜谱目录和简单说明，等决定要做哪道菜了，再写那道菜的详细步骤。

激发需求变更。 这一点很重要。必须通过不断增加功能、发布小版本、提供给用户试用、接受用户反馈等一系列的活动，让用户一步步明确自己真正想要的功能。对前期版本的反馈中，往往涉及比较多的需求变更，而此时大量用例还没有被细化，所以避免了需求变更造成的巨大冲击。

就像做菜，你先做几个简单版本给客人试吃，根据反馈调整，等客人满意了，再写详细菜谱。这样比一开始就写详细菜谱，然后频繁修改要好得多。

在项目早期"不将所有用例细化"，意味着"将大部分用例保持在'用例图+简短描述'的水平"。这样做，并不影响"开发原型、征求客户意见、识别需求变更、再原型、再识别需求变更..."的过程。此后，需求分析员对用例进行细化。

四、用例图、用例规约、用户故事，这些技术有什么关系？

用例图、用例规约、用户故事处于需求的不同层次：用例图反映用户级需求，用例规约描述行为需求，用户故事和用例简述类似，都是轻量级的行为需求描述。它们就像菜谱的不同部分：用例图像目录，用户故事像简单说明，用例规约像详细步骤。

很多人对用例图、用例规约、用户故事的关系感到困惑。其实，它们处于需求的不同层次，服务于不同的目的。

需求的三层结构：业务需求、用户需求、行为需求

需求分为三个层次：业务需求（为什么做）、用户需求（做什么）、行为需求（怎么做）。用例图、用例简述、用例规约、用户故事分别处于不同层次。

就像写菜谱，你需要先知道"为什么要写这本菜谱"（业务需求），然后决定"这本菜谱要包含哪些菜"（用户需求），最后详细描述"每道菜怎么做"（行为需求）。

业务需求：客户或出资者要达到的业务目标。例如，"提高银行工作效率"。
用户需求：用户使用系统来辅助完成哪些工作。例如，"柜员可以开户、销户"。
行为需求：软件系统必须执行的动作。例如，"系统验证密码后计算利息"。

用例图：反映用户级需求

用例图反映用户级需求，告诉你"系统要做什么"，但不告诉你"怎么做"。

用例图描述软件系统能为用户或外部系统提供的服务。它处于用户需求层次，只告诉你"系统有哪些功能"，不涉及"每个功能的具体步骤"。

就像菜谱目录，告诉你"这本菜谱有宫保鸡丁、麻婆豆腐"，但不告诉你"宫保鸡丁怎么做"。

用户故事和用例简述：轻量级的行为需求描述

用户故事和用例简述类似，都是轻量级的行为需求描述，用简短文字快速描述功能。

用户故事是敏捷方法中常用的需求描述技术，格式通常是："作为[角色]，我希望[功能]，以便[价值]"。

例如，银行储蓄系统的用户故事："作为柜员，我希望能够为客户开户，以便提高工作效率。"

用例简述是最简单、最实用的用例描述技术，用简短文字描述用例的功能。例如，"销户"用例的用例简述：帮助银行工作人员完成银行客户申请的活期账户销户工作，需客户提供证件和密码。

用户故事和用例简述本质上是一样的，都是轻量级的行为需求描述。就像菜谱的简单说明："宫保鸡丁：川菜经典，酸甜微辣，配米饭绝佳。"它们都处于行为需求层次，但描述得比较轻量。

用例规约：详细的行为需求描述

用例规约是详细的行为需求描述，精确描述"怎么做"的每个环节，包括正常情况和异常情况。

用例规约也处于行为需求层次，但描述得非常详细。它通常包括简要说明、主事件流、备选事件流、前置条件、后置条件、优先级等。

因此，用例图、用例规约、用户故事的关系是：用例图反映用户级需求（做什么），用户故事和用例简述是轻量级的行为需求描述（简单说明怎么做），用例规约是详细的行为需求描述（精确说明怎么做）。

五、如何应用？根据系统特点选择三套实践论

如何应用用例技术？根据系统特点选择小型、中型或大型方法。就像做菜，简单菜用简单方法，复杂菜用复杂方法。实践决定方法，不是方法一刀切实践。

实践中，不同系统有不同的特点：有的系统规模小，有的系统规模大；有的系统业务复杂，需要专门的业务流程建模；有的系统风险不在"业务复杂性"而在"技术复杂性"。

因此，不能一刀切地使用同一套方法。应该根据系统特点，选择合适的需求分析方法。

小型方法：适合业务不复杂的系统

小型方法适合业务不复杂、主要风险是技术难度的系统，只需要用例图+用例简述+用例规约。

小型方法包括三个需求工作项：

业务目标：提交《目标列表》，处于业务需求层次。
绘制用例图：提交《需求规格》或《用例模型》，处于用户需求层次。
编写用例规约：提交《需求规格》或《用例模型》，处于行为需求层次。

例如，嵌入式控制系统，主要风险是"技术难度"或"复杂控制规则"，不一定需要遵循业务系统的需求过程。就像做简单菜，你不需要复杂的准备过程，直接看菜谱做就行。

小型方法的好处是轻量级，适合快速开发，不易受到需求变更的冲击。

中型方法：适合需要明确业务目标的系统

中型方法在小型方法基础上，明确添加"高层需求=范围+Feature+上下文图"，需要提交相对正式的《愿景文档》。

中型方法包括四个需求工作项：

业务目标：提交《愿景文档》，处于业务需求层次。
高层需求：范围+Feature+上下文图，确保需求分析工作真正围绕业务目标展开。
绘制用例图：提交《需求规格》或《用例模型》，处于用户需求层次。
编写用例规约：提交《需求规格》或《用例模型》，处于行为需求层次。

就像做中等复杂度的菜，你需要先明确"要做什么菜"（业务目标），然后规划"需要哪些食材"（范围+Feature+上下文图），最后看详细步骤（用例图+用例规约）。

中型方法的好处是既保证了需求分析的完整性，又不会过于复杂。

大型方法：适合复杂业务系统

大型方法在中型方法基础上，明确添加"业务流程建模"，通过流程建模来发现用例。对于大规模解决方案，强烈建议不要"一上来就画用例图"，这往往导致需求遗漏。

大型方法包括五个需求工作项：

业务目标：提交《愿景文档》，处于业务需求层次。
高层需求：范围+Feature+上下文图。
业务流程建模：提交《流程模型》，通过业务流程建模来发现用例。
绘制用例图：提交《需求规格》或《用例模型》，处于用户需求层次。
编写用例规约：提交《需求规格》或《用例模型》，处于行为需求层次。

就像做复杂菜，你不能直接看菜谱，而要先了解"做这道菜的整个流程"（业务流程建模），然后从流程中发现"需要哪些步骤"（用例），最后看详细步骤（用例规约）。

大型方法的核心思想是：用例建模虽好，但对大规模解决方案来说不够，需要流程建模作为补充。对于大规模解决方案，强烈建议不要"一上来就画用例图"就认为完事了，这往往导致需求遗漏。需求变更不都是因为需求遗漏，但需求遗漏肯定导致需求变更，这是噩梦。

因此，对于复杂业务系统，应该先进行业务流程建模，然后从业务流程中发现用例。

六、需求分析的三套实践论中，用例建模和流程建模的关系是什么？

对于复杂业务系统，用例建模不够，还需要流程建模来发现用例。流程建模就像画地图，用例建模就像在地图上标记景点。先画地图，再标记景点，才能确保不遗漏。

很多人认为用例建模就够了，不需要流程建模。但实践表明，对于复杂业务系统，用例建模不够，还需要流程建模作为补充。

为什么需要流程建模？

流程建模是发现用例的有效手段。通过业务流程建模，可以更全面地发现功能、识别用例，避免需求遗漏。

对于大规模解决方案，强烈建议不要"一上来就画用例图"就认为完事了，这往往导致需求遗漏。需求变更不都是因为需求遗漏，但需求遗漏肯定导致需求变更，这是噩梦。

就像旅游，你不能直接在地图上标记景点，而要先画地图（业务流程建模），了解"整个区域有哪些地方"（业务流程），然后从地图上发现"哪些地方值得去"（用例），最后标记景点（用例图）。

流程建模的作用是：广泛地勾勒各种可能的业务场景，进行业务流程建模，识别必要的业务步骤。这些业务步骤，或者由几个步骤组成的业务流程片段，是发现"IT系统应该提供的功能（或日用例）"的最佳研究点。

如何从业务流程中发现用例？

从业务流程中发现用例的关键是：明确判断"业务步骤的3种类型"------全手工型、IT辅助型、IT全自动型。只有IT辅助型和IT全自动型的业务步骤，才会产生系统需求。

关键技巧是明确判断"业务步骤的3种类型"：

全手工型：不会产生"系统需求"。例如，"组建项目团队"是项目经理亲自来做，不推荐靠IT系统来组建团队。
IT辅助型（又称半手工型）：会产生"系统需求"，并由人机交互要求。例如，"制定进度计划"需要IT系统的帮助，因此发现用例"制定进度计划"。
IT全自动型：会产生"系统需求"，多为后台自动服务。例如，"自动计算利息"是系统自动处理，不需要人工干预。

从业务流程中发现用例的步骤是：

判断此业务步骤的"粒度"。如果不需要再继续分解，进入第2步。
判断此步骤是全手工型、IT辅助型、还是IT全自动型。经过判断，如果认定为"IT辅助型"或"IT全自动型"步骤，需要IT系统的帮助，因此发现用例。
将发现的用例添加到用例图中。

例如，对于"制定进度计划"这个业务步骤，判断为"IT辅助型"，因此发现用例"制定进度计划"。对于"组建项目团队"这个业务步骤，判断为"全手工型"，不推荐靠IT系统来组建团队，因此没有发现用例。

流程建模的实践方法：层层展开

流程建模采用"层层展开"的方式：针对每一个过于复杂的业务步骤，都可以展开成一个单独的子业务流程，如此递归。

首先，采用UML活动图绘制系统的高层业务流程图。例如，PM Suite的高层业务流程图，包括"项目启动"、"项目计划"、"项目执行"、"报告状态"、"项目归档"等业务步骤。

然后，采用"层层展开"的方式将业务流程建模推进下去。即，针对每一个过于复杂的业务步骤，都可以展开成一个单独的子业务流程，如此递归。

例如，对于高层业务流程图中的"项目计划"步骤，可以再进行业务流程分析，展开为"定义项目范围"、"创建WBS"、"制定进度计划"、"组建项目团队"、"分配任务"等子步骤。

这样，通过层层展开，可以更全面地发现业务流程中的每个步骤，然后判断每个步骤的类型，从而发现用例。

角色找全：另一个关键技巧

角色找全也是关键技巧：识别所有用户角色，避免遗漏需求。系统需要和外部哪些系统进行交互？谁使用系统的主要功能？谁需要系统支持他们的日常工作？谁来维护、管理使系统正常工作？系统需要操纵哪些硬件？

关键技巧，也是要把握全类型：

系统需要和外部哪些系统进行交互？
谁使用系统的主要功能？
谁需要系统支持他们的日常工作？
谁来维护、管理使系统正常工作？
系统需要操纵哪些硬件？

例如，思考"系统管理员"这个角色，可能会发现很多在业务流程分析时被忽略的"辅助流程"，从而发现更多"用例"。

角色找全和业务步骤类型判断是互补的。通过角色找全，可以发现更多用户角色，从而发现更多用例。通过业务步骤类型判断，可以从业务流程中发现用例。两者结合，可以更全面地发现需求。

总结：回答六个核心问题

用例技术是需求分析的实用工具，本文围绕六个核心问题展开：

1. 用例技术有哪些？它们有什么区别？ 用例技术是一个"技术族"，包含用例图、用例简述、用例规约、鲁棒图四种技术。它们就像菜谱的不同版本：用例图像菜谱目录（告诉你"要做什么菜"），用例简述像简单说明（快速了解），用例规约像详细步骤（精确描述），鲁棒图像做菜流程（属于设计）。

2. 用例图、用例规约、用户故事，这些技术有什么关系？ 它们处于需求的不同层次：用例图反映用户级需求（做什么），用户故事和用例简述是轻量级的行为需求描述（简单说明怎么做），用例规约是详细的行为需求描述（精确说明怎么做）。

3. 什么时候用哪个用例技术？ 不同场景需要不同层次：需求捕获和简单系统用用例图+用例简述，需求分析和需求规格定义用用例规约，初步设计用鲁棒图。就像做菜，先看目录决定做什么，再看简单说明了解大概，最后看详细步骤精确操作。

4. 如何应对需求变更？ 用例图像菜谱目录一样稳定（只描述"要做什么"），用例规约像具体步骤一样易变（精确描述"怎么做"）。聪明的做法是：先写简单版（用例图+用例简述），等需求稳定了再写详细版（用例规约）。推后用例细化，激发需求变更，让用户通过试用和反馈逐步明确真正想要的功能。

5. 如何应用？ 根据系统特点选择小型、中型或大型方法。小型方法适合业务不复杂的系统，只需要用例图+用例简述+用例规约。中型方法在小型方法基础上，明确添加"高层需求=范围+Feature+上下文图"。大型方法在中型方法基础上，明确添加"业务流程建模"。实践决定方法，不是方法一刀切实践。

6. 需求分析的三套实践论中，用例建模和流程建模的关系是什么？ 对于复杂业务系统，用例建模不够，还需要流程建模来发现用例。流程建模就像画地图，用例建模就像在地图上标记景点。先画地图（业务流程建模），再标记景点（用例建模），才能确保不遗漏。从业务流程中发现用例的关键是：明确判断"业务步骤的3种类型"（全手工型、IT辅助型、IT全自动型），只有IT辅助型和IT全自动型的业务步骤，才会产生系统需求。

用例技术不是万能的，但用对了场景，它是需求分析的有效工具。关键是理解不同用例技术的层次和特点，根据项目阶段和需求稳定性选择合适的用例技术，这样才能既保证需求分析的完整性，又避免需求变更带来的巨大冲击。对于复杂业务系统，还要结合流程建模，通过业务流程来发现用例，避免需求遗漏。