做好需求协商及复审

（五）做好需求协商及复审

1.为什么要需求协商

在需求分析过程中，来自客户的需求也许是重叠或者矛盾的。有些需求可能是模棱两可或者不现实的，其他一些需求可能还没有被发现。由于这些原因，在形成需求文档之前需要对需求进行协商及复审。

实际上需求协商及复审是与需求引导同步进行的。在进行需求引导时，就需要接受一定程度的审查。涉及社会群体的所有现代需求引导本来就是如此。此外，当引出的需求已经汇编成一张表后，它们仍然有必要接受细致的协商及复审。

需求协商及复审过程与需求文档的书写过程不可分离。需求协商通常是以文档的草稿为基础的。如果有必要，要对文档草稿中列出的需求进行协商和修正，删除错误的需求，增加新发现的需求。

需求复审需要更加完整的需求文档版本，其中所有的需求都要被清楚地标识和分类。利益相关者阅读文档并且召开正式复审会议，复审常常被结构化为走查或审查，它们也是测试的一种形式。

2.确定需求范围非常重要

信息技术项目的选择和需实现的系统都是在系统规划和业务建模活动中确定的。然而，系统之间详细的相互依赖关系只有在需求分析阶段被发现。确定系统边界是需求分析的重要任务，使得这个过程中的“范围调整”问题可以早点解决。

为了确定任何特定需求是在系统范围之内还是之外，需要对照参考模型，才能做出判断。以前，这种参考模型通常是以关联图的形式提供数据流图（DFD）解决。虽然DFD在UML中已经被用例图所代替，但是关联图仍然是目前建立系统边界的很好的方法。

然而，可能还有其他原因将需求归到系统范围之外。例如，需求也许太难，不能在计算机化的系统中实现，应当由人工处理；或者需求的优先级不高，需将其从系统的第一个版本中删除；需求也可能在硬件或者其他外部设备中实现，但这些都超出了软件系统的控制范围。

3.用需求依赖矩阵排“虫”

假定所有的需求都已经清楚地标识和编号，那么就可以构建需求依赖矩阵（或交互矩阵）来排除需求中的矛盾和重叠。需求依赖矩阵需要按一种分类顺序分别在行和列的表头上列出需求标识符，如表3-1所示。

表3-1　需求依赖矩阵示意图

矩阵的右上部分（包括对角线和对角线以上，即阴影区域）没有使用。剩下的单元格表示任何两个需求是否重叠、矛盾或者冗余（是指空白单元格）。

若发现了矛盾的需求，需求分析人员应加强与客户的沟通讨论，可能的话重新陈述这个需求以避免矛盾（矛盾的记录应该保留，并对后续的开发可见）。重叠的需求也要重新陈述以消除重叠。

当需求数目比较少的时候，需求依赖矩阵是一种发现需求矛盾和重叠的简单有效的技术。如果情况不是如此，但需求被按类分组，在每一类中独立地比较，这项技术也许依然有用。

4.强化需求风险识别工作

一旦需求中的矛盾和重叠已经解决，就产生了一组修正后的需求，接下来需要对这些需求进行风险分析，并排列优先级。风险分析要确认那些很可能在开发阶段产生困难的需求，而排列优先级是为了在项目面临延迟的时候，方便地重新界定其范围。

项目的可行性实际上依据项目风险而定。项目风险是对项目计划实施的一种威胁，其威胁往往来自于财政预算、时间、资源分配等方面。通过识别风险，项目经理能够尽力控制它们。根据国外经验，典型的需求风险有以下几种。第一，技术风险，需求在技术上难以实现。第二，性能风险，需求实现后，会延长系统的响应时间。第三，安全风险，需求实现后，会破坏系统的安全性。第四，数据库完整性风险，需求不容易验证，并且可能导致数据不一致性。第五，开发过程风险，需求要求开发人员使用不熟悉的非常规开发方法，如形式化规格说明方法。第六，政治风险，由于内部的政治原因，证实很难实现需求。第七，法律风险，需求可能触犯现行法规或者假定了法律的变更。第八，易变性风险，需求很可能在开发过程中不断变化或进化。

比较理想的状况是需求优先级可在需求引导过程中从个体客户处获得，然后在会议中协商，并且当附加了风险因素时，再一次进行修改。