【每周一本书】48 掌握需求过程

1 什么是需求？

当我们在做一个新产品时，可能会问，这个产品要做什么？是要实现远距离之间的通信？还是为了打发时间？这些是产品的目的，但是为了达到这个目的，应该要做哪些事情，这就构成了产品的功能性需求。在实现功能的同时，它必须易于上手，外观漂亮……这些就是它的非功能需求。

1.1 需求分类

•功能性需求：为了实现存在的根本理由，产品必须执行一些动作，功能性需求指明了产品必须做的事情。

•非功能性需求：产品必须具备的属性，这些属性使得产品有吸引力、易用、快速或可靠。这些属性存在不是因为它们是产品的基本活动，而是以为内用户希望这些功能性活动以某种方式执行。

功能性需求描述了从工作角度考虑的产品的动作。非功能性需求描述了用户在工作时的体验。

每项产品都有一些特征，把它与其他产品区分出来。我们买的音响，可能是因为它带来不同的感觉，或它比其他产品更易于使用。

非功能性需求存在多种类型：

•观感需求：产品的外观精神实质

•易用性需求：产品的易用性程度、以及特殊可用性考虑

•性能需求：功能的实现必须多快、多可靠、多精确……

•可操作性需求：产品的操作环境，以及对该操作环境必须考虑的问题

•可维护性和可移植性：期望的改变以及改变允许的时间

•安全性需求：产品的安全性需求

•文化和政策需求：有产品的开发者和使用者所带来的特别需求

•法律需求：哪些法律和标准适用于该产品

1.2 为什么需要需求

如果没有正确的需求，就不能设计或构造正确的产品，进而产品也就不能帮用户完成他们的工作。就像我们从小就学习的道德观“礼貌待人”，什么是礼貌呢？不骂人算吗？见面打招呼算吗？给老师起外号算吗？没有一个明确的需求定义，只有含糊的目标，是不可能做出满足需求的产品的。

据统计，产品开发中，60%的错误源于需求和分析活动。不好的结果是会层层传递，逐级放大的，从源头控制，是成本最低的方法。

2 需求过程

1 项目启动：确认产品的目标

2 网罗知识：收集产品需求

3 原型和场景建模：模拟产品，向用户表达需求

4 编写规格说明书：使用一致性的形式，记录潜在需求

5 质量关：检查潜在需求的完整性、相关性、一致性、可追踪性和其他质量属性，筛选出正式需求

6 重用需求：避免重复开发，寻找潜在可以重用的东西

7 鉴定需求：考虑需求规格说明书的完整性，检查遗漏的需求，保证所有的需求间协调一致，需求间没有冲突

8 事后分析：做对了什么？做错了什么？哪些地方可以改进？

3 需求规格说明书

所有的需求和限制条件，无论什么类型，都写入需求规格说明书中，这是产品能力的一个完整描述。

-----------------

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.反续版本需求：可能在产品将来的发行版本中包括的需求

-----------------

1.功能性需求示例：

2.非功能性需求示例

4 验收标准

验收意味着解决方案完全满足了需求。没有对需求的量化，就不可能知道实现是否符合需求，需求的量化就是它的验收标准。验收标准可以量化行为、性能或其他需求的质量。

1 功能性需求

一项功能性需求是产品必须要做的某件事情：产品必须采取的一项动作，因此验收标准指明了如何得知产品已经完成了该动作。对功能性需求来说，不存在度量的尺度，动作要么完成，要么没完成。

功能性需求的一般原则是，验收标准能确保功能被正确地执行。

例：

描述：产品将记录气象站的读书。

验收标准：记录的气象站读书与气象站发送的读书相符。

2 非功能性需求

非功能性需求看上去很难量化，但是，总可以为他们加上数字标准。如果不能对一项需求进行量化和度量，那么可能该需求其实不是一项需求，它可能是多项需求，或可能是一项还没有仔细考虑好的需求，甚至根本不是一项需求。

例：

描述：产品应该用户友好。

验收标准：新用户第一次使用时，能够在30分钟内完成添加、更改、删除操作。

5 质量关

质量关是为了防止无价值的需求进入需求规格说明书。在需求到达质量关之前，需求可能来自于任何地方，不论何时、以何种方式，每项需求出现时就捕获，不考虑完整性和一致性。当潜在需求到达质量关时，应该足够完整，以便通过测试来确定它应该被采纳还是排除。如果被排除，那么它被退回来源处进行澄清、修订或被放弃。

6 原型和场景

1. 原型

使用原型主要是给人们一些真实的东西，或至少表面上看上去真实的东西。原型可以让产品足够真实，这样潜在用户可以想到一些需求，不然就可能会遗漏这些需求。

------

例：

我希望这个电吹风能吹冷风。

我希望这个电子记事本能够识别电话号码，这样就能直接拨打记录的电话。

------

需求常常直到真正有人使用产品时才会出现，但那些已经晚了，产品已经存在了。需求收集的目的是在产品构建前就发现需求。

据统计，原型可以减少10%~25%的需求蔓延，但不是所有的需求都适合做原型。原型比其他需求收集方法潜在的花费更大，因此适用于一下场合：

•产品以前从未存在过，而且难于可视化

•产品的用户对这类产品没有经验，对建议使用的技术也没有经验

•用户对他们的工作已近有一段时间了，但在完成工作的方式上受到了阻碍

•用户在清晰说明他们的需求方面有困难

•需求分析师在理解需求上有困难

•需求的可行性值得怀疑

原型只用于帮助提取需求，从用户那里得到反馈，以产生新的需求。

2.场景

一个场景模型包括了一些场景或清洁，讲述了特殊情况下的一个详细故事。模型用于计划随着每个情节的推移，故事如何展开。

-------------

例：

业务时间#10 卡车车库报告卡车的故障

场景：没有卡车可以替代已抛锚的卡车

背景：Bill希望在1个小时内调度安排一辆卡车

情节1：

动作：Bill（地方工程师）向调度系统请求一辆卡车

结果：调度系统已经没有卡车可安排

情节2：

动作：Bill给Erik（区协调人）打电话

动作：Erik查看他的工作表

结果：没有卡车

结果：Erik宣布紧急情况

情节3：

动作：Bill给其他区打电话

动作：Erik给其他区打电话

结果：其他区借出一辆卡车

评估：是否需要与其他区联系？

如果其他区都没有可用的卡车怎么办？