论文摘要:
本文主要讨论如何更有效的进行需求管理，需求管理中需求考虑的一些问题，项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析，也包括项目中发生的变更和项目中发生问题的分析统计，以及需求管理中的一些应对措施。
关键字：
需求管理, 业务建模、项目管理、数据流图
通过高级项目经理5天课程的培训，个人感觉对于原先的工作实践有了一个很好的指导，从原先的实践上升了一个层次，对于实践有了一个很好的理论指导。
我想很多人可能会与我同感，一个项目做了很久，感觉总是做不完，就像一个“无底洞”。你想加人尽快完成这个项目，而用户总是有新的需求要项目开发方来做，就像用户是一个不知廉耻的要求者，而开发方是在苦苦接收的接受者。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理来决定的。那么，到底什么是需求管理，从这几天的学习中，我从理论上对此问题做了一个分析，表达一些自已的想法。
影响项目的最后成功的因素是多方面的，包括项目管理的九大知识领域（包括项目的整体管理、范围管理、时间管理、费用管理、质量管理、沟通管理、成本管理、人力资源管理、采购管理）。然而，要这九大知识领域对项目成功产生的影响的轻重程度上进行比较的话，我个人认为其中项目范围管理中的需求管理是最为重要的。本文主要讲述范围管理中的需求管理部分。
需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占了很大的一部分，本人从事的工作经历中有好２次就是因为需求不明确，导致最终的系统不可控，项目陷入困境。因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几万元，大到上千万元的软件项目的需求都或多多少的存在问题。
有的是开发者本身不重视原因,有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。
下面主要针对需求开发及需求管理两个方面对需求进行分析。
1. 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分:
请教行业专家
行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。
和客户交谈
你要面对“正确”的客户区分不同层次的客户需求,要面对不同层级，不同部门的客户，把客户分类,区分需求的优先级别.如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料,这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。当然，这也是系统分析人员的职责所在。在开始做需求的时候，你最后花一点时间搞清楚你接触的客户是不是做实际业务的客户，如果你面对的客户不是将来的系统的实际使用者。你就有点麻烦了。可能他是客户公司派过来的IT部的人，他会提一大堆东西，而这些东西可能根本不是实际业务需要的功能，而他一般还会兴致勃勃地给你一些技术实现的建议。这个时候你就要小心了，如果你听了他的话，你可能在最后才发现，你花了大量精力解决的问题，其实并不是客户真正需要的。而你真正需要关注的，却做得远远不够。
