【本篇为《如何有效实现软件的需求管理》第四篇，（第一篇，第二篇，第三篇）】

　　好了，上面把需求处理过程的四个阶段简单介绍了一下，后面结合我们公司流程时还是会提到，不过接下来的话，毕竟是要讲需求的管理，所以还是先讲讲这个“管理”的一些知识。

　　一个软件或者硬件必然是有N多的功能组合而成的，而一般情况下每个功能其实都是来源于一个需求的，当然一个需求可能也会有很多个功能来实现的。所以对于需求的管理，我们不是在管理一个需求，而是在管理一堆需求，需求管理好了，这个产品才有可能做得好。

　　所以对于需求的管理，我们必然需要有很多严格的要求：

　　1、需求管理必须流程化：

　　什么意思呢？因为需求的管理涉及了需求从被获取到分析到设计最后去实现这样子一连串的过程，每个过程其实都是缺一不可的（虽然在敏捷中可能过程的概念被弱化，但是事实上最基本的管理还是有的），而且过程之间是有必然的联系，比如我不可能获取了需求就去设计开发了，最后却发现做出来的东西不是客户需要的，这是因为你绕过的分析的阶段。

　　所以需求的管理对于过程的流程化很重视，需求需要严格按照流程来处理，每个过程最好由不同的人的来处理，并且过程之间转换时，需要有审核程序。

　　2、需求管理必须有审核：

　　其实第一条里也提到了审核，审核这个程序也是非常重要的，因为需求涉及到的这么多过程都是需要人处理的，人处理的好坏会直接影响到这个需求的实现，获取得不对，分析得不好，设计得不佳，开发得不行，只要有一点做得不好，都会导致这个产品失败，所以我们需要审核，一般情况下每一个过程都需要一次审核，审核失败就重新来过，有些公司甚至有几重审核机制。

　　3、需求管理必须欢迎变更：

　　“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”

　　现代软件开发中，变更已经是不可缺少的一个因素了，即使你初期软件设计得再好，总是或多或少在后期会有些需要变更的地方，增加或者减少或者改变功能点都是有可能的，所以我们必须欢迎变更，不然的话，客户会说，你的产品太差劲，连做些修改的都不行。

　　虽然我们必须欢迎变更，但是我们还是需要对变更做严肃的处理，做软件的人都知道，如果对于已经在开发功能做变更，会增加很多难度，不光成本上，时间上，更重要的是在质量上；如果是对于已经开发完的功能做变更，潜在问题可能更多。所以我们需要一套严格的机制来确保质量。