在项目管理过程中，项目经理经常面对用户的需求变更，如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这就决定了项目组必须拥有需求管理策略和有效的落地。
在软件项目的开发过程中，需求管理贯穿了软件项目的整个生命周期，在软件项目管理中需求工程是软件开发的第一步，是关键的一步，也是最难把握的一步。从软件的项目立项、研发、维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能、优化性能、提高用户友好性的要求。需求管理做得好坏直接影响到软件的质量，甚至软件项目的成败。
让我们一起来回顾一下实际研发过程中，通常会面临到的需求管理挑战：
1、缺乏需求的集中管理
按照需求工程的说法，在进入开发环节之前，开发团队和客户之间需要形成一份完整的需求规格说明书，详细地说明目标软件的各种需求，这其中包括功能性需求、非功能性需求和其他各种约束。在典型的瀑布模型中，需求规格说明书是在需求分析阶段完成的。然而，由于软件外部环境的变化，很少有哪个项目在需求分析阶段就能将所有可能的需求准确无误地包含进来，并且在开发阶段不需要修改，一句话，需求的变更是不可避免的。需求的变更也需要及时地反应到需求管理中。
除此之外，在实际的敏捷软件开发中，对开发而言，需求的来源不一定像瀑布模型那样完善的需求规格说明书，而通常有以下几种：
1)客户初始的业务需求：很多客户可能只会告诉我们，它想做一个系统或者工具平台，大致是什么样子，应该具备哪些功能，但这种需求往往比较抽象，缺乏细致的分析。这种需求可能源自于一次交谈，或者一封Email，形式上并不正式。
2)客户对项目快速原型的反馈意见：对于需求，在实际项目开发中，客户关注的业务功能，项目经理关注的是抽象设计，而开发人员关注的却是具体实现。在项目初期，客户往往也不是很清楚他们要什么，或者理想中的产品到底最后会是什么样的，界面布局，操作流程等等。这一点，在新产品的开发中尤为明显。
这时候，就需要开发团队能够按照现有的理解快速地开发一个原型，作为开发团队和客户讨论和分析需求的共同基础，原型能够帮助用户更好地发掘和定义需求。客户对于原型的论证作为反馈意见也可以使开发团队更加直观和感性地认识客户的需求。
3)客户对每个迭代周期发布的版本的修改建议
如果该企业采用的是敏捷开发，每个迭代周期都要发布一个可用的版本给客户，该版本尽可能多地实现了当前迭代周期内的需求以及之前迭代周期内遗留下来的需求。客户要验证需求的实现是否符合他们的要求，并提出修改意见和建议。
4)客户在研发周期中的需求变更
需求来源的特殊性决定了软件开发过程中需求管理的特殊性，尤其是对于一个同时承担数个小项目的开发团队而言，不同的项目需求是由不同的开发人员或QA分别进行管理和跟踪的，缺乏集中的管理，对于需求的跟踪也比较原始。往往是手工整理需求邮件和需求列表，然后形成简单的需求文档，在需求查询和状态维护方面存在明显不足。
2、需求变更频繁
软件开发的显著特点之一就是灵活性、机动性、对变化的快速响应能力。尤其是敏捷开发过程，需求变更更为频繁。敏捷开发的口号是拥抱需求变化，也就是说，开发团队对于客户提出的需求变更通常是抱以欢迎的态度