1  本文简介

 Rational ClearCase 作为一款功能强大的软件配置管理（ SCM ）工具，在国内已经得到许多企业用户的认可并被广泛采纳。为了帮助大家更好的了解和使用 ClearCase ，本文将全方位解剖 ClearCase 的重要组成部分：视图（ View ）。

2  ClearCase视图的分类

我们知道，软件配置管理工具的一个基本功能是建立和管理开发人员的工作空间。在 ClearCase 中，工作空间被称为视图（ View ），它可以选择所指定任务的每一个文件或目录的适当版本，并将它们呈现给使用者。通俗的讲， View 就像一个过滤器，依据一组配置规则从 VOB 中将我们需要的文件或目录的版本选择出来。 View 是访问 VOB 库中文件和目录版本的手段，通过视图，用户可以浏览、修改、构建可用的文件和目录。

在实际使用中， View 分为两种类型，即 Dynamic View （动态视图）和 Snapshot View （静态视图，又称快照视图）。下面我们来看看这两种视图有什么差异：

动态视图：

•  使用 MVFS 文件系统透明访问 VOB 库，不占用本机空间；

动态视图无需将文件拷贝到本地目录，通过虚拟文件系统对 VOB 中的版本进行存取操作。

•  动态视图的使用依赖于网络；

•  提供了共享派生对象和构建审计功能，这是动态视图独有的。

•  动态视图通过 mount 指定的 VOB 库来获取数据。

 动态视图采用 mount 的方式获取 VOB 中的数据，速度比较快，它是一个全局视图。

 静态视图：

•  只能定期通过 update 操作实现文件的更新；

•  文件被下载到本地，占用本地空间；

•  可以离线工作，断网使用；

•  可以在本地进行高速编译；

•  使用静态视图占用 ClearCase 服务器资源较少；

•  静态视图通过 load 指定的 VOB 库来查看文件。

因此你可以只选择下载与你的需要有关的文件拷贝（除非你需要所有的内容），这个可通过通过专门的下载规则来实现。当然静态视图也可以卸载在下载规则中被过滤和删除的文件。

通过对两种视图比较，我们会发现它们各有千秋。在实际使用中，当你希望离线工作或只需要 VOB 库中的部分代码时，建议使用静态视图，这样还能减少因对服务器频繁访问所造成的压力。如果你使用便携式电脑，使用静态视图则更加便利。

当需要节省本地磁盘空间、希望频繁自动更新或者仅仅是为了查看文档、代码，创建动态视图既快速又不占用本机空间，是个不错的选择。

3  如何创建视图

当你安装了 ClearCase 客户端软件后，要做的第一件事就是创建 View 。如图 1 所示，我们打开 ClearCase Explorer ，以 Base ClearCase 为例，在工具栏里有一项“ Create View ”：

图 1

点击“ Create View ”后，出现图 2 ，因为我们是以 Base ClearCase 为例，这里选择默认即可。

图 2

根据你的需求选择创建 Snapshot View 或者 Dynamic View ，见图 3 所示：

图 3

如果你要创建静态视图，如图 4 ，需要指定该视图在本机的存储路径（存放从 VOB 库中 load 的文件和目录）。

图 4

如果你要创建动态视图，则只需要指定一个映射盘符即可，见图 5 。因为动态视图是通过 MVFS 访问 VOB 库中的数据，不需要将数据下载到本机。

图 5

在图 4 和图 5 中都有一个“ Advanced Options ”按钮，点击进入后见图 6 ，这里可以选择你的视图是存储在服务器端还是本机。 ClearCase 的 View 数据（主要是 View database 等）既可以存放在 View Server 中，也可以存放在本机。一般建议存放在 View Server 中，以便组织进行统一管理。

图 6

选择完成后，将进入如图 7 所示界面，这里有一个“ Inspect Config Spec ”，用来定义该视图的配置规约（ Config Spec ），配置规约将决定哪些版本可以看到，点击进入：

图 7

进入“ Inspect Config Spec ”后，我们会发现里面有默认的规约，见图 8 ，可以直接使用。通常管理员或配置经理会根据开发的需要编写一些特定的配置规约供开发人员使用，在这里进行选择和修改。

图 8

完成了以上的选择和设置后，就可以成功创建一个视图了。

4  视图的管理

视图通常与任务对应，经过一段时间的使用后，用户因需要会创建了多个视图，这就涉及到视图的管理和维护问题。

4 .1 与视图相关的基本操作

对于普通开发人员而言，与视图相关的操作主要包括视图的创建和删除，操作相对比较简单。需要强调的是：在删除视图时，要使用 ”Remove View”进行操作，如图9所示。如果使用”Remove View shortcut”,则只是删除了该视图的快捷方式，更新后还会再次出现。

静态视图有一个特有的操作是 update，需要定期进行，才能和VOB中的数据保持同步。

图 9

4.2 关于 hijacked文件

我们知道，静态视图将 VOB中的文件下载到本地后，文件是只读的。如果你绕过检出(checkout)操作，只是去掉某个需要更改文件的只读属性就进行操作，那么该文件就被称为“劫持”（ hijacked）文件。 具体的表现为：在 ClearCase Explorer 中，处于“ hijacked ”的元素会有一个带对号的红色圆圈。

如果出现“ hijacked”，有两种操作方式可供选择：

•  鼠标右击“ Hijacked”的元素，选择“Undo Hijacked”。为了不丢失你对文件所做的改动，Undo Hijacked之后，ClearCase自动生成一个后缀为“keep”的私有文件（view private files），这时你不仅取消了Hijacked，同时也保存了你的工作成果（当然如果不需要可以删除这个私有文件）。

•  更新视图（ update view），然后鼠标右击“Hijacked”的元素，选择“Check Out”，该元素将处于“checked out”状态，这时你可以继续对该元素进行改动，也可以直接做Check in操作， 完成文件变更的入库，形成新的版本。

以上也给大家提供了利用静态视图离线或在家办公的方法，还不错吧。

4.3 视图的迁移

该部分内容主要针对 ClearCase管理员而言。视图的迁移主要是将View Server中的视图在同一个机器中从一个存储区域迁移到另外一个存储区或者跨服务器间移动。通常在视图存储空间不足或者为了提升View Server性能使用新服务器时，需要进行视图的迁移，这样原有的视图信息不会被破坏，客户端基本不受任何影响，迁移后可以正常使用原有的视图。

下面我们举例说明如何将视图从 CCSERV1这台视图服务器迁移到CCSERV2上：

4.3.1 首先对CCSERV1上的所有用户的视图信息进行备份。

4.3.2 将CCSERV2安装为视图服务器，并创建相应的视图存储路径。

4.3.3 做好以上准备后，就可以进行正式的迁移工作。

•  在CCSERV1上停掉ClearCase服务，如图10所示。

•  使用ccopy命令将CCSERV1的视图拷贝到CCSERV2上新建的视图存储目录中，如：

ccopy G:\cc_Storage\views\ccview \\ccserv2\cc_ Storage\views\ccview

上面的操作是将 CCSERV1中ccview目录中的视图信息拷贝到CCSERV2的ccview中，如果有多个目录需要进行拷贝可以写成一个脚本统一进行。

图 10

4.3.4 确认拷贝到CCSERV2的数据是否完整。

4.3.5 启动CCSERV1上的ClearCase服务，在CCSERV2上对迁移的视图进行重新注册。

因为可能涉及到成百上千的视图，单个进行注册是不现实的，需要通过程序进行。基本的思路是先将视图原有的注册信息删除，然后重新注册到CCSERV2上去。这里给大家一个perl语言编写的例子供参考：

printf ("All Views begin registering:\n");

@lines = `cleartool lsview -region soft1 -s`;

foreach $line(@lines)

chomp ($line);

$view_info = `cleartool lsview -region soft1 $line`;

$view_info =~ m/(\S+)\s+(\S+)/;

 $view_tag = $1;

$view_stg = $2;

printf "\n";

printf("The old view stg is:%s\n",$view_stg);

system("cleartool rmtag -view -region soft1 $view_tag");

system("cleartool unregister -view $view_stg");

$new_view_stg = $view_stg;

chomp ($new_view_stg);

if ($new_view_stg =~ m/ccview/)

{

$new_view_stg=~ s/\\\\ccserv1\\ccview\\views/\\\\ccserv2\\ccview \\views/;

}

printf ("The new_view_stg is:%s\n",$new_view_stg);

$rc = system("cleartool register -view $new_view_stg");

if ($rc)

{

 print LOG_F "$line\n";

}

system("cleartool mktag -nstart -region soft1 -view -tag $view_tag $new_view_stg");

printf "\n";

}

printf ("All Views register successfully!\n");

上面的程序完成了将视图在 CCSERV1上原有的信息删除，然后重新注册到CCSERV2的功能。这里需要注意的是：如果存在多个region，需要分别进行处理。

4.3.6 验证迁移后的视图使用是否正常。

在客户端检查原有的静态和动态视图能否正常使用，可以做一些常见的操作，如checkout、checkin、update和mount（仅对动态视图）等。

4.3.7 检查无误后可以将CCSERV1上的视图数据和视图存储路径予以清除。

至此，整个视图的迁移工作大功告成。

4.4 视图的清除

因为用户对视图处理不当，在经过一段时间的运作后，会出现一些垃圾视图（即已经不再使用但没有被彻底清除），日积月累会严重影响 ClearCase 服务器的性能。可以使用以下命令予以彻底的清除：

cleartool rmtag -view $tag;

cleartool rmview -force -all -uuid $uuid;

cleartool unregist -view -uuid $uuid;

以上命令需要的 tag 、 uuid 信息可以通过 lsview 命令获取，将这些命令进行组合，写成一个脚本便可以实现批量清除垃圾视图。

5  总结

本文对 Base ClearCase中的View进行了较为详细的介绍（UCM方式基于活动，故有所差异，本文没有提及），希望能对大家有所启示。由于View本身牵涉内容较多，如有更深层次的需求，可以参考ClearCase自带的用户手册，做进一步的研究。

本文缩略语：

VOB(Versioned Object Base): 版本对象库,ClearCase 数据的存储库，它存储了处于版本控制下所有的文件、目录和元数据等。

View: 视图，它可以选择所指定任务的每一个文件或目录的适当版本，并呈现它们。

View Server：存储View数据的服务器。

 MVFS(Multiversioned File System)：多版本文件系统，它通过使用标准操作系统协议增加一个新文件系统类型，MVFS提供了透明的版本控制机制。

摘要：

测试人员越早介入项目工作越好的观点已经被越来越多的测试人员所接受。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵的论断也已经成为了大家的共识。

测试人员需要参加需求评审，我想大部分测试人员都接受了这个观点，同时也是这么做的。但测试人员为什么需要参加需求评审，恐怕不是每一个人都知道个中道理。本文从作者多年从事软件测试和过程管理的经验出发进行论述，供同行们参考。

关键词：

测试  测试人员需求评审

正文：

我们知道，在项目的生命周期中，需求、设计、编码、测试等活动往往是由不同的专业技术人员协同完成的。这样，由于下游技术人员对上游技术人员工作产出物的理解偏差，将导致不同阶段的产出物之间不一致的现象出现，这也是导致项目可能不成功的重要风险之一。

基于以上的观点，需求人员编写的《用户需求说明书》、系统设计人员编写的《系统设计说明书》、编码人员实现的系统、测试人员编写的《测试用例》之间不可避免地存在不一致的现象。

由于测试工作的主要面向对象是《用户需求说明书》和可运行系统，为便于分析，我们先用图来表述一下三者之间的关系：

从理论上讲，上图中“需求”（S圆表示）、“可运行系统”（P圆表示）和“测试用例”（T圆表示）应该是重合，但实际上这三个圆很难重合。

从上图可以看出：可能会有没有测试到的已描述行为（区域2和区域5）；经过测试的已描述行为（区域1和区域4）；对应未描述行为的测试用例（区域3和区域7）；可能会没有测试的程序行为（区域2和区域6）；经过测试的程序行为（区域1和区域3）；对应于未通过程序实现的行为（区域4和区域7）。

由于我们今天讨论的主题是“测试人员为什么需要参加需求评审”，因此我们重点来看看与这一问题关系密切的区域2和区域5、区域3和区域7。

区域2和区域5这两部分是测试用例没有覆盖到的需求，即“没有正确的测试用例与该部分需求对应”。出现这种情况本人认为有三种可能：

1、                设计测试用例的测试人员对需求理解不完整，出现了应该被测试的需求而没有被测试用例覆盖到的现象；

2、                《用户需求说明书》中区域2和区域5对应的需求，具有不可测试性，测试人员无法设计用例；

3、                《用户需求说明书》中区域2和区域5对应的需求，不是用户的需求，是需求分析人员凭空增加的，测试人员无须设计与这部分需求对应的测试用例。

区域3和区域7这两部分是需求没有覆盖到的测试用例，即“没有正确的需求与该部分测试用例相对应”。出现这种情况本人认为有两种可能：

1、设计测试用例的测试人员对需求理解不充分，从而设计出了多余的测试用例；

2、《测试用例》中区域3和区域7的测试用例所对应的需求，是用户的真实需求，只是《用户需求说明书》中没有描述到而已。

从上面的分析可以看出，如果测试人员参加了“需求评审”，则上面出现的问题可以最大程度地避免，因为测试人员参加“需求评审”的重要作用正是针对产生这些问题的因素而进行的。

由此总结出，测试人员参加“需求评审”活动所需要达到的目标包括如下三个方面：

1、充分地理解需求，确保对需求的理解与需求分析人员是一致的；

2、从可测试的角度，努力发现《用户需求说明书》中不可测试的需求，从而提醒需求分析人员尽早修改；

3、从测试人员的角度努力发现《用户需求说明书》中的不完整性，从而提醒需求分析人员及时补充遗漏掉的这部分用户需求。

主要参考文献

[1] 《软件测试》机械工业出版社

[2] 《软件测试经验与教训》（美）Cem Kaner,James Bach,Bret Pettichord著，韩柯等译

[3]《编写有效用例》（美）Alistair Cockburn著，王雷、张莉译机械工业出版社

    本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。
    1 什么是软件需求和需求工程

    1.1 软件需求的定义
    在IEEE软件工程标准词汇表(1997年)中定义软件需求为：
    （1）用户解决问题或达到目标所需的条件或能力。

    （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。

    （3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

    1.2 需求工程的定义

    需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

    2 需求分析的风险

    由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在：

    （1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。
    （2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。
    （3）用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化，因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需求变化是每个开发人员、项目管理人员都会遇到的问题，也是最头痛的问题，一旦发生了需求变化，就不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化就像是万恶之源，为项目的正常的进展带来不尽的麻烦。
    （4）需求的完整程度。需求如何做到没有遗漏？这是一个大问题，大的系统要想穷举需求几乎是不可能的，即使小的系统，新的需求也总会不时地冒出来。一个系统很难确定明确的范围并把所有需求一次性提出来，这会导致开发人员在项目进展中去不断完善需求，先建立系统结构再完成需求说明，造成返工的可能性很大，会给开发人员带来挫折感，降低他们完成项目的信心。
    （5）需求的细化程度。需求到底描述到多细，才算可以结束了？虽然国家标准有需求说明的编写规范，但具体到某一个需求上，很难给出一个具体的指标，可谓仁者见仁，智者见智，并没有定论。需求越细，周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，相反，需求越粗，开发人员在技术设计时不清楚的地方就越多，影响技术设计。
    （6）需求描述的多义性。需求描述的多义性一方面是指不同读者对需求说明产生了不同的理解；另一方面是指同一读者能用不同的方式来解释某个需求说明。多义性会使用户和开发人员等项目参与者产生不同的期望，也会使开发、测试人员为不同的理解而浪费时间，带来不可避免的后果便是返工重做。
    （7）忽略了用户的特点分析。分析人员往往容易忽略了系统用户的特点，系统是由不同的人使用其不同的特性，使用频繁程度有所差异，使用者受教育程度和经验水平不尽相同。如果忽略这些的话，将会导致有的用户对产品感到失望。
    （8）需求开发的时间保障。为了确保需求的正确性和完整性，项目负责人往往坚持要在需求阶段花费较多的时间，但用户和开发部门的领导却会因为项目迟迟看不到实际成果而焦虑，他们往往会强迫项目尽快往前推进，需求开发人员也会被需求的复杂和善变折腾的筋疲力尽，他们也希望尽快结束需求阶段。

    3 如何做好需求工作

    需求分析是软件项目开发中最困难的一项工作，它不仅要求分析人员具有丰富的需求分析经验和良好的专业素质，还要求分析人员具有良好的学习能力、公关能力、语言能力和组织能力。在实际工作中分析人员要面对不同的单位、不同的部门、不同的人员、不同的文化、不同的关系、不同的管理水平等等不同的情况，面对如此纷繁复杂的环境，如何做好需求分析工作？首先需要建立一个有效的工作机制，只有建立了工作机制，才能保证需求工作按照既定方案执行，需求开发和管理的参与者才会在一种有序的状态下工作。其次才是充分运用工作机制和个人能力去获取问题、分析问题、编写需求文档和进行需求管理。

    3.1 建立需求分析工作机制需考虑的几个因素

    （1）抓住决策者最迫切和最关心的问题，引起重视。用户方决策者对项目的关心重视程度是项目能否顺利开展的关键，决策者的真实意图也是用户方的最终需求，因此，在开发过程中要利用一切机会了解决策者关心的问题，同时也要让他们了解项目的情况。在诸如谈判、专题汇报、协调会议、领导视察、阶段性成果演示等过程中用简短明确的语言或文字抓住领导最关心的问题，引导他们了解和重视项目的开发，当决策者认识到项目的重要性时，需求分析工作在人力、物力、时间上就有了保障。
    （2）建立组织保障，明确的责任分工。项目开发一般都会成立相应的项目组或工程组，目前，常见的组织形式是：产品管理组、质量与测试组、程序开发组、用户代表组和后勤保障组，各组的主要分工是：产品管理组负责确定和设置项目目标，根据需求的优先级确定功能规范，向相关人员通报项目进展。程序管理组负责系统分析，根据软件开发标准协调日常开发工作确保及时交付开发任务，控制项目进度。程序开发组负责按照功能规范要求交付软件系统。质量与测试组负责保证系统符合功能规范的要求，测试工作与开发工作是独立并行的。用户代表组负责代表用户方提出需求，负责软件的用户方测试。后勤保障组负责确保项目顺利进行的后勤保障工作。
    （3）建立良好的沟通环境和氛围。分析人员与用户沟通的程度关系到需求分析的质量，因此建立一个良好的沟通氛围、处理好分析人员与用户之间的关系显得尤其重要，一般情况，用户作为投资方会有一些心理优势，希望他们的意见得到足够的重视，分析人员应该充分的认识到这一点，做好心理准备，尽量避免与他们发生争执，因为我们的目的是帮助用户说出他们的最终需要。在沟通时分析人员应注意以下几个方面：1）态度上要尊重对方，但不谦恭。谦恭可能会让用户一时感到满意，但对长期合作并没有好处，尤其是在发生冲突的时候，用户会习惯性地感到自己的优势，而忽略分析人员地意见。2）分析人员要努力适应不同用户的语言表达方式。每个人都有自己的表达方式，所以优秀的分析人员应该是一个优秀的“倾听者”，他们能很快的适应用户的语言风格，理解他们的意思。3）善于表达自己，善于提问。分析人员在开口前应该先让对方充分表达他的意思，在领会了后，自己再说，尽量不要抢话。4）工作外的交流有助于增进理解，加强沟通。
    （4）需求质量控制要制度化需求的变化是软件项目不可避免的事实，因此需求质量控制是一项艰苦的工作，要保证该项工作的顺利实施，就必须有制度保证，这个制度可以在项目质量控制方案中制定，该方案主要是具体化、定量化的描述用户要求，形成全面、一致、规范的软件需求分析规格说明书，明确需求分析规格说明书的工作程序和要素，规范开发活动，为后续软件设计、实现、测试、评审及验收提供依据。在方案中要明确项目组各部门关于需求质量控制的职责，制定需求分析的工作程序，包括编制需求分析工作计划、编制《需求分析说明书》、《需求分析规格说明书》的评审和确认、《需求分析规格说明书》修改控制、确定需求质量控制的质量记录文档规范等内容。

    3.2 需求开发与管理的一些方法

    需求开发是一项复杂的工作，使用的方法也很多，不同的开发方式有不同的方法，这里简单介绍一些相关的方法：
    （1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
    （2）可行性分析：在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。
    （3）需求优先级：确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。
    （4）系统原型：当用户自身对有的需求不十分清楚时，我们可以建立一个系统原型，用户通过评价原型更好地理解所要解决的问题。。
    （5）图形分析模型：绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
    （6）数据字典：数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。
    （7）质量功能调配：质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。它将需求分为三类：期望需求、普通需求、兴奋需求。

    需求管理的目的就是要控制和维持需求事先约定，保证项目开发过程的一致性，使用户得到他们最终想要得产品。需求管理的方法主要包括以下一些方面：

    1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。

    2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

    3）建立需求基准版本和需求控制版本文档。确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

    4）维护需求变更的历史记录。将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。

    5）跟踪每项需求的状态。可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

    6）衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚。

    4 需求分析评价标准

    如何判断需求规格说明的好坏，不同的软件工程规范都有自己的一套标准，这里向大家介绍一个比较常见的NASA SEL推荐方法，它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一，它对软件需求过程的评价标准是：清晰、完整、一致、可测试。
    （1）清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
    （2）完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。
    （3）一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
    （4）可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。