需求管理

本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。

读过王玉荣的《客户为什么总是反反复复》，有感于自己的软件项目管理实践，借此话题介绍一点软件行业需求管理中的需求变更管理的实际经验，与各位读者共享。

当今，经济和社会生活对软件的依赖程度急剧增长，软件需求日益复杂，软件开发成为一项跨越技能，职责范围和时间阶段的综合团队活动。实践证明，良好的需求管理过程对于降低开发成本和保障项目成功至关重要。

需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因。

项目整体管理是平衡那些彼此冲突的项目目标的一种能力。看起来简单，但是实际上很复杂，项目主管在项目进程中要学会如何对常见变更进行控制，控制客户需求的肆意膨胀，保证项目健康稳定的进行。

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

系统分析、系统设计与系统实现是计算机应用项目开发的“三部曲”，书上是这么说的。国内目前系统分析级的人才奇缺，系统设计级的人才相比之下满大街（当然得是中关村的大街）都是，报纸上是这么说的。解决这个问题的办法大概只有一条，那就是快速培养系统分析师傅，因为这是关乎系统成败的关键，许多人都这么说。

需求包括业务需求、用户需求和功能需求。业务需求(Business Requirement )反映了组织机构或客户对系统、产品高层次的目标要求，用户需求(User Requirement )描述了用户使用产品必须完成的任务，功能需求(Functional Requirement )定义了开发人员必须实现的软件功能。

一般来讲，需求的变更通常意味着需求的增加，需求的减少相对很少，而且处理需求减少方面的问题也比较容易。当客户提出新需求的时候，项目开发人员应该分析这些新需求对项目现阶段带来的风险，得出双方实现变更需求的需要的成本，包括时间、人力、资源等等方面。

变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。

因此如何从软件工程的角度，通过采用适当系统设计方法和加强项目管理来解决需求不断变化的问题，是各个软件开发商的一个重要课题。通过实践，感到采用敏捷方法的基本思想和原则来设计系统和处理需求变化问题，能够产生较好的效果。

企业业务软件工程项目和商业软件产品项目上项目无论是需求重点，实现方式，项目管理等方面都有极大不同。现在的软件工程有关研究并没有关注此中的区别，实际上，其中绝大部分还集中在较简单的产品项目上。对于需求变动要大得多的企业软件项目来说，对需求进行分级管理是非常必要的，也是生死悠关的。

需求管理是CMM二级就开始关注的KPA，可见其重要性。关于这方面的书籍多种多样，不过最好的还是行之有效的实践经验。我在自己的项目管理中，充分应用经验，可以从容面对我的客户，希望它对您的项目成功有所帮助。

对于软件开发项目来说,开发的过程中不可避免的会出现需求变更，发生变更的环节也比较多，因此变更控制显得格外重要。变更控制对项目成败有重要影响，项目开发之前要明确定义，开发过程中要严格执行。对变更控制的目的并不是控制变更的发生，而是对变更进行管理，以便更好的处理变更，确保变更有序进行，从而减少因为需求变更而带来的损失，加快项目的开发速度。

经常遇到做软件设计的朋友抱怨用户的需求老是变化，自己不断的修改自己的设计，结构搞得自己疲惫不堪，而且软件的应用效果也不理想。其实类似的问题每个人都会遇到，关键是我们应该如何对待，如果我们总是不断的修改代码以适应用户的要求，这时候我们应该考虑软件是否具备足够的让软件开发人员自己比较舒适的适应能力，如果不具备这种能力，则改进设计，甚至具备足够的适应能力，否则，软件设计真的就成了苦差事。

作为开发人员，您可能认为"我没有时间进行需求管理"，或者"RM 与我毫无关系"。如果情况正是这样，那么项目团队如何定义您正在构建的系统功能呢?实际上，您对于项目交付的职责是由某位人员决定并定义的。无论这位人员只是在头脑中计划着这些需求、在纸上草画出需求、在正式会议上讨论了需求，还是将需求正式记录在需求文档中，每个软件开发团队都要涉及某种形式的需求管理。他们可能并没有意识到，因为他们的 RM 实践可能极其不规范。不管怎样，所有软件团队都要进行某种程度的 RM。问题只是您的软件团队的 RM 实践的规范化程度如何。

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

通常我们谈到需求管理，大多是谈到的是研发团队内部的需求管理问题和改进，因为软件工程/系统工程谈的都是工程领域的问题，严谨，科学，模式化都是工程师的词汇啊，那么对进入工程领域之前的活动呢，也就是对marketing，对sales来说，需要需求管理嘛?

在需求开发上，国内软件开发团队普遍的习惯是只有一种需求类型，要么是用例，要么是功能，缺乏需求类型的层次性;或者即使有用户需求，也是了了几笔带过。

项目需求的变化是项目管理中最令人头疼的事情了，而且如果变更的管理和控制不好的话，往往还会导致项目组内部的开发管理的混乱，降低了软件开发的效率，增加项目的成本，甚至会导致项目的失败。