6. 应用质量功能调配要

1）将产品特性、属性与对客户的重要性联系起来。

2）明确那些是客户为关注的特性。

3）将需求分为三类：

–期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意

–普通需求

–兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备

六、编写需求规则说明书

1. 采用软件需求规格说明模版

1）为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。

2）其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。

2. 指明需求的来源

1）为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源；

2）可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。

3. 为每项需求注上标号

1）可跟踪性和可修改性的质量标准，必须确定每个软件需求。

2）为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。

3）这种惯例应当很健全，允许增加、删除和修改。

4）作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。

5）需求标识方法有序列号;层次化编码;使用"待确定"（to be determined， TBD）符号等。

4. 记录业务规范

1）是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。

2）将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。

七、需求验证

1. 审查需求文档

1）在需求开发期间进行非正式评审。

2）对需求文档进行正式审查是保证软件质量的很有效的方法。

3）组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。

2. 依据需求编写测试用例

1）根据用户需求所要求的产品特性写出黑盒功能测试用例。

2）客户通过使用测试用例以确认是否达到了期望的要求。

3）从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。

4）要使用测试用例来验证需求模型的正确性，如对话框图和原型等。

3. 确定合格的标准

1）确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。

2）将合格的测试建立在使用情景描述或使用实例的基础之上。