无论对于开发还是测试，一个全面精准有预见性的设计是保证项目顺利进行的前提。实际项目操作中，常常感受到测试过程有着各种问题：

　　1、产品质量维度关注的不全面，测试类型不完整；

　　2、测试规格设计较为随意，测试分解分配比较随意；

　　导致测试过程中，经常会出现需求遗漏、测试设计遗漏的问题；

　　因此一份详细精准的测试需求分析有利于这些问题的解决。

　　测试需求的定义

　 　软件需求定义的是要产品要实现的功能是什么，而测试需求这个名词业界并没有权威的定义，多数的意见认为测试需求定义测试的范围（即主要解决测什么、及测 到什么程度的问题），这样说还是太过泛泛，换个说法，测试人员依据初期功能需求，评估需要测试的功能点都有什么，每个功能点需要什么类型的测试，每个功能 点测试到什么程度算是通过，这样初步评估出了测试的规模、复杂程度和风险，同时可以初步预估出哪个环节需要研发同事提供测试接口。

　　测试需求设计的愈加详细精准，代表对待测试的软件了解的愈深，对各种测试手段了解的愈深，但是这往往要求测试需求的设计者拥有一定的测试经验。

　　测试需求的流程

　　测试需求的采集

　　测试需求最直接的来源是：

　　1、软件需求规格；

　　2、业界协议规范；

　　3、测试经验库；

　　4、对于已有旧版本的软件测试，还需要考虑继承性的测试需求。

　　对以上内容进行梳理，形成原始测试需求表，列表的内容包括需求标识、原始测试需求描述、信息来源，如下：

　 　测试人员需要对开发需求进行整理，首先需要确认软件需求的正确性、其次保证软件需求的可测试性。所谓的可测试指的是“存在一个可明确预知的结果，可用某 种方法对这个明确的结果进行判断、验证。”原则上，所有的软件需求都应该是可测试的，因为如果作为测试人员对需求无法产生准确的理解（即无法得出明确的结 果），那么开发人员也同样无法对同一条需求产生准确的理解。每一个测试需求需要保证一条需求只包含一项测试内容，因此一条软件需求通常可能对应多条测试需 求。

　　这个阶段的测试需求整理，最重要的一点就是要注意广泛性和全面性，要尽可能的收集更多的原始需求，不存在遗漏，并且可以对需求进行适当的扩充，这些需求应该不仅仅局限于上述的五种来源类型，也不仅仅局限于各种文档、资料。

　　1.1 编写目的

　　本软件需求规格说明的目的在于为《软件测试工程师管理系统》项目的开发提供：

　　a. 提出软件总体要求，作为软件开发人员和最终使用者之间相互了解的基础；

　　b. 提出软件功能要求、性能要求、接口要求、数据结构等要求，作为软件设计和程序编制的基础；

　　c. 为软件测试提供依据。

　　本软件需求规格说明的读者对象主要是项目主管、软件设计人员和最终用户。

　　1.2 项目背景

　　该项目的实施主要是为提高北京梅梅公司的人事管理效率而编制的。

　　1.3 定义

　　1.4 参考资料

　　a. 《软件测试工程师管理项目条款》-北京梅梅公司。

　　2 项目概述

　　2.1 软件总体说明

　　本项目的目标是完成一个计算机人事管理系统，实现人事管理的自动化。系统的主要功能包括：人事信息的录入、管理、查询、删除、生成报表等。

　　进入本系统提供用户选择菜单，要求人机界面友好，具有错误处理和故障恢复能力。

　　2.2 总体数据流图

　　按照功能设计，系统数据流图如下：

　　图一：系统数据流图

　　2.3 使用者的特点

　　本软件的最终用户是北京梅梅公司的人事专员和财务专员。具有计算机操作和使用技能。且熟悉业务。

　　2.4 条件和限制

　　为了使本系统尽快投入使用，要求本系统的开发周期较短，要求在年内两个月内完成。因此要求系统设计一人，程序员一人，测试工程师一人。

　　3 运行环境

　　本软件的最终运行环境是操作系统DOS5.0以上，或Windows95/98/2000/me/NT/XP等DOS环境上，要求有中文平台或操作系统为中文的计算机上，配有一台打印机。

　　3.1 运行软件系统所需的设备能力

　　一台微机：主频>=100，硬盘>=1M，内存>=1M；

　　一台打印机；

　　3.2 支持软件环境

　　操作系统：DOS5.0以上，或Windows95/98/2000/me/NT/XP。

　　开发环境：Microsoft Visual C++6.0；

　　3.3 接口

　　该系统硬件和软件与外界软件没有接口，也不需要网络环境；

　　在界面上，要求使用DOS菜单选择，用户可以随时选择菜单进行；

　　在操作上，要求操作简单，通过少数的选择菜单或单击按钮即可完成操作；

　　在系统运行任何阶段，提示给用户当前系统的状态。

　　3.4 故障处理

　　当系统缺少参数等情况时，给出提示，并返回安全状态；

　　当系统出现故障无法返回时，用户的数据不能丢失，重新其它系统，可实现数据恢复。

　　4 软件详细要求

　　4.1 性能需求

　　要求本系统在完成各项功能的同时，要求系统处理迅速，处理事务需要长时间时，提示用户等待且等待时间在用户可接收的范围之内。

　　4.2功能需求

　　根据系统功能的需要，对系统的功能进行划分，表示如下图：

图二：软件测试工程师管理系统功能

　　下面详述每一项功能的要求：

　　无论对于开发还是测试，一个全面精准有预见性的设计是保证项目顺利进行的前提。实际项目操作中，常常感受到测试过程有着各种问题：

　　1、产品质量维度关注的不全面，测试类型不完整；

　　2、测试规格设计较为随意，测试分解分配比较随意；

　　导致测试过程中，经常会出现需求遗漏、测试设计遗漏的问题；

　　因此一份详细精准的测试需求分析有利于这些问题的解决。

　　测试需求的定义

　 　软件需求定义的是要产品要实现的功能是什么，而测试需求这个名词业界并没有权威的定义，多数的意见认为测试需求定义测试的范围（即主要解决测什么、及测 到什么程度的问题），这样说还是太过泛泛，换个说法，测试人员依据初期功能需求，评估需要测试的功能点都有什么，每个功能点需要什么类型的测试，每个功能 点测试到什么程度算是通过，这样初步评估出了测试的规模、复杂程度和风险，同时可以初步预估出哪个环节需要研发同事提供测试接口。

　　测试需求设计的愈加详细精准，代表对待测试的软件了解的愈深，对各种测试手段了解的愈深，但是这往往要求测试需求的设计者拥有一定的测试经验。

　　测试需求的流程

　　测试需求的采集

　　测试需求最直接的来源是：

　　1、软件需求规格；

　　2、业界协议规范；

　　3、测试经验库；

　　4、对于已有旧版本的软件测试，还需要考虑继承性的测试需求。

　　对以上内容进行梳理，形成原始测试需求表，列表的内容包括需求标识、原始测试需求描述、信息来源，如下：

　 　测试人员需要对开发需求进行整理，首先需要确认软件需求的正确性、其次保证软件需求的可测试性。所谓的可测试指的是“存在一个可明确预知的结果，可用某 种方法对这个明确的结果进行判断、验证。”原则上，所有的软件需求都应该是可测试的，因为如果作为测试人员对需求无法产生准确的理解（即无法得出明确的结 果），那么开发人员也同样无法对同一条需求产生准确的理解。每一个测试需求需要保证一条需求只包含一项测试内容，因此一条软件需求通常可能对应多条测试需 求。

　　这个阶段的测试需求整理，最重要的一点就是要注意广泛性和全面性，要尽可能的收集更多的原始需求，不存在遗漏，并且可以对需求进行适当的扩充，这些需求应该不仅仅局限于上述的五种来源类型，也不仅仅局限于各种文档、资料。

　　许多IT 企业都有过需求失控的痛苦经历，我们不难体会，没有好的需求管理会给我们带来什么：

　　● 需求以失控的状态进入软件过程，从源头上失去了项目的质量保证；

　　● 需求范围界定不清，使项目缺乏计划性，导致成本、研制周期失控；

　　● 需求变更失控，使组织处于被动反应式的环境中，项目组成为救火队；

　　● 需求管理不当，导致项目延期、士气低落，增加了项目的失败风险；

　　● ……

　　为了避免上述情况的出现，CMMI 对需求管理提出了明确的目的：一是管理项目的产品和产品构件的需求；二是标识哪些需求与项目计划及工作产品之间不

　　一致。通过适当的步骤，确保需求在项目的各个层面上动态地保持一致，一旦出现不一致，则启动相关的处理过程域，使其调整到一致。

　　需求管理的工具包括：

　　1、需求及相关文档管理的工具；

　　2、流程审批的流转电子化；

　　3、溯源性矩阵的维护工具。

　　其中最大的难点是需求溯源性矩阵的维护工具，对此我们作重点分析。

　　需求溯源包括的三个方面，可看作是三个子矩阵，每个子矩阵对某个方面都具有双向溯源性。

　　● 需求向低层分解的双向溯源矩阵

　　● 需求沿生命周期纵向产品溯源矩阵

　　● 需求的水平溯源矩阵（跨系统功能间）

　　综上所述，需求管理要求建立和维护需求双向溯源表，而双向溯源表的关联关系非常复杂，因此：

　　1、必须借助工具进行管理。对小的项目，可以用Excel 等简单工具进行管理，但对大型项目或组织级的需求管理，则应购买或自行开发专门的需求管理工具。

　　2、必须建立一套编码体系，以便进行标识和检索。

　　3、需求管理工具可以与配置管理工具同时考虑，即综合设计成一个管理系统。

　　一、国外需求管理工具

　　Rational RequisitePro

　　IBM Rational RequisitePro 解决方案是一种需求和用例管理工具，能够帮助项目团队改进项目目标的沟通，增强协作开发，降低项目风险，以及在部署前提高应用程序的质量。通过与Microsoft? Word 的高级集成方式，为需求的定义和组织提供熟悉的环境。提供数据库与Word 文档的实时同步能力，为需求的组织、集成和分析提供方便。支持需求详细属性的定制和过滤，以最大化各个需求的信息价值。提供了详细的可跟踪性视图，通过这些视图可以显示需求间的父子关系，以及需求之间的相互影响关系。通过导出的XML 格式的项目基线，可以比较项目间的差异。可以与IBM Software Development Platform 中的许多工具进行集成，以改善需求的可访问性和沟通。

　　网址：http://www-306.ibm.com/software/rational/

　　Telelogic DOORS

　　Telelogic DOORSreg; Enterprise Requirements Suite (DOORS/ERS) 是基于整个公司的需求管理系统，用来捕捉、链接、跟踪、分析及管理信息，以确保项目与特定的需求及标准保持一致。DOORS/ERS 使用清晰的沟通来降低失败的风险，这使通过通用的需求库来实现更高生产率的建设性的协作成为可能，并且为根据特定的需求定义的可交付物提供可视化的验证方法，从而达到质量标准。Telelogic DOORS 企业需求管理套件（DOORS/ERS）是仅有的面向管理者、开发者与最终用户及整个生命周期的综合需求管理套件。不同于那些只能通过一种方式工作的解决方案，DOORS/ERS 赋予你多种工具与方法对需求进行管理，可以灵活地融合到公司的管理过程中。以世界著名的需求管理工具DOORS 为基础，DOORS/ERS 使得整个企业能够有效地沟通从而减少失败的风险。DOORS/ERS 通过统一的需求知识库，提供对结果是否满足需求的可视化验证，从而达到质量目标，并能够进行结构化的协同作业使生产率得到提高

　　网址：http://www.telelogic.com

　　Borland CaliberRM

　　Borland CaliberRM 是一个基于Web 和用于协作的需求定义和管理工具，可以帮助分布式的开发团队平滑协作，从而加速交付应用系统。CaliberRM 辅助团队成员沟通，减少错误和提升项目质量。CaliberRM 有助于更好地理解和控制项目，是Borland 生命周期管理技术暨Borland Suite 中用于定义和设计工作的关键内容，能够帮助团队领先于竞争对手。CaliberRM 提供集中的存储库，能够帮助团队在早期及时澄清项目的需求，当全体成员都能够保持同步，工作的内容很容易具有明确的重点。此外，CaliberRM 和领先的对象建模工具、软件配置管理工具、项目规划工具、分析设计工具以及测试管理工具良好地集成。这种有效的集成有助于更好地理解需求变更对项目规模、预算和进度的影响。

　　网址：http://www.borland.com

　　二、国内需求管理工具

　　统御需求管理软件（oKit-req）

　　oKit-req 是一款基于Web 的需求管理工具，它是统御项目管理系统（oKit）的一个关键功能，也可以作为独立软件使用。oKit-req 具备以下主要功能：

　　(一) 支持对多个项目需求的管理；

　　(二) 版本化、层次化、条目化管理需求；

　　(三) 方便的建立需求跟踪矩阵；

　　(四) 进行变更影响分析和覆盖面分析；

　　(五) 输出成WORD 文档；

　　(六) 离线交换和合并文档；

　　(七) 全程跟踪需求变化历史，支持附件和图文表。

　　网址：www.kingrein.com

　　四者的比较

　　在软件开发中，大家都会遇到过这样的问题：客户的一个新想法，就推翻了之前与客户经过再三讨论而确认定下来的需求。如果是功能性需求变更还会让人容易接受一些，毕竟功能性需求不实现的话，是会大大影响到软件产品的质量。但是一些非功能性的变更会让人很头疼，许多是看起来无关痛痒的、鸡毛蒜皮的变更，却是极为令人无语和无奈，甚至是烦恼和厌恶的。

　　（1）什么是软件需求？

　　在IEEE中，软件需求的定义是：用户解决问题或达到目标所需的条件或功能。一般包含业务需求、用户需求、功能需求、行业隐含需求和一些非功能性需求。业务需求反映了客户对系统、产品高层次的目标要求；功能需求定义了开发人员必须实现的软件功能。所谓非功能性需求，是指为满足用户业务需求而必须具有除功能需求以外的特性。包括系统性能、可靠性、可维护性、易用性和对技术和对业务适应性等。其中最常见的是软件界面、操作方便等一系列要求。

　　（2）非功能性需求变更的特点

　　让我们从客户角度和开发人员角度去看看非功能性需求的特点。首先，有些非功能性小需求从客户角度看起来工作量不大，但是实际上开发人员要耗费比较长的时间去完成这些小功能。其次，许多非功能性需求，如界面美观、操作方便等都是客户头脑一热、或领导一拍脑袋就部署下去的需求，往往是原来在需求分析阶段所没有注意的内容。

　　其实，非功能性需求是常常被轻视，甚至被忽视的。原因是非功能性需求描述很困难，它很难像功能性需求那样，可以通过结构化和量化的词语来描述清楚。在描述这类需求时候，我们经常采用软件性能要好、操作要方便、软件界面要美观大方等较模糊的描述词语。例如，易用性就同时涉及到美工和UI界面、人机工程、交互式设计、心理学、用户行为模式等内容。这类描述词语都是脱离了软件的执行环境，是对人和相关的场景的描述，因此很难体现到软件架构设计和具体的实现中。

　　国内的很多软件公司，对于这种情况趋之若鹜，认为是负担，影响软件公司的工作安排，工作量以及工作进度，直接导致了软件公司的效益，几乎是很多软件公司的最大隐患，因此我们如何认识、对待这个普遍存在的问题就成了软件公司以及员工需要解决的问题；

　　1）首先，要从心理上彻底根除对需求变更的恐惧，从认识上明确需求变更是软件开发过程中不可缺少的部分，从方针上明确需求变更的存在性和必然性；

　　　　a）从软件公司角度，认清自身存在的不足， 客观面对需求的变更

　　　　b）从职员角度，提高本身的业务和技术能力

　　2）从技术角度上使需求变更的处理简单化，明确化，增加可维护性；

　　　　a）使用更好的技术手段，设计更灵活以用来适应更多变的需求；

　　　　b）使用更完善的软件工程的理念，让软件各个步骤细化，更易维护和修改；

　　　　c）使用完善的测试流程，最大的降低需求变更带来的软件风险；

　　3）对需求变更进行有效的管理，让需求变更可以规范化管理，做到有效的处理需求的变更，用有限的资源获得最大的效益；

　　　　a）软件的初期，就要考虑最大限度的减少将来可能存在的需求变更

　　　　b）需求的控制，减少需求的来源，过滤不合理的需求

　　　　c）文档化管理，有备可查，有据可依；

　　　　d）合适的公司体制和运作，找到一条适合自己公司发展的运作体制和管理模式；

　　可能大家觉得上面说的话有些空，那么我就从技术角度上再具体的谈谈。

　　就像刚才说过的，需求变更是必然存在的。从技术的角度来降低或避免需求变更给我们带来的影响就显得极为重要。

　　1、设计之初，充分理解需求，更好对需求进行整理和规划，预测可能变更的需求。

　　需求难做，业务难做，非功能性的需求变更更是难做。所以当我们在收集了用户需求后，不仅仅是简单的分类，然后按部就班的开发，而是要深入挖掘需求，一些看似固定业务的需求，可能由于业务的变更而使得你的系统不能使用。我们要做的就是拆分需求，把一些可能会发生变化的需求拆开，改成工作流程可配置的。就像面向过程转向面向对象的那样，面向过程是死的，而面向对象重新组合后，就特别简单。

　　就说说我们刚做的这个收银系统吧，用户要求结账时，要打印小票，并自动打开钱箱。这就是最最原始的需求。但是我们最终把它做成了这样：打印机是外部设备，可以增删和配置；打印次数可配置；打印样式可配置；打印时，要判断打印机状态，非正常状态要给出各种提示（不一一列举）；钱箱可以自动打开，也可以手动打开。另外还设定了许多功能配置：如禁用/启用全部打印机，禁用/启用某个打印机，是否打印订单小票，是否自动打开钱箱，是否显示错误提示信息等等（如图）。

　　我们把这个固定的需求，拆分成可配置的，这样就把这个需求可能的变更已经分析的差不多了。不论它怎么变化，我们的应对都会变得从容。就在前2天部署的时候出现问题了，打印机是新买的，不只是什么原因，在打印多个换行之后，就会失败，不能继续打印。这个问题是我们所料不及的，因为我们测的我们这里的所有打印机，都完美打印，而新买的也是同品牌，同型号的打印机。最终分析出这个问题后，我们不用更改系统，只要修改一下小票样式配置，就可以完美打印了。

　　小票样式设定（图）：

　　硬件设置（图）：

　　单个打印机设置（图）：

　　功能设置（图）：

　　2、系统完成之后，客户再提新需求后，要分析这个需求的深层次含义，分析客户要的到底是什么。对于一些需求，如果适合于大部分客户，而且改动很少，就可以完成，那么可以在下个升级版本中集成。而对于某些非功能性的需求，改动太大，或者基本的核心功能都需要更改的话，那么就不要先去急着实现，而是放置起来，等待系统需要进行大的升级或者重构时，再考虑添加。而且要防止客户滥用提需求的权力，对于一些不合理的需求，还要去引导客户，让他们理解这个功能的不合理的地方，从而重新修改需求或者放弃。

　　作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个 软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。但是需求带来的问题一直是各个软件公司项目失败的首要 原因，因此需求是很复杂的，我们希望能在不断地学习和实践中不断地理清需求、提高需求分析能力。

　　软件需求包括3个不同的层次：

　　【业务需求】

　　描述组织或客户的高层次目标，通常问题定义本身就是业务需求。这种目标通常体现在两个方面：

　　问题：解决企业/组织运作过程中遇到的问题，如物资供应脱节、用户投诉量大、客户流失率高等。

　　机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行等。

　　业务需求就是系统目标，它必须是业务导向的、指导软件开发的 高层需求。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开 发系统（why），组织希望达到什么目标。一般使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM后公司的客户满意度达到80％以 上”就是一条组织愿景。

　　【用户需求】

　　用户需求是指描述用户使用产品必须要完成什 么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系 统将给用户带来的业务价值，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要 的。

　　作为需求捕获阶段的主要产物，主要具备以下特点：

　　零散：用户会提出不同角度、不同层面、不同粒度的需求，而且常常是一句话形式提出的，如通过电话、短信等非正式方式提出的需求。

　　存在矛盾：由于用户处于企业/组织的不同层面，因此难免会出现盲人摸象的现象，而导致需求的片面性。

　　因此，我们还需要对原始需求进行分析和整理，从而得出更加精确地需求说明。用例、用户故事、特性等都是表达用户需求的有效途径。

　　【软件需求】

　　由于用户需求具有零散、矛盾的特点，因此需求分析人员还需要对其进行分析、提炼、整理，从而生成指导开发的、更准确的软件需求，软件需求是需求分析与建模的产物。

　 　软件需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。这些需求记录在软件需 求规格说明（Software Requirments Specification）中。SRS 完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工 具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。