软件项目中的需求管理-毕业论文

软件项目中的需求管理 本科毕业论文题 目： 软件项目中的需求管理姓 名：学 院：软件学院系 别：软件工程专 业：软件工程年 级： 学 号：指导教师： 职称： 年 月 日软件项目中的需求管理摘要:需求管理所关注的地方是理解软件开发组织及其客户的目标，然后将这种目标转化成潜在的功能和约束，以便这种功能和约束应用于产品、服务的开发及发展的过程。这包括理解目标和功能的关系，同时将这种关系以及系统的功能表现一起写成需求规格说明书。及时、不超预算地交付满足或超过顾客期望的产品，对于项目管理者来说是一个关键性的挑战。在这篇论文中将涉及到一个实际的软件项目，在这个软件项目中，运用需求管理中方法，从而使这个软件项目得到了完全的成功。关键词：需求，需求开发，需求管理，需求变更【Abstract】：Requirements management is concerned with understanding of the goals of the organization and its customers and the transformation of these goals into potential functions and constraints applicable to the development and evolution of products and services. It involves understanding of the relationship between goals, functions and constraints in terms of the specification of products, including systems behavior, and service definition.A key challenge for project managers is to deliver a quality product to the customer on time, on budget, and meeting or exceeding the customers expectations.This paper will talk about a real software projects. In the project, I lead it into success by means of requirement management.【Key words】: requirement ,requirement development, requirement management, requirement change.目录摘要:1【Abstract】2引言5第一章 需求及需求管理概述61.1.软件需求的定义61.1.1.关于“需求”的解释61.1.2.需求的层次61.2.需求管理的概念71.2.1 需求管理的概念71.2.2.需求管理目标及需求管理要点71.3.小结8第二章 项目及项目背景简介92.1. “厦门*公司墓石cad设计系统”项目背景介绍92.2. “厦门*公司墓石cad设计系统”项目介绍9第三章 需求获取阶段的控制和管理143.1.概述143.2.前提143.3.约定143.4.获取需求规格说明书153.4.1.调研前的准备153.4.2.调研过程153.4.3.整体调研163.4.4.具体业务调研163.4.5.对需求说明书的确认173.4.6. 总结173.5.编制开发计划183.6.小结18第四章 项目开发过程中的需求管理204.1.概述204.2.选择开发策略204.3.系统原型设计开发214.4.沟通224.4.1.在软件项目开发过程中主要沟通的方面224.4.2.可以选择的沟通方式224.4.3.小结224.5.变更控制234.5.1.前言234.5.2.变更产生的原因234.5.3.在软件项目中如何控制变更244.5.4.拒绝的方法244.5.5.客户提出需求变更254.5.6.版本控制264.5.7.资料留存264.5.8.复用策略274.6.小结27第五章 总结295.1.概述295.2.如何做好需求分析和变更管理?29致谢语32参考文献33引言人们常问：“需求、设计、编程、测试四者究竟哪个重要？”这个问题并不好回答。四者都是软件开发过程中必不可少的环节，只做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏的影响。若站在风险管理的角度讲，我认为需求开发与管理是最重要的环节。因为需求是产品的根源，需求工作的优劣对产品的影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：“开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。”对于一个软件项目，开发和实现用户所真正需要的产品是非常重要的。软件产品的成功与否很大程度上取决于对需求的管理。像我下面要介绍的项目“厦门*公司墓石cad设计系统”的成功，我觉得首先就要归功于我们对它进行了有效的需求管理。但是，谈到软件产品的需求管理，我们认为遇到了一个非常棘手的问题。实际上由于面对的客户和市场环境的不同，需求可以变得非常复杂，这种复杂往往又是动态的和难以描述的。客户的需求往往是很概括的，有时又是很具体的。客户有时会说:“我们需要一个整体解决方案”，有时又说:“图纸上的作者要这样写”。显然这样的需求无法被我们完全接受。客户的要求显然是重要的，产品应该以客户为导，如何把客户的需求变成我们技术人员能够接受的功能说明书，相反如何在产品开发前就让客户认可最终的产品，或者使用户的需要与产品之间不应有过大的偏差。此外，软件项目的需求管理，涉及到用户、市场、产品与开发等各种职能和角色，涉及到客户的需求、项目开发的时间和资源；如何平衡各方面的要求，从整体上实现客户需要的产品，对需求进行有效的管理和控制。对需求管理的方法和应用进行系统的分析，提出一些利于实际操作的方法是十分必要的。第一章 需求及需求管理概述1.1.软件需求的定义宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。IEEE软件工程标准词汇表(1997年)中定义需求为:(1)用户解决问题或达到目标所需的条件或能力。(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。1.1.1.关于“需求”的解释工EEE公布的定义包括从用户角度(系统的外部行为)，以及从开发者角度(一些内部特性)来阐述需求。关键的问题是一定要编写需求文档。另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”下面的定义则从用户需要进一步转移到了系统特性：需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。上述需求定义的一种解释如下：所谓需求，应该是来源于用户调查即客户的需要，来源于某个特定行业的一些抽象的提炼；并参照行业规范进行业务分析的结果，考虑用户自身的特性与要求。这些从客户处获得的“需要”，被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么或对于模糊的部分不做什么。而并不是通过一些零碎的邮件，或者与用户的对话，收集的一些零乱的资料，就说，我已经做好了需求，而这一种情况，恰恰就是导致失败的因素。1.1.2.需求的层次软件需求包括三个不同的层次业务需求、用户需求和功能需求(也包括非功能需求)。业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement)文档描述了用户使用产品必须要完成的任务，这在使用用例文档或方案脚本说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。1.2.需求管理的概念1.2.1 需求管理的概念需求管理的定义如下：顾名思义，需求管理是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足(甚至是充分满足)，仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。用通俗的话来说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。我认为需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解，并对此需求进行有效的控制，使项目走向成功。需求管理的过程，从需求获取开始贯穿于整个项目生命周期，力图实现最终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。1.2.2.需求管理目标及需求管理要点需求管理的目标是:1 使软件需求受控，并建立供软件工程和管理使用的基线。2 使软件计划、产品和活动与软件需求保持一致。3 控制需求变更，保证项目进度。需求管理要点:1 要明确和建立需求来源渠道，既为了避免需求蔓延，又要避免忽视客户需求、重复劳动、和不严肃的承诺；2 建立需求管理小组，对需求进行评审，如需求对系统的影响范围等；3 对需求变更进行管理，对于不同等级的需求，采取不同的测量；4 需求文档要进行版本控制。需求亦有基线和分支，并要和代码、文档等其它产品的基线和分支保持一致；5 需求文档中的SRS要其有唯一编号，可以通过项目号+SRS编号，唯一定位具体的需求；6 在后续的代码、文档等数据中引用需求要确保和需求文档保持一致；7 需求管理小组要严格控制进人设计和开发之后的需求变更，并根据变更频率，改进项目需求分析过程。8 要正确对待用户提出的新的需求以及需求变更，不能老报着“顾客是上帝”的心理，一味地答应用户的新需求。1.3.小结这一章主要讲述了需求和需求管理的定义，并着重解释了需求管理的概念、目标、流程等，我们可能有一些疑问：需求和需求管理有什么用？没有开发出一行代码，在整个软件工程过程中浪费这么多时间岂不是无用功吗?下面就需求及需求管理的重要性进行一下阐述。首先我们要树立一个概念：需求是根本，是我们一切开发活动的依据。由于忽略需求过程造成的项目返工是恶性的，后果不堪设想，大量的项目在需求阶段就注定了它的失败。以下是两个需求过程不科学的典型例子:1开发人员在用户处呆了两三天就埋头开发；2用户告诉开发人员我要开发一个xx系统，但是我很忙，你先开发一个让我看着，开发人员就盲目答应。上面的这两种态度都意味着项目的不成功，应该说上面的开发人员和用户都应该对此负责。需求是开发者和用户交互的一个过程，任何一方的不投人都会导致项目的失败。当然，由于用户不是专业人士，开发者有权利告诉用户应该采用何种态度来对待项目的需求。所有最成功的项目都有一个重要的特性：用户非常的支持。评判一个软件项目成功的标准是看它是否解决了用户的问题，而用户的问题就是体现为用户的需求，需求也就顺理成章的成为项目的成功标准。而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工，而需求的不慎不是说你小心就可以的，因为很多需求是隐性的，连用户都不清楚自己的需求。这时候就需要一种科学的方法来帮助软件项目组实施需求过程，。是不是我们在项目开始之前将所有的需求搞明白就可以使项目开发成功?我们姑且不讨论这种做法是否可行，只假设我们做到了这一点，可不幸的是：客户的需求是变化的，并且是一定要变化的。怎么办?全盘接受?全盘否定?这两种做法都是项目失败的种子。解决这些问题的办法就是用需求管理的办法，顾名思义，就是要把需求“管理”起来，让它为我所控制，从而顺利地完成整个项目。可以说，软件项目中绝大多数失败是需求的失败:或者是需求开发的失败，或者是需求管理的失败。所以，我们讨论在软件项目中进行需求管理就是十分必要的了。以下的章节，我将结合实际中的一个项目来具体谈一下小组软件项目中的需求管理问题。第二章 项目及项目背景简介2.1. “厦门*公司墓石cad设计系统”项目背景介绍厦门*公司员工一直以来都是使用一套叫“雅”的设计系统进行墓石设计，该系统由该公司从日本购进，成本较高。而且由于其是由日本人开发，好多使用方法不符合*公司习惯，致使该公司员工设计效率低下，不能很好的适应市场需求。为了适合*公司员工的工作需要，提高其工作效率，降低其开发成本，该公司迫切需要一套适合自己的开发设计系统。经过多方面考虑和挑选，最终选择委托给我们小组来进行新的系统的设计和开发。2.2. “厦门*公司墓石cad设计系统”项目介绍该项目是autocad的二次开发项目，使用ObjectARX开发包以及VC6.0进行开发。各模块最终生成各自的ARX模块，相对而言比较独立。下面我主要介绍一下系统的总体功能以及整体工作流程。系统总体功能如下：各子模块如下:系统的整体流程图如下：第三章 需求获取阶段的控制和管理3.1.概述需求获取阶段，即需求开发阶段，也可以叫需求分析阶段。在这个阶段，要对客户提出的需求进行提炼、分析，最后形成客户认可的需求规格说明书。在需求获取阶段还要编制一份开发计划。3.2.前提需求获取的前提是:用户与公司签定开发合同或者是需求调研合同。需求分析阶段是完成由公司的销售人员为重点转变为公司系统开发部门为重点过程中的第一步。对于用户来讲已经对多家开发商进行了挑选,最终明确一家开发商，并签订了开发合同。现在要进行提供具体需求并明确需求的过程明确告诉开发商要开发一个具有什么功能、什么特性的软件产品。这个前提是不可或缺的，在没有签定合同之前什么事情都会发生。在今年春节以前，我曾经遇到过这么一件事情:厦门的一家旅游公司，升级自己的门户网站，由于各种原因，决定不进行招标，直接选择厦门*软件公司进行开发。当需求已经谈完，合同已经到了谈论细节的时候，合同突然被另外一家公司抢走了。进行需求调研的另外一个前提是甲乙双方签定了需求调研合同。这个情况一般发生在甲方在几家公司之间做选择时。从上面的情况可以看出，进行需求调研的前提就是有合同保障，否则就会像我上面说的那样，会造成不必要的损失。3.3.约定用户对于其用什么系统平台，已经大概知道，并且已经认可。如WEB服务器的操作系统是WINDOWS 2000 server，数据库服务器是redhat linux，WEB服务器的软件是Apache，EJB中间件服务器是Weblogic/Websphere，数据库软件是ORACLE/SQL server等等。客户服务器的软硬件配置要经过客户的认可，并写入需求，签字确认，否则如果以后用户要提出更改，有可能会对我们的开发造成很大的影响造成不必要的损失。像“厦门*公司墓石cad设计系统”这个项目中，在进行需求分析时，我们就和客户约定好我们的平台是搭建在autocad2002上的，所以我们的开发、测试等活动都是在autocad2002的基础上进行。当我们的项目快接近尾声时，客户突然又提出要我们设计的系统能够兼容MDT6和autocad2004。我们进行了详细的分析，因为autocad2004和autocad2002的内核已经有很大的差别，如果要兼容的话大量的模块都要返工，这就意味着我们要进行重新设计开发，开发进度会落后很多。所以我们就拿签字的需求文档去跟客户谈，跟他们讲清楚我们开发困难等一些原因，而且由于我们开始也有签字约定，所以客户也就答应了。最终我们就只有兼容MDT6。如果我们当时没有约定，客户坚持他们的意见，那后果真的是不堪设想了。所用技术体系一般情况下在进行需求分析前最好是明确的，不然就要求系统分析人员了解所有的技术体系。不然运气好，系统分析人员所了解的技术体系和用户相求的相同，进行了正确分析;如果运气不好可能会把一些认为可以简单实现而实际实现却很难的需求答应下来。在所用技术体系大概范围已经明确的情况下，选择合适的系统分析人员。要求系统分析人员对相应技术体系有一定的了解，以便在相应的分析时有所依据。不同的技术体系有一定的局限性，而有些需求对某些技术体系有一定的难度。如WAP(手机上网)是不太可能实现打印。虽然没有绝对不能实现的用户业务需求，但一般情况下开发协议上明确的费用，已经决定系统功能做到什么程度。3.4.获取需求规格说明书3.4.1.调研前的准备在需求调研过程中，应该做好三种准备，保持两种心态，做到五种提高:三种准备：1)调研前应该将所有项目前期资料进行汇总，与相关的前期销售人员进行交流，以便对项目有一个基本轮廓的认识。2)做好调研前使用资料的准备，如需求调研模板，需求调研问题列表等。3)做好不怕一切困难的准备。两种心态：1)保持一种和客户平等合作的心态，确定需求调研是为了给客户解决问题，探讨问题而不是接受问题，更不是来指导工作的。2)平静面对需求变更的心态，在需求调研过程中，往往双方对需求理解不一致，造成需求调研前后矛盾，应当心平气和的去引导客户，达到需求理解基本一致。五种提高：1)首先提高自己业务知识，对于CAD制图，墓石设计的标准业务应该基本熟悉。2)其次应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户。这就需要我们阅读用户所在行业的资料、文章，尽量多选取一些整体性介绍的文章，这样可以在短时间内能够对该行业有一个全面的认识，这样我们就能够较好的和用户进行交流了。3)需求调研中，学会尽量不使用专业术语，而采用浅显易懂的口头语言来解释软件开发中的术语，以便用户能够很好的理解，提高自己的沟通交流能力。4)提高自己的速记能力，文字表述以及归纳能力，能迅速的记录需求调研核心的问题，总结归纳形成原始的需求调研资料。5) 提高自己的总结能力，书写一份完整的、前后一致的、可追踪的需求报告。3.4.2.调研过程在调研的过程中应该对会议进行记录。这项工作一般由开发商的需求分析人员进行，并在每日会议结束后，当场宣布本次会议的结果，并由参加会议人员进行签字。第二日复印或发送电子文件给参加会议人员及相关人员。以便做到有据可查，明确过程。开发商系统开发人员每周对用户提供开发周报，告诉用户当前开发的进展、是否有问题、是否需要用户协助等，这是一个好的加强双方沟通的方法。注意:在调研过程的中系统开发人员的变更会对计划产生重大的影响，不要简单认为是人员更换的问题。因为在调研过程中对业务的理解，不是通过看看文档就可以达到。3天通过讨论达到对需求理解的程序，9天对文档的学习也不一定能达到。3.4.3.整体调研对于调研过程中的整体调研，一定要让用户各部门的主管以及用户全体人员(含用户IT人员)参加，第一个目的是了解用户的整体需求细节，第二个目的使用户人员从各自的角度也了解到用户方要做一个什么样的系统。需求提供者如果是一个人，他知道自己要一个什么样的系统。但如果是多人，在开发商系统分析人员进行调研前，每人也不过是计划自己的需求而已，即使有时沟通，一般也是在讨论而不是进行结论。使业务需求并不是很明确。整体调研的其中一个目的就是把用户的多人需求组成一个整体，整体调研过程也是一个用户人员沟通并整合需求的一个过程。用户方多人在进行开发商需求确认前，业务互相有分歧是相当正常的，开发商系统分析人员必须要在需求调研过程中，使其达成一致。一般情况下需明确以下问题:1） 当前整体业务需求的目的2） 要求提供的需求功能列表3） 已经定义的需求规则4） 将来发展的设想5） 明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性等）6） 用户目前相关的技术人员和业务人员情况7） 将来最终系统操作人员的技术及业务人员情况8） 用户需求的系统及用户本身或其它系统的接口要求9） 用户的其它要求3.4.4.具体业务调研对于整体调研过后就要进行各个具体业务需求的调研，对于具体需求调研如果是用户提供的现有的文档，开发商的需求分析人员(或系统分析人员)只是对业务进行了解及进行修改为需求分析人员(系统分析人员)及业务人员全可以看懂的需求说明书，那么这个过程就比较容易。只要系统分析人员把业务文档看懂看明白，并且对于一些难理解的业务描述修改为易懂(有些业务名词有一定的专业性就要进行额外的说明)、明确进出的单据(数据项)就可以。当然编写需求说明书具体的细节可以参见其他的众多的书籍及文件模版了。如果用户对于自己的需求在调研开始并没有完全明确，需要进行引导及细化，那么这个过程就比较麻烦了。对于用户本身需求不明情况下，对于业务要先从基本业务进行细化，对于不明业务或不确定业务在后面进行。对于进出的单据(数据项)只需明确单据的进出的必须数据源就可以，如果做到细节，由用户在需求调研期确定单个数据项，是不太可能的只是设计单据的样式、风格就不是短时间可以完成的。对于报表也只能明确基本报表要求及数据项。一般这种情况使用原型法进行，先做一个简单的，在简单的上面再进行完善。对于用户本身需求不明情况下的调研要做每日(或2到3天最多3天为间隔)的工作(分析进展)记录，由双方签字，因为调研过程会出现为用户要求添加一支新业务，对新业务进行分析后，因某些原因发现不能添加。这个过程的结果是一个0，但为证明是0这结果可能花了很长的时间。要记录这个过程，说明调研过程中做了什么事情，有时有些人可能会说为什么这么长时间才出这点东西，到时以便说明原因。关于选取开发模型有时开发模型的选取不是很容易判断的，这里面有时不单是需求及开发的问题，对于开发商有开发周期、开发费用的问题，对于用户同样有内部计划、公司发展计划等因素进行影响。一般来说对于应用开发为客户开发软件，客户在开发及测试完毕软件后就要实际开始使用，那么就使用瀑布模型。当然在需求明确的情况下自然也要使用瀑布模型对于自主开发及客户需求不明并有较长的设计时间可以用演化模型。而螺旋模型适合于大型软件开发，吸收了“演化”概念，不过有时也用于用户需求不明的情况下。当然还有其他开发模型，没有在本文讨论。名词定义:瀑布模型:规定了各项软件工程活动。包括:制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。特点:自上而下，相互衔接的固定次序，如瀑布流水、逐级下落。演化模型:第一次只是试验开发，其目标只在于探索可行性，弄清软件需求;第二次则在此基础上获得较为满意的软件产品，通常把一次得到的试验性产品称“原型”特点:减少由于软件需求不明确而给开发带来的风险。螺旋模型:将瀑布模型及演化螺旋模型结合起来，并且加人被两种模型都忽略了的风险分析，弥补了两者的不足。3.4.5.对需求说明书的确认需求规格说明书完成后，先由需求分析人员(系统开发人员)对编写的文档进行内部审核及修订，特别是文字问题。内部审核后将需求规格说明书交由用户业务人员进行确认，明确需求分析人员(系统开发人员)已经了解业务需求，并进行签字确认。对需求规格说明书的签字确认，主要表明经过双方的努力，对系统的功能界定已经取得了初步的共识，形成了开发的一个基线。以后的开发、验收、需求更改要围绕着这个基线进行。3.4.6. 总结需求调研是对合同中规定的用户需求确认的过程。在这个过程中，不但要详细、正确地了解客户的真正需求，最后形成需求规格文档，还要考虑到整个项目开发的成本等因素。一般在项目签定合同之前，用户已经提交了一个粗略的需求清单，这个清单是签定合同的基础。但是不能以这个清单作为项目开发的基础，这有如下的原因:1、 客户提出的需求清单是很简单的，没有确定细节，不能作为系统开发的依据2、 在客户提出的需求清单中，有些名词的意思和开发人员通常理解的是不一样的。这些要逐一进行澄清。例如，在一个网站项目的需求调研中，客户原来提出一项“广告”的需求。按照一般的理解，广告功能有各种各样的形式，可能做的很复杂。可与客户实际一了解，原来客户所说的广告只是我们通常所说的“友情链接”而已。另外一个，客户提出一个“客户端”的需求(这个单词的意义上讲的范围就比较大了)，实际上这是对客户以弹出窗口的形式进行提醒罢了。试想，如果对这些双方有分歧的地方，不进行澄清的后果有多可怕。3、 需求调研的成果之一就是形成客户认可的需求规格说明书。这是对客户提出需求进行提炼、总结、归纳的过程。是进行设计、开发时的依据，也是很重要的。4、 需求调研中要考虑项目的成本控制问题。对于用户来说，既然已经签定了合同，总工程款已经确定，当然希望获得的功能越多越好;而对于开发商来说，功能不断扩充、项目延期是最可怕的事情。这就需要把客户一些不切实际的想法消灭掉。另外，要向客户解释清楚哪些功能不能实现。这些都是需求分析人员的工作。5、 需求调研过程是为客户解决问题的过程。通过与客户密切交流，解决客户心中的疑虑，为客户提供完善的解决方案。最终要让用户满意。备注:让用户满意并不是答应用户提出的所有要求。6、 需求调研过程要对整个系统的扩展性进行考虑。客户的想法会改变，业务会改变，甚至业务部门也会改变，这些在系统设计中都要通盘考虑。3.5.编制开发计划需求规格说明书编制完成后，就可以编制出这个系统的开发计划。开发计划的内容如下:1）项目名称2）项目委托方与承接方3）项目组成员4）项目实施进度计划5）项目开发实施步骤6）项目任务分配及资源7）项目风险及资源8）项目风险分析及管理9）承接方需委托方配合的工作10）双方关于项目管理的约定再上面这些内容中，最主要的是编制“项目实施进度计划”。编制开发计划不但要考虑功能需求多少，客户对时间的要求，还要考虑公司开发人员情况，其他项目情况等等。3.6.小结在需求获取阶段，通过与客户进行交流，弄清楚客户的真正需求。综合考虑客户需求、项目成本，时间进度等情况，形成最初版本的需求说明书、项目开发计划书。这是整个项目的开始阶段，直接决定了以后项目开发的成本、进度完成情况。对这个阶段进行有效的管理，就显得尤其重要了。进行完需求调研，获得了得到用户签字确认的需求规格说明书，下一步就进入项目开发阶段，签字确认的需求规格说明书将成为我们一切开发活动的依据。第四章 项目开发过程中的需求管理4.1.概述在软件项目或产品开发过程中，一般地来讲，把与需求直接相关的活动统称为需求工程。站在需求工程的角度来说，可以分为两大部分，即需求开发与需求管理。需求开发过程在需求获取阶段已经完成;而软件项目开发开始后，怎样对需求变更、版本进行控制就属于需求管理的范畴。在目前来说，需求工程是国内大学软件工程教育最薄弱的环节之一，那么，在这种教育模式下诞生的软件工程师会存在一种这样的习惯：他们在开发产品时并不清楚究竟该做什么，但却在一直忙碌不停地开发。这个现象，差不多成了国内软件业的瘤疾。而对于需求的管理而言，在整个开发过程中，对小组项目起着至关重要的作用;我们的软件工程师却在埋怨用户需求的不断变化，而站在用户的角度来说，你们的项目进度为何总是拖后。需求管理是完整管理模式中的一环，同其他特性:诸如完整性、一致性等不可分割，彼此相关而成一体。一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足(甚至是充分满足)，仅仅解决部分需求是没有意义的。对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。不同的需求组合起来，构成了一套完整的需求模型。用户需求决定了系统设计所要解决的问题，所要带来的结果。可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。需求管理的过程，从需求获取开始贯于整个软件项目生命周期，力图实现最终产品同需求的最佳结合。通过对需求管理在小组软件项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。根据我的经验，开发过程开始后，作为软件项目的需求经理，主要做以下工作：1） 根据项目特点，选择开发模型；2） 设计系统页面原型，并指导美工制作出页面；3） 担负开发项目组与客户之间的桥梁，承担绝大部分与客户交流的任务；4） 控制需求的变更；5） 对需求文档进行版本控制。按照上面的步骤，需求经理一步一步将存在纸面上的系统(需求规格说明)变成了可运行的系统；并保证不因外部因素(如客户提出新需求、开发人员错误理解需求)致使项目进人不可控制的境地:保证系统实现客户需要的功能，在规定的时间内，不突破预算地完成整个项目。4.2.选择开发策略选择开发策略的问题，在“具体业务调研”中已经涉及到，那些只是在需求调研阶段的设想。到软件项目开发过程中，这些设想就变成实实在在的策略了。针对于不同的小组软件项目，选择不同的软件开发模型。对于网站项目而言，主要有如下特点：1、 公司开发网站项目有丰富的经验和代码积累，网站项目中很多功能都有现成的代码，只做小小的改动，就可以拿来用；2、 2、由于对网站项目开发经验丰富，一般在需求调研阶段会得到良好的需求规格说明书。所以对于网站项目开发，可以选择“瀑布模型”。对于采用瀑布模型的网站软件项目，主要采取下述的开发策略：将软件生存期划分为若干阶段，根据不同阶段工作的特点，运用不同的方法、技术和工具来完成该阶段的任务。软件人员遵循严格的规范，在每一阶段工作结束时都要进行严格的阶段评审和确认，以得到该阶段的一致、完整和无多义性的文档，把这些文档作为阶段结束的标志“冻结”起来，并以它们作为下一阶段工作的基础，从而保证软件的质量。但是，有时很难得到一个完整准确的规格说明。特别是对于一些大型的软件项目，或是原来没有开发过的项目，在开发的早期，用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求，软件人员对于所要解决的应用问题认识更是模糊不清。经过详细的讨论和分析，也许能得到一份较好的规格说明，但很难期望该规格说明能将系统的各个方面都描述得完整、准确，并与实际环境相符。很难通过它在逻辑上推断出(不是在实际运行中判断评价)系统运行的效果，以此达到各方对系统的共同理解。随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也随之变化；开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来摆脱困境。因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。尽管在传统软件生存期管理中通过加强评审和确认，全面测试来缓解上述问题，但还不能从根本上解决这些问题。在这种情况下，需要采用快速原型法进行开发。“厦门*公司墓石cad设计系统”就属于这种情况，而且有一个现成的原型（客户目前使用的“雅”）供我们参考。由于我们原来没有开发过这种系统，对于这个系统的业务不是很了解，所以要采用演化模型进行开发。4.3.系统原型设计开发对于采用瀑布模型进行开发的系统来说，各模块设计主要是根据需求规格说明书规定的功能要求，以及客户的要求，制作出可进行变成的模块。其中，最重要的是确定系统的整体构架等。整体构架由客户确认后，就可以进而制作出各子模块的设计开发。对于采用演化模型进行开发的系统来说，系统原型的开发主要有如下作用： 增进软件人员和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求(主要是功能)明确化。对于系统用户来说，要他们想象最终系统是什么样的，或者描述当前有什么要求，都是很困难的。但是对他们来说，评价一个系统的原型要比写出规格说明容易得多。当用户看到原型的执行不是他们原来想象的那样时，原型化方法允许并鼓励他们改变原来的要求。由于这种方法能在早期就明确用户的要求。因此可防止以后由于不能满足用户要求而造成的返工，从而避免了不必要的经济损失，缩短了开发周期。原型化方法提供了一种有力的学习手段。通过原型演示，用户可以亲身体验早期的开发过程，获得关子计算机和所开发系统的专门知识，对使用者培训有积极作用。软件开发者也可以获得用户对系统的确切要求，学习到应用范围的专业知识，使开发工作做得更好。原型可以作为理解和确认软件需求规格说明的工具。软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。在系统原型开发阶段，应该注意以下问题：对各功能实现的每一个细节要做细致的检查，看是否符合需求规格说明书的要求。要及时与客户进行沟通，特别是制作出系统原型后，要及时让客户进行确认，然后再进行下面的开发。4.4.沟通4.4.1.在软件项目开发过程中主要沟通的方面在软件项目开发过程中，与客户及项目组成员保持及时有效的沟通十分重要。在以下方面需要与客户及时交流：制作系统原型时要将客户的意见反映给开发者，将开发人员的意见提交给客户进行参考。并将制作好的原型及时提交给客户审核；当客户提交意见时，要将项目组讨论的结果及时提交给客户。在必要的时候，要对结果再进行沟通；将开发组人员的意见提交给客户，并取得客户的支持。这个过程有时候也需要反复几次；各种文档的准备，需要和客户沟通、确认。有时候客户对文档有特殊要求时，需要往返几次；验收、上线运行等问题需要和客户沟通、确认4.4.2.可以选择的沟通方式根据现有的物质、技术条件，沟通方式大体有以下几种：面谈。一些问题要和开发人员当面探讨，一般不涉及到其他人、其它模块，并且开发者本人能够确定的。座谈。一般是项目开发小组、相关的领导一块讨论一些牵扯面比较大的问题。邮件。不论是和开发人员沟通，还是和客户沟通，邮件都是最常用的方式。可以用邮件传送文件资料，做正式的任务下达等。这要求沟通双方都有免费或者公司的邮件服务器，并且双方都乐意使用这种方式(不能有一方不愿意打字)。聊天工具。主要使用MSN等。主要用于日常沟通，当沟通双方打字速度都比较快时，是一个好的办法，成本低。但是遇到一方不会打字时，就不是好的选择了。电话。当用打字的办法不能准确表达意思时，就要选择电话方式了。传真。主要用于比较重要的文件传输等，如双方签定的协议。在整个项目过程中，我们主要通过面谈和电话的方式和客户进行沟通，个人觉得，如果方便的话，还是面谈比较好，可以和客户进行详细的探讨。4.4.3.小结沟通，可以说已经变得无比的重要。在软件业，沟通可以说是快速学习和掌握新知识，达到技术上的更高层次的最佳途径。小组员的沟通，可以很好的加强团队组织的凝聚力。可能更好的让小组软件项目良性的进行。而培养这种气氛，形成有效的沟通，这也是项目管理的基本内容。协调几个人的工作比自己完成一段编码更重要。如果小组成员在协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。在需求分析结束以后，甲乙双方要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。并在项目需求分析完成后，和客户明确项目的哪些部分可以在日后的进度中能修改，修改的限度，哪些不能修改。例如，应用背景、功能要求方面应该是在需求分析阶段确定，日后不能做修改。而性能、界面及接口等可以在日后作有限度的修改。尽早沟通、主动沟通就是其中的两个原则，实践证明它们非常关键。尽早沟通要求项目经理要有前瞻性，定期和项目成员建立沟通，不仅容易发现当前存在的问题，很多潜在问题也能暴露出来。在项目中出现问题井不可怕，可怕的是问题没被发现。沟通得越晚，暴露得越迟，带来的损失越大。主动沟通说到底是对沟通的一种态度。在小组软件项目中，我们极力提倡主动沟通，尤其是当已经明确了必须要去沟通的时候。当沟通是小组软件项目经理面对用户或上级、团队成员面对项目经理时，主动沟通不仅能建立紧密的联系，更能表明你对项目的重视和参与，会使沟通的另一方满意度大大提高，对整个小组软件项目非常有利。4.5.变更控制4.5.1.前言不被控制的变更是小组软件项目陷人混乱、不能按进度执行或软件质量低劣的共同原因。为了使开发组织能够严格控制小组软件项目应确保以下事项：应仔细评估已建议的变更。选择合适的人选对变更做出决定。变更应及时通知所有涉及的人员。软件项目要按一定的程序来采纳需求变更。只有软件项目风险承担者在开发过程中能控制变更，他们才知道将交付什么，哪一项将会导致与目标的差距。对项目越深人了解后，你就越能发现采纳变更需求条件的苛刻。在需求文档中一定要反映项目的变更，需求文档应精确描述要交付的产品，这就是你的原则。要是软件需求文档同产品不一致，那它就毫无用处，甚至就像没有一个软件需求文档来指导开发组开发一样。当不得不做出变更时，应该按从高级到低级的顺序对被影响的需求文档进行处理。举个例子。一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求。改动高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更，(典型的情况是一个功能性需求)，可能会导致需求同上层文档不一致。4.5.2.变更产生的原因在软件系统开发过程中，有很多问题都是由于在需求分析阶段没有正确地收集、编写、协商、修改产品真实需求而产生的，造成这样的状况有几方面的原因：对需求的理解分歧当客户向需求分析人员提出需求的时候往往是通过自然语言来表达的，这样的表达对于真实的需求来说是一种描述(甚至只是某个角度的描述)，远远不能保证这样的描述可以得到百分之百的正确理解，也许在同客户交流的第一时刻就埋下了理解分歧的种子，打一个比方说客户说我要的是大象，身子象一堵墙，耳朵象扇子，四条腿象四根柱子，尾巴象绳子，分析人员想，哦，墙、扇子、杆子、绳子这些我都知道，但是真的画出来的时候客户当然会跳起来了!这是理解分歧的问题，一般跟分析员的知识、背景，还有客户表述的标准程度、双方的交流情况有关。系统实施时间过长一个大中型系统的建设可能要延续一段时间，当客户提出要求之后，他当时并不能看到系统的运行情况，当双方认为理解大概没有分歧的时候(事实上还会有个Deadline)，开发方就开始工作了。当客户拿到差不多可以试用的产品时他可以实际操作，这时候他就会对系统的界面、操作、功能、性能等有一些切身的体会，有可能提出需求变更要求。客户具体情况不一当前客户的情况不一，有可能客户行业的竞争度高，需要随时作出调整和反应，那么他们自然会经常提出需求变更的要求；也有可能客户所在的行业操作不规范，本身存在很多人为因素，这时候开发方更是需要随时准备应变。开发本身要求有可能是来自开发方自身版本升级或性能改进、设计修正的要求出现需求变更，这时更是无法绕开这个问题的了。所以说就算分析人员和客户之间不存在理解分歧，客户对于实际的系统还是会提出一些个人意见，就算没有个人意见，他们自己的业务会变化或环境发生变化，这些都是无法避免的，所以不要梦想那么理想的需求分析，当你开始一个小组项目的时候就应该意识到，客户的需求变更一定会有的，那么对于这样的现状，我们该怎么办呢?难道我们要跟着客户的需求不停地修改软件，到最后工期延长，员工疲惫，成本成倍增长，客户满意度降低，原来的设计也会改变得支离破碎，系统难以维护。4.5.3.在软件项目中如何控制变更根据公司的规章制度，在小组软件项目中，控制软件需求变更是需求经理的职责。需求经理要面对开发人员和客户双方提出的需求变更。开发人员提出需求变更，一般情况是他们在实际开发过程中发现了原来的设计不合理之处，需要更改设计。或者是用现有的方法不能实现预定的功能。对于这样的变更，一般要做的只是及时将变更情况通知客户，并取得客户的谅解。但是，绝大多数的需求变更是由客户提出的。对于客户提出的变更请求，要区别对待：如果此变更是超出合同规定(或需求规格说明书中)的范围，应该明确予以拒绝；综合考虑功能、成本、进度等方面的内容后，认为可以进行变更的则答应；一些拿不准的事情，要和项目组成员进行商量，再做决定。其结果不外乎拒绝或答应。控制变更的方法是要敢于说“不”。很多人不喜欢说“不”，开发者只好在各种压力下接受每一项建议的需求。“客户总是对的”， “我们将使客户完全满意”这些话哲理上