需求说明的特征

　　1. 完整性

　　每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

　　2. 正确性

　　每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

　　3. 可行性

　　每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，好在获取（elicitation）需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

　　4. 必要性

　　每一项需求都应把客户真正所需要的和终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

　　5. 划分优先级

　　给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中丧失控制自由度。第13章将更详细地讨论如何划分优先级。

　　6. 无二义性

　　对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

　　7. 可验证性

　　检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。

　　1.5.2 需求规格说明的特点

　　1. 完整性

　　不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD（“待确定” ）作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的T B D项。

　　2. 一致性

　　一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。

　　3. 可修改性

　　在必要时或为维护每一需求变更历史记录时，应该修订SRS。这要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。

　　4. 可跟踪性

　　应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。第18章将详细说明需求的可跟踪性。

　　1.6 需求的开发和管理

　　需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作者把整个需求范围称之为“需求工程”，另一些则称之为“需求管理”。我认为可把整个软件需求工程研究领域划分为需求开发（本书的第二部分）和需求管理（本书第三部分）两部分更合适，如图1-2所示：

图1-2 需求工程域的层次分解示意图