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