需求评审

本节相关概念：

客户与用户：客户是消费的，用户可能是客户的职员，或亲戚（随便理解了）

原始需求：

针对项目类软件：指的是需求分析人员通过与最终用户或客户进行需求调研获得最初的文档。

针对产品类软件：指的是通过市场调研人员分析潜在用户的使用需求经过整理分析后形成的最初产品需求。

需求规格说明书（SRS）---software requirement specification：原始需求经过分析得到说明书经过基线化获得的产物。

                目的：A在客户和开发者之间达成一致

                      B为编制计划和成本计价提供基础

                      C为确认和验证提供一个基础（验收测试）

      D便于移值
                    写作要点：（每个项目其实对应着相关测试类型）

1项目介绍

                       2产品环境介绍

                       3软件功能

                       4用户特征

                       5假设和依赖关系

                       6功能需求

         7功能需求—简单介绍

         8功能需求—输入

                       9功能需求—处理

                       10功能需求—输出

                       11性能需求

                       12用户接口

                       13软件接口

                       14硬件接口

                       15标准符合度

                       16硬件约束

                       17技术限制和本地化

                       18需求分级

关注点：

需求只强调做什么，而不是如何做。概要说细设计中关注如何做。

必要性：

在国内许多开发人员和分析人员都不喜欢编写需求规格说明书，而用户也是既不关心需求规格说明书是否已经完成，也不关心需求规格书是否恰当地表述了用户的需求。大家所关心的仅仅是系统何时能够做出来，而这最终导致的一个结果是系统不断被除数修改，各种Bug不断出现，好像没有个尽头。其实任何文档形式的需求都是一个模型或一种描述，我们要保证所有的风险承担者在描述需求的那句词上能够达成一致的意见，这可以减少后期不断修改甚至一切到头来的麻烦，从而缩短了研发的进度同时保证质量，节省了不少的成本。

需求的分类：

显示需求：需求分析人员在用户或客户那里获得最早的软件信息。简单的说就是用户眼里未来软件的影子。

          主要组成部分：软件功能方面的特性（根据客户软件知识而定，不要以貌取人）

隐式需求：需求分析人员从用户的显示需求中分析或客户确认得到用户发现不了软件产品条件和能力。

          主要组成部分：软件的可靠性、易用性、效率、维护性、可移值性方面的性能（详细参考软件质量模型）

如研究人员不去关注隐式需求，客户也不会认帐的。你说我都是按你要求做的，客户你做出这样的东西怎么能用啊。最终也是通不过验收测试的。

需求工程：

                        需求工程

需求开发：                                        需求管理：

  需求获取                                          需求分配

 需求分析                                          需求评审

 需求定义                                          需求基线

 需求验证                                          需求跟踪

需求变更

需求获取：

方法：A调查问卷 B专家指导C企业实地实践D与用户/客户沟通（不一定单选）

注意事项：需求人员要补充相关方面的知识水平站在比客户还高的行业角度上去考虑问题，并给用户提解决方案。不能向软件方面知识不强的客户问专业方面的问题，要是部他问解决方案，一定要有备选答案，不然，他哪知道，这样用户开始会怀疑研发方的水平地。

成果物：原始需求（需求说明书）

需求分析：

目的：将需求规格化

规格化的过程：1明确每个需求输入参数

2明确每个需求处理处理

3明确每个需求的输出

4明确相关接口

5其它隐式需求

6相关的约束条件

成果物：需求规格说明书SRS

需求定义：

主要是指经过需求分析规格化过程后，将它形成一个正式的需求说明书SRS。

需求验证：（开发方与客户）

目的：和客户共同明确统一的需求，为后续的需求管理奠定基础。

需求分配：

目的：产生工作任务书，让工作明确划分。

对象：有公司内部人员，或其它公司人员。（如外包公司）

需求评审：

流程：把内部的SRS（经过需求定义）进行一次内部的确认，提交用户进行需求验证。（需求评审流程详见同行评审）

评审要点：

1是否所有的分配需求都在SRS中体现？

2在SRS中定义需求时，是否避免使用那些会引起歧义的术语，诸如也许、可能等，每条需求都清晰无歧义？

3是否在SRS中描述了软件使用的目标环境，指明并简短描述了软件要什么及不做什么？

4是否在SRS中描述了是否在SRS中描述了软件使用的目标环境，指明并简短描述了目标环境中其它相关软件产品/子系统/模块？

5是否每一个具体需求都有唯一的编号？

6每一个需求是否切实可行、可测试、前后一致、彼此不冲突？

7是否在SRS说明了对每个输入的验证措施，并描述了每个输入的属性如：度量单位、边界值、时序要求等等？

8是否在SRS中说明了对每个输入的处理？

9是否在SRS中说明了第个输出项是如何输出的，并且描述每个输出的属性如：度量单位、边界值、时序要求等等？

10是否在SRS中描述了软件所有的性能需求？

11、是否性能需求的描述能通过测试来进行验证?

12、是否在SRS中说明了所有对系统可能的约束？

13、质量属性是否以可测量或可验证的术语进行描述？

14、是否要SRS中描述了系统中与其它子系统、模块或硬件设备的相关接口？

15、是否对每个接口的描述足够清楚，实现时不需更多解释？

16、是否在SRS中描述了与操作系统的接口？

17、是否在SRS的附录中记录了分配求可行性的分析结果？

18、是否项目SOW文档所对应的分配需求都在RTM中体现？

注：原始需求也从这些方面入手，这项不是死的，也是根据质量模型扩展来，根据不同项目从不同的质量特性入手。

评审意义：通过需求评审，可以尽早发现缺陷，对于发现的缺陷可以及时修复，避免遗留到后继阶段，以免扩大，造成更大的损失，在需求阶段对修复投入的成本是最低的。

注意事件：1为了保证需求评审的并行果，必须确保参与评审人员技术水平；

评审工作完成，一定要做好后继的需求跟踪，当需求发生变更时，要重新对而求进行变理和评审。不然评审就毫意义了。

2要根据项目特点对评审流程以及评审参与人，评审时间进行调整和裁剪。

需求基线：

评审完成后，把SRS变为受控状态（详见配置管理）

需求跟踪：

需求的实现和验证和跟踪

开发方面：对需求逐步实现

测试方面：对需求逐级验证

需求跟踪涉及到的配置项：

配置项：是软件生命周期个阶段产生的程序、数据、文件、环境

通过需求的跟踪建立RTM可以进行变更控制，RTM没有完成时，需求变更所设计的变更项比较少，这也就测试工作为什么要在早期进行的原因了。

描术方法：

通过输入、输出来说明（自然语言）

使用规范化的模型方法（UML）

使用电子表格

使用代表性的例子

第二种是现在通用的表达方式。其UML详见ROSE工具

需求阶段的角色和职责：

软件开发项目经理：

带领项目组分析审核工作任务书；

带领项目组与系统工程师（需求分析人员）进行需求交流并进行分析和文档化

组织SRS文档评审

组织需求跟踪

软件开发人员：

完成SRS文档；

完成需求跟踪

参加SRS评审

根据SRS评审专家意见，修改SRS文档

参加系统测试计划的评审

软件经理

在SRS评审结束后，批准SRS文档

QA

监督项目组遵循需求管理流程

参加相关文档评审（关注过程）

保证相关组参加文档评审

CCB（需求变更委员会）

控制需求的变更

软件测试经理

参与开发人员的软件需求分析，提出可测试性需求

组织人员参与SRS的评审工作

软件系统测试计划写作

组织系统测试计划评审

组织本阶段测试需求跟踪

软件测试工程师

参与SRS评审工作

协助软件测试项目经理完成软件系统测试计划写作

参加系统测试计划的评审

完成本阶段测试需求跟踪

*各个公司人员的任务不一样，但也要有具备这些工作的责任人

在这里总结一下测试人员参与需求分析的具体工作：

A方法途径：测试人员与需求分析人员共同负责原始需求诉获取。或

测试人员依据需求分析人员获取原始的需求相关资料，通过一定的分析过程，来明确需求中的相关内容（显示需求、隐式需求）。

B如何分析：通过与用户和需求分析人员进行讨论和沟通。

依据相关的需求资料设计UML与用户和需求认员进行确认和讨论。

C需求分析确认：要保证需要每一个需求的可测试性。（构造各种不同的输入，依据需求明确的处理过程分析预期输出。如某一条件不具备，则需求是有问题的）

要保证所有需求都被文档化

协助需求分析人员整理需求文档

需求项

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

命名方式：产品编号—SRS—需求类型句—XXX

如：CALC——SRS——FUNC——ADD—001，表示计算器十进制加法功能需求。