掌握需求过程（三）

在为将要构建的产品明确需求时，如果我们在开始时能问一下“这些需求或与之相似的需求是否曾经明确过？”我们就有可能节省很多的的工作量。当我们打算确定我们是否有确定的可重用的需求，我们需要先对正在调查的工作有所了解，召开项目启动会议时应特别注意规格说明的前8部分：

1． 产品的目标——组织中是否存在其他的项目与本项目一致或实际上包含相同的领域？

2． 客户、顾客和其他风险承担者——我们可以重用一部分风险承担者的名单吗？

3． 产品的用户——其他产品是否涉及相同的用户，从而具有类似的易用性需求？

4． 需求限制条件——我们的限制条件是否已经在其他项目中指定？

5． 命令标准和定义——我们几乎肯定可以使用其他人的词汇，而不必自己重新发明所有的词汇。

6． 相关事实——请注意最近一些项目的相关事实，他们可能也适用于我们的项目。

7． 假定——对其他项目的假定也适用吗?

8． 产品的范围——我们的项目很有可能成为组织正在开发的其他项目的相邻系统。

我们可以发现为数不少的规格说明书可以利用一些现有的组件进行组装，而不是从空

开始。

在规格说明书的开发过程中，鉴定工作可能进行数次，他可能与自己的项目周期中的特定开发阶段对应，这种复查与质量关是有区别的，质量关单独地检查每项需求，而鉴定考虑的是所有的需求以及他们之间的相互影响。坚定的目标是复查规格说明书以发现这样的需求：遗漏的、冲突的、二义性的。

发现遗漏的需求：功能性需求应该足够完成每个用况的工作，为了检查这一点，通常需要与相应的用户一起把每个用况推演一遍，寻找遗漏的动作；针对非功能性需求类型的每个用况，该用况是否具备可他需要的和适合该类用况的所有非功能性需求？

是否已经发现所有的用况。

二义性的规格说明：规格说明书如果要做到实用就应该没有二义性，不应该使用任何代词，并对无限定的形容词和副词保持警觉——这些都会引起二义性，不要用“应该”这个词，他暗示着需求是可选的。规格说明书用到的所有属于都在命名规则和定义部分得到明确定义。

验收标准：每项需求都附有一项验收标准，验收标准是量化的目标。

功能点计算简介：功能点是软件功能性的度量，这意味着计算机自动化的产品所完成的工作量。工作量是基于产品所处理的数据和一些处理特征的。想法就是数据越多越复杂，所需的功能就越多。功能点计算能同时适用于面向过程的系统和面相对象的系统。

客户价值：满意度和不满意度反映了需求对我们的客户的价值。通常他们会附在每项需求后面，但是也可以附在每个用况的后面，以反应成功的实现这部分工作对客户的价值。这是客户告诉我们哪些需求最重要的最佳机制，用这个想法与我们的客户交流，鼓励他告诉你他对每项需求的真正想法。

对我们的产品，评估下面清单中的每种通用系统特征。这些评分将用于改变未调整的功能点计数，就像难度系数一样。通用系统的特征有：数据通信、分布式数据处理、性能、使用频繁的配置、事务处理比例、在线数据条目、最终用户效率、在线更新、复杂处理、可重用性、易于安装、易于操作、多个位置、易于改变。

需求也需要管理，不仅仅自编写规格说明书的时候，而是伴随产品存在的所有时间。需求工具如何、工具对照目标、剪裁过程、发布规格说明书、需求可追踪性（如果我们可以确定产品部分都是因为需求而存在的，并且对产品的任何部分来说，我们都可以指出源自于什么需求，那么需求就是可追踪的。需求必须是可追踪的，这样我们就可以保持产品和使用产品的外界之间的一致性）、处理变化(当我们推出一个产品，人们开始用它烤鹅安城工作时，经验告诉我们，需求会有变化，并且这种变化将伴随真个产品生命周期)、需求事后分析。