1.需求定义

IEEE软件工程词汇表中将软件的需求定义为：

• 用户解决问题或达到目标所需的条件或能力
• 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需要具备的条件或能力
• 一种反应上面两点所描述的条件或能力的文档说明

PMBOK第四版中把需求定义为：根据合同、标准、规格或其他正式的强制性文件，某个系统、产品、服务、成果或部件必须达到的条件或具备的能力。

2.需求管理重要性

　　实施立项开始，需求就成了所有项目经理的心头之痛。客户花钱购买了我们软件，理所当然地认为软件可以解决一切问题、甚至代替管理;加上销售过度承诺、客户应用经验的增加和对软件的了解程度加深等，都有可能使客户对软件的需求不断变化。如果不能有效管理这些需求，就很容易导致项目失去控制，客户购买的一辆QQ，也许最后你不得不为他打造一辆劳斯莱斯。

3.如何管理?blog.mypm.net

　一、需求无法控制，只能进行管理

　需求无法控制，只能进行管理，正如吃饭一样，饿了就得吃，不吃难受。为了把需求管理在一定的范围内，首先，实施顾问必须充分了解销售阶段是否有过度承诺(包括文字或签约)。其次，我们在制定实施方案时就要与客户项目负责人确认实施范围、目标、项目风险及本次实施工作的重点。项目管理者联盟文章

　二、了解需求产生的原因

　总结大部分项目，提出的需求所产生的原因往往集中在以下几方面：

　1、调研产生的需求;

　2、对软件操作不熟悉，总觉得需要快捷方式或快捷键;转自目管理者

    3、操作模式同之前的软件有较大的区别，这种情况尤其是此前使用过软件或习惯了EXCEL灵活模式的人；

    4、业务流程还未理顺，尤其是部门之间的衔接还不顺畅，这时候抱怨产生的需求;项目管理者联盟

　5、相关的基础数据不完善，甚至有错误的地方;

　6、出于部门利益的考虑，某个人或部门的想法，没有考虑全局;

　7、客户方人员或项目负责人变更引起;

　8、企业高层比较理想化的思维;

    9、随着对软件深入了解，对软件提出的更高要求。

三、需求收集　　

    收集需求的方法有很多，主要有：

    1.    与项目干系人一对一访谈，这种方法很有效，但是成本很高，而且很花时间。

    2.    焦点小组会议

    3.    问卷调查法

    4.    观察法

    5.    原型法

    四、需求分析

　1、需求调研和业务流程整理完成后，实施顾问手里就会有一大堆的新需求。这时，最忌讳的就是哪个最简单的，就先实现哪一个。而应该是那个最重要，最有影响力，就要先实现它，以达到很好的短期效果。

　2、针对实施过程中产生的临时需求，需要灌输"先固化、再优化"的思想。

　3、对于应用层面的，主要加强培训，并对提出者要给予鼓励和表扬，说明将在后续的工作或软件版本中给予响应或解决。

　4、对于关心部门利益的，可提交客户方项目负责人或多部门同时开会讨论解决，很多时候这种效果很明显。

　5、对于影响了企业全局工作或影响实施效果的需求，经过判断，应和客户管理层进行沟通。

　6、随着客户应用层面的提升，客户提出的需求必须明确可以提供解决方案，但不在本次实施范围。

　五、需求需要沟通并确认

　客户提供出了众多的需求，均需充分了解客户需要的是一个解决方案还是真正的功能需求。提前和客户方项目负责人及提出人一起，对需求的认识达成一致;确认需求时要避免与一般业务人员交谈，因为一般业务人员可能仅仅考虑软件的实际操作或习惯问题，应该与企业的管理层沟通，了解他们需求背后实际的管理要求，从而分清客户需要的是一个解决方案还是软件的功能需求;确认后双方书面签字确认。我们实施顾问经常忽略的一点是需要解决未和客户确认，这非常重要，问题解决一定要确认，看处理情况可以高调宣布。

　六、不要满足所有需求

　对项目干系人提出的新的需求不要立即答应，要经过项目评审委员会审核批准后才能满足，审核不批准就拒绝该需求。

　七、承诺必须兑现

　如果同客户确认了需求并明确了解决方案和实现时间，必须在规定时间内兑现，不能如期兑现的，也需提前和客户沟通，切忌到兑现时间没完成才去和客户谈，一次还好，多了直接影响客户对实施顾问的信任度。项目经理圈子