51Testing软件测试论坛

标题: 《掌握需求过程》学习笔记 [打印本页]

作者: houzeal 时间: 2009-9-17 11:52
标题: 《掌握需求过程》学习笔记
这几天读了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分钟。
安全性需求	产品的数据必须与数据的权威来源保持一致。
文化和政策需求	基于谁将认证产品是可接受的。
法律需求	法律部门/公司的律师将认证产品符合相关法律。
用例需求	所有相关需求的意图的总和。
限制条件	度量

五、需求管理
需求跟踪、需求变更、版本控制
需求事后分析，总结经验，从成功中获益并避免导致失败的失误。

六、需求开发过程

对收集、提取、编写和检查需求的过程进行剪裁，让这些过程能适应您的技术与文化环境。
需求中可以包含技术元素，但不能包含技术实现。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)

分类	内容
产品现在条件	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、后续版本需求——可能在产品将来的发行版本中包括的需求。