天若有情天亦老,人学物理数学金融生物死得早

现在让我们把目光聚焦到软件需求设计评审上来, 我们已经知道如何去获取需求,也知道了撰写需求规格说明书。现在的问题是,我们所撰写的需求规格说明书是否能让用户接受呢? 而用户又如何对需求说明书作出理性和客观的评审和确认呢? 事实上，当我们撰写需求规格说明书的时候不妨站在用户的角度去评写，唯其如此方能事先避免一些问题。本文探讨用户应该如何去“评审”软件需求说明书，并因此提出了需求评审的”八项注意”，以飨同仁。

需求确认是需求开发过程的第四个阶段,前三个阶段按顺序分别为需求获取、需求分析、编写需求规格说明。需求确认活动要力图确保如下几点:

1 需求规格说明正确描述了预期的、满足各方涉众需求的系统能力和特征。

2 所述之软件需求是由系统需求、业务规格和其他来源中正确推导而来的。

3 需求是完整和高质量的。

4 需求的表示在所有地方都是一致的。

5 需求为产品设计和构造提供了基础。

需求确认活动可以确保需求符合优秀需求陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证, 同时亦符合好的需求规格说明的特征，即完整性、一致性、易修改和可跟踪性。

一般而言，我们通过需求评审活动去实现需求确认的目标, 参与评审者应包括各级客户、开发人员和测试人员, 在整个审查过程中，我们会有诸多“注意”。事实上,在实践活动中,每个企业会根据自身的情况存在更多的检查事项, 在此列出的八项亦属于最基本的要素。

一、 注意对需求规格说明的正确性进行评审

需求规格说明的正确性通常可以从如下方面得以体现：

1 是否有需求与其他需求相互冲突或者重复？

通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念, 可使术语列表贯穿整份文档以达提纲挈领之效。

谈及此点,让我想起在“商机管理系统”需求评审会上，火眼金睛的用户们发现了我的需求说明书中关于系统用户角色定义部分出现了前后不一致的情况。在该报告前文中我定义了该系统有二种角色，即“商机成员”、“商机管理成员”,但在功能需求中我的报告中居然新生出一种“商机监理”角色，导致出现尴尬局面。 事后总结其主要原因是在撰写报告的前期和后期阶段,需求分析的思路有了明显的异动，但却没有把文档前后更新一致，这个教训