TA的每日心情 | 擦汗 2015-5-25 17:24 |
---|
签到天数: 3 天 连续签到: 1 天 [LV.2]测试排长
|
这几天读了Suzanne Robertson,James Robertson的《掌握需求过程》,本书用一个接一个的步骤、一个接一个的模板、一个接一个的例子,向我们展示了一个经过业界检验的需求收集和验证过程。
从项目启动、项目计划、项目实施、项目监控、项目结束主线角度描述了需求的目标与范围;需求规格说明书模版与需求框架;需求收集;通过需求原型获取更多、丰富的需求并发现遗漏需求;需求验证;需求管理、需求跟踪、需求事后经验总结。
一、Volere需求规格说明书模版与需求框架
分类
| 内容
| | 1、
产品的目标——构建产品的原因和如果使用了该产品能带给业务的优势。
2、
客户、顾客和其他的风险承担者——产品涉及他们的利益。
3、
产品的用户——预期的最终用户,以及他们的水平对产品可用性的影响。
4、
需求限制条件——项目的局限性和产品设计的限制条件。
5、
命名标准和定义——产品相关的词汇表。
6、
相关事实——对产品产生一定影响的外部因素。
7、
假定——开发者所做的假定。
| | 8、
产品的范围——定义产品的边界,以及它与相邻系统的连接情况。
9、
功能与数据需求——产品必须做的事情和功能进行的数据操作。
| | 10、观感需求——预期的外观
11、易用性需求——基于预期用户的操作水平作出。
12、操作需求——产品预期的操作环境。
13、性能需求——多快、多大、多精确、多安全、多可靠等。
14、可维护性和可移植性需求——产品的可改动性必须达到什么水平。
15、安全性需求——产品的安全性、保密性和完整性。
16、文化与政策需求——人的因素。
17、法律需求——满足适用的法律。
| | 18、开放式问题——那些尚未解决的问题,可能对项目的成功有影响。
19、商业上架式软件解决方案——利用已有的组件而不是从头开发。
20、新问题——因为引入新产品而带来的问题。
21、任务——将产品生产出来必须要做的一些事情。
22、迁移——从现存系统转换的任务。
23、风险——项目最有可能面对的风险。
24、费用——早期对构建产品的成本或工作量的估计。
25、用户文档——创建用户指南和文档的计划。
26、后续版本需求——可能在产品将来的发行版本中包括的需求。
|
二、需求收集
确定根本需求,将需求与解决方案分离,理解系统的真正目标。
做用户的学徒,揭示有意识和无意识的需求,如果用户因为“太忙”而无法交谈,这种方法很有用。
业务事件研讨会,产生业务规则与目标。
头脑风暴,召集一组聪明的、有意愿的、不同学科背景、不同经验的人,让他们对新产品产生尽可能多的想法。
用录像记录用户和需求分析师参加的研讨会和头脑风暴的过程,录像的作用有:记录、确认、备忘。
通过网络查找技术,可以收集需求的相关线索。
用户访谈与问卷调查。
网罗知识
三、需求原型
需求原型是对需求模拟的模型,设计目的是帮助了解更多用户需求。需求原型有三种:
低保真原型是一种快速模拟产品的方式,使用熟悉的技术,诸如笔、纸、白板等。低保真原型有助于将注意力集中在产品做什么上,而不是产品看起来如何,他们有助于发现遗漏的功能和测试产品的范围。
高保真原型使用做原型的工具来给出非常真实的外观,他们对于发现易用性需求是特别有效的。
场景模型是一项是抽象主题变得生动的技巧,它通过对一个特定实例讲故事的方式来做到这一点。这些模型能有效地帮助人们将注意力集中在细节上,并发现其他情况可能会遗漏的异常。
四、需求验证
方面
| 验收判断标准
| 功能性需求
| 确保功能被正确地执行
| 非功能性需求
| 量化度量,引入该产品的3个月之内,60%的用户将用它来完整规定的工作。在这些用户之中,将有75%对产品表示赞许。
| 客户
| 询问客户一个关键问题来确定,这个问题是:“什么会被认为是满足需求失败?”。
| 测试
| 产品将不会让测试组的80%的人感觉到被冒犯。
| 观感需求
| 界面的兼容性作为验收标准
| 易用性需求
| 经过一天培训之后,10个用户中有9个能够成功地完成选择的任务。
| 性能需求
| 在95%的情况下,响应时间将不超过1.5秒,在其他情况下不超过4秒。
| 可操作性需求
| 对要求的环境下使用是否容易或使用是否成功的量化标准。
| 可维护性需求
| 新的用户将能被加入系统,并且对现存用户的打断不超过5分钟。
| 安全性需求
| 产品的数据必须与数据的权威来源保持一致。
| 文化和政策需求
| 基于谁将认证产品是可接受的。
| 法律需求
| 法律部门/公司的律师将认证产品符合相关法律。
| 用例需求
| 所有相关需求的意图的总和。
| 限制条件
| 度量
|
五、需求管理
需求跟踪、需求变更、版本控制
需求事后分析,总结经验,从成功中获益并避免导致失败的失误。
六、需求开发过程
对收集、提取、编写和检查需求的过程进行剪裁,让这些过程能适应您的技术与文化环境。
需求中可以包含技术元素,但不能包含技术实现。 |
|