2. 需求变更频繁

软件开发的显著特点之一是灵活性、机动性、对变化的快速响应能力。尤其是敏捷开发过程，需求变更更为频繁。敏捷开发的口号是拥抱需求变化，也是说，开发团队对于客户提出的需求变更通常是抱以欢迎的态度，尽管这些变更可能会给项目计划和项目进度带来麻烦，但这种观念上的转变更能体现开发团队和客户之间合作的诚意。

客户在迭代周期中的变更大致可以分为五种类型：添加新需求、删除本次迭代周期内的需求、删除之前迭代周期内的需求、更改本次迭代周期内的需求、更改之前迭代周期内的需求。这是说，开发团队需要实时高效地管理这些变更，并且将需求变更涉及到的迭代周期内项目计划和人员安排变更的影响小化。

3. 缺乏有针对性的需求管理流程

传统的需求管理过程，尤其是其中的变更控制过程是针对那些组织机构清晰，只能定义明确的传统软件项目，其流程相对比较严谨和死板。同时，为了弥补需求变更对项目进程带来的影响，开发人员常常需要快速的进行功能修改和增加，而没有遵循统一的流程控制，从而常常使得软件开发的有序性被破坏，人为地增加了工作量。这需要有更为高效和精简的需求管理过程以及相应的工具支持。

4. 需求、测试用例、Bug管理脱节

软件开发中，需求和测试用例是紧密联系的，通常来说，一条需求只有通过了所有针对该需求的测试之后才能说这条需求的实现真正实现了。而测试的结果是产生Bug报告，如果针对某条需求的一个测试用例没有通过测试，换句话说，也是产生了一个Bug，这说明该需求根本没有完成。同时，需求的变更直接影响到与该需求相关的测试用例的更新，继而影响到现有Bug的状态的更新。然而现实情况却是，大多数敏捷开发团队都没有实现需求、测试用例和Bug的一体化管理。

我们希望在需求、测试用例和Bug之间建立一种动态的联系，能够实时地更新三者的状态，并且实现三者之间状态的动态联动，从而减少开发团队在管理和维护需求、测试用例和Bug时的工作量。

5. 缺乏量化的项目管理反馈

企业在项目管理中，需求的频繁变更对项目管理者评估需求、制定迭代周期内的项目计划都是个巨大的挑战。管理者在需求评估经验和能力上的不足，以及管理者对团队成员开发能力认识不足容易造成需求评估出现大的误差，虽然这种误差是不可避免的、但是我们希望可以通过历史评估数据的反馈来帮助项目管理者积累经验，逐步修正和调整自己的判断和评价体系，从而尽可能减小由于评估误差引起的项目风险。而没有工具的支持，历史的准确数据则很难获取。

总结以上问题，显而易见，需求管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此有效的需求管理是企业软件开发项目顺利达成目标的重要支撑条件。如何理解项目开发的目的和用途，梳理用户需求，监控需求变化，进行需求确认，对需求风险进行防范，并利用工具进行有效的实施需求管理工具，方能推进软件项目良性发展，达到用户与软件开发企业的双赢。

有效的需求管理方法与工具

方法一：量化需求管理

如前所述，企业研发项目通常规模巨大，涉及部门众多，需求功能描述文件中包含众多内容，若仅仅只用整篇的文档来指导开发和测试工作，很容易引起任务分配的混乱；当发生需求变更时，也很难追溯历史版本。

TechExcel公司推出的DevSuite产品研发管理软件，从实践中提炼出一个行之有效的解决方法——用规范点（Specification，以下简称Spec）量化需求，正规表达每一个功能单元。只需打开《需求功能描述书》的WORD文档，可以利用插件，将其中的功能单元逐条地复制出来，在需求管理系统 DevSpec中直接生成Spec。相对于需求，Spec是更面向技术人员的语言。