在上一篇文章中介绍了有关软件测试常用的技术，今天笔者继续来和大家分享。
需求的重要性，在软件测试过程中，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的80%；系统测试阶段引入测试手段，能发现剩余缺陷中80%的缺陷；在运行维护阶段经过长时间、大量运行软件后，能够发现最后剩余的20%缺陷
软件需求的定义，IEEE软件工程标准词汇表（1997年）中定义需求为：
（1）用户解决问题或达到目标所需的条件或权能（Capability）
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
软件需求的层次：用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
软件需求主要包括两个方面：需求开发和需求管理。需求开发可进一步分为四个阶段：
1.需求获取阶段
2.需求分析阶段
3.编写需求规格阶段
4.需求验证阶段
软件需求规格说明的特点：
1.完整性，不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD（“待确定”）作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项；
2。一致性，一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确；
3.可修改性，在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改
4.可跟踪性，应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。
这是今天笔者和大家分享的知识，在后续的文章中，笔者会继续带着大家来学习。
