项目管理人员继续教育论文

如何做好项目中的需求管理

20xx年12月24日

摘要：项目需求管理是软件设计和实现的基础，是构成任何项目范围的基础部分，也是项目能否建设成功的基础。本文主要通过对信息系统项目管理知识的系统学习并结合多年来自己参与部分软件项目实施的工作经验，介绍在项目建设过程中如何对需求进行有效的管理探索出的一些有效措施。

关键词：需求获取 需求分析 需求评审 需求变更

如今尽管有关开发的知识和经验不断丰富，可利用的工具也不断增多，但仍然有相当比例的软件项目失败，原因常常是因为在开始时没有正确地确定和定义需求，或者随着项目的展开没有正确地管理需求，对获取到的需求没有进行有效的分析，或者获取到的需求本身就是不准确的。

软件需求管理正是解决用户这种需求，软件需求管理是关乎软件项目开发成败的重要因素。现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确。从而引发项目开发中的一系列更改。这些更改可能导致浪费大量的资源、软件项目无法按时完成等严重问题。

本人通过对软件项目管理知识的系统学习并结合近年来自己参与部分软件项目实施的经验，介绍在需求管理研究中探索出的一些有效措施。

一、明确项目干系人

项目干系人又称为项目相关利益者，是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织。项目干系人对项目的目的和结果施加影响。应当从项目的启动开始，项目管理团队就要识别项目用户方干系人包含哪些人和组织，通过沟通协调确定他们的需求和期望，尽最大可能地明确项目干系人中的决策者在项目中所起到的作用，以确保项目获得成功。

很多项目往往都是由客户单位的技术主管部门主导，项目经理在前期接触时，跟这些技术部门接触的比较多，而没有和业务部门或系统开发完成后的实际的使用者接触。该类人员对技术比较精通，但对应用部门的相关业务可能不是特别熟悉，从而导致项目组获取到的需求发生偏差，在软件开发完成后和用户的实际需求相差甚远，导致用户频繁提出需求更改，更有甚者推翻重建。

第1页 共6页

项目管理人员继续教育论文

因此项目经理在与客户初次接触时应首先明确干系人，识别项目干系人及其角色，确定项目组的组织架构，确定项目组各干系人的职责范围，确定对需求实现的最终决策者。

二、熟悉业务采用合理方法获取需求

在明确了项目干系人后，那么在这个项目中各个业务场景，业务流程，业务规则，组织结构和岗位角色就是我们在接下去所需要重要调研的内容。而往往一些项目经理在获取需求的过程中，仅仅是充当了一个“书记员”的角色，即客户说什么？他就记录什么？在获取的过程中缺少与客户的互动。我们的的目的是为了搞清楚用户的业务现状和问题，而不是简单的听到或问到用户要什么，因为有些客户自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。

我们一般可以通过双方对需求的了解情况上，分为四种情况：开发方和用户方都清楚项目需求；开发方不清楚项目需求但用户方清楚；开发方和用户方都不清楚项目需求；开发方清楚项目需求但用户方不清楚。针对这四种情况，我们可以采用问卷调查法、会议讨论法、界面原型法、原型系统法来获取客户的需求，这四种方法可以在需求获取过程中组合使用。我们结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，这样才能设计出真正符合客户需求的系统。通过界面原型法或原型系统法，使客户人员能够比较直观的明白以后他们的业务流程在系统中是如何展现的，使客户人员对系统有一个观感上的认知，同时项目组成员也能够明确客户所期望的产品是怎么样的。

使用上述方法有以下优点：(1)增进软件开发者和用户对需求的理解，使比较含糊的具有不确定性的软件需求(主要功能性的需求)明确化；(2)可以容易地确定系统的性能，确认系统主要服务的可应用性，确认系统设计的可行性，确认系统最终作为产品。

第2页 共6页

项目管理人员继续教育论文

三、分析需求的可行性

在需求获取过程中，项目组收集的需求往往存在以下几问题：⑴需求范围超出合同范围；⑵对同一功能，各干系人提出的需求不一致；⑶存在明显不合理的需求；⑷对需求理解发生偏差。因此对获取到的需求进行有效、准确的分析是必不可少的步骤。

在项目建设过程中，不同的项目用户方干系人其愿望和追求的目标可能会存在不一致，有些干系人的期望值较高，远超合同建设范围；而有些干系人提交的需求，相互之间不一致，造成需求冲突。因此需求分析人员应对获取到的需求进行整理并进行有效分析。对于超出合同范围的需求，可由商务一起协调进行增补或在二期中进行建设；对于需求不一致的，可召开项目协调会，由甲方最终决策者拍板确定或寻求平衡点折衷处理；对于需求理解偏差和客户描述不清的需求，可通过原型界面法，反复确认。因为对于需求分析是需求管理中很重要的一个工作部分。

对获取到的需求，进行优先级评估。需求分析人员应分清客户提出的需求，哪些特性是必要的，哪些是重要的，是需求开发的主要部分，设定这些需求的优先级，并与客户进行讨论明确。因为开发者应该按照客户的观点决定项目需求的优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

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

很多时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求

第3页 共6页

项目管理人员继续教育论文

分析中包含技术实施上有难度的功能。

四、编写需求规格书和进行需求评审

在准确领会客户的意图后，软件需求规格说明书就是需求分析阶段需要产生的最主要的文档。准确而详细地编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，在编写文档时，开发人员严禁采用“猜测”的方式编写。在需求文档中暂时加上“待定”标志是个好方法。用该标志可指明哪些是需要再进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上 “待定” 。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

需求规格说明书的每个功能点的描述要通俗易懂，能够使客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。所以分析说明书对功能细节的描述不能有歧义或二义性，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。

需求规格说明书一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的审核，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题。

需求文档完成之后，并不是把它扔给后面的设计人员就了事了。作为项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求分析也是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务。

第4页 共6页

项目管理人员继续教育论文

五、做好项目需求变更管理

在软件项目建设过程中，需求变更是不可避免的，但在开发生命周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。分析人员及时评估，为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。在不放弃所提出的需求变更情况下，对每项要求的变更进行分析、综合考虑，最后做出合适的决策。

造成需求变化的原因有很多。比如:随着项目的进展,开发方和客户方对需求的了解越来越深入,原先的需求文档可能存在这样或那样的错误和不足,因此要变更需求;以或者由于市场、业务发生了变化,原先的需求文档可能跟不上当前市场的要求,因此要变更需求等等。需求的变更问题是每个开发人员、项目经理都会遇到的问题,需求的变更不一定是坏事,常常提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。但是一旦需求发生了变化,随之而来的将是不得不修改设计、重写代码、修改测试用例、调整项目计划等问题,对项目开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,这将为项目的正常进展带来诸多的麻烦,开发小组也要为此付出较重的代价。

当然在软件项目建设过程中，并不是所有的需求变更都能够被采纳的话，要学会适当的拒绝，通过变通的方法实现。否则有可能，这个项目也许永远不能按时完成，进度无限期滞后。因此在需求变更过程中最难办的事情就是拒绝客户提出的需求变更请求,通常情况下开发方是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。因此作为一名项目经理，你应当规范需求管理，对客户的需求变更进行评估分析，对变更带来的影响、成本和得失告知客户。当然开发人员不能由于不想实施变更而随意夸大评估成本。

结论：项目需求管是是一个项目建设生命周期中的一个重要开端,也是项目建设成功的基石。在以往建设失败的项目中,80%是由于需求的不明确或需求变更没有控制好而造成的。因此一个项目成功的关键因素之一,就是对需求管理的把握程度。

参考文献：

第5页 共6页

项目管理人员继续教育论文

【1】 软件需求管理用例方法第二版——莱芬韦尔——【M】中国电力出版

社 2004

【2】 软件需求管理——K.E.维格斯——【M】机械工业出版社2009

作者简介：

第6页 共6页

 

第二篇：如何做好IT项目需求管理

约定：本文涉及到的关键字概念和采用的技术的概念都不做详细解释，里面的概念定义请查阅相关书籍，这里只讨论这些在需求管理中的使用;同时里面的案例信息也不在这里做详细交代。

    引用案例：某市网上审批项目。

    1　概述

    我们知道现代项目管理的六要素是：时间、成本、质量、组织、范围、客户满意度，实际上，要满足这六个要素，计划一个良好的需求分析是实现这六因素的前提，如果我们在项目生命周期的某些阶段出了问题，而我们可能还不知道，这将影响整个项目周期，无论该计划如何详尽，如果需求有误和需求分析不到位，项目的控制将没有任何价值，IT软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)，从某种意义来讲，项目的成功基于项目的需求管理的成功。

    2　需求的定义及特点

    根据IEEE项目工程标准词汇表(1997)年中对需求的描述如下：业主解决问题或达到目的所需的条件或权能，和系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。在PMBOK中，项目需求就是在“项目范围”约定的。

    需求最显著的特点是“随着项目而改变、随着项目而渐进明晰”，项目管理的特点是随着进展而渐进明细化，可以看出需求管理和项目管理一样，这就意味着需求在项目的整个生命周期都可能存在的，这样项目管理的过程，也必不可少需求的管理。

    3　如何获取需求

    获得需求的方式可以有多种多样：电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书)，其实这些方法都是GET方式，我们可以通过以下两类技术手段来达到：GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求，而这两个过程都是必须交互进行的，一般我们可以筛选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程师，长期在客户那里工作，他的工作主要是界定项目的范围和需求变更管理，通过我们编制的各类模板文档来实现需求变更的控制;

    一般来讲IT集成需求包含三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需求提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明;用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求，必须具备一定的业务背景和技术背景，能从三个不同的层次发掘客户的需求。

    根据我们在某市网上审批项目中的经验，我们采用如下方法，其中每项工作都记录文档备案：如查阅了大量资料和病历资料格式、各类应急防御措施、统计分析报表、系统规划书、旧系统业务状况、历史资料、还访谈了操作员的应用感受、多次技术交流、专题讨论等多种形式的交互式讨论和分析。这样无论是业务、功能、用户详尽的期望我们都了解的比较透彻。

    4　需求管理

    获取了需求接着要作的的工作就是对需求分析、消化和评审、基线制定、需求说明书制定，这里我们主要集中在需求分析和需求说明书两方面来。

    4.1需求分析

    1)建立需求关联图：需求关联图是用于定义系统与系统外部实体间的界限和接口的简单模型，同时它也明确了通过接口的信息流和物质流，通过关联图，对用户需求的约定和确认以及CCB的评审都是非常关键的。

    2)创建开发原型：创建用户接口原型可以在如下应用如下情况：如果开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。通过开发原形，业主和集成商都可以相互了解业务，发掘潜在的信息，避免用户需求的不必要变更。

    3)分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍，这个主要用于内部评审和制定技术线路提供依据，如在什么情况下采用.NET技术,什么情况下采用J2EE技术,我们在20##年电子政务网上审批系统中充分对需求(业务、技术、用户操作人员需求、现有系统需求等)做整体提取分析来确定技术线路的选型。

    4)确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

    5)为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

    6)编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

4.2建立需求与产品质量的关系模型

    需求是项目正确实施的一个前提,如果没有抓住用户的需求,那么很可能是漏洞百出，最终产品将不是一个真正的可交付物。我们知道，质量是一个客户满意度的一个主要因素，质量在项目中又有许多影响因素，这里我们着重从需求的角度出发来讨论需求与质量的关系，那么如何来从需求的角度出发建立与质量的控制呢?

    我们来建立一个思路如下：客户所有的期望 需求产生 转换矩阵 产品开发 可交付物 客户满意。在这里转换矩阵就非常关键了，如何来实现需求与质量的关联呢，可以通过质量功能调配(QFD)来实现，通过QFD可以把需求(用户期望)、产品特性关联起来，这里要用到一个工具：质量屋(House of Quality)，我现在用一个案例来说明这个工具，在做某市网上审批项目中，我们从客户哪里收集和整理了许多需求：审批项目、报表要求、认证方式、工作流要求、数据范围及格式、操作界面、医药管理规范等等;我们通过建立质量屋完成了需求与如何去实现，如下图所示：

     

    在QFD技术中以三种形式来定性地描述工程特征之间的相关影响关系，即正相关(向相同方向变化)、不相关和负相关(向相反方向变化)。对相关程度还可以进一步地细分为强相关、一般相关和弱相关几种关系，并给以标度值来表达相关程度，这样我们可以定义一些需求的强弱程度：如不确定需求、一般确定需求、强烈确定需求等，在这个HOQ中，还要用到其他技术工具，如：要素加权法等，这样做的好处是主次分明，可以把需求分析和管理做到随时间的推进客户的变更变限于固定的框架里，符合如下曲线，而不至于走向极端。

    

    
    4.3需求说明书编写经验谈

    目前需求说明书有固定的格式和要求,可以从专门介绍需求说明书的相关书籍中获得,在本论文中,我着重阐述需求说明书的经验，编写优秀的是没有公式化的方法的，这需要大量的经验，要从你在过去的文档中发现的问题学习。

    1) 采用IT项目需求规格说明模版,要注意的是很多人拿来需求说明书模板就套用,这就有很大的风险,例如:会出现需求不全、需求范围界定不到位、需求分类不明确等因素，我们应该把需求规格说明书拿来后先罗列许多要点：约定、法律法规、需求分类、技术限制、采用的技术和工具等等全面考虑，与项目干系人特别是用户进行沟通，然后讨论，可以采用头脑风暴法和德尔菲方法来讨论，确定说明书大纲，而不能照本著书。

    2) 附加文档的管理，值得注意的是需求说明书并非一成不变的，我们可以通过附加文档来跟踪用户的新的需求和需求变更，这样必须建立一个配套的文档集合，随时跟踪需求，保证开发团体步进统一，一般这些文件是要考虑的：《需求(或功能)变更申请书》、《需求(或功能)变更规格书》、《需求清单一览表》等。这样做的好处是对需求时实监控，保证项目的安排，同时让用户知道变更是一件很严肃的事情，可以防止个别人提出无法界定的需求(因为现实IT项目中，很多问题是其他系统的遗留而又超出本项目技术线路可以弥补的问题等)。

    3) 编写需求说明书的时候，可能还会遇到一些解决不了的需求，我们也一定用专门的章节要罗列出来，防止漏项，同时也利于我们在做实施计划的时候来采取那种措施，采购其他设备、投入相关人力或其他办法。

    4) 需求必须要客户确认，许多项目，可能开发商为了保护自己的“利益”很多事情都没有得到客户的确认，其实在需求阶段，我们的需求是要跟客户确认的，比如数据字典、界面选型、技术线路、功能模块等，这样做的好处是防止需求把握不得当，缺少了用户必要的功能，另一个就是防止了开发商需求镀金，提供了不必要的功能。

    5　总结

    经过以上各个方面来讨论需求管理在整个项目生命期所起到的作用，结合自身的经验，和一个案例《某市网上审批系统》综合分析了需求管理的办法和用到的工具，根据自身经验提出编写需求说明书要注意的地方。