我想很多人可能会与我同感，一个项目做了很久，感觉总是做不完，像一个“无底洞”。你想加人尽快完成这个项目，而用户总是有新的需求要项目开发方来做，像用户是一个不知廉耻的要求者，而开发方是在苦苦接收的接受者。实际上，这里涉及到一个需求管理的概念。项目中哪些该做，哪些不该做，做到什么程度，都是由需求管理来决定的。那么，到底什么是需求管理，从这几天的学习中，我从理论上对此问题做了一个分析，表达一些自已的想法。
　　影响项目的后成功的因素是多方面的，包括项目管理的九大知识领域（包括项目的整体管理、范围管理、时间管理、费用管理、质量管理、沟通管理、成本管理、人力资源管理、采购管理）。然而，要这九大知识领域对项目成功产生的影响的轻重程度上进行比较的话，我个人认为其中项目范围管理中的需求管理是为重要的。本文主要讲述范围管理中的需求管理部分。
　　需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占了很大的一部分，本人从事的工作经历中有好2次是因为需求不明确，导致终的系统不可控，项目陷入困境。因此，需求工作将对软件项目能否终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几万元，大到上千万元的软件项目的需求都或多多少的存在问题。
　　有的是开发者本身不重视原因，有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。
　　下面主要针对需求开发及需求管理两个方面对需求进行分析。
　　1. 需求开发，从目前我们的实际工作情况来看按顺序主要分成如下几个部分：
　　请教行业专家
　　行业客户对信息化的需求越来越细化，对专业性以及行业能力的全面性要求越来越高，惟有深入行业，洞察其需求，研发出更适合客户需求的产品，才能成功。因此有必要先请这方面的行业专家对于客户的业务需求进行从流程上的梳理。为什么请行业专家，而不是直接请客户进行交谈，得到其实需求，个人认为主要是因为目前各政府部门、企事业单位对于信息化与业需求的整合这一块缺少经验，大部分情况还不能完全整理出完善、清晰的系统需求来。只有通过行业专家对其实业务流程进行梳理，一方面更容易与客户产生共鸣，另一方面也可以大大减少因为知识方面的差异导致错识需求的产生。
　　? 和客户交谈
　　你要面对“正确”的客户区分不同层次的客户需求，要面对不同层级，不同部门的客户，把客户分类，区分需求的优先级别。如果你做的项目业务是你熟悉的，那还好，如果是你不熟悉的，一定要花点精力学习一下这个行业业务的背景资料，这也是我上面谈到的先请行业专家的原因。毕竟，客户是不可能给你系统地介绍业务的。只有你通晓了行业业务，才能和用户交流，并正确而有效地引导客户，做好需求分析，你不能指望客户能明确地说出需求。当然，这也是系统分析人员的职责所在。在开始做需求的时候，你后花一点时间搞清楚你接触的客户是不是做实际业务的客户，如果你面对的客户不是将来的系统的实际使用者。你有点麻烦了。可能他是客户公司派过来的IT部的人，他会提一大堆东西，而这些东西可能根本不是实际业务需要的功能，而他一般还会兴致勃勃地给你一些技术实现的建议。这个时候你要小心了，如果你听了他的话，你可能在后才发现，你花了大量精力解决的问题，其实并不是客户真正需要的。而你真正需要关注的，却做得远远不够。
　　参考其他类似软件和系统
　　在经过与客户的沟通，并形成初步的需求之后，不要急成正式的需求，请先参考一下以前的一些系统，去理解一下了解到的需求与原先系统的差异，并去发现是否有些需求会产生错识需求。
　　业务建模
　　为需求建立模型，需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
　　需求整理并形成需求规格说明书
　　需求规格说明书的模板我想每家公司都是不一样的，也没有必要都一样，但我认为每个需求规格说明书至少应包括
　　软件需求一旦通过了评审，应该基线化，纳入配置管理库。而在配置管理库中的文档或代码不能再轻易进行修改。当有需求要进行变更的时候，必须提出申请，写需求变更计划，审核通过，才有权限进行需求变更。然后配置管理员一定要做好需求的跟踪。，凡是跟变更需求有牵连的开发人员和测试人员都要同步的通知到和及时让他们做好相应部分的各类文档的修改。
　　需求变更管理
　　需求的变更管理我个人认为是容易出问题，一般项目做不完也主要是由此产生。需求变更的出现主要是因为在项目的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式；或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也越多，需求变更因此不可避免地一次又一次出现。如何有效的管理需求变更，下面是我公司目前的做法。公司采用Test Director作为需求管理工具，需求人员每次与客户沟通后形成需求调查表，统一录入Test Director，并进行综合及整理后形成需求规格说明书， 之后由研发部、产品部、及销售代表（如果有客户参加更好了）进行需求评审，建立需求基线。制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循变更控制流程进行控制，同时每一笔重要的需求变更都需要客户签字确认才认为需求变更生效。需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。因为Test Director提供了需求变更记录，可以帮助我们形成良好的文档，便于进行管理。
　　2. 需求管理
　　首先要针对需求做出分析，随后应用于产品并提出方案。需求分析的模型正是产品的原型样本，的需求管理提高了这样的可能性：它使终产品更接近于解决需求，提高了用户对产品的满意度，从而使产品成为真正优质合格的产品。从这层意义上说，需求管理是产品质量的基础。
　　需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
　　需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
　　需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
　　需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
　　根据上面描述的具体方法及步骤，由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险，应引起项目相关干系人的注意。这些风险主要表现如下：
　　1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是的，只要简单的说说自己想干什么是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。从另一方面来看，他们对于计算机的理解肯定不是很到位，而我们如何引导，正确梳理出正确的需求需要先从工作业务流程出发，而不是先从计算机方面来考虑问题。
　　2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。针对此类问题我们一般的做法是在项目开始阶段先确定好一个与客户沟通过的需求调研计划，当然这样还是经常会有变动，但相对来讲从责任上来讲，客户也会有一定的压力，因为如果不配合可能会导致系统进度的延误，其实这也不是客户希望看到的。
　　3）用户需求的不断变更。由于需求识别不全、业务发生变化、需求本身错误、需求不清楚等原因，需求在项目的整个生命周期都可能发生变化，因此，我们要认识到，软件开发的过程实际上是同变化做斗争的过程，需求变化是每个开发人员、项目管理人员都会遇到的问题，也是头痛的问题，一旦发生了需求变化，不得不修改设计、重写代码、修改测试用例、调整项目计划等等，需求的变化像是万恶之源，为项目的正常的进展带来不尽的麻烦。针对这类需求变更的问题，个人认为是影响进度的大的敌人，目前我们的做法是每次根据客户的需求整理出一个书面的文件，由客户签字确认。当然这里还有一个很重要的问题是不是每个需求都是必须做的，我们要学习如何拒绝客户。