User Story用户情景与用例规约

Posted on Posted in UML学习, 产品经理

【说明】产品经理在描述需求阶段,经常会利用UML语言中的用例图(Use Case)来描述需求,但在敏捷开发Scrum中,往往会把需求拆分为User Story。对Use Case和User Story的区别,很多时候会分不清楚。本文转载自http://www.uml.org.cn/RequirementProject/20112224.asp,对此进行了详细的比较和说明。

转载开始:

User Story,译为“用户情景”,在敏捷软件过程Scrum中,用来表达需求模块。而对于熟悉UML的人员而言,使用Use Case,译为“用例”,多年来专业软件开发团队都用以表达需求模块。

User Story与Use Case有什么差异?这些差异背后又体现出了哪些开发思想的不同?本文对这两者有价值的差异点进行探讨。

 一、User Story与Use Case形式上的差异

字段示例
用例名称故事定义
用例ID目标
参与者(列表)特性
用例概述(价值)说明
前置条件功能
基本事件流描述
备选事件流先决条件
后置条件流程
扩展点验收测试
其它(非功能需求、技术约束、补充需求、技术风险、遇到的问题)功能测试
 设计

表1:形式上的差异

Use Case有2种维度来描述,即图形维度(用例图)和文字维度(用例规约)。User Story一般使用文字维度来表述,所谓文字维度,并不是说不可以图文并茂,而是无需特意使用建模工具建模。

  二、用例规约要点
用例规约示例

图1:用例规约示例

用例规约要点如下:

事件流以Actor参与者或“系统”作为主语,使用主动语句; 谨记用例是“黑盒”。描述语句只能描述Actor可以看见的交互,而不能描述软件内部的情况(打开数据库连接对象、执行SQL语句等等); 在“其它”字段,尽可能把此功能块的“非功能需求”也都应详细描述

 三、用户情景要点
用户情景示例

图3:用户情景示例(摘自微软文章)

每个用户情景都会有一个测试工程师负责其质量,测试工程师会为情景设计两个测试计划:一个是“验收测试计划”,另一个是“功能测试计划”。验收测试是黑盒测试,其目的在于验证用户故事是否按照设计预想的那样被实现。这里需要注意的是,在着手实现一个用户故事之前,准备好这样的验收测试步骤(当然,这样的验收测试不一定全部是自动化的)并且将其集成到用户故事文档中去是一个必要的步骤。验收测试的编写并且通过,需要被纳入用户故事“完成”的标准中去。如果没有经过这样的一个步骤,用户情景就不能被签字认可。相对而言,功能测试计划是一个更为详细的计划,测试工程师需要针对不同的代码路径以及不同用户输入情况进行测试,从而保证软件在各种情况下都能正常工作。

  四、深层次的思考
Use Case有2种维度来描述,即图形维度(用例图)和文字维度(用例规约)。用例图很难表达非功能需求,而在用例规约中描述。但不少团队在项目进度紧急时,往往会忽略功能以外的需求,这会导致团队重功能而轻性能。

用户情景在字段上,描述的信息和用例规约基本是一致的。最重要的区别,在于两个测试计划,强调了对开发出的模块的质量要求。更加符合迭代增量式的开发思想。

结语:
用例技术可以很好的与MSF / RUP等迭代增量式的开发过程整合。而User Story则更加强调在频繁交付时的质量门槛,值得推广。

转载结束。

 



4 thoughts on “User Story用户情景与用例规约

  1. 我的理解:User Story是业务需求描述;比较灵活,直接指导产品设计。产出产品原型后,可以依据它进行业务验证;Use Case是技术需求描述,更严谨,指导技术开发和测试!

    1. 我理解的倒不一样,User Story反而更好的指导了开发和测试,因为User Story是PM、RD、QA一同完成的,而User Case只是RD完成。

  2. User Story描述是通过传统手写记录在卡片上,思考方法是:card 包含story正文,通过会话得出细节,并记录在测试用例中。我是这样理解滴。

  3. 只用UC描述功能,开发和测试不容易完全理解系统,US到是一个让开发和测试了解系统全貌的好方法

发表评论

电子邮件地址不会被公开。 必填项已用*标注