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