撰写网站建设项目需求文档指南：详解编制网站建设需求说明书的方法

如何编制网站建设项目需求说明书

一个网站项目的确立源于各式各样的需求，这些需求可能源自客户的具体需求或公司自身发展的需求，其中客户的具体需求，即交易性质的需求占据了大部分。面对对网站开发知识水平不一的客户，项目负责人对用户需求的理解程度，在很大程度上决定了此类网站开发项目的成败。因此，如何更好地了解、分析、明确用户需求，并以文档形式准确、清晰地传达给参与项目开发的每个成员，确保开发过程按照满足用户需求的目标正确进行，是每个网站开发项目管理者需要面对的问题。针对这个问题，本文提出了一些看法和建议，希望读者批评指正：

一、哪些人应参与网站开发项目的需求分析活动

需求分析活动实际上是一个与客户交流、引导客户将自己的实际需求用适当的技术语言表达（或由相关技术人员帮助表达）以明确项目目标的过程。这个过程中也包含了对要建立的网站基本功能和模块的确立和策划活动。因此，项目小组每个成员、客户甚至开发方的部门经理（根据项目大小而定）的参与是必要的。项目管理者在需求分析中的职责包括以下几个方面：

1. 负责组织相关开发人员与用户一起进行需求分析。

2. 组织美术和技术骨干代表或全部成员（与用户讨论）编写《网站功能描述书（初稿）》文档。

3. 组织相关人员对《网站功能描述书（初稿）》进行反复讨论和修改，确定《网站功能描述书》正式文档。

4. 如果用户有这方面的能力或用户提出要求，项目管理者也可以指派项目成员参与，由用户编写和确定《网站功能描述书》文档。

5. 如果项目较大的话，最好有部门经理或其授权的人员参与到《网站功能描述书》的确定过程中。

二、完整的需求调查文档记录体系

在整个需求分析过程中，按照一定规范编写需求分析的相关文档，不仅可以帮助项目成员将需求分析结果更加明确化，也为以后开发过程中做到了现实文本形式的备忘，并有助于公司日后的开发项目提供有益的借鉴和模范，成为公司在项目开发中积累的符合自身特点的经验财富。需求分析中需要编写的文档主要是《网站功能描述书》，它是整个需求分析活动的结果性文档，也是开发工程中项目成员主要可供参考的文档。为了更清楚地描述《网站功能描述书》，往往还需要编写《用户调查报告》和《市场调研报告》文档来辅助说明。各种文档最好有一定的规范和固定格式，以便增加其可阅读性和方便阅读者快速理解文档内容，相关规定将在本文后面讨论。

三、向用户调查些什么

在需求分析过程中，往往有很多不明确的用户需求，这时项目负责人需要调查用户的实际情况，明确用户需求。一个理想的用户调查活动需要用户的充分配合，并可能需要对调查对象进行必要的培训。因此，调查的计划安排（时间、地点、参加人员、调查内容）都需要项目负责人和用户的共同认可。调查的形式可以是：发放需求调查表、召开需求调查座谈会或现场调研。调查的内容主要包括：

1. 网站当前以及日后可能出现的功能需求。

2. 客户对网站性能（如访问速度）的要求和可靠性要求。

3. 确定网站维护的要求。

4. 网站的实际运行环境。

5. 网站页面总体风格以及美工效果（必要时用户可以提供参考站点或由公司向用户提供）。

6. 主页面和次级页面数量，是否需要多种语言版本等。

7. 内容管理及录入任务的分配。

8. 各种页面特殊效果及其数量（js、flash等）。

9. 项目完成时间及进度（可根据合同）。

10. 明确项目完成后的维护责任。

调查结束后，需要编写《用户调查报告》，《报告》的要点包括：

1. 调查概要说明：网站项目名称、用户单位、参与调查人员、调查开始终止时间、调查工作安排。

2. 调查内容说明：用户的基本情况、用户的主要业务、信息化建设现状、网站当前和将来潜在的功能需求、性能需求、可靠性需求、实际运行环境、用户对新网站的期望等。

3. 调查资料汇编：将调查得到的资料分类汇总（如调查问卷、会议记录等）。

四、市场调研活动内容

通过市场调研活动，清晰分析相似网站的性能和运行情况，可以帮助项目负责人更清楚地构想出自己开发的网站的大体架构和模样，在总结同类网站优势和缺点的同时，项目开发人员可以博采众长开发出更加优秀的网站。但由于实际中时间、经费、公司能力所限，市场调研覆盖的范围有一定的局限性。在调研市场同类网站时，应尽可能调研到所有比较出名和优秀的同类网站。应该了解同类网站的使用环境与用户的差异点、类似点，同类产品所定义的用户详细需求（需要公司或项目负责人有一定的关系）。市场调研的重点应该放在主要竞争对手的作品或类似网站作品的有关信息上。市场调研可以包括以下内容：

1. 市场中同类网站作品的确定。

2. 调研作品的使用范围和访问人群。

3. 调研产品的功能设计（主要模块构成、特色功能、性能情况等）。

4. 简单评价所调研的网站情况。

调研的目的是明确并引导用户需求。对市场同类产品调研结束后，应撰写《市场调研报告》，主要包括以下要点：

1. 调研概要说明：调研计划、网站项目名称、调研单位、参与调研、调研开始终止时间。

2. 调研内容说明：调研的同类网站作品名称、网址、设计公司、网站相关说明、开发背景、主要适用访问对象、功能描述、评价等。

3. 可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、可采用的原因。

4. 不可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、不可采用的原因。

5. 分析同类网站作品和主要竞争对手产品的弱点和缺陷以及本公司产品在这些方面的优势。

6. 调研资料汇编：将调研得到的资料进行分类汇总。

一个网站项目的设立依托于各式各样的需求，此类需求通常源自客户的实际需求或公司自身发展的需求，其中客户的实际需求，即交易性质的需求占据了绝大多数。面对对网站开发知识层次不同的客户，项目负责人对用户需求的理解程度，在很大程度上决定了此类网站开发项目的成败。因此，如何更好地了解、分析、明确用户需求，并能准确、清晰地以文档形式传达给参与项目开发的每个成员，确保开发过程按照满足用户需求为目的的正确项目开发方向进行，是每个网站开发项目管理者需要面对的问题。针对这个问题，本文想提出自己的一些看法和建议，希望各位读者批评指正：

一、哪些人应该参与网站开发项目的需求分析活动

需求分析活动实际上就是一个与客户沟通，正确引导客户能够将自己的实际需求用较为适当的技术语言进行表达（或者由相关技术人员帮助表达）以明确项目目的的过程。这个过程中也同时包含了对要建立的网站基本功能和模块的确立和策划活动。因此，项目小组每个成员、客户甚至是开发方的部门经理（根据项目大小而定）的参与是必要的。而项目的管理者在需求分析中的职责有如下几个方面：

1. 负责组织相关开发人员与用户一起进行需求分析。
2. 组织美术和技术骨干代表或者全部成员（与用户讨论）编写《网站功能描述书（初稿）》文档。
3. 组织相关人员对《网站功能描述书（初稿）》进行反复讨论和修改，确定《网站功能描述书》正式文档。
4. 如果用户有这方面的能力或者用户提出要求，项目管理者也可以指派项目成员参与，而由用户编写和确定《网站功能描述书》文档。
5. 如果项目比较大的话，最好能够有部门经理或者他授权的人员参与到《网站功能描述书》的确定过程中来。

二、完整的需求调查文档记录体系

在整个需求分析的过程中，按照一定规范的编写需求分析的相关文档，不仅可以帮助项目成员将需求分析结果更加明确化，也为以后开发过程中做到了现实文本形式的备忘，并且有助于公司日后的开发项目提供有益的借鉴和模范，成为公司在项目开发中积累的符合自身特点的经验财富。需求分析中需要编写的文档主要是《网站功能描述书》，它基本上是整个需求分析活动的结果性文档，也是开发工程中项目成员主要可供参考的文档。为了更加清楚地描述《网站功能描述书》，往往还需要编写《用户调查报告》和《市场调研报告》文档来辅助说明。各种文档最好有一定的规范和固定格式，以便增加其可阅读性和方便阅读者快速理解文档内容，相关规定将在本文后面讨论。

三、向用户调查些什么

在需求分析的工程中，往往有很多不明确的用户需求，这个时候项目负责人需要调查用户的实际情况，明确用户需求。一个比较理想化的用户调查活动需要用户的充分配合，而且还有可能需要对调查对象进行必要的培训。因此，调查的计划安排：时间、地点、参加人员、调查内容，都需要项目负责人和用户的共同认可。调查的形式可以是：发需求调查表、开需求调查座谈会或者现场调研。调查的内容主要如下：

1. 网站当前以及日后可能出现的功能需求。
2. 客户对网站的性能（如访问速度）的要求和可靠性的要求。
3. 确定网站维护的要求。
4. 网站的实际运行环境。
5. 网站页面总体风格以及美工效果（必要的时候用户可以提供参考站点或者由公司向用户提供）。
6. 主页面和次级页面数量，是否需要多种语言版本等。
7. 内容管理及录入任务的分配。
8. 各种页面特殊效果及其数量（js,flash等）。
9. 项目完成时间及进度（可以根据合同）。
10. 明确项目完成后的维护责任。

调查结束后，需要编写《用户调查报告》，《报告》的要点是：

1. 调查概要说明：网站项目的名称；用户单位；参与调查人员；调查开始终止的时间；调查的工作安排。
2. 调查内容说明：用户的基本情况；用户的主要业务；信息化建设现状；网站当前和将来潜在的功能需求、性能需求、可靠性需求、实际运行环境；用户对新网站的期望等。
3. 调查资料汇编：将调查得到的资料分类汇总（如调查问卷，会议记录等等）。

四、市场调研活动内容

通过市场调研活动，清晰分析相似网站的性能和运行情况，可以帮助项目负责人更加清楚地构想出自己开发的网站的大体架构和模样，在总结同类网站优势和缺点的同时，项目开发人员可以博采众长开发出更加优秀的网站。但是由于实际中时间、经费、公司能力所限，市场调研覆盖的范围有一定的局限性，在调研市场同类网站的时候，应尽可能调研到所有比较出名和优秀的同类网站。应该了解同类网站的使用环境与用户的差异点、类似点，同类产品所定义的用户详细需求（需要公司或者项目负责人有一定的关系）。市场调研的重点应该放在主要竞争对手的作品或类似网站作品的有关信息上。市场调研可以包括下列内容：

1. 市场中同类网站作品的确定。
2. 调研作品的使用范围和访问人群。
3. 调研产品的功能设计（主要模块构成，特色功能，性能情况等等）。
4. 简单评价所调研的网站情况。

调研的目的是明确并且引导用户需求。对市场同类产品调研结束后，应该撰写《市场调研报告》主要包括以下要点：

1. 调研概要说明：调研计划；网站项目名称、调研单位、参与调研、调研开始终止时间。
2. 调研内容说明：调研的同类网站作品名称、网址、设计公司、网站相关说明、开发背景、主要适用访问对象、功能描述、评价等。
3. 可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、可采用的原因。
4. 不可采用借鉴的调研网站的功能设计：功能描述、用户界面、性能需求、不可采用的原因。
5. 分析同类网站作品和主要竞争对手产品的弱点和缺陷以及本公司产品在这些方面的优势。
6. 调研资料汇编：将调研得到的资料进行分类汇总。

五、明确的需求分析成果——《网站功能说明书》在受到前期公司与客户签订的合同或标书的约束之下，通过较为细致具体的用户调研和市场研究活动，参考其输出的《用户调研报告》和《市场研究报告》文件，项目负责人应对整个需求分析活动进行细致的总结，将分析前期模糊的需求一一明确化，并输出一份详尽清晰的总结性文件——《网站功能说明书（最终版）》作为未来项目开发过程中的参考。《网站功能说明书》必须包括以下内容：1、网站功能2、网站用户界面（初步）3、网站运行的软硬件环境4、网站系统性能规范5、网站系统的软硬件接口6、确定网站维护的要求7、确定网站系统空间租赁需求8、网站页面整体风格及美术效果。9、主页面及次页面大概数量。10、管理及内容录入任务分配。11、各种页面特殊效果及其数量。12、项目完成时间及进度（根据合同）13、明确项目完成后的维护责任。综上所述，在网站项目的需求分析中，主要由项目负责人确定对用户需求的理解程度，而用户调研和市场研究等需求分析活动的目的就是帮助项目负责人加深对用户需求的理解，并对前期模糊的地方进行明确化，以便于未来在项目开发过程中作为开发成员的参考。

当然，一次成功的需求分析不仅需要项目负责人甚至是客户等所有项目相关人员的共同努力，还与公司的能力范围有关。需要指出的是，本文所述的需求分析活动内容是基于较为理想的基础。由于各个公司实际情况的不同，读者可以根据自身情况选择性地借鉴吸收利用。重要的是能根据本公司的情况，系统地规范此类文档，做好保存和收集，相信这对公司未来其他网站项目的进行以及公司自身实力的提升都会有很大帮助。

星想互联，一家专注于网站建设与SEO优化推广的网站

如何高效进行网站开发项目需求分析

从广义上理解：需求分析包括需求的收集、分析、规格说明、变更、验证、管理等一系列需求工程。

从狭义上理解需求分析指的是需求的分析、定义过程。

原因

需求分析就是分析软件用户的需求是什么。如果投入大量的人力、物力、财力、时间，开发出的软件却无人问津，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发，这种返工是让人痛心疾首的（相信大家都有体会）。比如：用户需要一个适用于Linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然地认为是开发适用于Windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。

需求分析之所以重要，就因为它具有决策性、方向性、策略性的作用，它在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析有足够的重视。在一个大型软件系统的开发中，它的作用要远远大于程序设计。

任务

简言之，需求分析的任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求。

过程

需求分析阶段的工作可以分为四个方面：问题识别、分析与综合、制订规格说明书、评审。

问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求（软件运行所需的内存、CPU等）、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。

分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析它们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的模型）。

制订规格说明书：即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。

评审：对功能的正确性、完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作，否则重新进行需求分析。

方法

需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从未使用过这些方法在此不讨论。

原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。

原型化方法就是尽可能快地构建一个粗糙的系统，这个系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。构建这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的需求，可以用某些软件工具快速地构建一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。

原型主要有三种类型：探索型、实验型、进化型。

探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。

实验型：用于大规模开发和实现前，检验方案是否合适，规格说明是否可靠。

进化型：目的不在于改进规格说明，而是将系统构建得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

演变型：其目标并非在于优化规格说明，而是构建一个易于调整的系统，在逐步完善原型的过程中，逐步将其发展成为最终系统。

在应用原型化方法时，存在两种不同的策略：舍弃策略、增补策略。

舍弃策略：首先构建一个功能单一且质量要求不高的模型系统，针对该系统进行反复修改，形成良好的思路，据此设计出较为完整、精确、统一、可靠的最终系统。系统构建完成后，原来的模型系统将被舍弃。探索型和实验型属于此类策略。

增补策略：首先构建一个功能单一且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充和修改，逐步增补新要求，最终发展成为最终系统。演变型属于此类策略。

需求分析20条准则

客户与开发人员之间的沟通需要有效的手段。以下提供20条准则，客户和开发人员可以通过评审以下内容并达成共识。若出现分歧，将通过协商达成对各自义务的相互理解，以减少未来的摩擦（如一方要求而另一方不愿意或无法满足要求）。

1、分析人员应使用符合客户语言习惯的表达

需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员需了解客户的业务及目标

只有分析人员更好地了解客户的业务，才能使产品更好地满足需求。这将有助于开发人员设计出真正满足客户需求并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下旧系统，有利于他们明白系统是怎样工作的，其流程情况以及可供改进之处。

3、分析人员必须编写软件需求报告

分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、要求得到需求工作结果的解释说明

分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、开发人员要尊重客户的意见

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、开发人员要对需求及产品实施提出建议和解决方案

通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、描述产品使用特性

客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、允许重用已有的软件组件

需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、要求对变更的代价提供真实可靠的评估

有不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、获得满足客户功能和质量要求的系统

每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、向分析人员讲解您的业务

分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

分析人员需依赖客户阐述业务观念及术语，但客户不宜期待分析人员能成为该领域的专家，而仅需让他们理解您的问题和目标；不宜期望分析人员能洞察客户业务的微妙潜在之处，他们可能不了解那些对客户而言显而易见的“常识”。

12、预留时间清晰阐述并完善需求

客户虽忙碌，但无论如何客户需抽出时间参与“头脑风暴会议”的讨论，接受访谈或其他获取需求的活动。有些分析人员可能先理解了您的观点，而过后发现还需您的解释，这时请耐心对待一些需求和需求的细化工作过程中的反复，因为这是人们交流中很自然的现象，何况这对软件产品的成功至关重要。

13、精确而详尽地阐述需求

编写一份清晰、精确的需求文档是困难的。由于处理细节问题既繁琐又耗时，因此很容易留下模糊不清的需求。但在开发过程中，必须解决这种模糊性和不准确性，而客户正是为解决这些问题作出决策的最佳人选，否则，就只能依赖开发人员去正确猜测了。

在需求分析中暂时标注“待定”是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写入“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以与开发人员一起反复修改，不断完善需求定义。

14、及时作出决策

分析人员会要求客户作出一些选择和决策，这些决策包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决策的客户必须积极地对待这一切，尽快做出处理，做出决策，因为开发人员通常只有等客户做出决策才能行动，而这种等待会延误项目的进展。

15、尊重开发人员的需求可行性和成本评估

所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

16、确定需求的优先级

绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

17、审查需求文档和原型

客户审查需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

18、需求变更需立即通知

不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

19、遵循开发小组处理需求变更的程序

为将变更带来的负面影响减少到最低限度，所有参与者必须遵循项目变更控制程序。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

20、尊重开发人员采用的需求分析过程

软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

这两种看法都是不恰当的。因为无法在项目初期就完全掌握所有需求，而且需求肯定会出现变动。在“需求分析报告”上签字确认是结束需求分析流程的正确做法，因此我们必须清楚签字的含义。

对“需求分析报告”的签署建立在需求协议的基础之上，因此我们应当这样理解签署的意义：“我认可这份需求文件反映了我们对项目软件需求的认知，后续的变更可以在这一基础上，依照项目规定的变更流程进行。我明白变更可能会导致我们重新协商成本、资源以及项目阶段任务等相关事宜。”就需求分析达成共识能够使双方更容易接受未来的分歧，这些分歧可能源于项目的优化、需求的偏差或市场及业务的新需求等。