之前把软件工程中的测试部分，文档管理部分都已经做了一些简单的介绍，因为都是我实际工作中经常接触的，所以也算是我的一些经验吧，不过我也不是每个部分都接触得很深入，总是有些地方讲得不太好的，也请大家谅解，希望大家能提出宝贵经验，呵呵。

　　下面是之前讲过部分的链接（点击就可以访问），如果之前没看过我的文章的话，有空可以看看。

　　1、【浅谈在软件开发中的开发与测试】

　　2、【敏捷测试理论以及实践】

　　3、【谈软件开发过程管理系统、版本控制系统及它们之间的集成】

　　4、【文档管理】

　　但是软件工程中除了我已经讲过的部分，其实还有几个部分还没讲了，因为我们公司是用 TechExcel 的 DevSuite 系统的，所以还是借用他们的软件工程过程图来给大家讲一下。

　　看下图，之前讲了知识管理（文档管理），测试管理，开发管理（任务跟踪），PPM，这篇文章的话，我会讲一下需求管理，至于其它几个部分，比如项目规划管理，我还在考虑之中，因为有些知识在前面几篇文章里已经部分提到了，所以讲起来可能就重复了。Anyway，先不管了，反正我这篇“需求管理”还是会正常写下去，谢谢大家阅读！

PPM

编辑本段十三、PPM项目组合管理

　　PMI对组合管理的定义为“Project Portfolio management refers to the selection and support of projects or program investments. These investments in projects and programs are guided by the organization’s strategic plan and available resources .”，即项目组合管理是指在可利用的资源和企业战略计划的指导下，进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化，确保项目符合企业的战略目标，从而实现企业收益最大化。

　　项目和项目组合管理（PPM）是项目型组织创新的系统化管理理论和实践，过去项目管理的理论和工具都是基于单个项目管理的，解决的问题是项目如何使干系人满意，如何按时、在预算内成功交付项目。对于组织级层面如何管理项目，例如如何使项目目标与组织的业务目标一致，如何跨项目优化利用组织的资金和资源等，一直没有很好的理论和方法的支持。组合（Portfolio）管理是金融领域的方法论，在2000年左右被引入到项目管理领域，尝试解决组织级项目管理问题。

　　自2002年初开始，PPM方法论首先在产品研发管理领域取得了重大成功，并逐渐扩展到IT治理和专业服务领域。这期间，欧美出现了一批非常成功的PPM独立软件厂商。从2005年开始，国际上PPM进入整合阶段，IBM、CA、HP、Microsoft、Oracle、蓝云软件等国际知名IT企业陆续通过收购进入PPM领域。PPM是未来项目型组织，尤其是IT组织管理优化的方向，这一点已成为业界共识。著名研究机构Forrester Research指出：“PPM已经成为IT企业的ERP”。

　　什么是软件需求呢？为什么它需要管理呢？

　　软件需求完全严格来解释就是：

　　（1）用户解决问题或达到目标所需条件或权能（Capability）。

　　（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

　　（3）一种反映上面（1）或（2）所述条件或权能的文档说明

　　也许看起来有点深奥，其实简单来说，软件需求就是一个软件要实现的功能，当然这里所谓的“功能”可能分为两种情况，一种是有形的，一种是无形的：

　　● “有形”的应该很好理解，你实际可以用到的功能，比如在Word文档里能把字加粗。

　　● “无形”的其实也好理解，虽然你平常用不到，但是还是能感受到的，比如说软件的运行速度，稳定性，还有比如这个软件要达到什么目的（比如Word的目的是可以让你处理文字信息）。

　　当然，其实最终所有“无形”的需求还是需要靠一个个的“有形”的需求来实现，只是有些“有形“的需求即使实现了客户也无法直接看到，只有设计、开发与测试才能看到它们。

　　那为什么要对需求进行管理呢？

　　软件需求是随着计算机的发展而发展的，在计算机发展早期，软件规模很小，所以当时大家关注的是编码，而对于需求并不怎么关注，后来随着“软件危机”的出现，诞生了软件工程，而需求阶段就是其第一阶段，至此，软件需求（也称之为需求分析）阶段开始慢慢被关注。

　　大家都知道，“软件危机”的原因是落后的软件生产方式无法满足迅速增长的计算机软件需求，软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出，原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。

　　而软件需求分析阶段作为软件工程的第一阶段，需要为一个软件的开发搭好最初的框架并且还要考虑好后面可能的修改，所以对于软件可靠性、易用性、可扩展性和可维护性来说，需求分析阶段是及其重要的，直接关系到一个软件是否能够成功。

　　如果一个产品在需求分析阶段没有被设计好的话，在以后的各个阶段，开发与维护的成本就会非常高，导致最后失败的可能性就会非常大，著名的例子比如微软的Vista，设计初期没有考虑好兼容性与硬件，导致发布以后发现与其他软件的兼容性很差，而且硬件要求又很高，很多客户不买他们的账，所以最后匆匆收场，赶紧推出Windows 7来，要知道Vista的开发成本估计要接近百亿美金了，都还没怎么赚钱就赶紧推出另外一个产品，足见其失败了。

　　所以软件需求分析阶段对于软件工程而言，已经成为至关重要的阶段，其实按照我的理解，它已经成为软件工程最重要的阶段，记住，不是之一。（当然，我这里说的需求分析阶段是包含软件的设计阶段的）

　　一个软件的成功与否，在需求分析与设计阶段已经可以基本上预见了，因为需求分析与设计阶段从概念上其实已经把这个产品做出来了，而之后的编码阶段只是去实现它，让产品能真正可以去用。那这个“实现”阶段其实相对来说就不会那么重要了，所以现在很多跨国公司只在总部保留设计部门，研发部门都外包出去，就是这个原因。 “苹果”就是这样一个公司，把需求分析与设计工作做好，让台湾人去把产品做出来，最后得到一个完美的产品。

　　既然软件需求阶段已经变成如此重要，那对它的管理也就相应的变得特别重要了，只有把需求设计做好了，产品才有可能成功，所以我们就需要对这个阶段进行有效的管理，而且是非常有效的管理！

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/