需求管理

在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

“需求变更”，一旦提到软件开发项目进程中的需求变更，无论是项目经理还是程序开发人员都感觉到头疼。而且，在一些项目管理顾问的PPT课件中，以及一些软件项目管理的技术图书和教程中，也把“需求变更”作为单独的一项来研究。本文中，与您共同探讨软件开发项目中的需求变更发生的原因、需求变更控制，以及当发生需求变更的时候如何应对解决。

在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。

客户的需求是否应该得到满足?软件工程是否目的就是满足客户的需求?这个问题看来是无法加以回答的，因为，它没有提供两个基本的解释，其一：客户 的需求即算从客户的利益立场出发，是不是合理的?其次，客户的需求有多大程度上是必要的?还是只是一种个人的喜好?

辛辛苦苦熬了几个月的通宵，终于确立了ERP需求，规范了工作流程，系统配置也完成了，正准备按部就班ERP系统上线时，企业用户突然改变了需求，不想这么做了，提出了新的需求。这对于ERP实施顾问来说，正如晴天惊雷，这也是所有ERP顾问最感到恐怖的事情。因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。

在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很大的差距和不足。

本文介绍了软件需求评审失败的5个案例，提出对软件需求评审的实践具有指导意义的9个建议。

良好的需求分析是软件成功的基础。文章内容是作者对需求分析工作实践的一次小结以及综合性的思考，是对需求分析本身所做的一次分析。在此基础上，作者提出了逆向沟通的设想，即系统分析员主动进行沟通，提出指导性意见。当软件融合了客户和系统分析员双方智慧，其质量将会进一步得以提高。

变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。

在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

在中国软件行业现状中，恶性竞争比比皆是，而恶性竞争的产生物：合同，导致大中型软件项目中，项目组面临着在时间上，成本上和人力上都不切实际的目标，一个在标准含义上注定要失败的项目；而项目组对于这种项目要做，并且还要尽量做好，同时由于客户成熟度不够，而造成更多的问题。

软件复用本质是为了快速适应不断变化的需求（adapt to changing needs ），两者目标是一致的，但是当我们过于注重软件复用（如组件复用component reuse又译构件复用）时，千万需要牢记：快速适应不断变化的需求是根本目的，它的重要性要重于组件复用技术本身。本文试图阐述两者概念比较以及时下流行的组件复用技术概要。

在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。

需求变更的控制当然与项目管理范畴之外的纯技术因素息息相关，比如面向对象的分析、面向对象的设计、面向对象的编码方式等等。但所有技术的发展趋势都是一样，那就是为了使变更管理变得更容易，因此，不论在项目变更控制中采取什么方法、策略，对于项目本身的变化一定要时时洞悉，处处留意，只有这样才能从真正意义上对项目进行很好的变更控制。

需求调研对于系统的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。我希望我们能得到一块“德芙”。

在CMM 1.1版本中第一个KPA（关键过程域）就是需求管理。虽然在CMM2级的标准文本中对需求管理的论述篇幅最少，但它却是最容易让开发人员和项目经理提出疑问的一个KPA。如何进行有效的需求管理？笔者将需求管理的基本原则与方法总结为以下几点。

客户的需求是否应该得到满足？软件工程是否目的就是满足客户的需求？这个问题看来是无法加以回答的，因为，它没有提供两个基本的解释，其一：客户 的需求即算从客户的利益立场出发，是不是合理的？其次，客户的需求有多大程度上是必要的？还是只是一种个人的喜好？

RequisitPro 中的需求种类和一般步骤。