需求变更的管理流程
开篇：润墨网以专业的文秘视角，为您筛选了八篇需求变更的管理流程范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
需求变更的管理流程范文第1篇
按照UCM的方法，我们也将CPMM的组成部分抽象为不同的工作流，其中最重要的工作流程包括：
1、变更预估流程 （Change Forecast Process，CFP）；
2、变更请求与处理流程 （Change Apply and Manage Process，CAMP）；
3、变更评估流程（Change Evaluation Process，CEP）。
CFP在软件工程项目的初期对工程中可能产生的变更进行预估。这是在软件工程项目中经常被忽略的流程。通过这个流程，可以在软件的时间和经费预算中提前考虑变更所带来的影响，同时在软件项目的设计和规划中预留接纳变更的空间。保证在产生变更的情况下软件工程项目仍然能有序地进行和正常地完成。
变更预估是软件工程中比较难以把握的方面，目前的预估都是依靠个人经验的主观判断。这样的预估存在准确性低和不能量化的缺点，这对软件工程本身并不能提供有用的帮助。CPMM中的CFP流程对软件工程中的变更评估采用定量的计算方式。在进行项目的需求分析时，通过对影响项目变更的因素，如评估项目的创新程度 T(1)、客户对项目的把握程度 T(2)、我方对项目的把握程度 T(3)和需求调研的详细程度 T(4)等方面的数值，计算出软件项目的各个过程中可能发生的变更概率。由此对软件工程项目的预算、项目规划提供有力支持。
软件工程步骤i可能产生的变更概率如下面“变更预估公式”所示：
其中：V (i)为软件项目过程i完成时可能发生的变更概率。
C (ij)为各项因素对变更比率产生影响的系数，这个系数需要根据不同的开发小组情况和项目类型有所不同。系数的产生和修改则需要根据变更评估流程产生和修改。
D (i)为修正因子。
CAMP是在项目中接纳变更的处理流程，包括变更的提交、审批、实施及完成。CAMP主要强调通过规范的方式接纳变更，并且通过各种有效的手段严格控制变更被引入的方式和时间，确保系统开发的有序进行。CAMP主要通过图1所示的流程处理变更：
需求变更的管理流程范文第2篇
关键词：项目管理；需求管控；成本控制
中图分类号：F27文献标识码：A
随着信息时代的来临，IT行业发展迅猛，各行各业都试图通过IT系统支撑其业务发展，提高效益。但从整体看，IT行业项目管理程度较低，据了解，国内真正实现或基本实现项目目标的IT项目占比很小。究其原因，不少失败IT项目在项目管理方面都不同程度地存在着这样或那样的问题，而在这当中，有很多都是对IT项目实施中的需求变更处理不当造成的。
一、IT项目需求变更问题
完整的IT项目需求管理一般包括业务需求、用户需求、功能需求、非功能需求和需求分析报告等五部分内容。其中，业务需求来源于业务发展需要，用户需求来源于用户实际功能要求，功能需求来源于业务部门管理的流程及思路，非功能需求来源于用户的习惯爱好，需求分析报告则是IT人员对上述内容的汇总。但在IT项目管理实践中，往往不能全面地获得上述资料，原因很多，比如用户对未来业务预估并非准确、用户本身也许并没有完整的阐述其需求等，这一切的结果，就是项目经理时刻面对着用户不断提出的需求变更。为应对这些需求变更，项目经理只好在实施中不断调整项目计划，其结果就造成了项目成本难以控制，项目交付日期不断推延，以至于IT项目管理当中流传着这样一句笑话：做IT项目哪有不延期的。
客观地说，需求变更这种情况的出现几乎是必然的，因此如何解决需求管控，并对其进行有效处理就变成了IT项目经理的必修课。IT项目需求之所以变化，是IT项目需求本身的复杂性造成的。与传统项目比较，IT项目的需求相对模糊，变动较大，主观随意性较强，具体体现在以下三个方面：
1、需求的准确描述。需求来源于客户，但很少有客户会很认真地准备需求文档。笔者在项目当中经常见到的情况都是甲方简要的提出自己的需求（三言两语而已），或者甲乙双方在需求沟通会上做一个业务设想的沟通交流，这样造成了需求最初来源的简易化和随机化。一般情况下，乙方会根据沟通会上的情形对甲方需求进行还原，最终形成上百页的需求文档，并交由甲方签字确认，以此作为需求的文字来源。如此操作在表面上看来是完备的，但实际工作当中，需求往往来源于甲方不同部门、不同层次的业务人员，不同的人员对业务的理解自然也带有自身的本位想法，对系统的关注角度也不尽相同。这可能就此造成了需求的矛盾与歧义（此问题是可以在甲方层面上协调解决的）。甲方确认需求当然是毫无疑义的，但甲方是否系统的、全面的审阅了乙方还原后的需求汇总，那就不得而知了。
同时，甲乙双方对于需求的理解也有一定的差距，比如作一个登录用户的认证功能，对于甲方来说可能有自己先入为主的认识，很可能乙方也已经有了自己的理解，在这样的沟通过程中，甲乙双方很可能就迅速达成了“共识”，当按照乙方理解开发出来的最终产品呈现在对此功能已经有了设想的甲方面前的时候，此功能的需求文档就成了双方掰持不清的糊涂账。
另外，由于甲乙两方在业务知识层面上属于两个不同的方向，这样很可能造成需求的完整度不足。一般来说，甲方对业务更为了解，技术业务层面了解相对较少；反之，乙方亦然。这样就造成了双方沟通需求的时候，甲方提供的需求完整度不足，比如，甲方提供了必须实现的业务需求，乙方忠实地作了记录，并根据沟通了解了甲方的需求内容，但甲方只是提供了自己的需求、想要的功能，要知道系统是由多个功能模块组成的，甲方很可能把一些其自认为是常用的功能模块作为必须功能而未作阐述，这就造成了需求功能的缺失。
需求的详细准确程度也是一个大问题，在明确需求的时候，往往甲乙两方只是对某一需求达成了共识，但可能并不明确这个达成共识的需求具体如何实现，也许乙方的实现并非甲方所愿，如甲方要求实现某种数据检索，乙方的实现方式只能支撑低量级的数据量，碰巧实战当中要检索的数据量是天量级的，这就造成功能失效。
2、明确需求工期不足。需求的生成也是需要工期的，对于甲方来说，需求由乙方前来调研，开完需求调研会，再开几个碰头会，需求调研应该就算完成了。对于乙方项目经理来说，这种工作恐怕只是开始。如前文所述，需求的准确获取需要大量时间，还需要相当一部分人力资源，对需求进行推敲、确定。但在实际工作当中，甲乙双方的上层很难认同这种耗费时间且没什么直接效益的工作，如此就造成了如下现象：项目经理为保证需求的准确性拼命拖时间；甲乙双方上层因为见不到成果不断对项目组施加压力；由于需求的反复沟通修改，项目组成员也对此感到疲乏厌倦，希望尽快了结此项工作；多方权衡的结果，很可能就造成项目经理的退让。在这样情况下诞生的需求文档，其有效性、稳定性就有可能是有限的。
3、项目需求变化极快。不同于工程类项目，IT项目的变化极快，尤其是互联网类型的项目。前文中我们了解了需求不完整这一情况，需求调研的不完备、不准确都会给后边的项目实施带来变数。在互联网时代，业务的诞生几乎是爆炸式的，新的业务往往会对现有的项目造成影响，甚至是颠覆性的影响，这也给项目实施带来困难。
在项目实施当中，随着时间的推移，用户、业务都在发生转变，由于操作人员、系统、业务流程之间的关系发生变化，业务发生变化，自然需求也跟着变化。在互联网项目当中，往往某些项目带有突发的革命性需求，如甲方设计一个搜索网站，必须保证与业界同类型的网站保持一致，若业界出现了一个全新的极受用户欢迎的业务，那就必须把此项功能加入，否则可能本项目就算完成，也不能达成甲方项目设计的初衷。此案例中的需求变化对项目造成的影响可以说是颠覆性的。
二、IT项目管理需求变更对策
以上几点是笔者分析项目需求变化的原因，对于这样的需求变化，必须有对于需求变更的管控办法或者处理策略，否则这些需求变更造成的项目成本增加、进度推迟恐怕会毁了项目实施。笔者认为，对于上文所提到的项目需求不完备等情况，由于现时情况不太可能得到彻底的解决，因此只能在后续的项目需求管控当中进行补救处理。
1、需求评审流程化处理。对于需求的变更、增添认定均需要走专门的流程。可能有不少同行感觉这样要求有点多余，但笔者认为新的需求变化都是在业务演进过程中逐步出现的，对于需求变更的评审，有助于项目组加强对业务需求本质的把握与理解，有可能通过对新需求的评估，推断出业务的演进方向，或者增加项目需求的完备程度。同时，对需求的评估也可以使项目组更好地把握现有的工作进展情况。
2、需求确认。任何需求的变更，都不可避免地影响到项目的工作量，进而影响到进度，且项目需求来源于甲方，因此需求的确认必须有甲方的签字确认。对于乙方来说，所有的这些需求的实现都是有投入成本的，这些成本的来源就是甲方的“签字”确定的需求或需求变更。笔者曾经历过一个IT项目，在该项目实施过程当中，为避免风险，邀请一个甲方业务人员作为业务指导，项目期间项目组对甲方代表的意见言听计从，根据其要求对项目的某些部分进行大量变更，因此延误了项目工期，且发现项目上线后，某些其建议功能并不为甲方整体认可，为此还得修改，其间造成了不少无用的工作，此部分项目投入没有任何意义。这一案例表明，项目需求的变更应经过甲方官方同意，若甲方业务决策人员知悉此问题，就可能避免这部分无效投入。
3、项目计划冗余准备。项目计划冗余准备是指在项目计划当中，对项目投入准备一定比例的富余量。在具体项目实施项目中，项目变更几乎是不可避免的，这些变更包括需求变化、风险的发生等多种情况，若在项目收支许可的范围内做一定的冗余准备，在较小的变更发生时，就可以通过项目计划当中的富余资源处理，从而保证项目实施进度。平心而论，这种操作办法是要让乙方投入更多的成本来完成项目，对乙方不太公平，但在商业项目当中，若能尽早完成项目，就可以保证乙方的大部分利益，适当的平衡一下投入上的取舍，也是很好的解决办法。同时，本办法也适用于项目的风险处理。
4、商务处理办法。笔者曾经见过一个工程项目，在此项目合同中确定了工程的基本工作量预估，并明确当实际工作量超过预估工作量的10%以内时，由乙方自行承担；若超过10%限度，根据超出工作量多少，结合合同约定的单价进行处理。此案例给了我们另一个解决项目变更的办法：通过商务合同中对工作量的约定，来保障项目的实施。案例当中的实际工作量异常，可视为IT项目当中的需求调研不完备，或是需求变更造成的实际工作量增加，若在商务合同当中明确有关工作量、超额工作量的约定，就可以按照合同约定解决由于需求变更而造成的项目成本、进度问题。
（作者单位：北京交通大学经济管理学院）
主要参考文献：
需求变更的管理流程范文第3篇
关键词：软件项目管理；需求管理
中图分类号：TP311 文献标识码：A文章编号：1007-9599 (2011) 17-0000-01
Demands Management in Software Project Management
Yuan Jue,Hu Jun
(Shanghai Asia&Pacific Computer Information System co.,Ltd,Shanghai200040,China)
Abstract:Demand management is the foundation in whole software engineering management,also is to determine key of success or failure.This paper discusses the importance of demand management,the existing problems.In the light of these problems,puts forward relevant solutions.
Keywords:Software project management;Demands management
何谓需求管理？理解需求管理的第一步就是对什么是需求管理达成共识。需求是正在构建的系统必须符合的条件或功能，符合某些需求决定了项目的成功或失败，因此找到这些需求、记录它们、追踪它们的变化，都是很有意义的活动。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
一、需求管理的重要性
系统开发团队之所以管理需求，是为了让项目获得成功。满足项目需求即为成功打下了基础。2001年，Standish Group的CHAOS Reports报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四的项目是失败的，即这些项目不能按时按预算完成，其中提到最多的导致项目失败的原因就是“用户需求变更”。
软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，是软件开发的第一步，关键的一步，也是最难把握的一步。项目管理过程中，项目经理经常面对用户的需求变更，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气越来越低落，直接导致项目成本增加、质量下降及项目交付日期推后。这些都决定了项目组必须拥有需求管理策略。
二、存在的问题及解决策略
（一）项目干系人的确立
项目用户方干系人，指所有可能受到项目结果重大影响的人，即可能是项目的受益者，也可能是项目的受害者。项目用户干系人往往涉及到多个层面、多个部门的用户，其中的关系错综复杂，对项目的需求也不尽相同，甚至是相互矛盾冲突的，这些大大增加了需求调研工作的难度和不确定性。
因此，从项目启动初期，就要分清项目用户方干系人包含哪些人和组织，在组织结构图基础上，勾画出全体项目用户干系人结构图，明确项目干系人之间的关系，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。
同时，不同的项目用户方干系人其愿望和追求的目标往往相差甚远，因此对项目用户方干系人的愿望进行平衡是一件非常重要而又相当困难的事情。当不同用户方干系人有不一致的需求时，必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用系统的用户种类、各类用户对系统的用法、以及与系统业务目标的关系，将有助于决定哪一个用户类所占份额更大。当开发者想象的产品与客户需求冲突时，通常应该由客户做出决策；然而，不要陷人“客户总是对的”的陷阱中去，现实中，客户并不总是对的。
（二）需求描述的细致性、准确性、完备性
一般来说，需求描述越详细越好，但系统的需求是层出不穷的，并且随着时间的推进，用户的需求也会越来越多，要在需求分析阶段做到穷举需求是不可能的。因此在需求描述的问题上，如何把握需求阶段投入的人力、时间、需求描述的细致程度，是没有统一的界定，需要需求分析人员学会适当的把握，采取恰当的需求获取方法，尽可能详尽到位的挖掘用户需求。
首先，项目需求包含明确的和隐含的，也可以分为NEED，WANT，WISH等不同的层次。为了获取最贴近用户的需求，应对项目所有用户方干系人进行足够的沟通，使其尽可能地参与项目，尽可能避免出现用户相关责任人不明确、提出的需求具有太多的随意性、项目前期对需求的确认不够积极、项目后期需求变化随意等极可能造成项目范围的蔓延，进度的拖延，成本的扩大，甚至项目的完全失败的现象发生。
其次，各种用户对系统的要求不尽相同，比如一个没有经验的用户更关心系统是否简单易用，对于高级用户则关心系统的易用性和高效性。因而需要对用户进行分类，每一个用户群将有自己的一系列功能和非功能要求。在项目中，要尽早为系统确定并描述不同的用户群，这样就能从每一个重要的用户群中获取不同的需求。
最后，当面对缺乏计算机知识，无法提出完整准确、隐含或潜在需求的用户，可以利用各种可视化需求调研的方法启发引导用户清楚地叙述需求，使需求更加全面完善。需求分析人员应善于想用户所想，用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。
（三）需求变更的控制
需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化好比是万恶之源，为项目的正常进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。
软件开发过程中有这样一条真理：需求的变化是永恒的，需求不可能是完备的。因此软件开发的过程实际上是一个变化的过程，需求变更贯穿软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳入计划之中是完全必要的。
实现需求文档的版本控制是最基本的。变更的需求之所以变得难以管理，不仅是因为一个变更的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接表达需求与开发生命周期的其他工件之间的依赖关系。
三、结束语
需求管理是一个持续的不断完善的过程，软件项目开发过程中需求管理的问题有很多，随时都有用户提出需求变更，需求分析的错误也时常发生，需求质量难以保证，针对这些问题，如何采取有效的措施尽可能减少这些问题可能给项目造成的影响显得尤其重要。另外关于需求的质量问题，怎样结合CMMI标准进行需求的质量管理，有效提高软件的总体质量水平也是值得我们关注的问题。
参考文献：
[1]毋国庆等编著.软件需求工程[M].机械工业出版社,2008,8:1
需求变更的管理流程范文第4篇
经营决策阶段成本是指公司经营方向的选择，这是成本管理的第一个也是最为核心的环节。不过对于大多数IT软件业公司而言，这个阶段往往是最大的问题之所在，有时经常凭一个觉得是灵感的想法或者对市场初步的直观层面的调研就进行的决策。而这样的结果是往往没有摸透市场的真实情况，轻率上马项目，造成方向性错误，以至于导致企业的危机。
该阶段的成本控制，关键在于经营决策前科学而深入的市场调研及准确分析，目前很多中小型IT软件企业，其经营部的职员大多都并不是社会调查专业的，因而他们做市场调查的过程中所采用的方法不太科学，如在样本选取及抽样过程不合理，没有按照严格的社会调查方法进行调查和数据分析，甚至问卷设计都存在倾向性导致调查数据信度偏低。此外，大量的公司自我宣传的各种形式的软文和竞争对手有意的攻击性文章夹杂在其中，并不是很容易的进行分辨，更何况数据的随意性，来源的不可追溯性各种情况，所以只能作为参考。
2需求整理及分析确认阶段的成本及其控制
需求整理指市场经营人员根据高管对于市场方向的决策，而提出的具体的产品或者项目的原始需求，需求分析是指技术员对市场部门的需求进行分析，评估其可实现性以及实现难度，大致工时等，提交相关需求分析报告，最后市场经营部门进行确认这个阶段。
该阶段的成本控制，首先需要搞清这种沟通过程中产生偏差的原因，最为主要的往往并不是技术语言和市场语言的差异，或者市场人员和技术人员之间的思维定势的差异，而在于两者缺乏确定的科学的流程和在交流之前的准备以及相关概念约定俗成的定义造成的问题，同时还由于沟通和确认环节由于其特殊性，经常难以被有效的纳入进度管理程序流程当中。而提高该阶段的成本控制效率，必须逐一针对性的解决以上问题，首先要清晰的确定并严格执行市场和技术沟通的流程，尤其是要明确每个环节的控制点，也就是双方交付给对方的关键交付物，一定要有清晰的共同确认的模板，同时每次沟通前必须对于一些概念有着清晰的界定，然后公布这些信息，并在沟通前做好充足的准备，明确每次沟通前要沟通什么，要解决哪些问题，沟通结束后要交付哪些文档让双方进行确认等，同时一定要通过线上或者线下的管理模式，讲所有沟通环节全盘把握，并纳入进度管理。
3规划阶段成本及其控制
规划阶段成本是指在需求已经得到确认后，进入技术规划阶段的相关成本控制，该阶段有些软件开发公司常常出现的问题是对于规划予以过度的期望和过于沉重的内涵，在实际项目操作过程中，这个规划实际上包含着技术规划和非技术规划两个部分，因为对这两个部分的混淆，导致一些技术层面和市场层面的东西不必要的纠缠在一起，并且直接导致项目进度的拖欠，而且会导致由于非技术规划的不清晰，直接影响技术规划层面的实施。
该阶段的成本控制，必须清晰的区分非技术规划和技术规划，尤其在公司内部技术部门和市场经营部门之间的职责，需要设立一个在提出需求到技术规划之间过渡的位置，即对于需求具体细节的整理，要对于交付物有着清晰的确定，尤其是在不同时期交付不同的关键文档，如除了上面说的那六个文档外，技术部项目组长在需求分析的时候，还应该明确提交功能模块分析，开发代价，功能流程图，功能关联性图，可维护性及可拓展性分析等六个文档，此外在项目开发规划阶段，还要对于控制点的一些要素进行详细的规划用来提交给市场部门，如详细页面元素，页面元素价值度分析，表现形式，页面结构，页面效果等。
4开发阶段的成本及其控制
开发阶段的成本指需求确定并且规划清晰后的具体开发过程的成本管理问题，该阶段相对其他阶段来说比较清晰，但这里笔者认为需要关注的是，如何使得人力资源得到最大程度的利用，它是指公司第一线技术人员的能力最大程度发挥的状态，包含几个层次，（1）全部时间利用，（2）最大效率利用，（3）最大潜力激励利用，这三步需要逐步递进实现。这个需要一种完善的内部管理制度，以及公平公正的价值认定模式和绩效制度，从而一方面促进员工本身的发展，一方面增加对人才的吸引力。
该阶段的成本控制，可以引入最大可控制成本的概念，这里是指人力资源最大程度发挥后所能控制的成本，是公司在一定投入前提下，最大的可能的减少因管理导致人力发挥不足够而造成的成本，该成本为人力资源的极致成本，无法再进一步降低，此成本状态下的仍然出现效益不佳情况，则可说明在经营定位和经营方向上的问题，而非内部问题。促使人力资源得到最大利用度和发挥度，在此基础上的成本，为最大可控制成本，以上可以通过内部的管理系统来很好的实现。
5需求变更成本及其控制
需求变更成本指在开发过程中，由于市场部门的需求改变导致的成本增加而实施的控制，对于项目开发的过程中，需求的频繁变更就成本控制而言是致命的，很多项目由于需求的变更而导致破产。
该阶段的成本控制，最关键的是要对于需求变更过程进行严格的管理，要从需求变更的开始，对于整个变更的每个具体的步骤进行跟踪，并且严格核算每次变更所需要的工作时，从而做好评估。同时，务必要明晰需求变更的必要性和风险性，以及所带来的实际成本的增加，所以需求要尽量经过详细的论证。
6测试成本及其控制
需求变更的管理流程范文第5篇
关键词：项目需求；需求管理；软件需求
中图分类号：TP311 文献标识码：A 文章编号：1007-9599 （2013） 02-0000-02
1 引言
社会的不断进步促使产生许多软件公司，使他们之间的业务合作与竞争关系越来越普遍，随之而来的是客户需求的不断变化，这使得从事软件开发工作十分困难。软件开发的根源是客户的软件需求，因此，软件需求管理在软件行业中具有十分重要的地位。在我国，许多软件公司很多时候并不能达到客户的需求，所以我们对软件需求的开发管理过程进行研究具有十分重要的价值和实践意义，能够为以后软件需求管理提供一定的指导作用。
2 项目需求工程基础
为了更好的使项目的开发方和项目的委托方对所合作的项目能够产生清晰的认识，并且可以在以后的合作过程中能够顺利完成要求工作，我们就运用了需求工程。所以需求工程在项目的进行中具有举足轻重的作用，它是针对所有与需求有着直接或者间接联系的工作的总称。按照活动不同将需求工程进行分类可以分为需求开发和需求管理两大类别。从根本上来说需求工程就是为以后我们所进行的项目进行系统概述，并且进行指导，所以它具有很好的实用价值。
在软件行业中，软件需求针对开发商所涉及的软件规格进行系统定义说明，在开发的过程中，软件需求对于整个软件系统的特性和进展状况进行概述，对开发进程进行全方位约束，促进软件开发的顺利完成。软件需求针对不同的应用方面起到不同的作用，一般分为：针对用户的需求、针对业务性质的需求、针对软件功能的需求、针对商业进展的需求、针对软件设计的需求以及针对软件整个系统的需求，这些在实际的软件开发过程中会经常用到。
在软件开发过程中，软件需求如果运行不能顺利，软件开发商与需求客户之间会出现分歧，开发商的设计过程不能够满足客户需求，对整个项目的进展状况产生严重的影响，很大程度上会导致整体系统的失败。因此，在软件的开发过程中，如果能够把握好软件需求，能极大的提高软件开发的速度，提高软件开发设计的效率，为企业增加效益。
3 软件需求开发与管理
3.1 软件需求开发。在软件工程中，软件的设计周期一般分为需求阶段、设计阶段、编码阶段、测试阶段和维护阶段。软件需求开发是首要步骤，在所有进行的工作中，它始终占有重要的位置，为整个软件工程的进展起到铺垫的作用，决定了整个项目结果是否满足客户的需求。
一般情况下，软件需求开发主要包括以下几个步骤：
（1）针对客户的需求进行调查研究。使用不同渠道搜集各种信息，来得到客户的最根本的需求。一般来说，获得软件需求由很多种不同的方法，根据不同的情况进行使用，具体方法如下：直接接触客户，咨询相关问题；参与客户实际工作状态，了解客户真实工作需求；针对客户工作场景进行分析；进行与客户相关人群问卷调查或者市场调查；请教用户工作领域内专家学者，听取他们的意见；收集已有或者同类软件资源，分析其运行状态；通过互联网进行国内外技术方面资料查询等。
（2）针对客户调查研究进行客户需求分析。分析以上所收集的客户根本需求的各种材料信息的真实数据，处理数据，补充遗漏细节问题，完善需求文档方案，确保最终能够完全正确的达到客户的要求。
（3）对客户的需求进行项目需求制定。在前面所做工作的基础上，完整的按照客户要求编写客户需求文档，即《需求规格说明书》，整个项目参与人员必须都要依据此项目说明书进行以后的开发设计维护等工作。
3.2 软件需求管理。在网络急速发展的今天，软件需求管理包含项目评审、跟踪、以及变更控制三项，三项完成的好坏关系到项目能否成功，它们相互制约集成为一体。无论其中哪一个环节出现差错都会影响整个系统的完成情况。下面我们着重对需求管理中潜在的问题和出现问题的应急措施进行阐述。
（1）需求管理中潜在的问题。源于需求管理在项目实施中的关键作用而言，对于某一项目的描述应尽量细致。但在实际实施过程中，经常会出现只要基本要求达到预期效果即可，详细的细节便可省略或过后再补写。这样就会造成用户信息不详，项目与项目之间没有统一的标准，在项目竣工后的整理规划非常困难，难以实现再改进。
开发人员对用户描述的正确性有待把握。技术人员和使用者之间存在对专有名词理解的代沟，致使在需求理解方面存在偏差，经常会出现用户需求与软件描述不一致的现象。如果用户想了解其需求的软件还要借助其他帮手，不仅浪费资源还浪费时间。
完整的描述也是软件卖点的关键。客户对软件需求目的不同，要求软件必须把所能解决的问题及解决的详细步骤写明。然而，随着社会的快速发展，客户需求的多样性决定我们不可能列举来所有的步骤，这样需求的完整性就难以达到。成为我们难以攻克的难题。
需求变更问题是软件需求管理的难题。就像地球每天都在自转和公转一样，用户的需求也不是一层不变的。用户需求一旦变化，要求程序、项目计划书等都要重新编写，为项目按时完成构成威胁。
（2）需求管理对出现问题的应急措施。终上所述，建立解决问题模块势在必行。用户的需求变更问题的解决是重中之重。如何认识变更，解决变更，就必须把用户的需求放在第一位，把用户的需求作为我们的终极目的。
首先，细节很重要，抓好交易过程中所有文档的保存工作。当用户需求发生变更时，工作人员要经过细致的评审，跟踪其需求基线的发展路线，为用户需求再次发生变更做有效的控制准备。
其次，正确理解用户需求变更。与生物链相似，每一个需求变更都会涉及到下面多个需求程序语言变化，意味着所有程序均要修改，不仅费时而且费力，所以建立一个具有一题多解式的产业链弹性结构显得更加重要，只要发生变更，软件会自动判断并执行用户需求指令。
再次，建立需求变更实施流程标准。由发生需求变更到最终实现变更需求，整个项目完成周期依次经历了发生变更、细致评估、跟踪变更和变更控制四个节点，每个节点都需要有一个明确的流程标准，并依此标准实现用户的需求。此标准包括需求变更的交易文档，详细的评审报告和执行变更指令所需要的所用文档。这样可以从实施过程中节省不必要的理论争议，有理可依。
最后，完善软件服务体系。服务体系包括用户需求接待、用户需求管理及与用户需求沟通，其中需求沟通是项目成功的关键。软件需求及需求变更的每一步都需要与用户充分交流，了解用户需求的终极目的，工作人员为用户分析并整理相关资料，找到最适合用户项目的软件程序。
软件需求管理要求其不断的更新换代，已由以往的简单发展到今天的复杂，形成了较为完善规模，但还存在着一系列的缺陷，这就要求工作人员继续研究和总结，深层次的剖析用户的需求，不断的改进软件需求管理水平。
4 结语
在软件工程中关于需求管理会出现很多问题，因此软件需求管理也会伴随着项目的进行不断的进行改进，如果能使软件需求管理做到完善，将会明显减少我们的工作返工数量，可以降低软件在开发过程中不必要的成本，提升企业的实力。因此，在以后的软件工程发展中，我们一定要认真对待软件需求管理，不断提高需求管理技术，在实践中认识软件需求管理重要性，这样才能更顺利的完成软件项目，对提高软件整体质量水平做出自己应有的贡献。
参考文献
需求变更的管理流程范文第6篇
乙方的项目经理往往非常害怕这类变更，因为一旦处理不好，项目就会失控，但现实情况是项目变更是常态。
ERP项目实施过程中项目经理如何管理“变更”呢？
调整ERP项目经理的心态
我在面试项目经理的过程中会问的一个问题是：你如何处理客户在项目验收阶段提出的新需求？相当一部分人的答案是：先和客户谈一下，能不做就不做。如果从企业方角度来看这个问题，我相信大多数IT经理的答案是：如果需求不做，我们一定不会验收项目。由此可以看到，项目变更往往事关甲乙双方关系。
前面这些项目经理的回答反映了典型的乙方心态。为了项目的进度与回款，不加选择地对客户进行拒绝（虽然有的时候拒绝得很有技巧），而乙方项目经理在采取这个方法解决问题时，往往没有考虑到客户满意度和项目质量，对于最终结果来说项目只实现了单赢――进度，而放弃了项目的双赢――质量与进度。
从客观角度来看，回避解决不了根本问题，如同前面所说，项目就是在不断的变更过程中不断推进的。即便是在项目的验收阶段客户提出了新需求，乙方的项目经理也一定要正视客户的需求，分析需求变更的原因，并对由此引发的相关影响进行评估，最终和客户明确应对策略。
分析ERP项目变更类型
项目实施过程中变更是正常的事情，但是否可以理解为项目变更就是一件合理的事情呢？首先要分析项目变更原因，然后根据项目的具体情况判定是否合理。项目中引起变更的原因通常有如下几类。
范围变更（What）：项目要实现什么（What）发生了变化。比如说某ERP项目的试点原计划是深圳和广州，但因为业务发展需求，需要把北京纳入到项目中，这就是典型的项目范围变更。这一类的范围变更相对容易处理。还有一类的范围变更则更为复杂一些，比如说原本项目约定梳理现有业务流程之后实现ERP系统的上线。但企业突然发现自己的业务流程不够清晰、岗位职责不明确、考核制度不完善，就想由乙方ERP顾问对企业管理进行诊断之后再实施ERP，毕竟业务流程梳理也是ERP厂商的职责之一。这时乙方往往会认为这超出了ERP项目实施范围，涉及到了企业管理咨询的范畴，这类的范围变更是否合理，则就需要看前期合同的约定了，但这无疑是许多ERP项目发生重大争议的原因。
项目目标变更（Why）：为什么（Why）要做这个项目也就是项目目标发生了变化。在ERP项目实施的过程中，许多人以为项目目标只是老板一句话的事，而且这个目标往往非常虚，是落不到实处的，但却不知ERP项目的目标，是随着企业信息化进程的深入、企业高层对于信息化的认识的深入、企业外部竞争环境的变化、企业业务发展的进程动态发变化的。
干系人变更（Who）：谁（Who）来完成这个项目有了变化。比如说由于项目小组成员离职导致的干系人变更，这种变更在项目实施过程中较为常见，在项目经理看来是在可控范围之内的变更。但还有一种变更让人头疼，如我们最近在实施的项目，乙方公司整体被收购了，该项目的出资方发生了主体变更，项目出现了重大的干系人变更，项目就只能进入暂停状态，未来是否能够重启还是未知数，这也是风险最高但概率最小的干系人变更了。
项目主体变更（Where）：在何地（Where）完成项目的约定发生了变更。这类的项目变更较少见，但在集团化运营企业中还是会存在的，比如说我曾经实施的某项目：原本约定ERP项目的试点是在集团总部+北京公司，但后来考虑到ERP项目实施的风险等问题，就将ERP项目的实施只放在了北京公司。
进度变更（When）：何时（When）完成项目的约定发生了变更。这也是项目中的常见变更类型，比如因为项目实施过程中企业有重要订单需要紧急交付，必须把ERP项目小组的关键用户都投入到业务生产中，而不再有精力顾及ERP项目实施工作时，企业方就有可能提出项目进度变更，从何使得项目延期完成。而进度的变更也往往受制于其它几类的变更，如干系人变更、目标变更、范围变更。
需求变更（How）：如何（How）完成ERP项目实施工作的变更。需求变更对于项目所带来的风险相对于上述五个W来说要小许多，需求变更是在蓝图方案的框架之下讨论如何实现的问题，在这个环节更需要关注的是技术可行性、实现代价（投入与产出）等问题。
ERP项目变更引发的后果
基于上述不同的项目变更类型，我们需要思考项目变更给项目带来的后果。如果从项目管理的“黄金三角形”来看，项目变更一般有如下几种后果――
项目成本变化（增加或减少）：这里的项目成本是指ERP产品模块的购买费用、ERP产品的用户许可费用、ERP顾问投入的人/天费用、甚至是由此引发的差旅费用等，而项目成本的变化往往导致项目双方重新进行商务谈判，基于上述基础签署补充协议。
项目进度变化（提前或延期）：这是项目变更之后最常见的后果了，无论是哪种变更，导致的直接后果往往是项目进度延迟，而许多ERP项目就是因为一次又一次的延期，最终在人疲马乏的情况下最终不得不宣布项目失败。
项目范围变化（增加或减少）：项目范围不断扩散（或者是变化）的主因就是项目主体变更、项目目标变更或是项目范围变更，项目范围的扩散同时也可能导致项目成本增加、项目进度延期。项目范围变化未必是件坏事，因为项目范围的扩散还有可能导致项目的质量提高（客户满意度提高）。所以，不要对项目范围变化产生抵触情绪，凡事有利有弊，在项目上同样也是这个道理。
项目质量变化（提高或降低）：这一项是在项目变更之后大家提及非常少的一点，原因之一是ERP项目实施过程中的质量标准非常难以衡量，所以大家在谈到ERP项目变更的时候，可以很清晰地识别到范围、成本与进度方面的影响，但质量这块根本无论深入进去讨论。再者，在面临着强势客户的压力时，乙方项目经理面临着范围扩散问题，但成本与进度层面得不到有效支撑时，就只好牺牲项目质量了。
制定项目变更流程与策略
通过前文的讨论，我们已经清晰了ERP项目实施过程中存在的几类项目变更，以及由项目变更引发的后果（或者是影响），那么我们可以据此制定一个项目变更流程与应对策略了。首先看看项目变更流程。
提交变更申请：项目团队中的任何人都可以提交变更申请，对项目的变更内容说明包括变更描述、变更原因、变更利益、变更成本、变更带来的影响、支持性文件。在这里需要说明的是，如果是企业方提出项目变更就一定需要说明变更所带来的利益和成本支出；如果是乙方顾问在向ERP厂商提出ERP项目变更，其变更利益有可能就是企业方的变更成本支出，而乙方的变更成本就可能是企业方的变更利益，其实这就是一个等价交换过程。
审核变更申请：由变更经理对变更申请表进行审核，以决定是否需要一份充分的可行性报告以供变更审批小组做决策。
识别变更可行性：决定是否变更的标准大致为实施变更给项目带来的风险、不实施变更给项目带来的风险、实施变更对项目产生的影响（时间、资源、财务、范围等各个方面）。
批准变更申请：变更审批小组可以做出拒绝变更、需要与变更相关的更多信息、批准变更申请、在特定条件下批准变更等决策。
需求变更的管理流程范文第7篇
下,如何持续地提高电信企业的综合竞争力从而占据市场是电信企业重点关注的发展主题。传统的电信运营信息系统面向的是网元、网络、客户、产品,如今伴随对电子化理念的不断提升,现在电信企业信息系统更将面向各种管理流程、内部用户等复杂的元素。而且信息化对各业务流程的不断渗入,相关系统日趋专业、复杂,以及众多第三方开发厂商的不断增加,都对管理信息系统的建设提出更高的要求。
2企业管理信息系统现状及面临形势综述
目前公司的管理信息系统已经涉及到公司的人、财、物、业务、市场管理的各个方面,主要包括企业内部门户、邮箱、公文、财务ERP、HR、工程管理、合同管理等系统以及各项业务管理流程(如IT需求管理、协同平台中包含的近50个流程)。随着公司业务及管理的需要,公司的下属部门单位已经增加到近50个,目前信息系统的全部有效用户已经近万人,并还在不断增加中。
当前电信企业的内外部环境日益复杂,从市场形势角度看,全业务运营带来的市场压力逐步显现、世博会带来的机遇与挑战;从集团公司角度,随着全国应用管理办法下发,将加大对应用的管理力度、全网业务需求(包括服务、数据产品、集团产品)进一步增加、强调系统能力的提升(如交流、检查);从本公司业务需求角度,需求提出对象人员继续增加、全业务竞争市场不平衡状态下业务产品更新频度高(家庭、集团市场)。所有这一切都要求公司的管理信息系统随时能够根据市场、业务、用户的需求及时进行开发、调整,保证相关业务工作的正常开展。
3企业管理信息化建设的几点思考
3.1需求工单管理
3.1.1如何确保工单的及时性,避免未及时完成引起用户投诉
落实IT开发工单管理人员,定期监督各工单的执行进度,及时协调开发过程中存在的问题。定期汇总工单完成情况,以内部通报形式抄送部门领导和各工单负责人,起到督促作用。在人力资源紧张的情况下,通过合并需求设计环节、设计开发人员的对口带教等方式,缩短开发周期,提高工单完成的时效。充分发挥公司IT需求管理系统的作用,工单执行过程中遇到需求变更、数据准备等影响工单完成及时性的情况,在工单管理系统中留下痕迹。及时协调厂商的开发资源,通过更换、补充、引入等方式,保证工单的及时完成。
3.1.2遇特殊、紧急情况工单,如何确保支撑工作的有效完成
每次遇到公司组织架构调整或者公司内部招聘结束,信息化需求变更单高速增长,内部充分协调资源,保证工作的正常进行,外部加强工单内容分析,根据重点部门、重点岗位、重点需求,把串行方式转变为并行方式,有序、及时完成IT需求变更工作。如遇到奥运、重大节日、会议等要求系统部门封网的时候,事前内部制定特别开发方案,合理安排工单进度,主动加强与业务部门沟通,合理安排封网前后的及时上线。
3.1.3跨部门工单,往往成为工单管理的难点
建立基于工单内容的责任人制度,分拆工单实施的具体内容,合理安排各方面工作进度,建立跨部门的联调、测试、上线工作机制。兼顾各部门工单管理的具体流程,通过内部工单等形式,将需其他部门配合的实施内容及进度予以书面安排,纳入到各部门正常的工单管理工作。应引起相关部门领导重视,通过他们及时协调存在的问题,确保工作及时完成。
3.2应用系统、项目建设
3.2.1在人员紧张的情况下,面对大量的系统建设,如何保证任务的及时完成
建立项目责任人制,充分调动合作方力量,统一安排各项目的实施过程,安排多个团队并行实施。项目实施的前期,安排专人负责通用专业规则的制定,如:前台风格、展示工具、开发规范,提高联调的成功率,减少不必要的修正。关注实施的阶段性成果,加快系统联调、业务部门试用的进程,注重正式运行环境的形成。在业务试用前期,紧密联系业务、技术主管部门,提前梳理准备必要的上线条件,提供UAT案例,尽快推动新系统的正式使用。参考网。参考网。
3.2.2如何避免业务部门的需求频繁变动,对应用建设产生的影响
注重与业务部门的有效沟通,了解业务部门真正急切的需求,突出重点应用,制订双方认可的开发计划,分阶段实施,边完善已上线的应用,边开发新的应用。把握应用建设的时效,主动联系主管部门对应用建设的具体内容、方向进行明确,尽量减少无效、重复开发工作的产生。合理区分BUG和新需求,设定明确需求的最后时限,尽量减少后期的变更影响系统上线的时效。 3.3应用推广 3.3.1需实现高层的应用需求和基层的生产运做有机结合 把握公司
的重点工作,进行数据整合、主题展示、信息化应用开发,集中力量支撑重点主题建设,增强对管理层应用需求的敏感性。主动了解业务部门的运做困难,加强数据提取、协作分析、数据跟踪等的技术支撑,解决生产运做的实际问题。参考网。
3.3.2新系统实施、推进,需改变用户原有的工作习惯,推进难度高
管理信息系统统的特点是通过对工作流程、管理流程的梳理,通过电子流程的再造,运用信息化工具提升工作的质量和效率,项目建设工作不能闭门造车,要实地调研,了解业务部门实物管理、流程管理的具体情况,使再造的电子流程能符合实际工作的需要。积极采用原型设计,分阶段推进原型的确认、试用,掌握技巧根据用户部门的承受度,边使用、边评估、边优化、边推广,有效有计划推进工作实施。
4结束语
管理信息系统的建设要求我们发挥使能者的作用,一方面主动联系业务部门寻找可以推进信息化的内容,另一方面从系统运行数据和用户报障中查找已有信息化系统的不足,并给出具体优化建议。加强管控能力,注重实施进度、狠抓开发测试质量,同时一切提升用户感知度出发,提升用户满意度。系统的建设要从流程规范化的管理向提高效率与质量并举、提升IT部门使能者能力的方向转变,从而能能够为公司业务发展、管理提升提供更加有效的支持。
需求变更的管理流程范文第8篇
【关键词】信息化项目建设;需求管理;管理分析;需求跟踪
引言
信息技术正以其广泛的渗透性、无形值价和无与伦比的先进性与传统产业结合，信息资源已成为与材料和能源同等重要的战略资源。信息化建设水平已经成为一个企业综合实力的重要标志，同时也是推进企业发展的助力器。
然而，据美国Standish Group的报告，只有26%的项目是真正成功的， 28%的项目是彻底失败的（即中途夭折的项目），其它的46%介于成功与失败之间。而且，报告还指出“不成功”的项目50%以上归因于需求管理。
用户是系统最终用户，因此在大型信息化项目需求管理过程中， 用户扮演者非常重要的角色。本文主要从系统最终用户的角度，对大型化项目需求管理过程中所存在的问题进行研究，并且针对目前大型信息化项目需求管理过程中存在的问题，给出可行的解决方案。
1.大型信息化项目建设的需求管理难点
需求管理是非常复杂和动态的过程，特别对于大型信息化项目，由于其项目建设范围和用户使用范围广、业务需求庞杂、系统架构复杂等特点，需求管理尤其显得更为复杂和困难，主要表现在以下几点：
1.1 需求收集过程中，用户缺乏需求收集的主动性
在大型信息化系统建设过程中，需求管理工作一般由软件公司主导，而本应该为系统需求管理主导力量的系统最终使用用户却往往只是被动的配合软件公司的需求收集工作。这种现象出现的原因主要有以下两方面。
一方面，由于软件开发公司更加熟悉项目调研的要点，能够对信息化项目进行整体规划和设计;可以从信息系统的角度，将业务流程更加专业的描述出来，便于项目的设计和优化。同时，软件开发公司需要最终对项目实施的成败负责，为此用户作为大型信息化项目的甲方，往往认为需求分析管理是软件开发公司的责任，在需求收集过程中，用户只是被动的配合软件公司的调查，只是被动的等待，缺乏主动性。
另一方面，大型信息化项目需求管理流程复杂，通常需要用户多个部门进行彼此合作来完成。如果用户应用部门缺乏对多个部门业务需求的综合考虑，那么所开发的应用系统会出现彼此失去关联的状况，缺乏综合性，在进行业务系统的整合时会使得这些弊端暴露无遗。
由于需求管理流程复杂，而且用户往往缺乏信息化项目需求管理的经验，感觉无从下手，只能够被动的等待、配合软件公司的需求管理工作。
1.2 需求管理过程中，用户对需求描述不清晰
在大型信息化项目需求管理过程中，需求梳理困难的问题主要表现在如下三个方面：
一方面，在大型信息化项目的需求管理过程中，用户熟悉业务流程，但是由于缺乏计算机技术知识。因此，用户往往只能够通过日常语言来对业务进行描述，缺乏计算机处理时所需要很多细节性的描述。
另一方面，由于缺乏具体的业务背景，技术人员可能会对用户所描述的需求产生歧义，从而造成开发失误。
由于系统用户和系统开发人员的生活、工作经验不同，如果双方缺乏有效的沟通，用户对需求的描述不规范，都容易导致系统开发人员误解系统用户的需求，增加系统开发风险。
1.3 项目建设过程中，用户难以保证需求落地
在项目开发过程中，为了保证用户需求被正确理解，需要对用户需求进行追溯。但是，在大型信息化项目建设过程中，需求追溯困难，其主要表现在如下两个方面：
一方面，大型信息化项目的功能模块众多，往往涉及多个部门，多部门之间的交互不方便。从而，导致开发前期的需求不够深入，直到系统的后期，用户还会提出新的业务需求，或者会对现有的需求进行改动。
另一方面，用户无法保证所提出的系统需求被软件设计人员所真正理解，但是在系统最终交付到用户手中之前，用户不能够确定软件设计人员是否真实的按照自己的需求在进行软件的设计和开发，最终导致用户需求难以落地。
2.大型信息化项目建设采用需求管理用户建议
针对目前大型信息化系统建设过程中需求管理存在的问题，用户应该更加积极主动的收集系统需求，并且通过规范的文档清晰、完整的表达其对信息系统的需求，同时设定合理的跟踪追溯机制，保证用户需求落地。
2.1 明确需求收集流程，主动收集系统需求
需求管理模型的第一个阶段就是需求获取，也是最重要的一个阶段。需求获取的过程也是系统用户对业务工作的归纳，总结的过程，所捕获的需求也是系统用户对将要建设的信息化系统业务功能期待的指标。因此，由软件公司闭车造车的获取系统需求的方式是不可取的。需要系统用户积极主动的提出对所需产品的愿景。通过各种方式来获取各部门对系统的需求。
由于，建设大型信息化项目需求的来源点多面广，需求获取范围大（人多、类型多、分布广），需求获取困难（说不清、道不明、各种信息噪音混淆在一起）。因此，用户可以先以问卷的形式进行初步调研，根据初步调研的结果梳理访谈提纲，准备更进一步的现场访谈。经过一系列的初步需求调研，对业务需求及需求范围、框架有一定的意识，可是通过意见征集的方式更进一步做到全员参与并征集到准确需求信息。需求征集流程图2-1如下：
图2-1 意见征集流程图
（1）启动咨询阶段
在需求征集的启动咨询阶段，需要根据系统的最终用途，确定需求征集的范围和方法，建立和完善需求征集制度，从而使得需求征集工作运作有序化、规范化，保障需求获取工作顺利进行。需求征集制度的内容包括：工作范围和工作过程、时间安排、征集人员名单、意见征集手段、意见征集流程、应急预案等内容。并且将需求征集制度下发到各部门。
（2）需求征集阶段
在需求征集阶段，各部门根据需求征集制度中的规范，采用面谈法、观察、界面原型征集法等具体的手段，来获取系统最终用户对系统图的需求。
（3）研究分析阶段
在各部门完成了征集了最终用户对系统的需求之后，汇总各个部门对系统的需求，进行审批，对汇总的需求进行完善，最终形成需求征集报告发给软件开发公司，作为软件开发公司编写系统需求文档的原材料。
2.2 规范需求工作，保障需求描述清晰完整
用户的规范需求管理工作，应该按照“统一管理、统一规划、统一标准、统一建设”的信息化项目建设原则，对大型信息化系统的需求进行规范化管理，强化项目过程和质量管理，从而减少用户与软件设计人员的误解。
用户提交给软件公司的需求，应该按照标准化模板进行编写，形成统一、规范的需求阶段交付成果，并加强加付成果的配置管理，对里程碑交付物、重点过程文档、关键环节活动的资料等进行规范的版本管理。从而让软件公司更加清晰、明了的了解用户需求。同时，规范的需求描述文档，也可以让客户自己理清思路，发现其中遗漏的需求，从而保证需求的清晰和完整。
在客户收集用户需求时，根据需求收集的不同阶段，应该制定相应的需求描述规范文档。各阶段模板内容如图2-2所示：
图2-2 各阶段需求描述规范
在需求管理工作过程中，由项目组成员负责业务需求收集、分析，并按照相关制度及模板要求编制《业务模型说明书》，《需求规格说明书》、《功能测试方案》，经广泛征集各方意见后，进行修改审核，需求各阶段产出成果。
明确需求管理制度，确定需求管理方法，对收集的用户需求意向进行分析，分解出可实现、可检测的需求项，从而将需求意向条目化处理。使用正确的、有效的需求获取、描述分析、管理方法，有效的规避需求管理过程中所遇到的问题及风险。
2.3 采用信息化技术，实现双向跟踪追溯机制
在大型信息化项目中，需求变更几乎是不可避免的。作为大型信息化系统的管理人员，一方面软件公司应该加强对客户的需求变更进行管理，避免客户需求变更所导致的工期拖延或者质量下降等问题;另一方面，用户也应该实时监督系统开发流程，保证需求落地。因此，可以采用需求追踪链的方式来对需求进行追踪处理。
（1）需求跟踪链管理
需求跟踪是成本和质量控制的基础。CMM/CMMI2就定义了需求管理这个KPA，要求对需求进行双向跟踪，需求跟踪的双向性要求体现在两个方面：
1）需求的横向跟踪和纵向跟踪
横向跟踪体现在跟踪所有需求之间的依赖关系;纵向跟踪表现为对需求的定义、设计、实现与测试等生命周期过程的关联和对应。
2）需求的正向跟踪（Tracking）和逆向回溯（Back Tracking）。
要求：可以从需求项出发追溯到该需求的设计、编码和测试用例;也可以从代码或测试用例或设计模型出发回溯到对应的需求项，包括需求的来源、需求的理由等等。
需求跟踪链管理如图2-3所示。
图2-3 需求跟踪能力链
图2-4 需求跟踪矩阵样例图
（2）《需求跟踪矩阵》维护
因此，不论采用何种跟踪方式，都需要建立与维护《需求跟踪矩阵》。需求跟踪矩阵易于创建和维护，可以很容易发现需求与后继工作成果之间的不一致，有助于项目管理人员有时纠正偏差。如图2-4需求跟踪矩阵。
《需求跟踪矩阵》主要是跟踪及统计功能需求和非功能需求。当需求基线第一次形成时就需要填写这个文档，这篇文档中的功能点名称和编号需和需求文档中对应，不得存在差异。
采用信息化支撑工具，能使需求跟踪更清晰、方便、快捷。需求跟踪工具需满足过程透明化、成果可追踪、需求一致性的特点。需求跟踪流程如图2-5所示。
图2-5 需求跟踪-需求视图
3.结束语
用户需求管理是大型信息化项目建设过程中的关键环节，对信息化项目的实施和最终交付成果有直接的影响。作为系统的使用者，用户对系统的需求是系统建设的基础。但是在大型信息化系统中，由于项目涉及面广、业务复杂、建设周期长，因此用户往往也难以清晰的了解和描述其对系统的需求。为此，本文主要从系统用户的角度对大型信息化项目建设的需求管理进行研究。
针对目前大型化信息系统需求管理过程中所存在的问题。一方面，用户应该规范需求管理工作，明确需求管理流程，主动、准确、有效的收集系统需求;另一方面，应该统一需求管理各阶段相关模板，对需求进行清晰、完整的描绘苏，实现各参与方对需求的共识和需求的一致性;最终，应该明确需求跟踪流程，实现双向跟踪机制，从而实现对需求变更的流程化、规范化管理，有效控制变更风险的发生，确保用户需求最终落地。
参考文献
[1]吴艳艳，周长伦，姜家轩.软件项目管理中的需求管理[J].信息技术与信息化，2008（4）.
[2]孙莉.软件项目管理中的需求管理[J].信息系统工程，2011（4）.
[3]陈江.控制工程项目管理之需求管理[J].项目管理技术，2009（6）.
作者简介：