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

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

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


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

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

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

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

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

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

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

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

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


4.       需求管理必须有版本控制：

版本控制的好处是可以随时知道以前怎么改的，对于需求管理而言，这个是极其重要的，因为设计啊开发啊这种工作，经常在不停地修改数据，你经常会发现我改错，我想把几天之前的数据回滚回来，或者我不知道现在这个设计有没有问题，我想和几天之前的数据做个比对，这些都是需要版本控制的。

查看各种版本的数据与比较各个版本的数据，这是版本控制必须具备的，很多情况下版本控制还需要具备基线（Baseline）的功能，以比较产品初设计与终实现的变化。


5.       需求管理必须有可跟踪性：

所谓的可跟踪性，说得简单点是这个需求自始至终所有的过程我都能跟踪到和记录下来，这样的目的，

第一，   是为了能完全管理到整个需求过程，如果整个过程中，每件事情我如果都能跟踪到，从理论上会保证我能Control这个需求的发展过程，我能知道这个需求谁在做，在做什么，什么时候能完成，已经修改了多少次了，谁负责审核的。。。。。。

第二，   以后很多时候，我们需要去查找以前的一些数据，这个可跟踪性比较重要了，比如说，这个需求完成代码后发现严重与客户的要求不符，这样子的话，我需要知道当初谁来负责需求获取的，谁负责分析的，谁负责审核的。

第三，   跟踪和记录下尽可能多的数据，可以使得报表能采用尽可能真实的数据，从而能真实展现现在、分析过去和预测未来。