软件项目需求分析阶段的知识和管理

1、第第5章章 软件项目需求分析阶段的软件项目需求分析阶段的知识和管理知识和管理本章要点： 需求分析是软件项目的立足之本 需求分析的工作内容 需求分析阶段的团队组织 需求分析阶段的项目管理 需求获取的方法和特点 需求分析方法和建模工具 需求分析阶段性成果和考核依据 软件需求分析阶段工作的基本任务就是软件需求分析阶段工作的基本任务就是要准确回答要准确回答“用户真正需要一个什么样的软用户真正需要一个什么样的软件系统件系统?该软件系统必须完成什么功能该软件系统必须完成什么功能?”。 需求分析阶段将对软件系统提出完整、准需求分析阶段将对软件系统提出完整、准确、清晰、具体的要求。确、清晰、具体的要求。5.1

2、 需求分析是软件项目的立足之本需求分析是软件项目的立足之本 需求分析是整个软件项目开展工作的基需求分析是整个软件项目开展工作的基础，需求分析质量的好坏，直接关系到软件础，需求分析质量的好坏，直接关系到软件项目交付成果的客户满意度，甚至整个项目项目交付成果的客户满意度，甚至整个项目的成败。如果需求分析工作做的不扎实，无的成败。如果需求分析工作做的不扎实，无论设计阶段工作完成得如何出色、软件编码论设计阶段工作完成得如何出色、软件编码质量如何高，其结果将只会给用户带来失望，质量如何高，其结果将只会给用户带来失望，给开发者带来失败的苦恼。给开发者带来失败的苦恼。5.2 需求分析的工作内容需求分析的工作

3、内容5.2.1需求分析的目标、内容和任务需求分析的目标、内容和任务 目标目标 获取完整、准确的用户需求；获取完整、准确的用户需求； 充分理解、认识和分析用户的需求；充分理解、认识和分析用户的需求； 采用需求建模方法编写需求规格说明，采用需求建模方法编写需求规格说明，为开展整个软件项目的连续工作提供详细的为开展整个软件项目的连续工作提供详细的任务要求，为开发者和用户提供软件项目成任务要求，为开发者和用户提供软件项目成果质量评价的重要依据。果质量评价的重要依据。 工作内容工作内容 刻画出软件的功能和性能、指明软件刻画出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满和其他系统元素的

4、接口、并建立软件必须满足的约束条件；足的约束条件； 分解软件系统模块，建造将被软件处分解软件系统模块，建造将被软件处理的数据、功能和行为模型，为软件设计者理的数据、功能和行为模型，为软件设计者提供了可被翻译成数据、体系结构、界面和提供了可被翻译成数据、体系结构、界面和处理流程的设计模型；处理流程的设计模型； 提交需求规格说明书，形成软件项目提交需求规格说明书，形成软件项目管理过程的第一个里程碑成果。管理过程的第一个里程碑成果。 任务任务 问题分析问题分析 (即如何获取需求即如何获取需求 )、需求描述、需求描述(即如何定义需求即如何定义需求)和需求验证。和需求验证。 问题分析问题分析 需求分析人

5、员通过对问题及其环境的理需求分析人员通过对问题及其环境的理解、分析和综合，消除用户需求的模糊性、解、分析和综合，消除用户需求的模糊性、歧义性和不一致性。歧义性和不一致性。 系统分析人员应该将自己对客户需求及系统分析人员应该将自己对客户需求及问题的理解与自己所拥有的软件开发经验结问题的理解与自己所拥有的软件开发经验结合起来，以便发现哪些要求是由于用户的片合起来，以便发现哪些要求是由于用户的片面理解和短期行为所提出的不合理的要求，面理解和短期行为所提出的不合理的要求，哪些要求是尚未提出但具有真正价值的潜在哪些要求是尚未提出但具有真正价值的潜在需求。需求。 由于用户群中每个用户的出发点不同，由于用户

6、群中每个用户的出发点不同，思考问题的角度也有所区别，从不同的应用思考问题的角度也有所区别，从不同的应用层面阐述对原始问题的理解和对目标系统的层面阐述对原始问题的理解和对目标系统的要求，因此，有必要对原始问题及其软件求要求，因此，有必要对原始问题及其软件求解建立模型。解建立模型。 这种模型一方面用于精确记录用户从不这种模型一方面用于精确记录用户从不同的角度、在不同的抽象级别对原始问题和同的角度、在不同的抽象级别对原始问题和软件要求的描述；另一方面，它也将帮助分软件要求的描述；另一方面，它也将帮助分析人员发现用户需求中的不一致性，排除不析人员发现用户需求中的不一致性，排除不合理的部分，挖掘潜在的用

7、户需求。合理的部分，挖掘潜在的用户需求。 这种模型是分析人员对于原始问题及其这种模型是分析人员对于原始问题及其软件理解的一种知识结构。这种结构往往包软件理解的一种知识结构。这种结构往往包含问题及其环境所涉及的信息流、处理功能、含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束。它是需求用户界面、行为模型及设计约束。它是需求规格说明书、软件设计和实现的主要基础。规格说明书、软件设计和实现的主要基础。 (2)需求描述 以需求模型为基础，考虑问题的软以需求模型为基础，考虑问题的软件可解性，生成需求规格说明书件可解性，生成需求规格说明书。 需求规格说明书包含对目标系统外需求规格说明书

8、包含对目标系统外部行为的完整描述、需求验证标准以及部行为的完整描述、需求验证标准以及用户对系统在性能、质量、可维护性等用户对系统在性能、质量、可维护性等方面的要求。方面的要求。 (3)需求验证需求验证 分析人员在用户和软件设计人员的配合分析人员在用户和软件设计人员的配合下对生成的需求规格说明进行复核，以确保下对生成的需求规格说明进行复核，以确保软件需求的全面性、精确性、一致性、可行软件需求的全面性、精确性、一致性、可行性。性。 并使用户和软件设计人员对需求规格说并使用户和软件设计人员对需求规格说明及用户手册的理解达成共识，达成对目标明及用户手册的理解达成共识，达成对目标系统理解的一致性。系统理

9、解的一致性。 问题分析、需求描述和需求验证并不遵问题分析、需求描述和需求验证并不遵循线性顺序，这些活动是相互渗透、增量并循线性顺序，这些活动是相互渗透、增量并行和连续反复的。包括四个过程：行和连续反复的。包括四个过程： 第一，系统分析员和用户开展面对面的第一，系统分析员和用户开展面对面的交流，记录用户提供的信息，即开展获取活交流，记录用户提供的信息，即开展获取活动；动； 第二，需求分析员处理从用户那里获取第二，需求分析员处理从用户那里获取的信息并理解它们，把它们分成不同的类别，的信息并理解它们，把它们分成不同的类别，并将客户需求同可能的软件需求相联系，即并将客户需求同可能的软件需求相联系，即开

10、展需求分析活动；开展需求分析活动； 第三，系统分析人员将客户需求信息结第三，系统分析人员将客户需求信息结构化，编写成文档和示意图，形成需求规格构化，编写成文档和示意图，形成需求规格说明书；说明书； 最后，组织用户代表评审文档，并纠正最后，组织用户代表评审文档，并纠正存在的错误，完成需求的验证工作。存在的错误，完成需求的验证工作。 这四个过程循环往复，渗透到客户业务这四个过程循环往复，渗透到客户业务系统的各个环节，贯穿于需求分析的整个工系统的各个环节，贯穿于需求分析的整个工作过程中，直到项目组人员与客户在对目标作过程中，直到项目组人员与客户在对目标系统的功能、流程、接口、数据、操作等多系统的功能

11、、流程、接口、数据、操作等多方面内容达成共识后，方可宣布需求分析任方面内容达成共识后，方可宣布需求分析任务的结束。务的结束。 需求还有可能再发生变动，此时需求分需求还有可能再发生变动，此时需求分析的结束，只是标志客户需求在一定时期内析的结束，只是标志客户需求在一定时期内的的“相对锁定相对锁定”，这对整个项目未来工作的，这对整个项目未来工作的开展非常重要。开展非常重要。5.2.2需求分析的工作模式需求分析的工作模式 需求分析在通常情况下划分为三个阶段。需求分析在通常情况下划分为三个阶段。 第一阶段：第一阶段：“访谈式访谈式”(Visitation) 这一阶段是和具体用户方的领导层、业这一阶段是和

12、具体用户方的领导层、业务层人员进行访谈式沟通，主要目的是从务层人员进行访谈式沟通，主要目的是从上把握用户的具体需求，了解现有的组织上把握用户的具体需求，了解现有的组织架构、业务流程、硬件环境、软件环境、现架构、业务流程、硬件环境、软件环境、现有系统等具体情况，建立起良好的沟通渠道有系统等具体情况，建立起良好的沟通渠道和方式。和方式。 实现手段：访谈、发放调查表实现手段：访谈、发放调查表 成果：调查报告、业务流程报告成果：调查报告、业务流程报告 第二阶段：第二阶段：“诱导式诱导式”(1nducement) 在分析人员已经了解了具体用户方的组在分析人员已经了解了具体用户方的组织架构、业务流程、硬件

13、环境、软件环境、织架构、业务流程、硬件环境、软件环境、现有的运行系统等信息的基础上，作出简单现有的运行系统等信息的基础上，作出简单的用户流程和操作界面，同时结合以往的项的用户流程和操作界面，同时结合以往的项目经验对用户采用诱导式、启发式的调研方目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的法和手段，和用户一起探讨业务流程设计的合理性、准确性、方便性、习惯性和易操作合理性、准确性、方便性、习惯性和易操作性。性。 实现手段：拜访（诱导）、实现手段：拜访（诱导）、DEMO演示演示 输出成果：调研分析报告、原型反馈报输出成果：调研分析报告、原型反馈报告、业务流程报告。告、

14、业务流程报告。 第三阶段：第三阶段：“确认式确认式”(Affirm) 进行具体的流程细化、数据项的确认阶进行具体的流程细化、数据项的确认阶段。段。 分析人员需要完成明确的业务流程报告、分析人员需要完成明确的业务流程报告、数据项描述、修改后的数据项描述、修改后的DEMO系统及业务流系统及业务流设计目标。设计目标。 用户方审查业务流程报告、数据项描述用户方审查业务流程报告、数据项描述以及通过操作开发方提供的以及通过操作开发方提供的DEMO系统，提系统，提出反馈意见，并对已经完成并可接受的报告、出反馈意见，并对已经完成并可接受的报告、文档签字确认。文档签字确认。 实现手段：拜访实现手段：拜访(回顾、

15、确认回顾、确认)，提交业务，提交业务流程报告、数据项描述；流程报告、数据项描述；DEMO演示系统。演示系统。 输出成果：需求分析报告输出成果：需求分析报告 5.3 需求分析阶段的团队组织需求分析阶段的团队组织5.3.1团队组织与建设团队组织与建设 需求分析作为软件开发生命周期的第一需求分析作为软件开发生命周期的第一个里程碑，它的内容贯穿于整个软件生命周个里程碑，它的内容贯穿于整个软件生命周期全过程，是一个需要团队成员高度配合和期全过程，是一个需要团队成员高度配合和密切协作的阶段。密切协作的阶段。 需求分析阶段参与项目的人员及工作职需求分析阶段参与项目的人员及工作职责如下：责如下： (1)项目经

16、理：负责需求分析阶段项目进项目经理：负责需求分析阶段项目进度的安排和控制；参与项目的各种资源调度；度的安排和控制；参与项目的各种资源调度；负责项目的总体协调工作。负责项目的总体协调工作。 (2)系统分析人员：与用户方的技术人员系统分析人员：与用户方的技术人员和业务人员进行良好的沟通，了解业务流程、和业务人员进行良好的沟通，了解业务流程、功能需求、系统构想和项目目标，完成软件功能需求、系统构想和项目目标，完成软件需求说明书的编制任务。需求说明书的编制任务。 (3)程序员：在采用原型法的系统分析过程序员：在采用原型法的系统分析过程中，程序员参与用户的需求分析过程，根程中，程序员参与用户的需求分析过

17、程，根据用户的实际需求，完成原型系统的开发工据用户的实际需求，完成原型系统的开发工作。作。 (4)质量管理人员：负责组织有关人员完质量管理人员：负责组织有关人员完成对需求分析工作的质量审核和需求说明书成对需求分析工作的质量审核和需求说明书的评审工作。的评审工作。 (5)配置管理人员：把通过评审的需求说配置管理人员：把通过评审的需求说明书纳入软件的配置管理项。明书纳入软件的配置管理项。 (6)用户方的技术人员：用户方参与项目用户方的技术人员：用户方参与项目的技术人员的技术人员(往往是计算中心的工作人员，未往往是计算中心的工作人员，未来工作是维护系统来工作是维护系统)，通过与系统分析人员的，通过与

18、系统分析人员的沟通，确定系统的技术实现方案。要求该人沟通，确定系统的技术实现方案。要求该人员具有对需求说明书中系统技术方案的最终员具有对需求说明书中系统技术方案的最终签字认可权。签字认可权。 (7)用户方的业务人员：用户方参与项目用户方的业务人员：用户方参与项目的业务人员，经过与系统分析人员的沟通，的业务人员，经过与系统分析人员的沟通，确定未来软件系统实现的具体功能和业务模确定未来软件系统实现的具体功能和业务模型。要求该类人员对需求说明书中的业务需型。要求该类人员对需求说明书中的业务需求具有最终签字认可的权利。求具有最终签字认可的权利。 图5-4为需求分析阶段典型的团队组织模型。 需求分析涉及

19、的单位、组织和人员主要需求分析涉及的单位、组织和人员主要包括两大类，一类是用户方，一类是开发方。包括两大类，一类是用户方，一类是开发方。 双方参与需求分析阶段工作的人员在各双方参与需求分析阶段工作的人员在各自项目经理的领导和协调下开展工作，并分自项目经理的领导和协调下开展工作，并分别与对方项目人员进行充分的沟通和交流；别与对方项目人员进行充分的沟通和交流；双方项目人员之间协调不了的事情由双方项双方项目人员之间协调不了的事情由双方项目经理进行协调，项目经理协调不了的事情目经理进行协调，项目经理协调不了的事情交项目委员会协调。交项目委员会协调。 整个软件需求分析阶段的团队组织是按整个软件需求分析阶

20、段的团队组织是按照项目管理中典型的矩阵式结构来开展，能照项目管理中典型的矩阵式结构来开展，能够有效地利用项目资源，增加了沟通的机会，够有效地利用项目资源，增加了沟通的机会，充分发挥项目人员的积极性。充分发挥项目人员的积极性。5.3.2团队管理团队管理 本阶段的团队管理包含项目参与双方团本阶段的团队管理包含项目参与双方团队的管理工作。队的管理工作。 团队管理的特点有：团队管理的特点有： (1)团队成员能力的要求团队成员能力的要求 具有良好的沟通及协作能力是对项目所具有良好的沟通及协作能力是对项目所有参与人员的共同要求。有参与人员的共同要求。 对开发方需求分析人员，需要具备丰富对开发方需求分析人员

21、，需要具备丰富的需求分析经验、良好的业务知识。切忌承的需求分析经验、良好的业务知识。切忌承担分析任务的分析人员既是新手，又不熟悉担分析任务的分析人员既是新手，又不熟悉业务知识业务知识 对用户方人员来说，技术人员要具备良对用户方人员来说，技术人员要具备良好的技术背景，熟悉本单位的计算机系统及好的技术背景，熟悉本单位的计算机系统及网络状况。业务人员需要具有丰富的业务知网络状况。业务人员需要具有丰富的业务知识，熟悉各种业务的处理流程及结果形式。识，熟悉各种业务的处理流程及结果形式。 (2)明确划分双方的职责明确划分双方的职责 在需求分析阶段开始时，要明确项目双在需求分析阶段开始时，要明确项目双方在合

22、作中的权利和义务，形成正式的项目方在合作中的权利和义务，形成正式的项目协作文件。协作文件。 为了避免用户方工作人员不愿意积极参为了避免用户方工作人员不愿意积极参与需求调研过程，或对需求分析的工作不重与需求调研过程，或对需求分析的工作不重视的现象，对需求分析结果，用户方必须签视的现象，对需求分析结果，用户方必须签字确认。字确认。 (3)团队矛盾及问题的防范及解决办法团队矛盾及问题的防范及解决办法 需求分析阶段容易发生的矛盾与问题主需求分析阶段容易发生的矛盾与问题主要是系统分析人员与用户的工作配合上。要是系统分析人员与用户的工作配合上。 例如：由于种种原因，用户借工作忙，例如：由于种种原因，用户借

23、工作忙，使需求调研工作一拖再拖；或用户拒绝对各使需求调研工作一拖再拖；或用户拒绝对各项需求分析结果进行签字确认等；或是双方项需求分析结果进行签字确认等；或是双方工作方式上的不恰当，造成工作配合上的矛工作方式上的不恰当，造成工作配合上的矛盾和摩擦等。盾和摩擦等。 可采用以下办法加以防范和解决：可采用以下办法加以防范和解决： 1)明确各自的责任和义务明确各自的责任和义务 2)树立共同的项目目标和成功意识树立共同的项目目标和成功意识 3)增加友谊增加友谊 4)出现问题尽量在小范围内自行协调解出现问题尽量在小范围内自行协调解决决 5)组织项目协调会议组织项目协调会议5.4 需求分析阶段的项目管理需求分

24、析阶段的项目管理5.4.1需求分析阶段的进度管理与控制需求分析阶段的进度管理与控制 做好需求分析阶段的进度管理工作，需做好需求分析阶段的进度管理工作，需要做好以下几个方面的工作：要做好以下几个方面的工作： (1)详细的工作计划和明确的责任分工详细的工作计划和明确的责任分工 由于需求分析阶段项目双方工作协作较由于需求分析阶段项目双方工作协作较多，容易出现配合上的矛盾和问题。所以，多，容易出现配合上的矛盾和问题。所以，在需求分析阶段开始时，双方的项目经理要在需求分析阶段开始时，双方的项目经理要进行沟通，制定本阶段详细的工作计划、参进行沟通，制定本阶段详细的工作计划、参与人员的工作分工及职责。与人员

25、的工作分工及职责。 计划主要包括：计划主要包括： 本阶段详细的进度计划安排；本阶段详细的进度计划安排； 项目参与双方参与人员的工作分派及项目参与双方参与人员的工作分派及职责要求；职责要求； 双方人员的工作时间约定、工作内容双方人员的工作时间约定、工作内容及工作时间的保证要求；及工作时间的保证要求； 在项目协作过程中双方工作人员的工在项目协作过程中双方工作人员的工作流程约定、问题及其解决流程约定等。作流程约定、问题及其解决流程约定等。 计划完成后，要形成正式的书面文件。计划完成后，要形成正式的书面文件。双方项目经理签字认可后下发执行。双方项目经理签字认可后下发执行。 (2)合理的需求调研和科学的

26、工作安排合理的需求调研和科学的工作安排 较为理想的需求调研步骤为：较为理想的需求调研步骤为： 首先与用户方的技术人员交流，确定系统首先与用户方的技术人员交流，确定系统实现的技术方面的需求，即技术实现的架构实现的技术方面的需求，即技术实现的架构与要求。与要求。 接下来再与业务人员交流，获取详细的业接下来再与业务人员交流，获取详细的业务需求。在业务需求的调研过程中，应先确务需求。在业务需求的调研过程中，应先确定系统的主要功能要求，再在此基础上逐步定系统的主要功能要求，再在此基础上逐步进行需求细化工作。进行需求细化工作。 (3)有效遏制需求变更有效遏制需求变更 需求分析阶段用户需求的变更主要表现为需

27、求分析阶段用户需求的变更主要表现为用户需求的反复，容易使需求分析工作原地用户需求的反复，容易使需求分析工作原地转圈，无法按计划完成需求分析工作。转圈，无法按计划完成需求分析工作。 要遏制分析阶段的需求变更，通常采用的要遏制分析阶段的需求变更，通常采用的办法有以下几种：办法有以下几种： 1)充分到位的需求调研。充分到位的需求调研。 详细周密的需求分析，以及对用户需求详细周密的需求分析，以及对用户需求的深层次挖掘等工作，是保证高质量需求分的深层次挖掘等工作，是保证高质量需求分析工作的基础，也是防止需求变更的基本手析工作的基础，也是防止需求变更的基本手段。段。 2)用户签字制度。用户签字制度。 签字

28、的办法可以使用户在需求调研中以签字的办法可以使用户在需求调研中以积极负责的态度，认真对待每个需求分析项。积极负责的态度，认真对待每个需求分析项。这样做可有效遏制需求的反复。这样做可有效遏制需求的反复。 3)定期的工作通报制度。定期的工作通报制度。 开发方项目经理要定期将需求分析阶段开发方项目经理要定期将需求分析阶段的工作进展情况、存在的问题进行汇总，向的工作进展情况、存在的问题进行汇总，向项目双方的高层领导、项目管理委员会进行项目双方的高层领导、项目管理委员会进行工作通报。工作通报。 4)对签字认可后的需求纳入需求管理，对签字认可后的需求纳入需求管理，对发生的需求变更，执行需求变更处理流程。对

29、发生的需求变更，执行需求变更处理流程。 (4)确保与用户沟通的深度和广度确保与用户沟通的深度和广度 所谓深度是指分析人员在需求调查的过所谓深度是指分析人员在需求调查的过程中，不但要与用户建立良好的工作关系，程中，不但要与用户建立良好的工作关系，甚至要努力去建立比较深厚的私人关系，拉甚至要努力去建立比较深厚的私人关系，拉近距离，便于沟通。只有这样才能更清楚的近距离，便于沟通。只有这样才能更清楚的了解用户的真实想法，获得用户的尊重和工了解用户的真实想法，获得用户的尊重和工作支持。作支持。 所谓广度就是在需求调研过程中要进行所谓广度就是在需求调研过程中要进行整体调研，需求调研要面向用户项目参与的整体

30、调研，需求调研要面向用户项目参与的全体人员。一方面是要了解用户的整体需求全体人员。一方面是要了解用户的整体需求细节；另一方面也可从不同人员各自的角度细节；另一方面也可从不同人员各自的角度了解用户方到底想要完成一个什么样的系统。了解用户方到底想要完成一个什么样的系统。 对于用户方的不同认识，分析人员可通对于用户方的不同认识，分析人员可通过召开项目协调会议的方法，协调并统一用过召开项目协调会议的方法，协调并统一用户方人员对相关需求的一致看法。户方人员对相关需求的一致看法。 (5)采取有效的需求调研方法采取有效的需求调研方法 分析人员要确保本阶段工作能够按计划分析人员要确保本阶段工作能够按计划执行，

31、首先需要分析在项目需求分析中的困执行，首先需要分析在项目需求分析中的困难和问题，并采用有针对性的需求调研方法。难和问题，并采用有针对性的需求调研方法。 (6)需求的复用需求的复用 在软件项目实施的过程中，许多不同项在软件项目实施的过程中，许多不同项目间的需求都有相似性，特别是对于同类型目间的需求都有相似性，特别是对于同类型项目在不同用户间的实施，需求之间的相似项目在不同用户间的实施，需求之间的相似性就更加普遍。所以，分析人员应该十分注性就更加普遍。所以，分析人员应该十分注意需求的复用。意需求的复用。 通过复用，用户形成了一个需求的原型，通过复用，用户形成了一个需求的原型，进而只需要对原型进行修

32、改和完善即可。进而只需要对原型进行修改和完善即可。 (7)需求分析的结束控制需求分析的结束控制 要做好需求验收工作，需要踏踏实实做要做好需求验收工作，需要踏踏实实做好需求分析的各阶段工作：好需求分析的各阶段工作： 1)通过项目的合同条款，做好项目的范通过项目的合同条款，做好项目的范围规划，明确项目的工作内容。围规划，明确项目的工作内容。 2)做好分析阶段的工作计划，明确工作做好分析阶段的工作计划，明确工作进度、人员分工及各自的工作职责。进度、人员分工及各自的工作职责。 3)做好各部分需求条款的签字验收工作做好各部分需求条款的签字验收工作及定期的工作总结与工作汇报。及定期的工作总结与工作汇报。

33、4)做好目标系统的介绍或原型系统的演做好目标系统的介绍或原型系统的演示。示。 在做好上述工作的基础上，才能确保需在做好上述工作的基础上，才能确保需求分析工作按进度、高质量地完成，需求阶求分析工作按进度、高质量地完成，需求阶段的验收工作也就可以顺利地进行。段的验收工作也就可以顺利地进行。5.4.2需求分析阶段的质量管理与控制需求分析阶段的质量管理与控制 高质量的需求最能真实反映用户的实际高质量的需求最能真实反映用户的实际要求，也将对整个项目的开展带来较少的变要求，也将对整个项目的开展带来较少的变更处理及较高的软件开发效率。更处理及较高的软件开发效率。 要得到高质量的需求分析，应做到以下要得到高质

34、量的需求分析，应做到以下几点：几点： (1)积极认真进行调研准备积极认真进行调研准备 分析人员在进行每一次需求调研前，要分析人员在进行每一次需求调研前，要认真做好调研前的准备工作：即要按照工作认真做好调研前的准备工作：即要按照工作计划设定需求调研主题；设计采用的需求调计划设定需求调研主题；设计采用的需求调研方式；可能的结果形式估计及每种结果的研方式；可能的结果形式估计及每种结果的应对措施等。应对措施等。 (2)正确理解用户的需求描述及非二异性的正确理解用户的需求描述及非二异性的需求文字记录需求文字记录 对于用户描述的软件需求，一方面分析对于用户描述的软件需求，一方面分析人员要正确理解，使项目双

35、方之间达成共识；人员要正确理解，使项目双方之间达成共识；另一方面，分析人员在进行记录或书写需求另一方面，分析人员在进行记录或书写需求说明书的时候，要表达准确，避免二异性描说明书的时候，要表达准确，避免二异性描述的出现。述的出现。 (3)做好各需求项的用户签字认可工作做好各需求项的用户签字认可工作 需求分析结果是项目验收的质量标准，需求分析结果是项目验收的质量标准，具有用户评审及验收签字的需求文档是最终具有用户评审及验收签字的需求文档是最终软件产品能否通过验收的关键。将需求分析软件产品能否通过验收的关键。将需求分析阶段的所有需求调研及会议讨论的结果形成阶段的所有需求调研及会议讨论的结果形成正式的

36、书面文件，经用户审核签字后，纳入正式的书面文件，经用户审核签字后，纳入需求管理。需求管理。 (4)做好需求的管理工作做好需求的管理工作 完成需求文档的版本控制及需求变更的完成需求文档的版本控制及需求变更的控制工作，一方面可使需求分析的结果可管控制工作，一方面可使需求分析的结果可管理，防止频繁的修改及内容混乱；另一方面理，防止频繁的修改及内容混乱；另一方面通过有效的管理也可提高软件需求文档的复通过有效的管理也可提高软件需求文档的复用率。用率。 (5)定期的会议交流和评审定期的会议交流和评审 通过定期召开项目交流会议，一方面可通过定期召开项目交流会议，一方面可将已获得的结果通报全体用户人员；另一方

37、将已获得的结果通报全体用户人员；另一方面将需求分析中的问题拿出来，供全体人员面将需求分析中的问题拿出来，供全体人员讨论，最终形成一致的结果。同时对已完成讨论，最终形成一致的结果。同时对已完成的需求结果进行用户的确认，形成的需求结果进行用户的确认，形成“相对锁相对锁定定”的用户需求。的用户需求。5.4.3需求分析阶段的沟通管理需求分析阶段的沟通管理 (1)沟通的主要目的沟通的主要目的 沟通的主要目的就是要准确、全面地了沟通的主要目的就是要准确、全面地了解用户的实际应用需求和理想目标。为最终解用户的实际应用需求和理想目标。为最终实现和满足用户的实际需求奠定良好的基础。实现和满足用户的实际需求奠定良

38、好的基础。 (2)沟通的技巧沟通的技巧 需求分析人员一方面不能有害怕用户的需求分析人员一方面不能有害怕用户的心理，应以一种积极、主动，将项目做好的心理，应以一种积极、主动，将项目做好的心态与用户进行沟通；另一方面要将需求调心态与用户进行沟通；另一方面要将需求调研看作是为了给用户解决问题，而不是来指研看作是为了给用户解决问题，而不是来指导工作的。导工作的。 在协作工作中，只有对别人尊重和理解，在协作工作中，只有对别人尊重和理解，才能换取别人的尊重和支持。同时在工作中才能换取别人的尊重和支持。同时在工作中要以平和的心态面对用户的需求变更，应当要以平和的心态面对用户的需求变更，应当积极地与用户进行交

39、流，实现对需求变更的积极地与用户进行交流，实现对需求变更的最佳解决。最佳解决。 （不卑不亢、相互尊重、心平气和）（不卑不亢、相互尊重、心平气和） (3)沟通的形式沟通的形式 1)正式的形式。即按照本阶段工作计划正式的形式。即按照本阶段工作计划的安排，对用户进行需求调研。或者是相关的安排，对用户进行需求调研。或者是相关人员参与问题的讨论等。人员参与问题的讨论等。 2)非正式的形式。通过共同进餐、闲聊、非正式的形式。通过共同进餐、闲聊、体育活动等方式。体育活动等方式。 在实际工作中，采用非正式的用户沟通在实际工作中，采用非正式的用户沟通形式往往可以取得意想不到的工作效果。形式往往可以取得意想不到的

40、工作效果。 (4)沟通结果沟通结果 对于沟通取得的工作结果，都要形成正对于沟通取得的工作结果，都要形成正式的书面文件，经过用户的签字验收，纳入式的书面文件，经过用户的签字验收，纳入需求管理范围。需求管理范围。5.4.4需求管理需求管理 软件项目的实现过程是由需求驱动的，软件项目的实现过程是由需求驱动的，因而人们希望在软件的开始阶段尽量提供一因而人们希望在软件的开始阶段尽量提供一个精确的需求定义，然后严格的实现这些需个精确的需求定义，然后严格的实现这些需求。求。 但是，每个大型软件的需求都是随着需但是，每个大型软件的需求都是随着需求的发展和人们认识程度的提高发生不同程求的发展和人们认识程度的提高

41、发生不同程度的需求变更。度的需求变更。 所有针对需求变更的工作在需求分析阶所有针对需求变更的工作在需求分析阶段要纳入需求管理的范围。段要纳入需求管理的范围。 （1）需求工程）需求工程 把所有与需求直接相关的活动通称为需求工程。把所有与需求直接相关的活动通称为需求工程。 需求工程的活动可分为两大类：需求开发；需求工程的活动可分为两大类：需求开发；需求管理。其结构如图需求管理。其结构如图5-5所示所示需求开发需求获取需求分析需求定义需求验证需求跟踪需求变更控制版本管理需求复用需求工程需求管理图5-5 需求工程结构图 需求开发的目的是通过调查与分析，获需求开发的目的是通过调查与分析，获取用户需求并定

42、义产品需求。需求开发的过取用户需求并定义产品需求。需求开发的过程有四个主要活动程有四个主要活动: 1)需求获取。与用户进行交流，捕捉、需求获取。与用户进行交流，捕捉、分析和修正用户目标系统的需求，并提炼出分析和修正用户目标系统的需求，并提炼出符合解决问题的用户需求，产生符合解决问题的用户需求，产生用户需求用户需求说明书说明书。 2)需求分析。对各种需求信息进行分析需求分析。对各种需求信息进行分析并抽象描述，为目标系统建立一个概念模型。并抽象描述，为目标系统建立一个概念模型。 3)需求定义。是根据需求调查和需求分需求定义。是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，析的结果，进

43、一步定义准确无误的产品需求，产生产生需求规格说明书需求规格说明书。 4)需求验证。指开发方和用户共同对需需求验证。指开发方和用户共同对需求文档进行评审，经双方对需求达成共识后求文档进行评审，经双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效作出书面承诺，使需求文档具有商业合同效果。果。 需求管理的目的是：在用户与开发方对需求管理的目的是：在用户与开发方对需求有着共同理解的基础上，维护需求的完需求有着共同理解的基础上，维护需求的完整性和一致性，并控制需求的变更。整性和一致性，并控制需求的变更。 需求管理过程也有四个主要活动：需求管理过程也有四个主要活动： 1)需求跟踪。指通过比较需求文

44、档与后需求跟踪。指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据续工作成果之间的对应关系，确保产品依据需求文档进行开发。需求文档进行开发。 2)需求变更控制。指依据需求变更控制。指依据“变更申请一变更申请一审批一更改一重新确认审批一更改一重新确认”的流程处理需求的的流程处理需求的变更，防止需求变更失去控制而导致项目发变更，防止需求变更失去控制而导致项目发生混乱。生混乱。 3)版本管理。详细记录发生需求变更的版本管理。详细记录发生需求变更的需求文档版本的日期，发生变更的原因，变需求文档版本的日期，发生变更的原因，变更发生的控制记录，更新后文档的版本号等。更发生的控制记录，更新后文档的

45、版本号等。 4)需求复用。实现为需求开发过程提供需求复用。实现为需求开发过程提供可复用的需求文档资料，提高需求开发的工可复用的需求文档资料，提高需求开发的工作效率和质量。作效率和质量。 需求开发与需求管理活动的业务流程如图需求开发与需求管理活动的业务流程如图5-65-6所示。所示。 (2)需求跟踪需求跟踪 是为了建立与维护是为了建立与维护“需求一设计一编程需求一设计一编程一测试一测试”之间的一致性，确保所有的工作成之间的一致性，确保所有的工作成果符合用户需求。果符合用户需求。 需求跟踪有两种方式：需求跟踪有两种方式： 1)正向跟踪。通过检查正向跟踪。通过检查需求规格说明需求规格说明书书中的每个

46、需求，看是否都能在后继工作中的每个需求，看是否都能在后继工作成果中找到对应点。成果中找到对应点。 2)逆向跟踪。通过检查设计文档、代码、逆向跟踪。通过检查设计文档、代码、测试用例等工作成果，看是否都能在测试用例等工作成果，看是否都能在需求需求规格说明书规格说明书中找到出处。中找到出处。 在实际工作中，我们通常将正向跟踪和在实际工作中，我们通常将正向跟踪和逆向跟踪合并使用。逆向跟踪合并使用。 (3)需求变更控制需求变更控制 对软件项目来说广需求的变更是不可避对软件项目来说广需求的变更是不可避免的，并且许多需求的改进是必要的、合理免的，并且许多需求的改进是必要的、合理的。的。 需求发生变更的原因主

47、要有：需求发生变更的原因主要有： 1)随着项目的进展，人们对需求的认识随着项目的进展，人们对需求的认识越来越深入。对于早些时候的在需求描述中越来越深入。对于早些时候的在需求描述中的错误或不足有了清晰的认识，因此要对早的错误或不足有了清晰的认识，因此要对早先提出的需求进行必要的变更处理。先提出的需求进行必要的变更处理。 2)业务或市场发生了变化，原先的需求业务或市场发生了变化，原先的需求文档已经不能适应用户实际业务的发展要求、文档已经不能适应用户实际业务的发展要求、或跟不上当前市场的变化。因此，要进行需或跟不上当前市场的变化。因此，要进行需求的变更处理，否则，完成的软件产品就失求的变更处理，否则

48、，完成的软件产品就失去了其应有的应用价值。去了其应有的应用价值。 提出需求变更的动机是好的，目的是希提出需求变更的动机是好的，目的是希望产品更加符合用户的需求或市场的变化。望产品更加符合用户的需求或市场的变化。但对软件项目开发小组而言，变更需求意味但对软件项目开发小组而言，变更需求意味着要调整项目资源、调整工作计划和重新分着要调整项目资源、调整工作计划和重新分配工作任务、修改前期的工作成果等，开发配工作任务、修改前期的工作成果等，开发小组要为此付出较大的代价。因此，变更请小组要为此付出较大的代价。因此，变更请求要有一定的范围，否则项目实施将会遥遥求要有一定的范围，否则项目实施将会遥遥无期。无期

49、。 需求变更控制的基本出发点是：需求变更控制的基本出发点是： 1)如果需求变更带来的好处大于坏处，如果需求变更带来的好处大于坏处，那么允许变更，但必须按照在计划阶段已定那么允许变更，但必须按照在计划阶段已定义好的变更处理流程执行，避免变更失去控义好的变更处理流程执行，避免变更失去控制。制。 2)如果需求变更带来的坏处大于好处，如果需求变更带来的坏处大于好处，那么拒绝变更。那么拒绝变更。 需求变更控制是一个渠道和过滤器，通需求变更控制是一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更可过它可以确保采纳最合适的变更，使变更可能产生的负面影响减少到最小。能产生的负面影响减少到最小。 需求变更

50、控制的一般流程如下需求变更控制的一般流程如下 1)提出变更申请提出变更申请 需求变更申请的提出者可以是任何一个需求变更申请的提出者可以是任何一个项目的利益相关人员。目的是完善需求或修项目的利益相关人员。目的是完善需求或修改原需求文档中不正确的内容。改原需求文档中不正确的内容。 2)审批审批 对于变更申请的审批流程要根据项目计对于变更申请的审批流程要根据项目计划阶段确定的变更处理流程进行。一般要由划阶段确定的变更处理流程进行。一般要由开发方和用户方共同承担需求变更的审批工开发方和用户方共同承担需求变更的审批工作。审作。审 批工作的主要目的是评价需求变更是批工作的主要目的是评价需求变更是利大于弊、

51、还是弊大于利，根据评价结果决利大于弊、还是弊大于利，根据评价结果决定是否同意进行需求变更。定是否同意进行需求变更。 3)修改需求文档修改需求文档 对于通过审批的变更申请，变更申请人对于通过审批的变更申请，变更申请人从配置管理员或需求管理从配置管理员或需求管理 员处获得需要修改员处获得需要修改的当前使用的需求文档版本，完成相关内容的当前使用的需求文档版本，完成相关内容的修改和完善工作。的修改和完善工作。 4)重新进行需求确认重新进行需求确认 修改完成的需求文档，要重新组织对需修改完成的需求文档，要重新组织对需求的评审和确认工作。对通过需求评审和确求的评审和确认工作。对通过需求评审和确认的需求文档

52、纳入配置管理和需求管理，形认的需求文档纳入配置管理和需求管理，形成最新的需求文档版本。成最新的需求文档版本。 5)变更结束变更结束 需求变更处理结束后，需要根据变更处需求变更处理结束后，需要根据变更处理过程的工作记录完成理过程的工作记录完成需求变更控制报需求变更控制报告告。根据需求变更情况进行工作量的估算，。根据需求变更情况进行工作量的估算，并进行工作计划的调整。并进行工作计划的调整。 需求变更将造成费用增加、工期延长，需求变更将造成费用增加、工期延长，所以，在审批阶段就要认真进行变更所带来所以，在审批阶段就要认真进行变更所带来的工作量及成本增加情况的评估。的工作量及成本增加情况的评估。 若工

53、作量或成本增加不是很大时，可由若工作量或成本增加不是很大时，可由项目双方协商是否由用户方增加适当的开发项目双方协商是否由用户方增加适当的开发费用完成。费用完成。 若工作量或成本增加较大时，一个较为若工作量或成本增加较大时，一个较为理想的解决办法是将变更部分作为本项目的理想的解决办法是将变更部分作为本项目的二期项目来实施。二期项目来实施。 5.5 需求获取的方法和特点需求获取的方法和特点5.5.1需求获取的主要困难及对策需求获取的主要困难及对策 整个软件项目实施过程中，需求获取是整个软件项目实施过程中，需求获取是软件开发中最困难、最关键、最易出错及最软件开发中最困难、最关键、最易出错及最需要沟通

54、和交流的重要方面。需要沟通和交流的重要方面。 造成需求获取困难的主要原因是：造成需求获取困难的主要原因是： (1)分析人员领域知识的缺乏分析人员领域知识的缺乏 大多数承担需求分析任务的需求分析人大多数承担需求分析任务的需求分析人多数是技术出身，而不是业务出身。其知识多数是技术出身，而不是业务出身。其知识结构的重点是计算机技术，对在项目实施过结构的重点是计算机技术，对在项目实施过程中的管理及用户的业务操作等一般都不太程中的管理及用户的业务操作等一般都不太熟悉。而用户是个计算机的门外汉。熟悉。而用户是个计算机的门外汉。 需求分析员应当抓紧补习和学习该领域需求分析员应当抓紧补习和学习该领域的业务知识

55、。可能的话，最好聘请既懂软件的业务知识。可能的话，最好聘请既懂软件开发又懂领域知识的行家来帮忙。开发又懂领域知识的行家来帮忙。 (2)用户对需求描述不清用户对需求描述不清 大多数的用户不知道应该提什么样的需求，大多数的用户不知道应该提什么样的需求，或者说他们对目标系统到底要做成什么样子或者说他们对目标系统到底要做成什么样子只有一个模糊的概念。这样的想法很可能只只有一个模糊的概念。这样的想法很可能只是出自于企业规划中提出的一个宏观描述是出自于企业规划中提出的一个宏观描述 需求分析员要善于挖掘、善于诱导、甚需求分析员要善于挖掘、善于诱导、甚至给用户演示一些实际应用系统来启发用户至给用户演示一些实际

56、应用系统来启发用户对目标系统的理解和认识。对目标系统的理解和认识。 (3)对需求理解上的偏差对需求理解上的偏差 在需求分析的过程中，对于用户表达的在需求分析的过程中，对于用户表达的软件需求，不同的开发人员可能存在不同的软件需求，不同的开发人员可能存在不同的理解。如果需求分析员误解了用户的真正意理解。如果需求分析员误解了用户的真正意图，将会导致后续的开发工作在错误的方向图，将会导致后续的开发工作在错误的方向指引下越走越远。指引下越走越远。 不论是复杂的项目还是简单的项目，需不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求分析员和用户都有可能误解需求。所以需求评审求评审(

57、需求验证需求验证)工作必不可少，通过需求分工作必不可少，通过需求分析、用户交流、需求评审等手段可使项目所析、用户交流、需求评审等手段可使项目所有人员对目标系统的认识有人员对目标系统的认识 达成共识。达成共识。5.5.2基于调查的需求获取方法基于调查的需求获取方法 (1)需求调查工作流程需求调查工作流程 需求调查的一般工作流程如下：需求调查的一般工作流程如下： 1)需求调查准备。需求调查准备。 2)进行需求调查并记录。进行需求调查并记录。 3)分析用户的需求信息并撰写分析用户的需求信息并撰写用户需求用户需求说明书说明书。 4)进行需求确认工作。进行需求确认工作。 (2)需求调查准备需求调查准备

58、需求调查准备工作围绕以下三个中心进需求调查准备工作围绕以下三个中心进行：行： 1)要调查什么内容要调查什么内容? 2)通过什么方式进行调查通过什么方式进行调查? 3)对对“何人何人”在在“何时何时”进行调查进行调查? 确定需求调查的内容确定需求调查的内容 需求分析调查前，分析人员应将所有的需求分析调查前，分析人员应将所有的项目资料进行汇总和分析，并与本项目的相项目资料进行汇总和分析，并与本项目的相关人员进行简单沟通，以便对项目整体上有关人员进行简单沟通，以便对项目整体上有一个基本的了解。一个基本的了解。 然后，根据自己对项目的认识，确定进然后，根据自己对项目的认识，确定进行需求分析工作的重点和

59、目标，起草相关的行需求分析工作的重点和目标，起草相关的需求调查问题表，将调查工作的重点锁定在需求调查问题表，将调查工作的重点锁定在该问题表内。该问题表内。 确定需求调查的方式确定需求调查的方式 一般可以采取以下几种方式：一般可以采取以下几种方式： 与用户交谈，向用户提问题。与用户交谈，向用户提问题。 参观用户的工作流程，观察用户的操参观用户的工作流程，观察用户的操作。作。 向用户群体发放调查问卷表。向用户群体发放调查问卷表。 与同行专家交谈，听取他们的意见。与同行专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取分析已经存在的同类软件产品，提取需求。需求。 从行业标准、规则中提取需求

60、。从行业标准、规则中提取需求。 从从Inlemet上搜查相关资料。上搜查相关资料。 对于一个具体的软件项目，分析人员可对于一个具体的软件项目，分析人员可以根据具体项目和用户的情况选择以根据具体项目和用户的情况选择12种方种方式作为本项目主要的需求调查方式，其他方式作为本项目主要的需求调查方式，其他方式作为辅助的调查方式完成需求调查的任务。式作为辅助的调查方式完成需求调查的任务。 最后，需要确定调查的时间、地点和最后，需要确定调查的时间、地点和人员等人员等 对于调查的时间、地点、人员的确定，对于调查的时间、地点、人员的确定，分析人员首先需要做好自己的需求调查计分析人员首先需要做好自己的需求调查计