这几天读了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分钟。 |
|
安全性需求 |
产品的数据必须与数据的权威来源保持一致。 |
|
文化和政策需求 |
基于谁将认证产品是可接受的。 |
|
法律需求 |
法律部门/公司的律师将认证产品符合相关法律。 |
|
用例需求 |
所有相关需求的意图的总和。 |
|
限制条件 |
度量 |
五、需求管理
需求跟踪、需求变更、版本控制
需求事后分析，总结经验，从成功中获益并避免导致失败的失误。
六、需求开发过程
对收集、提取、编写和检查需求的过程进行剪裁，让这些过程能适应您的技术与文化环境。
需求中可以包含技术元素，但不能包含技术实现。
