《如何做好项目中的需求管理.pdf》由会员分享，可在线阅读，更多相关《如何做好项目中的需求管理.pdf（6页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、-如何做好项目中的需求管理如何做好项目中的需求管理2021 年 1 月 15 日摘要：摘要：项目需求管理是软件设计和实现的基础，是构成任何项目范围的基础部分，也是项目能否建设成功的基础。本文主要通过对信息系统项目管理知识的系统学习并结合多年来自己参与部分软件项目实施的工作经验，介绍在项目建设过程中如何对需求进行有效的管理探索出的一些有效措施。关键词：关键词：需求获取需求分析需求评审 需求变更如今尽管有关开发的知识和经验不断丰富，可利用的工具也不断增多，但仍然有相当比例的软件项目失败，原因常常是因为在开始时没有正确地确定和定义需求，或者随着项目的展开没有正确地管理需求，对获取到的需求没有进行有效
2、的分析，或者获取到的需求本身就是不准确的。软件需求管理正是解决用户这种需求，软件需求管理是关乎软件项目开发成败的重要因素。现在的软件项目中返工开销几乎占了总开发的一半，而导致返工的主要原因是需求分析不明确。从而引发项目开发中的一系列更改。这些更改可能导致浪费大量的资源、软件项目无法按时完成等严重问题。本人通过对软件项目管理知识的系统学习并结合近年来自己参与部分软件项目实施的经验，介绍在需求管理研究中探索出的一些有效措施。一、明确项目干系人项目干系人又称为项目相关利益者，是指积极参与项目、或其利益会受到项目执行或完成情况影响的个人或组织。项目干系人对项目的目的和结果施加影响。应当从项目的启动开始
3、，项目管理团队就要识别项目用户方干系人包含哪些人和组织，通过沟通协调确定他们的需求和期望，尽最大可能地明确项目干系人中的决策者在项目中所起到的作用，以确保项目获得成功。很多项目往往都是由客户单位的技术主管部门主导，项目经理在前期接触时，跟这些技术部门接触的比较多，而没有和业务部门或系统开发完成后的实际的使用者接触。该类人员对技术比较精通，但对应用部门的相关业务可能不是特别熟悉，从而导致项目组获取到的需求发生偏差，在软件开发完成后和用户的实际需求相差甚远，导致用户频繁提出需求更改，更有甚者推翻重建。1/61/6-因此项目经理在与客户初次接触时应首先明确干系人，识别项目干系人及其角色，确定项目组的
4、组织架构，确定项目组各干系人的职责范围，确定对需求实现的最终决策者。二、熟悉业务采用合理方法获取需求在明确了项目干系人后，那么在这个项目中各个业务场景，业务流程，业务规则，组织结构和岗位角色就是我们在接下去所需要重要调研的内容。而往往一些项目经理在获取需求的过程中，仅仅是充当了一个“书记员”的角色，即客户说什么？他就记录什么？在获取的过程中缺少与客户的互动。我们的的目的是为了搞清楚用户的业务现状和问题，而不是简单的听到或问到用户要什么，因为有些客户自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。我们一般可以通过双方对需求的了解情况上，分为四种情况：开发方和用户方都清楚项目需求；开发方
5、不清楚项目需求但用户方清楚；开发方和用户方都不清楚项目需求；开发方清楚项目需求但用户方不清楚。针对这四种情况，我们可以采用问卷调查法、会议讨论法、界面原型法、原型系统法来获取客户的需求，这四种方法可以在需求获取过程中组合使用。我们结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。用户可以操作简单演示的 DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超
6、出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，这样才能设计出真正符合客户需求的系统。通过界面原型法或原型系统法，使客户人员能够比较直观的明白以后他们的业务流程在系统中是如何展现的，使客户人员对系统有一个观感上的认知，同时项目组成员也能够明确客户所期望的产品是怎么样的。使用上述方法有以下优点：(1)增进软件开发者和用户对需求的理解，使比较含糊的具有不确定性的软件需求(主要功能性的需求)明确化；(2)可以容易地确定系统的性能，确认系统主要服务的可应用性，确认系统设计的可行性，确认系统最终作为产品。2/62/6-三、分析需
7、求的可行性在需求获取过程中，项目组收集的需求往往存在以下几问题：需求范围超出合同范围；对同一功能，各干系人提出的需求不一致；存在明显不合理的需求；对需求理解发生偏差。因此对获取到的需求进行有效、准确的分析是必不可少的步骤。在项目建设过程中，不同的项目用户方干系人其愿望和追求的目标可能会存在不一致，有些干系人的期望值较高，远超合同建设范围；而有些干系人提交的需求，相互之间不一致，造成需求冲突。因此需求分析人员应对获取到的需求进行整理并进行有效分析。对于超出合同范围的需求，可由商务一起协调进行增补或在二期中进行建设；对于需求不一致的，可召开项目协调会，由甲方最终决策者拍板确定或寻求平衡点折衷处理；
8、对于需求理解偏差和客户描述不清的需求，可通过原型界面法，反复确认。因为对于需求分析是需求管理中很重要的一个工作部分。对获取到的需求，进行优先级评估。需求分析人员应分清客户提出的需求，哪些特性是必要的，哪些是重要的，是需求开发的主要部分，设定这些需求的优先级，并与客户进行讨论明确。因为开发者应该按照客户的观点决定项目需求的优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，
9、或在质量上寻找折衷。在需求分析过程中，应尽量使用已有的软件组件来实现，以节省资源。需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。很多时候，用户的想法在实际实施过程中是不现实的。若一味地求全和盲目遵从用户的设想，将为项目的后续工作带来很大的风险。因此应尽量避免在需求3/63/6-分析中包含技术实施上有难度的功能。四
10、、编写需求规格书和进行需求评审在准确领会客户的意图后，软件需求规格说明书就是需求分析阶段需要产生的最主要的文档。准确而详细地编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，在编写文档时，开发人员严禁采用“猜测”的方式编写。在需求文档中暂时加上“待定”标志是个好方法。用该标志可指明哪些是需要再进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一
11、时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。需求规格说明书的每个功能点的描述要通俗易懂，能够使客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。所以分析说明书对功能细节的描述不能有歧义或二义性，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。需求规格说明书一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的审核，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题。需求文档完成之后，
12、并不是把它扔给后面的设计人员就了事了。作为项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求分析也是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务。4/64/6-五、做好项目需求变更管理在软件项目建设
13、过程中，需求变更是不可避免的，但在开发生命周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。分析人员及时评估，为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。在不放弃所提出的需求变更情况下，对每项要求的变更进行分析、综合考虑，最后做出合适的决策。造成需求变化的原因有很多。比如:随着项目的进展,开发方和客户方对需求的了解越来越深入,原先的需求文档可能存在这样或那样的错误和不足,因此要变更需求;以或者由于市场、业务发生了变化,原先的需求文档
14、可能跟不上当前市场的要求,因此要变更需求等等。需求的变更问题是每个开发人员、项目经理都会遇到的问题,需求的变更不一定是坏事,常常提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。但是一旦需求发生了变化,随之而来的将是不得不修改设计、重写代码、修改测试用例、调整项目计划等问题,对项目开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,这将为项目的正常进展带来诸多的麻烦,开发小组也要为此付出较重的代价。当然在软件项目建设过程中，并不是所有的需求变更都能够被采纳的话，要学会适当的拒绝，通过变通的方法实现。否则有可能，这个项目也许永远不能按时完成，进度无限期滞后。因此在
15、需求变更过程中最难办的事情就是拒绝客户提出的需求变更请求,通常情况下开发方是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。因此作为一名项目经理，你应当规范需求管理，对客户的需求变更进行评估分析，对变更带来的影响、成本和得失告知客户。当然开发人员不能由于不想实施变更而随意夸大评估成本。结论：结论：项目需求管是是一个项目建设生命周期中的一个重要开端,也是项目建设成功的基石。在以往建设失败的项目中,80%是由于需求的不明确或需求变更没有控制好而造成的。因此一个项目成功的关键因素之一,就是对需求管理的把握程度。参考文献：参考文献：5/65/6-【1】软件需求管理用例方法第二版莱芬韦尔【M】中国电力出版社 2004【2】软件需求管理K.E.维格斯【M】机械工业出版社 20096/66/6