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

由于用户群中每个用户的出发点不同， 思考问题的角度也有所区别，从不同的应用 层面阐述对原始问题的理解和对目标系统的 要求，因此，有必要对原始问题及其软件求 解建立模型。 这种模型一方面用于精确记录用户从不 同的角度、在不同的抽象级别对原始问题和 软件要求的描述；另一方面，它也将帮助分 析人员发现用户需求中的不一致性，排除不 合理的部分，挖掘潜在的用户需求。 这种模型是分析人员对于原始问题及其 软件理解的一种知识结构。这种结构往往包 含问题及其环境所涉及的信息流、处理功能、 用户界面、行为模型及设计约束。它是需求 规格说明书、软件设计和实现的主要基础。
第二阶段：“诱导式”(1nducement) 在分析人员已经了解了具体用户方的组 织架构、业务流程、硬件环境、软件环境、 现有的运行系统等信息的基础上，作出简单 的用户流程和操作界面，同时结合以往的项 目经验对用户采用诱导式、启发式的调研方 法和手段，和用户一起探讨业务流程设计的 合理性、准确性、方便性、习惯性和易操作 性。 实现手段：拜访（诱导）、DEMO演示 输出成果：调研分析报告、原型反馈报 告、业务流程报告。
2)用户签字制度。 签字的办法可以使用户在需求调研中以 积极负责的态度，认真对待每个需求分析项。 这样做可有效遏制需求的反复。 3)定期的工作通报制度。 开发方项目经理要定期将需求分析阶段 的工作进展情况、存在的问题进行汇总，向 项目双方的高层领导、项目管理委员会进行 工作通报。 4)对签字认可后的需求纳入需求管理，对 发生的需求变更，执行需求变更处理流程。
图5--4为需求分析阶段典型的团队组织模 型。
需求分析涉及的单位、组织和人员主要 包括两大类，一类是用户方，一类是开发方。 双方参与需求分析阶段工作的人员在各 自项目经理的领导和协调下开展工作，并分 别与对方项目人员进行充分的沟通和交流； 双方项目人员之间协调不了的事情由双方项 目经理进行协调，项目经理协调不了的事情 交项目委员会协调。 整个软件需求分析阶段的团队组织是按 照项目管理中典型的矩阵式结构来开展，能 够有效地利用项目资源，增加了沟通的机会， 充分发挥项目人员的积极性。
(3)有效遏制需求变更 需求分析阶段用户需求的变更主要表现为 用户需求的反复，容易使需求分析工作原地 转圈，无法按计划完成需求分析工作。 要遏制分析阶段的需求变更，通常采用的 办法有以下几种： 1)充分到位的需求调研。 详细周密的需求分析，以及对用户需求 的深层次挖掘等工作，是保证高质量需求分 析工作的基础，也是防止需求变更的基本手 段。
(4)确保与用户沟通的深度和广度 所谓深度是指分析人员在需求调查的过 程中，不但要与用户建立良好的工作关系， 甚至要努力去建立比较深厚的私人关系，拉 近距离，便于沟通。只有这样才能更清楚的 了解用户的真实想法，获得用户的尊重和工 作支持。 所谓广度就是在需求调研过程中要进行 整体调研，需求调研要面向用户项目参与的 全体人员。一方面是要了解用户的整体需求 细节；另一方面也可从不同人员各自的角度 了解用户方到底想要完成一个什么样的系统。 对于用户方的不同认识，分析人员可通 过召开项目协调会议的方法，协调并统一用 户方人员对相关需求的一致看法。
5.3.2团队管理
本阶段的团队管理包含项目参与双方团 队的管理工作。 团队管理的特点有： (1)团队成员能力的要求 具有良好的沟通及协作能力是对项目所 有参与人员的共同要求。 对开发方需求分析人员，需要具备丰富 的需求分析经验、良好的业务知识。切忌承 担分析任务的分析人员既是新手，又不熟悉 业务知识 对用户方人员来说，技术人员要具备良 好的技术背景，熟悉本单位的计算机系统及 网络状况。业务人员需要具有丰富的业务知 识，熟悉各种业务的处理流程及结果形式。
第三阶段：“确认式”(Affirm) 进行具体的流程细化、数据项的确认阶
段。 分析人员需要完成明确的业务流程报告、 数据项描述、修改后的DEMO系统及业务流 设计目标。 用户方审查业务流程报告、数据项描述 以及通过操作开发方提供的DEMO系统，提 出反馈意见，并对已经完成并可接受的报告、 文档签字确认。 实现手段：拜访(回顾、确认)，提交业务 流程报告、数据项描述；DEMO演示系统。 输出成果：需求分析报告
5.2.2需求分析的工作模式
需求分析在通常情况下划分为三个阶段。 第一阶段：“访谈式”(Visitation) 这一阶段是和具体用户方的领导层、业 务层人员进行访谈式沟通，主要目的是从宏 观上把握用户的具体需求，了解现有的组织 架构、业务流程、硬件环境、软件环境、现 有系统等具体情况，建立起良好的沟通渠道 和方式。 实现手段：访谈、发放调查表 成果：调查报告、业务流程报告
⒊任务 问题分析 (即如何获取需求 )、需求描述 (即如何定义需求)和需求验证。 ⑴问题分析 需求分析人员通过对问题及其环境的理 解、分析和综合，消除用户需求的模糊性、 歧义性和不一致性。 系统分析人员应该将自己对客户需求及 问题的理解与自己所拥有的软件开发经验结 合起来，以便发现哪些要求是由于用户的片 面理解和短期行为所提出的不合理的要求， 哪些要求是尚未提出但具有真正价值的潜在 需求。
这四个过程循环往复，渗透到客户业务 系统的各个环节，贯穿于需求分析的整个工 作过程中，直到项目组人员与客户在对目标 系统的功能、流程、接口、数据、操作等多 方面内容达成共识后，方可宣布需求分析任 务的结束。 需求还有可能再发生变动，此时需求分 析的结束，只是标志客户需求在一定时期内 的“相对锁定”，这对整个项目未来工作的 开展非常重要。
Байду номын сангаас
(2)明确划分双方的职责 在需求分析阶段开始时，要明确项目双 方在合作中的权利和义务，形成正式的项目 协作文件。 为了避免用户方工作人员不愿意积极参 与需求调研过程，或对需求分析的工作不重 视的现象，对需求分析结果，用户方必须签 字确认。
(3)团队矛盾及问题的防范及解决办法 需求分析阶段容易发生的矛盾与问题主 要是系统分析人员与用户的工作配合上。 例如：由于种种原因，用户借工作忙， 使需求调研工作一拖再拖；或用户拒绝对各 项需求分析结果进行签字确认等；或是双方 工作方式上的不恰当，造成工作配合上的矛 盾和摩擦等。 可采用以下办法加以防范和解决： 1)明确各自的责任和义务 2)树立共同的项目目标和成功意识 3)增加友谊 4)出现问题尽量在小范围内自行协调解决 5)组织项目协调会议
计划主要包括： ▲本阶段详细的进度计划安排； ▲项目参与双方参与人员的工作分派及 职责要求； ▲双方人员的工作时间约定、工作内容 及工作时间的保证要求； ▲在项目协作过程中双方工作人员的工 作流程约定、问题及其解决流程约定等。 计划完成后，要形成正式的书面文件。 双方项目经理签字认可后下发执行。
(2)合理的需求调研和科学的工作安排 较为理想的需求调研步骤为： 首先与用户方的技术人员交流，确定系统 实现的技术方面的需求，即技术实现的架构 与要求。 接下来再与业务人员交流，获取详细的业 务需求。在业务需求的调研过程中，应先确 定系统的主要功能要求，再在此基础上逐步 进行需求细化工作。
5.3 需求分析阶段的团队组织
5.3.1团队组织与建设
需求分析作为软件开发生命周期的第一 个里程碑，它的内容贯穿于整个软件生命周 期全过程，是一个需要团队成员高度配合和 密切协作的阶段。 需求分析阶段参与项目的人员及工作职 责如下： (1)项目经理：负责需求分析阶段项目进 度的安排和控制；参与项目的各种资源调度； 负责项目的总体协调工作。 (2)系统分析人员：与用户方的技术人员 和业务人员进行良好的沟通，了解业务流程、 功能需求、系统构想和项目目标，完成软件 需求说明书的编制任务。
(3)程序员：在采用原型法的系统分析过 程中，程序员参与用户的需求分析过程，根 据用户的实际需求，完成原型系统的开发工 作。 (4)质量管理人员：负责组织有关人员完 成对需求分析工作的质量审核和需求说明书 的评审工作。 (5)配置管理人员：把通过评审的需求说 明书纳入软件的配置管理项。
(6)用户方的技术人员：用户方参与项目 的技术人员(往往是计算中心的工作人员，未 来工作是维护系统)，通过与系统分析人员的 沟通，确定系统的技术实现方案。要求该人 员具有对需求说明书中系统技术方案的最终 签字认可权。 (7)用户方的业务人员：用户方参与项目 的业务人员，经过与系统分析人员的沟通， 确定未来软件系统实现的具体功能和业务模 型。要求该类人员对需求说明书中的业务需 求具有最终签字认可的权利。
5.4 需求分析阶段的项目管理
5.4.1需求分析阶段的进度管理与控制
做好需求分析阶段的进度管理工作，需 要做好以下几个方面的工作： (1)详细的工作计划和明确的责任分工 由于需求分析阶段项目双方工作协作较 多，容易出现配合上的矛盾和问题。所以， 在需求分析阶段开始时，双方的项目经理要 进行沟通，制定本阶段详细的工作计划、参 与人员的工作分工及职责。
第5章 软件项目需求分析阶段的 知识和管理
本章要点： 需求分析是软件项目的立足之本 需求分析的工作内容 需求分析阶段的团队组织 需求分析阶段的项目管理 需求获取的方法和特点 需求分析方法和建模工具 需求分析阶段性成果和考核依据
软件需求分析阶段工作的基本任务就是 要准确回答“用户真正需要一个什么样的软 件系统?该软件系统必须完成什么功能?”。 需求分析阶段将对软件系统提出完整、准 确、清晰、具体的要求。
5.1 需求分析是软件项目的立足之本
需求分析是整个软件项目开展工作的基 础，需求分析质量的好坏，直接关系到软件 项目交付成果的客户满意度，甚至整个项目 的成败。如果需求分析工作做的不扎实，无 论设计阶段工作完成得如何出色、软件编码 质量如何高，其结果将只会给用户带来失望， 给开发者带来失败的苦恼。
(2)需求描述 以需求模型为基础，考虑问题的软 件可解性，生成需求规格说明书和初步 的用户手册。 需求规格说明书包含对目标系统外 部行为的完整描述、需求验证标准以及 用户对系统在性能、质量、可维护性等 方面的要求。
用户手册则包括用户界面描述以及 有关目标系统使用方法的初步构想。