在上一篇文章中介绍了有关软件测试常用的技术，今天笔者继续来和大家分享。
需求的重要性，在软件测试过程中，从需求分析开始到集成测试阶段引入测试手段，能发现所有缺陷的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 ）的方式编写并单独标明，而不是大段大段的叙述。
这是今天笔者和大家分享的知识，在后续的文章中，笔者会继续带着大家来学习。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69914734/viewspace-2655868/ ，如需转载，请注明出处，否则将追究法律责任。
