在我们公司，获取了一个需求以后，
首先，相关人员会先在DevSpec建立一个条目，添加相应的一些属性信息，比如标题，内容描述，状态，对应文档，优先级，紧急程度，负责人，对应版本，对应浏览器，对应数据库等等。。。
提交完了条目以后，由于这个条目设置了一个负责人，所以那个负责人登录系统就可以马上看到自己名下有这个条目，他就会马上去处理这个需求。（可能有些人没登录系统去看，我们也可以设置Email或者手机短信的自动提醒功能）
这里提到的“负责人”，在不同的过程里，负责人都是不同的，比如“评审”阶段就有专门的评审负责人，普通人无法成为评审负责人，哪些人在哪些过程里能成为负责人是可以在流程中设置的。而上面提到的提交完条目后，一般情况第一个过程就是要审核刚获取的需求，负责人审核通过后就可以把这个需求从“审核”状态改到“需求分析”阶段了，当然负责人也会改变，“需求分析”过程的负责人就会马上知道自己有事情干了。
就这样，经过一个一个的过程，经手了一个一个的负责人，这个需求就逐渐从一个只有一个思想，到有了轮廓，再设计出里面的框架，然后最后被实现。
其实，大家都是这么来处理需求的，不同的是，我们通过一个工具来管理这个过程，而有些公司只是就人工来做一下。我们这么做，好处和坏处其实都有，正如之前有个客户问，你们这么做的话，是不是每一个需求的处理效率会降低？对，的确会降低，我们承认，因为这些都是严格的流程，而且是在一个系统中管理，肯定没有他们口头直接说一下快。但是，我们考虑的是我们是在卖产品，牺牲一部分的效率来确保产品的质量，我们觉得划得来，毕竟质量才是最重要。人家虽然速度快，但是问题也来得多，需求多的时候，这个忘做了，那个做错了，或者相互责任推来推去的事情多着了，最终导致产品质量出问题的事情比比皆是。但是我们用了系统以后，就避免了这些事情，实践也证明了我们这么做以后，产品质量是得到保证了的。
当然，产品的质量也不是简简单单像我说上面说的“经过一个一个的过程，经手了一个一个的负责人”就能马上实现了，这里还会涉及到很多细节注意点了，待我一一道来。
我之前说过需求管理有几个严格的要求，流程化和审核机制大家其实已经看到了，其实在某种程度上，审核是流程化的一部分，因为审核过程本身就是需求处理过程中一个过程而已，我们只要在流程中设置了这种过程，安排负责人去负责就行了，当需求进入这个过程，就自然有人会去审核了。
如果把上面两个要求看成是需求管理的基础的话，那其他几个严格的要求：欢迎变更、版本控制、可跟踪性，就可以看成是确保产品质量成功的关键点了。有了基础才有可能成功，有了关键点才能保证成功！
欢迎变更：
欢迎变更的重要性大家应该知道了，变更其实也就是需求经常变，从某种程度上也就意味着产品的质量下降，因为这个需求你不断变化，今天刚写好这段代码，明天要改成那样，后天又要大改，谁都知道有潜在风险，而且还有与之有关联的功能呢？你突然改了个接口参数，人家可能还不知道了。靠测试？测试人员也没法很好解决这个问题，因为今天刚测完这个功能，明天却大改了，但是那个测试人员虽然看到这个功能需要测试，但是他却可能认为昨天已经测好了，是不是忘记关闭了，所以就去测其他功能了。
那怎么解决呢？也很简单，当有变更的时候，
首先，尽量让相关的人知道，让开发知道，让测试知道，让需要我们接口的人知道，这样子大家就都会同步就完成自己要做的事情，不会出现需要做的人却不知道他要去做这个事的情况。在DevSpec中，我们可以采用变更自动通知功能来实现，因为在DevSpec中一个需求总是和它的开发任务和测试任务关联在一起的，所以当需求有了变更以后，只要发送一个通知，开发人员和测试人员就能马上看到变更，就能及时去做他们的工作了。
第二点就是，尽量把影响的范围搞得清楚点，让开发知道哪些地方可能会影响到，做的时候小心点；让测试知道这个改动会造成哪些地方有潜在的Bug，需要重点测一下。在DevSpec中，我们会有专门的功能让设计人员和开发人员注明影响到的地方，需要重点测的地方，而且这个功能可以设置成强制，只要有变更，设计人员和开发人员就必须注明，甚至可以要求测试人员也注明测了哪些点，可以让设计与开发人员检查是否有遗漏。
第三点就是，针对任何变更（特别对于瀑布模式那种公司），因为关系到了可能会影响质量、进度及成本，风险很大，所以对于变更的内容需要专门的评审流程，评审通过后才能开始开发。在DevSpec中，我们针对这种情况，就会经常启用变更管理视图，在这个视图中，会有特别的流程对变更做评审，在次期间，这个需求是没办法被任何人转到开发环节的，也避免了有些人不清楚情况，直接就把没审核的需求直接让开发去做了。（当然，我们现在很多产品已经是用敏捷开发的模式了，所以这个功能就用得比较少了）
这样子做的话，我们还是能把质量掌握在自己的手中，也就是把公司的前途掌握在自己手中。
（未完待续）