要资料 文章 文库 视频 Code iProcess 课程 角色 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
 

User Story用户情景与用例规约

 

2011-2-22 来源:网络

 

  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则更加强调在频繁交付时的质量门槛,值得推广。



需求分析方法—把测试流程图表化
敏捷需求分析五大关键因素
写好市场需求文档的10种技巧
需求分析中减少客户摩擦的法则
软件项目需求管理复杂性分析
EPC-事件驱动的流程链
更多...   


软件需求分析与管理实践
业务建模与业务分析
软件需求分析与管理
软件需求分析师
面向产品的需求分析与管理
IT规划体系与实践

相关咨询服务
软件需求分析与管理


北京 软件需求分析与管理
某知名基金 软件需求分析
联想 业务需求分析与建模
财税领域某IT服务商 测试需求分析
医疗行业 面向产品的需求管理
某知名IT服务商 测试需求分析>
某高新技术公司 测试架构、需求分析
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号