发帖
雷达卡
文章目录
- 用例技术有哪些？就像菜谱有简版和详版
- 什么时候用哪个用例技术？不同场景需不同层次
- 如何应对需求变更？用例图稳定，用例规约易变
- 用例图、用例规约、用户故事，这些技术有什么关系？
- 如何应用？根据系统特点选择三套实践论
- 需求分析的三套实践论中，用例建模和流程建模的关系是什么？
一、用例技术有哪些？就像菜谱有简版和详版
用例技术是一个“技术族”，包括用例图、用例简述、用例规约、鲁棒图四种技术。它们类似于菜谱的不同版本：用例图像菜谱目录，用例简述像简单说明，用例规约像详细步骤，鲁棒图像做菜流程。
用例技术不是单一的技术，而是一个“技术族”，由多种技术组成。就像菜谱有简版（告诉你“要做什么菜”）和详版（告诉你“怎么做菜”的每个步骤）。用例技术也是如此，有不同的层次，适用于不同的场景。
用例图：菜谱的目录
用例图类似于菜谱的目录，告诉你“系统要做什么菜”，但不告诉你“怎么做菜”。它描述了软件系统能为用户或外部系统提供的服务。就像菜谱的目录，它告诉你“这本菜谱有哪些菜”（系统有哪些功能），但不告诉你“每道菜怎么做”（每个功能的具体步骤）。
用例图最重要的元素是“参与者”（Actor）和“用例”（Use Case）。参与者是指与系统交互的角色或系统，可以是用户，也可以是另一个系统。用例是系统能为外部参与者提供的功能。
例如，银行储蓄系统的用例图中，参与者是“柜员”，用例有“开户”、“销户”。就像菜谱目录告诉你“这本菜谱有宫保鸡丁、麻婆豆腐”，但不告诉你“宫保鸡丁怎么做”。
用例图的作用有两个：一是识别与系统交互的角色或外部系统，二是描述系统必须提供的功能。对系统开发而言，用例图从视觉上明确了系统范围内的所有功能。
用例简述：菜谱的简单说明
用例简述类似于菜谱的简单说明，用简短文字描述“这道菜是什么”，适合快速了解。用例图中的用例必须命名，但用例图本身提供的信息有限。因此，需要其他“用例描述技术”进行进一步说明。
用例简述是最简单、最实用的“用例描述技术”，用简短文字描述用例的功能。一般来说，用例简述应包含成功场景的简单描述。
例如，银行储蓄系统“销户”用例的用例简述：帮助银行工作人员完成客户申请的活期账户销户工作，需客户提供证件和密码。就像菜谱的简单说明：“宫保鸡丁：川菜经典，酸甜微辣，配米饭绝佳。”
很多敏捷方法，如极限编程（XP）的用户故事卡、特性驱动开发（FDD）的特性，都使用类似用例简述的技术来捕获和沟通需求。
用例规约：菜谱的详细步骤
用例规约类似于菜谱的详细步骤，精确描述“怎么做菜”的每个环节，包括正常情况和异常情况。用例规约是另一种用例描述技术，是详细描述，通常包括简要说明、主事件流、备选事件流、前置条件、后置条件、优先级等。
用例规约的主要目的是定义软件系统的行为需求（可以归类为业务需求、用户需求、行为需求）。行为需求是指软件系统必须执行的动作，以提供用户需要的功能。
例如，银行储蓄系统"销户"用例的用例规约，详细描述了销户的每个步骤：银行工作人员进入"活期账户销户"程序界面→使用磁条读取设备扫描活期存折的磁条信息→系统自动展示该活期账户的客户资料和账户详情→银行工作人员核验申请人身份并确认销户→系统提示客户输入取款密码→客户通过密码输入装置输入取款密码→系统验证密码后计算利息、扣除利息税、计算最终销户金额并打印销户及利息结算单→系统记录销户交易流水及其分账户信息。
就像菜谱的详细步骤：“1. 鸡胸肉切丁，用料酒、盐腌制10分钟；2. 花生米炸至金黄；3. 热锅加油，快速炒鸡丁…“不仅告知"做什么”，还说明"如何做”、“何时做”、“遇到问题怎么办”。
用例规约的特点是详尽（详细），而用例简述则是简洁（简单）。用例规约以用户为中心描述系统行为，便于与用户沟通。它既关注成功场景（由主事件流描述），也关注异常情况（由备选事件流描述），这促进了系统的整体思维，有助于发现异常情形，提升系统功能，增强可用性。
鲁棒图：做菜的流程图
鲁棒图犹如做菜的流程图，说明"做菜所需工具和食材及其配合方式”，属于设计范围。
用例实现是面向对象理论中的"协作”部分，多个对象通过互动来达成目标。鲁棒图用于对用例实现进行建模，阐述实现用例功能所需的类及其互动。
例如，银行储蓄系统"销户"用例的鲁棒图，描述了销户功能所需边界对象（活期账户销户界面、磁条读取设备、打印装置）、控制对象（销户、计算利息）、实体对象（客户资料、销户流水、活期账户、利息率、利息税率）及其间的互动关系。
就像做菜的流程图："需要锅、铲、食材→先准备食材→再下锅炒→最后装盘。”它描述了做菜所需工具和食材，以及它们如何配合使用。
鲁棒图（用例实现）是从功能需求到设计方案的桥梁，是"思维的纽带”。需要注意的是，用例代表需求，而鲁棒图则是设计的一部分。
二、什么时候应用哪种用例技术？不同场景需不同层次
不同情境需要不同程度的用例技术：需求捕获使用用例图+用例简述，需求分析使用用例规约，初步设计使用鲁棒图。就像做菜，先看菜谱目录决定做什么，再看简单说明了解大概情况，最后看详细步骤进行精确操作。
4种用例技术，用于3种实践场景：
场景1：需求捕获和简单系统的需求分析
用例图+用例简述：既可用于需求捕获，也可用于业务不太复杂的系统的需求分析。
有两点好处：一是涵盖面广，所有功能需求都能被覆盖；二是深入的细节不多，不易受到需求变更的影响。
就像做菜，你先看菜谱目录（用例图）决定"要做什么菜”，再看简单说明（用例简述）了解"这道菜大致是什么”。如果菜谱很简单，这样就足够了。
场景2：需求分析和需求规格定义
用例规约：用于需求分析与需求规格定义。
用例规约本身是一种思维工具，它围绕"为参与者带来价值的可见结果”展开，挖掘出各种处理场景、异常情况，使需求定义更加完善。需求分析的目标是获得明确和规范的需求定义，用例规约技术正适用于此。
就像做菜，如果菜谱较为复杂，你需要看详细步骤（用例规约），了解"每个步骤如何操作”、“遇到问题怎么解决”。
场景3：初步设计
用例实现（鲁棒图）：用于初步设计。
用例是需求，而鲁棒图则是设计。鲁棒图描述了实现用例功能所需的类及其互动，属于设计范围。
就像做菜，详细步骤告诉你"如何操作”，但做菜的流程图（鲁棒图）告诉你"需要哪些工具和食材，它们如何配合使用”。
三、如何应对需求变更？用例图稳定，用例规约易变
面对需求变更，用例图像菜谱目录一样稳固，用例规约像具体步骤一样容易变化。明智的做法是：先编写简化版（用例图+用例简述），等需求稳定后再撰写详细版（用例规约）。
用例图和用例规约处于不同的"需求层次”（业务需求、用户需求、行为需求），因此对需求变更的抵抗力不同。
用例图：像菜谱目录一样稳固
用例图能稳定反映用户级需求，因为它只描述"要做什么”，而不涉及"如何做”。例如，1999年11月1日，中国开始对储蓄利息征收个人所得税。这个变化影响了"结息”功能，需要调整数据库结构和功能。
但开征利息税对包括"结息”在内的整个用例图没有影响。因为用例图仅反映"储蓄系统必须有结息功能”，而不涉及"结息业务规则的变化”。就像菜谱目录，即使"宫保鸡丁”的做法变了，目录上还是"宫保鸡丁”，不会变成"宫保鸡丁2.0”。
这意味着用例图适合在项目早期使用，因为它不易受到需求变更的冲击。
用例规约：像具体步骤一样易变
由于用例规约精确所以容易变化，需求变更通常发生在行为需求层面，这正是用例规约描述的内容。开征利息税对"结息”用例的用例规约影响很大。主事件流需要新增步骤：系统计算此账户的利息税=利息×利息税率；系统计算出应付利息=利息-利息税。其他步骤也发生了变化。
这些重大变化发生在行为需求层面，反映在用例规约的主事件流和备选事件流中。就像菜谱的详细步骤，如果"宫保鸡丁”的做法变了，详细步骤必须修改。
这意味着用例规约适合在需求相对稳定后进行详细编写，过早细化会增加需求变更管理的负担。
实践启发：推迟用例细化，促进需求变更
为了更明智地应对需求变更，应该“推迟用例细化、促进需求变更”。具体来说：不是对软件架构至关重要的用例，可以推迟到实现该用例所定义的功能之前再进行细化。
正如前面所述，需求变更对用例图和用例简述的影响较小，而对用例规约影响较大。因此我们应“推迟用例细化、促进需求变更”。
推迟用例细化。
不是对软件架构至关重要的用例，可以推迟到实现该用例所定义的功能之前再进行细化。过早地为这些用例制定用例规约会增加“需求变更管理”的负担，使需求变更的影响加大。
就像做菜，你不必一开始就写出所有菜的详细步骤。先写菜谱目录和简要说明，等决定要做哪道菜了，再写那道菜的详细步骤。
促进需求变更。
这一点非常重要。必须通过不断增加功能、发布小版本、提供用户试用、接受用户反馈等一系列活动，让用户逐步明确自己真正需要的功能。在前期版本的反馈中，往往涉及较多的需求变更，而此时大量用例尚未细化，因此避免了需求变更带来的巨大冲击。
就像做菜，你先做一些简单版本给客人试吃，根据反馈进行调整，等客人满意后，再写详细菜谱。这样做比一开始就写详细菜谱，然后频繁修改要好得多。
在项目早期“不将所有用例细化”，意味着“将大多数用例保持在‘用例图+简短描述’的水平”。这样做，并不影响“开发原型、征求客户意见、识别需求变更、再原型、再识别需求变更…”的过程。此后，需求分析师对用例进行细化。
四、用例图、用例规约、用户故事，这些技术有什么关系？
用例图、用例规约、用户故事处于需求的不同层次：用例图反映用户级需求，用例规约描述行为需求，用户故事和用例简述类似，都是轻量级的行为需求描述。它们就像菜谱的不同部分：用例图像目录，用户故事像简要说明，用例规约像详细步骤。
很多人对用例图、用例规约、用户故事的关系感到困惑。其实，它们处于需求的不同层次，服务于不同的目的。
需求的三层结构：业务需求、用户需求、行为需求
需求分为三个层次：业务需求（为什么做）、用户需求（做什么）、行为需求（怎么做）。用例图、用例简述、用例规约、用户故事分别处于不同层次。
就像写菜谱，你需要先知道“为什么要写这本菜谱”（业务需求），然后决定“这本菜谱要包含哪些菜”（用户需求），最后详细描述“每道菜怎么做”（行为需求）。
业务需求
客户或出资者要达到的业务目标。例如，“提高银行工作效率”。
用户需求
用户使用系统来辅助完成哪些工作。例如，“柜员可以开户、销户”。
行为需求
软件系统必须执行的动作。例如，“系统验证密码后计算利息”。
用例图：反映用户级需求
用例图反映用户级需求，告诉你“系统要做什么”，但不告诉你“怎么做”。用例图描述软件系统能为用户或外部系统提供的服务。它处于用户需求层次，只告诉你“系统有哪些功能”，不涉及“每个功能的具体步骤”。
就像菜谱目录，告诉你“这本菜谱有宫保鸡丁、麻婆豆腐”，但不告诉你“宫保鸡丁怎么做”。
用户故事和用例简述：轻量级的行为需求描述
用户故事和用例简述类似，都是轻量级的行为需求描述，用简短文字快速描述功能。用户故事是敏捷方法中常用的需求描述技术，格式通常是：“作为[角色]，我希望[功能]，以便[价值]”。例如，银行储蓄系统的用户故事：“作为柜员，我希望能够为客户开户，以便提高工作效率。”
用例简述是最简单、最实用的用例描述技术，用简短文字描述用例的功能。例如，“销户”用例的用例简述：帮助银行工作人员完成银行客户申请的活期账户销户工作，需客户提供证件和密码。
用户故事和用例简述本质上是一样的，都是轻量级的行为需求描述。就像菜谱的简单说明：“宫保鸡丁：川菜经典，酸甜微辣，配米饭绝佳。”它们都处于行为需求层次，但描述得比较简洁。
用例规约：详细的行为需求描述
用例规约是详细的行为需求描述，精确描述“怎么做”的每个环节，包括正常情况和异常情况。用例规约也处于行为需求层次，但描述得非常详尽。它通常包括简要说明、主事件流、备选事件流、前置条件、后置条件、优先级等。
就像菜谱的详细步骤：“1. 鸡胸肉切丁，用料酒、盐腌制10分钟；2. 花生米炸至金黄；3. 热锅下油，爆炒鸡丁…“不仅告诉你”做什么”，还告诉你”怎么做”、“什么时候做”、“如果出问题怎么办”。
因此，用例图、用例规约、用户故事的关系是：用例图反映用户级需求（做什么），用户故事和用例简述是轻量级的行为需求描述（简单说明怎么做），用例规约是详细的行为需求描述（精确说明怎么做）。
五、如何应用？根据系统特点选择三套实践论
如何应用用例技术？根据系统特点选择小型、中型或大型方法。就像做菜，简单菜用简单方法，复杂菜用复杂方法。实践决定方法，而不是方法一刀切。
在实际操作中，不同系统具有不同的特性：有的规模较小，有的较大；有的业务复杂，需要专门的流程建模；而有的风险则主要在于技术而非业务。
因此，不能一概而论地使用同一套方法。应根据系统的具体特点选择合适的需求分析方法。
小型方法：适合业务简单的系统
小型方法适用于业务简单、主要风险为技术难度的系统，只需用例图+用例简述+用例规约。
小型方法包含三个需求工作项：
- 业务目标：提交《目标列表》，处于业务需求层次。
- 绘制用例图：提交《需求规格》或《用例模型》，处于用户需求层次。
- 编写用例规约：提交《需求规格》或《用例模型》，处于行为需求层次。
例如，嵌入式控制系统的主要风险在于技术难度或复杂的控制规则，并不一定需要遵循业务系统的需求过程。这就像做简单的菜肴，你不需要复杂的准备步骤，直接按照菜谱操作即可。
小型方法的优点是轻量级，适合快速开发，不易受到需求变更的影响。
中型方法：适合需明确业务目标的系统
中型方法在小型方法的基础上，增加了“高层需求=范围+特性+上下文图”，需要提交相对正式的《愿景文档》。
中型方法包含四个需求工作项：
- 业务目标：提交《愿景文档》，处于业务需求层次。
- 高层需求：范围+特性+上下文图，确保需求分析围绕业务目标展开。
- 绘制用例图：提交《需求规格》或《用例模型》，处于用户需求层次。
- 编写用例规约：提交《需求规格》或《用例模型》，处于行为需求层次。
这就像制作中等复杂度的菜肴，你需要先明确“要做什么菜”（业务目标），然后规划“需要哪些食材”（范围+特性+上下文图），最后查看详细步骤（用例图+用例规约）。
中型方法的优点是既保证了需求分析的完整性，又不至于过于复杂。
大型方法：适合复杂的业务系统
大型方法在中型方法的基础上，增加了“业务流程建模”，通过流程建模来发现用例。对于大规模解决方案，强烈建议不要一开始就绘制用例图，这往往会导致需求遗漏。
大型方法包含五个需求工作项：
- 业务目标：提交《愿景文档》，处于业务需求层次。
- 高层需求：范围+特性+上下文图。
- 业务流程建模：提交《流程模型》，通过业务流程建模来发现用例。
- 绘制用例图：提交《需求规格》或《用例模型》，处于用户需求层次。
- 编写用例规约：提交《需求规格》或《用例模型》，处于行为需求层次。
这就像制作复杂的菜肴，你不能直接查看菜谱，而要先了解“做这道菜的整个流程”（业务流程建模），然后从流程中发现“需要哪些步骤”（用例），最后查看详细步骤（用例规约）。
大型方法的核心思想是：虽然用例建模很好，但对大规模解决方案来说并不够，需要流程建模作为补充。对于大规模解决方案，强烈建议不要一开始就绘制用例图并认为任务已完成，这往往会导致需求遗漏。需求变更不全是因为需求遗漏，但需求遗漏肯定会引起需求变更，这是噩梦。
因此，对于复杂的业务系统，应先进行业务流程建模，然后从业务流程中发现用例。
六、需求分析的三套实践论中，用例建模和流程建模的关系是什么？
对于复杂的业务系统，仅靠用例建模是不够的，还需要通过流程建模来发现用例。流程建模就像画地图，用例建模则是在地图上标记景点。先画地图，再标记景点，才能确保不遗漏。
很多人认为用例建模已经足够，无需进行流程建模。但实践表明，对于复杂的业务系统，仅靠用例建模是不够的，还需要通过流程建模来补充。
为什么需要流程建模？
流程建模是发现用例的有效手段。通过业务流程建模，可以更全面地发现功能、识别用例，避免需求遗漏。
对于大规模解决方案，强烈建议不要一开始就绘制用例图并认为任务已完成，这往往会导致需求遗漏。需求变更不全是因为需求遗漏，但需求遗漏肯定会引起需求变更，这是噩梦。
就像旅游，你不能直接在地图上标记景点，而要先画地图（业务流程建模），了解“整个区域有哪些地方”（业务流程），然后从地图上发现“哪些地方值得去”（用例），最后标记景点（用例图）。
流程建模的作用是：广泛地勾勒各种可能的业务场景，进行业务流程建模，识别必要的业务步骤。这些业务步骤或由几个步骤组成的业务流程片段，是发现“IT系统应提供的功能（或日用例）”的最佳研究点。
如何从业务流程中发现用例？
从业务流程中发现用例的关键在于：明确判断“业务步骤的三种类型”——全手工型、IT辅助型、IT全自动型。只有IT辅助型和IT全自动型的业务步骤，才会产生系统需求。
关键技巧是明确判断“业务步骤的三种类型”：
- 全手工型：不会产生“系统需求”。例如，“组建项目团队”由项目经理亲自完成，不推荐依赖IT系统。
- IT辅助型（又称半手工型）：会产生“系统需求”，并涉及人机交互要求。例如，“制定进度计划”需要IT系统的帮助，因此发现用例“制定进度计划”。
- IT全自动型：会产生“系统需求”，多为后台自动服务。例如，“自动计算利息”由系统自动处理，不需要人工干预。
从业务流程中发现用例的步骤是：
- 判断此业务步骤的“粒度”。如果无需进一步分解，则进入下一步。
确定此步骤是完全手动型、IT辅助型还是IT自动型。经过评估，如果确认为"IT辅助型"或"IT自动型"的步骤，则需要IT系统的支持，因此会产生用例。
将识别出的用例添加到用例图中。
例如，对于“制定进度计划”这一业务活动，判断为“IT辅助型”，因此产生用例“制定进度计划”。对于“组建项目团队”的业务步骤，判断为“完全手动型”，不建议使用IT系统来组建团队，因此没有生成用例。
流程建模的实践方法：分层次展开
流程建模采用“分层次展开”的方式：对于每个过于复杂的业务活动，都可以细化成一个独立的子业务流程，以此类推进行递归。
首先，使用UML活动图绘制系统的高层次业务流程图。例如，PM Suite的高层次业务流程图包括“项目启动”、“项目规划”、“项目执行”、“报告状态”、“项目存档”等业务步骤。
然后，采用“分层次展开”的方式将业务流程建模推进下去。即，对于每个过于复杂的业务活动，都可以细化成一个独立的子业务流程，以此类推进行递归。
例如，对于高层次业务流程图中的“项目规划”步骤，可以进一步进行业务流程分析，细分为“定义项目范围”、“创建WBS”、“制定进度计划”、“组建项目团队”、“分配任务”等子活动。
这样，通过分层次展开，可以更全面地识别出每个业务活动的细节，然后判断每个活动的类型，从而产生用例。
角色全找：另一个关键技巧
角色全找也是重要技巧：识别所有用户角色，避免需求遗漏。系统需要与哪些外部系统交互？谁使用系统的主要功能？谁依赖系统支持日常工作？谁来维护、管理使系统正常运行？系统需要操作哪些硬件？
关键技巧在于全面掌握：
- 系统需要与哪些外部系统交互？
- 谁使用系统的主要功能？
- 谁依赖系统支持日常工作？
- 谁来维护、管理使系统正常运行？
- 系统需要操作哪些硬件？
例如，思考“系统管理员”这一角色，可能会发现许多在业务流程分析中被忽略的辅助活动，从而产生更多用例。
角色全找和业务活动类型判断是互补的。通过角色全找，可以识别出更多用户角色，进而产生更多用例。通过业务活动类型判断，可以从业务流程中发现用例。两者结合，可以更全面地捕捉需求。
总结：回答六个核心问题
用例技术是需求分析的实用工具，本文围绕六个核心问题展开：
- 有哪些用例技术？它们有何区别？
用例技术是一个“技术群”，包括用例图、用例简述、用例规约和鲁棒图四种技术。它们就像不同版本的菜谱：用例图类似于菜谱目录（告诉你“要做什么”），用例简述像简单说明（快速了解），用例规约像详细步骤（精确描述），鲁棒图像做菜流程（属于设计）。 - 用例图、用例规约和用户故事，这些技术有何关联？
它们处于需求的不同层次：用例图反映用户级需求（做什么），用户故事和用例简述是轻量级的行为需求描述（简单说明怎么做），用例规约是详细的行为需求描述（精确说明怎么做）。 - 何时使用哪种用例技术？
不同场景需要不同层次：需求捕获和简单系统适合用例图+用例简述，需求分析和需求规格定义适合用例规约，初步设计适合鲁棒图。就像做菜，先看目录决定做什么，再看简单说明了解大概，最后看详细步骤精确操作。 - 如何应对需求变更？
用例图像菜谱目录一样稳定（只描述“要做什么”），用例规约像具体步骤一样易变（精确描述“怎么做”）。明智的做法是：先写简单版（用例图+用例简述），等需求稳定后再写详细版（用例规约）。推迟用例细化，促进需求变更，让用户通过试用和反馈逐步明确真正想要的功能。 - 如何应用？
根据系统特点选择小型、中型或大型方法。小型方法适合业务不复杂的系统，只需用例图+用例简述+用例规约。中型方法在小型基础上增加“高层次需求=范围+特性+上下文图”。大型方法在中型基础上增加“业务流程建模”。实践决定方法，而不是一刀切。 - 需求分析的三套实践中，用例建模和流程建模的关系是什么？
对于复杂业务系统，仅用例建模是不够的，还需要流程建模来发现用例。流程建模就像绘制地图，用例建模像在地图上标记景点。先绘图（业务流程建模），再标记景点（用例建模），才能确保不遗漏。从流程中发现用例的关键在于：明确判断“三种类型”的业务活动（完全手动型、IT辅助型和IT自动型），只有IT辅助型和IT自动型的业务活动才会生成系统需求。
用例技术并非万能，但在合适的场景下，它是需求分析的有效工具。关键是理解不同用例技术的层次和特点，根据项目阶段和需求稳定性选择合适的用例技术，这样才能既保证需求分析的完整性，又避免因需求变更带来的重大影响。对于复杂业务系统，还需结合流程建模，通过业务流程来发现用例，防止需求遗漏。
京公网安备 11010802022788号
