用例、用例图肯定不少人听说过，也都基本知道它们大概是什么，我之前也是如此，直到最近偶然发现一本软件工程的书：《编写有效用例》，带着好奇心读了一遍，了解了一下软件工程技术角度对软件设计的思维方式，这里发文mark一下

一、重新理解用例

1、《编写有效用例》的内容总结

完整的用例体

       你会发现可能比原来网上看到的用例多了一些东西，多了使用语境、范围、级别、项目相关人员和利益、技术和数据变化列表这5点，其实在描述产品需求的时候，完全可以不描述这几个点，前4点更多属于设计产品时的考量，和实际的系统行为无关，最后一点则可以合并到扩展中，但是我认为有必要理解其中的思想，以便在我们从业务逻辑、从场景中提取产品需求后，对整体产品的功能逻辑进行更全面的考虑，下面介绍主要的点：

1、项目相关人员：包括了所设计系统外的一切人或物，可理解为系统的利益相关者，只是不像我们在需求分析时关注的那么广，此时只是聚焦到当前用例所涉及到的人，其实就是产品设计中对主要、次要、反面人物模型的梳理；

1）主执行者：书中说是请求系统提供服务的人（不得不吐槽这个描述太那啥了），其实就是指用户，可能包括多个角色，在《交互设计精髓》中则可理解为主要人物模型，从描述产品需求的目的出发的话，我们只需要讲清楚该用例是关于哪些用户、哪些角色即可

2）辅助执行者：为使系统运转所起来到的外部人或物，比如订单系统需要依赖库存系统才能知道我这订单能不能生成，点餐系统需要依赖后厨打印机厨师才可接到单子

2、范围（设计范围）：指设计时考虑的部分，由于一个用例可能涉及到本次无需设计的部分，此时通过这一点其实就是在说明该需求涉及到的部分是哪里，哪里是没有涉及到的

3、级别：指的是目标级别，目标的层次很好理解就不多说了（举个例子就是吃饭是一个层次目标，吃饭是为了生存是另外一个层次的目标，生存是为了找到自身价值又跑到另外一个层次的目标，扯远了。。），实际上只需要在设计时明确用户目标即可

4、前置条件：必要条件，执行用例前必须满足的前提

5、最小保证：系统对项目相关人员的承诺，保证多方利益，特别是失败情况下的承诺，比如多次输入密码失败后还是能申诉

6、成功保证：即系统成功执行后的结果

7、触发事件：启动用例的事件，有时也是用例的第一步

8、主成功场景：以理解为该用例的主干流程（书中将用例的每个步骤集称为一个场景，比如添加规则，可以是导入的方式，也可以是手动的方式，两个分支对应着不同的步骤，也就对应着不同的场景）

9、扩展：包括其他分支、异常情况以及对应情况下的处理，着重考虑几种以下几种情形：

1）其他正常情况路径

2）操作错误的情况

3）无任何操作的情况

4）系统确认/校验不通过的情况

5）从外部系统/人没有得到响应或响应错误

6）系统崩溃

2、如何理解运用

       现在讲究效率的背景下，编写冗长的用例会耗费不少时间，除非很有必要（比如规范规定）。所以要记得用例本身只是一种描述产品需求的方式，所以从这个目标出发，我重新整理了在实际中如何去运用这种描述需求的思路：将上面提到的概念运用到画功能流程图中（适合在最后细化的使用，不要一上来就画到很细，书中也提到用例本身也是不是一次性完善的，而是逐步确认逐步再细化的），如下：

基于用例的思想来画功能流程图

       可以看出用例中提到的点基本都囊括在了功能流程图中，在写PRD时再注意将对应的点描述出来（这其实也是书中提到的用例的表达方式之一）

3、文档表达需求的注意点（摘录自书中）

1）用例名：简单的”主谓（前置短语）宾“

2）从第三方的角度进行描述

3）显示执行者的目标而非操作界面的动作，不涉及界面元素，减少维护和改动成本（在进入具体设计阶段之前）

二、重新理解用例图

       用例图描述的是用例之间的关系，网上说到有泛化、扩展、包含，但我建议如果不是有很强的必要性，不去管这些UML用例图中提到的关系，只专注于你只是希望想传播出功能范围这件事即可，用简单的分支帮助自己梳理清楚功能间的关系，帮助团队了解到需求的范围。

三、总结

工具为目的服务才是关键，标准有时候是有道理的，有时候也要加以改变，特别是老的思想，需要在新的背景下结合使用，以上便是读完《编写有效用例》后的感受，欢迎交流~

微信公众号：产品有温度