软件管理需求

为什么习软件需求？

先来讲述一个真实的故事：

一天，小明和家人在吃晚饭的时候，对他的母亲、奶奶、姑姑说：他的裤子左腿（比右腿）长了3厘米，希望剪掉。

他的姑姑在晚饭后把小明的裤子左腿剪短3厘米；

他的母亲在睡前也把小明的裤子左腿剪短3厘米；

他奶奶在第二天早上把小明的裤子左腿剪短3厘米；

第二天，小明穿着这条裤子高高兴兴上学去......

这个故事的甲方小明提出了明确的需求，委托给乙方（家庭项目组），但由于沟通不力，在各组员积极的工作下，充分完成了任务。

有这个例子可以看到，乙方并没有跟踪项目的完成状态，完成的组员没有汇报，其他组员没有验证需求，导致多裁剪了6厘米。这个示例应用到软件中也是一样的。

那这个案例给我们什么样的启示呢？

• 软件需要基线化，要有管理，否则需求的实现是盲目的、不受控制的。
• 软件需求的实现要跟踪、记录和标识。
• 要测量、验证软件需求。

那么后续相关测试模型，比如V模型和W模型，都是以需求分析展开的，所以，有必要学习软件需求。

作为测试人员，有必要知道，在软件需求管理方面，我们应该充当什么角色，软件需求对我们的工作有什么样的影响。

除了满足客户的显式需求，作为软件开发者还要挖掘隐式需求。

总览整个项目生命周期，因为在需求阶段引发的缺陷，要比设计和编码阶段引发的缺陷还要多。

需求的定义

来看IEEE对需求的定义：

• 解决用户问题或达到用户目标所需要的条件或能力。
• 为遵循合同、标准、规格或其他要求的正式文档，系统必须满足或拥有的条件或能力。
• 按文档表现中的条件或能力，也就是需求文档（SRS）强调的做什么（What），而不是如何做（How）。

简单来讲，要从两方面来考虑需求：

• 用户角度，这也是系统的外部行为。
• 开发者角度，内部特性。

对于需求来说，它是有层次的：

• 业务需求，反映了组织机构或客户对系统、产品高层次的目标需求。在项目视图与范围文档中予以说明，比如在签订合同中的说明。
• 用户需求，描述了用户使用产品必须完成的任务，这在使用实例文档或方案脚本，在一些说明中进行说明，比如说用例交互图。
• 功能需求，定义了开发人员必须实现的软件的功能，目的是满足业务需求和用户需求。

交互的概念：一次交互就是指在特定语境中，为了实现某一个目标，而在一组对象之间进行交换的一组消息所表示的行为。

软件需求是需求工程对软件行业阐述的一个课题，其中主要包含开发和管理两个部分。

需求开发

需求开发的活动包括：

• 确定产品的期望的客户类，也就是对客户进行划分
• 获取每个用户类的需求。
• 了解实际用户任务和目标以及这些任务所支持的业务需求。
• 分析用户源信息，以区别用户任务需求、功能需求、业务规则、质量属性和其他的附加信息。
• 复杂的系统划分为子系统。
• 优先级。
• 质量属性的重要性。是功能重要啊，还是可靠性重要，都要考虑到。

需求获取

再来看需求获取，可以有下面几种形式：

• 访谈。
• 焦点小组会议，或针对需求的某个主题，拉着相关人员进行讨论一下。
• 联合应用开发，比如开发和客户一起工作，有啥问题，当面解决。
• 群众创新技术，比如开头脑风暴会议，大家都提供好的想法。
• 群体决策会议，比如提供一些好的方案，大家投票也好，共同决策出一个好的方案。
• 问卷调查。
• 观察法。
• 原型法等等。

需求分析

获取完了需求，要对需求进行分析，也有相应的需求分析人员来完成，那么对需求分析人员的要求有哪些呢？

• 符合客户的语言习惯，也就是说最起码不能跟客户有沟通障碍，比如你说中文，人家说日语。
• 了解客户系统业务及目标，这个客户他的业务是做保险的，还是做推销的，还是做保险推销的， 你要对相应的业务有所了解。
• 文档编写能力，编写有效的需求规格。
• 好的沟通能力。
• 积极的职业态度。
• 重用已有的软件和组件，也就是需要会点技术。

需求分析人员的角色非常重要，因为他决定软件是否能满足用户需求。那么需求分析都有哪些重要性呢？决策性、方向性、策略性，你要能对软件做全面的描述，帮助用户判断实现功能的确定性、一致性和完整性。因为有些客户他都不太清楚他的需求是什么，我们要引导......

另外，还需要了解软件实现所需要的全部信息，为软件设计、确认和验证提供基础。为所有的项目开发、测试工作编写相关文档提供依据。

那么，需求分析人员都是从哪些方面分析需求的呢？

• 功能需求。
• 软件与硬件或其他外部系统接口。
• 软件非功能需求。
• 罗列出软件设计和实现的限制。

需求分析人员，对外要完全了解用户需求，对内要为开发、测试提供清晰的思路。

需求定义

分析完了之后，要将需求进行定义，也即是将需求结果输出到文档，比如采用哪些工具、语言以及其他的特点。

最终是使开发组合用户的意见达成一致。

在对需求定义完了之后，要进行验证。

需求验证

需求的验证，指需求定义结束后，有客户、公司的决策层、专家来考虑项目的预算、进度等等角度，最终符合合同。

那么需求开发阶段完事，接下来就是要对需求进行管理了。

需求管理

需求管理，它是一种获取、组织并且记录系统需求的系统化方案，保证用户与项目团队对不断变更的需求达成并保持一致的认识。

需求管理强调：

• 控制对需求基线的变动。
• 保持项目计划与需求一致。
• 控制单个需求和需求文档的版本情况。
• 管理需求和联系链之间的联系。就是持续的跟踪需求。

需求工程和需求管理的关系

• 需求工程包含需求管理。
• 需求管理侧重于需求工程中的管理活动。
• 需求管理是CMM二级的第一个KPA。

那么，需求开发环节完毕后，就要进行需求分配，比如一个很大的系统，需要分配给不同的项目组来完成；然后项目组对需求进行评审（解决模糊或有歧义的地方），如果有些问题的话，就要遵循一定的基线进行需求变更，如果没有问题，也要遵循一定的基线进行开发测试； 如果需求进行了变更，那么就要对此进行跟踪；那么要对需求进行变更也要遵循一定的流程，来看软件需求变更的流程。

软件需求变更流程

变更控制：

• 首先要提出变更，也就是建议变更。
• 既然要变更，就可能带来一定的影响，我们就要分析影响。
• 根据影响作出决策。
• 影响太大，不能变更，或者可以变更，都要跟相关人员（设计）进行交流。
• 在一番交流后，合并决策结果。
• 最后，要测量（变更后的）需求的稳定。

CMM2级的KPA中的需求管理部分的目标是，把软件需求建立一个基线，供软件工程和管理使用，然后软件计划产品和活动同软件需求保持一致，但它并不涉及需求的收集和分析。

当需求管理遵循基线作出变更后，然后确定变更后的版本，在版本控制中，要确定需求文档的版本，到底是哪些文档要发生变化，完了之后，确定需求文档的版本；

开发和测试工作的展开是基于确定的需求文档展开的。

一旦开发或测试中的某个环节发生变更，那么所有相关的变更都要随之改变，并保持一致，比如一些开发或测试计划与需求保持一致。

来看有哪些反应变更的方法：

• 暂时搁置次要的需求。
• 得到一定数量的后备人员，用来弥补可能由于变更而缺少人手的问题。
• 将新的需求安排到工作进度中去。

关于需求的所有变更都要进行跟踪。

软件需求跟踪

可以看到上图中每个环境的箭头都是双向的，也就是自上而下可以持续跟踪，自下而上可以追根溯源，避免遗漏。

而软件需求规格无疑起着承上启下的作用的，当需求规格说明书明确之后，后续的人员就可以继续展开工作，比如设计人员就可 以进行概要设计，详细设计，编码实现，进行单元测试、集成测试、系统测试，编写用户手册等文档。它（需求规格说明书）是上述步骤的有力依据。

那软件需求跟踪有哪些流程呢？

跟踪软件需求的流程是将跟踪目标分解到各个活动中，也就是说流程是由活动组成的。那这个流程中具体都有哪些活动，而对应这些活动的角色又有哪些呢？

来看一下需求跟踪涉及到的活动以及它们需要跟踪的配置项。

在需求跟踪中，我们除了要知道它的活动，我们处于什么位置，我们的工作内容是什么，我们最终要满足什么，还需要知道用什么方法，约束我们，让我们的跟踪过程更加清晰，这就用到了需求跟踪矩阵（RTM，Requirement tracking matrix）。

当需求准备完毕并已经明确到位，那我们的跟踪工作就开始了，首先我们要初始化需求跟踪矩阵，然后把我们的工作任务书（SOW）和原始需求（AR）列出来。

完事就开始后续的工作，分析需求规格说明书，列出需求项、概要设计项、详细设计项、编码项，以及系统测试项、系统测试子项；集成测试项、集成测试子项；单元测试项、单元测试子项；把最原始的需求标识在需求跟踪矩阵中。

需求跟踪矩阵它确保了：

• 确保需求被实现。
• 确保需求被验证。
• 了解需求变更影响的范围。

软件需求跟踪阶段划分

对于软件需求跟踪，总体划分为开发、测试两条主线。并且两条主线都有具体的阶段划分，在每个阶段划分中，都有相应的输出：

上图中，每个活动中， 都有相应的跟踪活动。

由PM负责需求跟踪， 需求跟踪的目的是确保所有的分配需求均被实现（开发线）、被验证（测试线），后续的工作产品与分配需求一致。

需求跟踪过程的主要活动是对RTM的维护，通过建立如下跟踪关系，达到需求跟踪的目的：

• （开发线）分配给项目的需求 -- 项目的软件需求规格 -- 概要设计 -- 详细设计 -- 代码
• （测试线）项目的软件需求规格 -- 系统测试项 -- 系统测试子项 -- 系统测试用例
• （测试线）概要设计 -- 集成测试项 -- 集成测试子项 -- 集成测试用例
• （测试线）详细设计 -- 单元测试项 -- 单元测试子项 -- 单元测试用例

软件需求跟踪方法

对于软件需求跟踪方法来说，无非就是让我们的跟踪项能够被唯一标识，也就是怎样命名跟踪项，以及被跟踪对象是什么。

来看需求项的定义：根据工作任务书（用户需求）的规格，把任务书中的任务分解为可以实现的符合要求的具体的需求项，需求项最终落实到需求文档中（SRS）。

需求项的命名方式：

• 产品编号-SRS-需求类型-特性名-XXX
• 如：CALC-SRS-FUNC-ADD-002，表示计算器十进制加法功能需求。

概要设计项的定义：针对需求规格说明书中的需求项做分解，一个需求项可以被分级为一个或者多个模块，每个模块之间有明确的接口，模块的功能独立，符合高内聚、低耦合的原则，标识每一个模块的项目即概要设计项，概要设计项最终落实到概要设计说明书中。

概要设计项的命名方式：

• 产品编号-HLD子系统名称-模块名-XXX
• 如：CALC-HLD-ADD-DEC，表示计算器十进制加法功能模块。

详细设计项的定义：为了实现概要设计说明书中的模块，在详细设计中，把概要设计模块细化到函数或者函数组的层面，函数或者函数组即详细设计项，详细设计项目最终落实到软件详细设计说明书中。

详细设计项的命名方式：

• 产品编号-LLD-模块名称-XXX
• 如：CALC-LLD-ADD-DEC-001，表示计算器十进制加法功能模块参数判断函数的详细设计项。

系统测试用例的定义：测试人员根据需求规格说明书中的需求描述，完成的系统测试项、系统测试子项、系统测试用例，称为系统测试用例项。

一个项目软件需求项可以对应一个、多个甚至数十个系统测试用例项目。

一个系统测试用例项也可以对应一个、多个软件需求项。

命名方式：

• 产品编号 - ST - 系统测试项目 - 系统测试子项名 - XXX

集成测试用例的定义：测试（开发）人员根据概要设计文档中的概要设计项完成集成测试用例，称之为集成测试用例项。

集成测试用你的设计主要关注软件模块间的接口，比如文件接口、共享内存接口、socket接口、管道接口、数据库接口、二进制API接口等。

命名方式：

• 产品编号 - IT - 集成测试项目名 - 集成测试子项目名称 - XXX

单元测试用例的定义：测试（开发）人员根据详细设计文档中的详细设计项，完成的单元测试用例，称之为单元测试用例项，每个详细设计项应该对应一个或一个以上的单元测试用例项目。

命名方式：

• 产品编号 - UT - 单元测试项目名称 - 单元测试子项目名称 - XXX

需求阶段需求跟踪

需求阶段需求跟踪——开发人员

需求跟踪责任人：PM（开发）。

需求跟踪的步骤：在SRS review之前，由PM组织项目组成员创建需求跟踪表，完成需求项录入。

需求跟踪方法：在原始需求项和需求分析文档（SRS）项之间建立对应关系。

需求阶段需求跟踪——测试人员

需求跟踪责任人：PM（测试）。

需求跟踪的步骤：在软件测试计划（STP） review之前，由PM组织项目组成员完成系统测试项录入。

需求跟踪方法：在需求分析文档（SRS）和系统测试项之间建立对应关系。

概要设计阶段需求跟踪——开发人员

需求跟踪责任人：PM（开发）。

需求跟踪的步骤：在HLD review之前，由PM组织完成概要设计项录入。

需求跟踪方法：在概要设计项和需求分析文档（SRS）项之间建立对应关系。

概要设计阶段需求跟踪——测试人员

需求跟踪责任人：PM（测试）。

需求跟踪的步骤：

• 在系统测试方案、系统测试用例 review之前，由PM组织完成概要设计项录入。
• 在集成测试计划（ITP）review之前，由PM组织完成集成测试项录入。

需求跟踪方法：

• 在系统测试项和系统测试子项、系统测试子项和系统测试用例之间建立对应关系。
• 在概要设计项和集成测试项之间建立对应关系。

详细设计阶段需求跟踪——开发人员

需求跟踪责任人：PM（开发）。

需求跟踪的步骤：在LLD review之前，由PM组织完成概要设计项录入。

需求跟踪方法：在详细设计项和概要设计项之间建立对应关系。

详细设计阶段需求跟踪——测试人员

需求跟踪责任人：PM（测试）。

需求跟踪的步骤：

• 在集成测试方案、集成测试用例 review之前，由PM组织完成集成测试子项、集成测试用例项录入。
• 在单元测试计划（UTP）review之前，由PM组织完成单元测试项录入。

需求跟踪方法：

• 在集成测试项和集成测试子项、集成测试子项和集成测试用例之间建立对应关系。
• 在详细设计项和单元测试项之间建立对应关系。

编码阶段需求跟踪——开发人员

需求跟踪责任人：PM（开发）。

需求跟踪的步骤：在代码 review之前，由PM组织完成代码函数项录入。

需求跟踪方法：在代码函数项和详细设计项之间建立对应关系。

编码阶段需求跟踪——测试人员

需求跟踪责任人：PM（测试）。

需求跟踪的步骤：

• 在单元测试方案、单元测试用例 review之前，由PM组织完成单元测试子项、单元测试用例项录入。

需求跟踪方法：

• 在单元测试项和单元测试子项、单元测试子项和单元测试用例之间建立对应关系。

需求变更

CR也就是变更请求，可以来自不同的来源，比如用户、潜在用户、需求分析人员、测试人员、开发人员、第三方、供应商等等。

CCB是变更控制委员会（高层经理、项目经理、配置管理负责人、测试负责人、QA），来控制变更流程。

完了不是提交变更就能变更的，还要经过一系列的评审、完事之后修改相应的文档等，始终要保持各个节点的状态保持一致。

再来看因为需求变更都会影响哪些地方会受到影响。

需求变更引起的需求跟踪

• 需求分析阶段：
  • 需求分析 - 系统测试计划
• 概要设计阶段：
  • 需求分析 - 概要设计
  • 需求分析 - 系统测试计划 - 系统测试方案 - 系统测试用例
  • 概要设计 - 集成测试计划
• 详细设计阶段：
  • 需求分析 - 概要设计 - 详细设计
  • 需求分析 - 系统测试计划 - 系统测试方案 - 系统测试用例
  • 概要设计 - 集成测试计划 - 集成测试方案 - 集成测试用例
  • 详细设计 - 单元测试计划
• 编码及后期测试执行阶段：
  • 需求分析 - 概要设计 - 详细设计 - 代码
  • 需求分析 - 系统测试计划 - 系统测试方案 - 系统测试用例
  • 概要设计 - 集成测试计划 - 集成测试方案 - 集成测试用例
  • 详细设计 - 单元测试计划 - 单元测试方案 - 单元测试用例

需求跟踪工具

那么都有哪些需求跟踪的工具供我们使用呢？

• TestDirector
• DOORS
• QC

需求评审

那么了解完了，在软件需求中的需求开发，和需求管理的大部分内容。那再来研究在对于需求的评审。

在整个项目流程中，我们测试人员重点打交道的就是需求跟踪和评审。

那首先回顾一下什么是需求管理？就是让开发人员和客户对于变化的需求达成共识，这些共识包括：

• 业务需求。
• 功能需求。
• 非功能需求。
• 质量属性。
• 外部接口需求。

评审这部分需要注意的是软件需求规格说明书的写作要点，需求规格说明书的评审都有哪些流程，以及评审都有哪些要点等。

再来回顾一下软件需求规格说明书（SRS）的定义：是对在特定环境下要完成一定功能的软件产品，程序或一组程序的说明。

应该从以下几个方面去描述：

• 功能：软件要做什么。
• 外部接口：如何与人、系统硬件、外部的硬件和软件交互。
• 性能：速度、响应时间、恢复时间等。
• 属性：可移植性、可靠性、可维护性、可用性等。
• 实现的设计约束：标准、实现语言、资源限制、操作环境等。

软件需求规格说明书的目的

• 在客户和开发之间达成共识。
• 为编制计划和成本计价提供基础。
• 为设计提供了基础。
• 为确认和验证提供基础。
• 提高开发效率。
• 便于移植。

除此之外，客户和营销部门以需求规格说明书来了解产品，项目经理根据包含在软件需求规格说明书描述的产品来指定计划并预测进度安排、工作量、人力资源等。

对于软件开发小组来说，可以以此来更好的理解开发的到底是一个什么样的产品。

对于测试人员来说，根据软件需求规格说明书对产品的描述指定测试计划、测试用例和明确测试过程。

对于维护和支持人员来说，可以以此来了解产品的各个功能。

产品发布组在需求规格说明书和用户界面设计的基础上编写客户文档，如用户手册和帮助文档。

对于培训人员，可依次为编写用户培训资料。

那么什么样的软件需求规格说明书算是合格的呢？优秀的需求规格说明书有7+4特征。

7特性指的是对于每条需求来说：完整性、正确性、一致性、可跟踪性、划分优先级、无二义性、可验证性。其中，划分优先级单拎出来来讲，所以就剩下了6大特性。

• 软件需求完整：不能遗漏任何必要的需求信息。
• 软件需求的正确性：指每一项需求都必须准确的陈述要开发的功能。
• 软件需求一致性：需求规格说明书中所罗列的需求和其他软件的需求或高层次的需求不相矛盾，比如在文档的不同位置对同一个需求的描述不一致。
• 软件需求无歧义：对所有的需求说明，针对不同的读者都只能有一个明确统一的解释。尽量用客观量化的数据表明需求，避开描述性的语言，比如色彩艳丽、高度适中，这些不同的人会有不同的理解。
• 软件需求可验证性：检查每项需求是否能通过设计测试用例或其他的验证方法。
• 软件需求可跟踪性：应该能在每项软件需求与它的根源和设计元素、源码、测试用例之间建立连接链。

4特性是针对整篇需求规格说明书来说：完整性、一致性、可修改性、可跟踪性。

需求分类

有的时候，用户提出的需求可能是模糊笼统的， 那么我们就需要多用户的需求加以分析，分类别，为后续的工作提供更清晰的支撑。说道需求分类，我们从管理角度来看有，：

• 原始需求，也称为业务需求，描述客户或者开发公司可以从产品中得到的资金、市场或者其他业务利润的需求。
• 产品需求，也称使用需求，有关利用系统执行业务任务或者达到用户目标的总体陈述。
• 软件需求，开发需求，项目开发人员要开发完成的系统应该提供一些全能和条件。
• 测试需求，分析要测试的需求，可控、 容易观察、通过测试用例能够实现。

从功能角度来说，可以分为：

• 功能需求，系统应该能满足用户的需求。
• 非功能需求，对于功能需求的补充，隐性的需求。是否使用简答，方便快捷等等。

从技术角度来说：

• 技术需求：功能、性能、健壮性、接口。
• 非技术性要求：项目进度要求、质量、成本等方面的要求。

需求的属性

每一个需求类型都有多个属性：

• 划分优先级
• 工作量
• 风险
• 可用于界定项目的范围、估计工作量、计划和平衡资源等。

需求的表达

如何将需求表达出来呢？

• 通过输入、输出来说明，也就是文档。
• 使用规范化的模型方法（UML）。
• 使用电子表格。
• 使用代表性的例子。

需求表达应该避免的问题

需求描述过多涉及到具体的设计和实现。

• 超出规格，对需求描述大大超出用户的需求。
• 过度限制，对需求进行了不必要的限制。
• 不确定性：
  • 以相对的方式描述需求。
  • 没有结束的需求。
  • 主管或含糊的描述需求。
• 需求描述基于未经过确认的假设。

需求规格说明书的写作要点

那么在需求规格说明书中，大致有以下几方面的内容。

• 项目介绍：
  • 描述本软件需求所描述的项目背景。
• 产品环境介绍：
  • 描述的是当前软件与其它产品或者项目所组成的整体环境。
  • 如果该软件时独立的并完全自我包含，要在此说明一下。
  • 如果SRS定义的产品使更大的系统或项目的组件，那么应该：
    • 描述上级系统或项目每个组件的功能，并且标识接口。
    • 确定本软件产品主要外部接口。
    • 描述相关产品硬件和所使用的外部设备。
    • 通过方块图来描述上级系统或者项目的主要组件、互连性以及外部接口是非常有效的。
• 软件功能（概述）：
  • 概述软件必须实现的和通过用户操作实现的主要功能，这里只需要进行简要描述（比如目录列表描述），详细描述在详细需求部分描述，对需求功能进行组织，以便于读者理解，并能指导后续的设计和测试。可以用图表来表示主要需求群组之间的关系，如高层的数据流图，面向对象分析等。
  • 有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层规格（如果有的话）直接引用。
  • 本节不应该描述具体的需求，但本节内容是具体需求章节的基础。
• 用户特征：
  • 列出对用户或系统操作者的要求，如经验、能力、角色等。
  • 列出用户属性，如教育程度、国籍、年龄、性别等。
• 假设和依赖关系：
  • 列出可能影响SRS中需求的所有的假设因素，包括准备使用的第三方或者商业组件，操作和开发环境的问题约束等。如果上述假设不正确、没有被告或者改变了都将对项目产生影响。
  • 列出项目对外部条件的依赖，例如重用其他项目的模块，如果在其他文档（项目计划、范围文档等）里已经描述了，在这里可以不用描述。
• 功能需求：
  • 本子章节应该描述软件产品的输入怎么样被转换成输出，它描述了软件必须执行的基本动作。
  • 对每一类功能或有时对每一个单独的功能，必须描述输入、处理、输出方面的需求，对于每一个功能需求，可以有以下描述：
    • 简要介绍，你要对功能做下简要的介绍，包括项目如何响应预期的错误输入，非法条件和无效输入，需求应该简明、完整、可验证。必要是当需求要求的信息不确定的时候，使用待定。
    • 输入，有什么输入。对该功能的输入数据做详细的描述，包括输入来源、数量、度量单位、时间要求等，包含精度和容忍度的有效输入范围。在适当的位置提供对接口规格或者接口控制文档的参考。
    • 处理，你做了什么处理。描述对输入数据所执行的所有操作如何获得输出的过程，这包括输入数据的有效性检测、操作的确切次序，事件的时序等；对异常情况的回应，如溢出、通信失败、错误处理等。
    • 输出，输出的结果要描述。对该功能所有输出数据的详细描述，包括输出到何处？打印机或者文件等；数量；度量单位；时序；包含精确度和容忍度的有效输出范围；对非法值的处理；错误消息；在适当的位置提供对接口规格或者接口控制文档的参考。
    • 为了对需求做更好的跟踪，我们要对需求编号多多考虑，避开功能需求（1）和功能需求（2）之类的。
• 性能需求（非功能需求）：
  • 在本段落描述读软件的静态和动态的量化需求。
  • 静态量化包括：支持的终端书目；支持的同时使用的用户数；处理文件和记录的数目；表和文件的限制；
  • 动态量化需求包括：在正常或者峰值工作量情况下特定时间内处理事务或者任务数目及数据量和对系统资源的消耗。
• 用户接口：
  • 对每种人机界面，软件所必须支持的特性，如系统用户通过一个显式终端进行操作，那么应该包括：要求的屏幕格式；页面规划及报告或者菜单的内容；输入和输出的相关时序；一些组合功能键的用法等等。
  • 与系统用户接口使用相关的所有方面，这可能只是一个简单的关于系统怎么样展示给用户，该做什么和不该做什么的列表。
• 软件接口：
  • 应该描述如何使用其它软件产品（如数据库、操作系统），以及与其它应用系统的接口。
  • 对每个必需的软件产品，应提供：名字；助记符；版本号；接口。
  • 如果接口已在其它文档中描述清楚，这里无需重复描述，但需要说明应该参考的文档。
• 硬件接口：
  • 在此描述软件产品和系统硬件组件之间接口的逻辑特性，包括支持哪些设备，怎样支持这些设备和协议等。
  • 按软/硬件协议内容和格式定义接口，如果接口已在其它文档中很清楚的描述，这里无需重复描述，但需要说明应该参考的文档。
• 标准符合度：
  • 说明需求所采用的标准或者规范的来源，如果项目采用了国际标准，应该说明国际标准及项目与标准的偏离情况。
• 硬件约束：
  • 包括软件在不同的硬件平台运行的需求，如时间相关的约束，内存方面的约束等。
• 技术限制和本地化：
  • 技术限制：包括对使用特定的技术限制，接口、数据库、并行操作、通讯协议、设计约定、编程规范等。
  • 本地化，描述支持多语言的需求。
• 需求分级：
  • 必须的，绝对基本的特性，如果不包含，产品就会被取消。
  • 重要的，不是基本的特性，但这些特性会影响产品的生存能力。
  • 最好有的，期望的特性，但省略一个或多个这样的特性不会影响产品的生存能力。

需求阶段的角色和职责

软件开发项目经理：

• 带领项目组分析审核工作任务书。
• 带领项目组与系统工程师进行需求交流并分析和文档化。
• 组织SRS文档评审。
• 组织需求跟踪。

软件开发工程师：

• 完成SRS文档。
• 完整需求跟踪。
• 参加SRS review。
• 根据SRS评审专家意见，修改SRS文档。
• 参加系统测试计划的评审。

软件（产品）经理：在SRS评审结束后，批准SRS文档。

QA：

• 监督项目组遵循需求管理流程。
• 参加相关文档的review。
• 保证相关组参加文档review。

CCB（变更控制委员会）的负责人：控制需求的变更。

软件测试项目经理：

• 参与开发人员的软件需求分析，提出可测试性需求。
• 组织人员参与SRS的评审工作。
• 软件系统测试计划写作。
• 组织系统测试计划的评审。
• 组织本阶段测试需求跟踪。

软件测试工程师：

• 参与SRS评审工作。
• 协助软件测试项目经历完成软件系统测试计划写作。
• 参加系统测试计划评审。
• 完成本阶段测试需求跟踪。

评审流程

参与软件产品的审查的参与者代表三方面的观点：

• 产品的开发组。
• 先前产品的开发者或者正在评审的项目规格说明编写者。
• 要根据正在审查的文档来展开工作的成员。

软件评审的过程首要要有一个触发能够评审的必要条件，也就是什么时候开始评审。

被评审对象是需求，也就是主角软件需求规格说明书，或这还要搭配原始的需求说明书，项目计划书等材料。

每次评审都要有一个评审重点，如果软件功能较多，那么一次评审不完，我们整理成一个Checklist，每次评审其中一个重点。

相关的材料准备完毕，接下来就要选择，由哪些人（专家）来参加评审，一般我们建议这些人参见评审：

• 接受过关于review的目标、原则和方法培训的人员。
• 主要的候选review人员：来自review人员资源池中涉及该工作产品所处生命周期上一阶段、当前阶段和后一阶段的review人员。
• 受影响组的成员，如测试工程师。
• 与review工作产品有关的同行。

除了上面那些专家之外，还需要有软件需求评审组织者：

• 接受过关于review的目标、原则和方法培训的人员。
• 接受过如何领导review团队培训的人员。
• 有组织能力。

这些组织者负责组织评审会议，选择合适的专家，还要有相应的权利、技术。

在评审的时候，除了组织者和评审专家，可能还需要作者、记录员、讲解者参与。

并且，在评审过程中，还需要遵守一定的原则：

• 任何一次review最少需要3人，一个作者两个review人员。
• 任何一次review最多需要7人参与（人太多，七嘴八舌的.......），一个作者和6个review人员。
• 需求规格说明书的review规模不过超40页。
• 作者在提交检视对象前，首先进行自检。
• 组织者可以根据review工作产品的checklist来定制本次review的checklist重点事项，保证review质量。
• 组织者应当根据被review对象的规模及复杂程度为检视这留出足够的准备时间，对review规模不超过40页的工程文档，建议准备时间是2~3天。
• review会议时间一般为2小时，但组织者可以根据被review对象的类型及规模来调整。
• 在review会议上组织者根据返工带来的影响程度（如修改量的大小，是否影响到关键的功能和算法）等来决定是否需要再此review，同时还可以参考本次review的效果（如是否达到质量目标）来决定是否需要再次review。

经过一番评审专家的评审，也会有相应的评审结果产生，如根据评审专家意见修改后的软件需求规格说明书，也可以有这样一个软件需求规格说明书评审表格。

评审人员	问题描述	位置（页/段/所有）	缺陷/疑问	缺陷严重程度	问题确认	作者修改说明	是否已改正

那么在评审中要注意哪些事项呢？

• 是否所有的 分配需求都在SRS中体现？
• 在SRS中定义需求时，是否避免使用那些会引起歧义的术语，诸如也许、可能等，每条需求都清晰无歧义？
• 是否在SRS中清晰的描述了软件要做什么及不做什么？
• 是否在SRS中描述了 软件使用的目标环境，指明并简短描述了目标环境中其它相关软件产品/子系统/模块？
• 是否每一个具体需求都有唯一编号？
• 每一个需求是否切实可行、可测试、前后一致、彼此不冲突？
• 是否在SRS中说明了对每个输入的验证措施，并描述了每个输入的属性如：度量单位、边界值、时序要求等等？
• 是否在SRS中说明了每个输入的处理？
• 是否在SRS中说明了每个输出项是如何输出的，并且描述了每个输出的属性，如度量单位，边界值等等？
• 是否在SRS中描述了软件所有的性能需求？
• 是否性能需求的描述能通过测试来进行验证？
• 是否在SRS中说明了所有对系统可能的约束？
• 质量属性是否可以测量或可验证的术语进行描述？
• 是否在SRS中描述了系统中与其它子系统、模块或硬件设备的相关接口？
• 是否对每个接口的描述足够清晰，实现时不需要更多解释？
• 是否在SRS中描述了与操作系统的接口？
• 是否在SRS的附录中记录了分配需求可行性的分析结果？
• 是否项目工作任务书（SOW）所对应的分配需求都在RTM（发布生产阶段）中体现？

同行评审

在需求评审中，主要采用同行评审的方法。想想目前火爆的选秀节目，都是采用同行评审的方法。

同行评审（Peer Review）是一种通过作者的同行来确认缺陷和需要变更区域的检查方法，需要进行同行评审的特定产品在定义软件过程的时候被确定并且作为软件开发计划的一部分被安培了进度。需要前期准备、计划和时间进度表，越早进行同行评审效果越好。

同行评审的作用：早期发现缺陷、去除缺陷、降低成本、提高质量。

同行评审的类型：

• 正规检视：软件正规检视是在软件开发过程中进行的，发现、排除软件在开发周期各阶段存在的错误、不足的过程，是一种软件静态测试方法，其生存周期为软件的开发周期，应用于开发过程中产生的（非阶段性）软件文档和程序代码。正规检视的主要目的是发现缺陷。它的评审对象比较广泛，有严格的评审流程，但要考虑时间成本等问题。
• 技术评审：是由一个正式的组对产品进行评价，它确认任何与规格和标准不一致的地方或者在检查后给出可替换的建议，或者包含这两者，技术评审的严格程度没有像正规检视那么严格，技术评审的参与者包括作者，以及产品技术领域内的专家。
• 走读，走读的目的是要评价一个产品，通常是软件代码，走读一直以来都与代码检查联系在一起，其实走读也可以应用到别的产品，比如结构设计、详细设计、测试计划等。走读最主要的目标是发现缺陷、遗漏和矛盾的地方、改进产品和考虑可替换的实现方法。走读还有其它的目的，比如技术交换、参与人员技术培训，设计思想的介绍等。

同行评审流程中，主要有七个活动，其中有两个活动根据实际情况进行选择，那就是介绍会议和第三小时会，根据情况是否开启介绍会议和第三小时会议。

通用评审流程计划阶段：

• 项目负责人指定组织者。
• 作者自检工作产品。
• 组织者规划本次评审。
• 检查入口准则。
• 准备评审包（工作产品/参考资料评审表单/检查表）。
• 指定评审专家（3~6人）。
• 组织者将评审包、评审通知单发给相关人员。

通用评审流程介绍会议：

• 评审专家向组织者提出申请，组织者裁决是否召开介绍会议（比如说评审专家不熟悉这块领域，要开个介绍会议介绍一下相关情况），介绍评审流程及相关要求。

介绍完了相关情况之后，并不能直接召开评审会议，评审会议是澄清问题、解释问题、确定问题的，而不是评审产品的，所以，此时到了一个评审会议的准备阶段。

通用评审流程评审准备阶段：

• 收到组织者发来的评审包，审核工作产品、发现缺陷填写评审表单，反馈评审表单给组织者。记住，评审的对象是产品而不是作者。
• 而组织者要检查评审表单，裁决是否需要增加评审投入。

准备好了之后，我们就可以开始正式的评审会议了：

• 讲解员讲解工作产品，大家共同确认评审表单中记录的问题、会上发现的问题；当争执不下时，组织者要作出相应的裁决，对已确认的问题进行分类，作者决定是否召开第三小时会议；记录员记录所有的问题及分类，并发给组织者更新评审表单。

由于就某个问题争执不下，作者决定召开第三小时会议，大家对评审表单中为解决的问题给出决议，对评审表单中以确认的问题讨论解决方案，记录员进行记录，然后交给组织者，组织者更新评审表单。

完事之后，作者得到了返回意见，回家改呗，这就是评审的返工阶段。

组织者汇总所有需要的数据到评审表单发送给相关评审专家。组织评审专家确认各缺陷得到了修改，并且没有引入新的缺陷。

同行评审常见问题：

• 没有评审计划。
• 专家选择不合适。
• 没有充分准备。
• 没有使用checklist作为指导，也就是没有评审重点。
• 问题修改后跟踪不力。
• 评审会议中过多争论占用了大量的时间。
• 评审会议偏离主体和重点。