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

　　在我们公司，获取了一个需求以后，

　　首先，相关人员会先在DevSpec建立一个条目，添加相应的一些属性信息，比如标题，内容描述，状态，对应文档，优先级，紧急程度，负责人，对应版本，对应浏览器，对应数据库等等。。。

　　提交完了条目以后，由于这个条目设置了一个负责人，所以那个负责人登录系统就可以马上看到自己名下有这个条目，他就会马上去处理这个需求。（可能有些人没登录系统去看，我们也可以设置Email或者手机短信的自动提醒功能）

　　这里提到的“负责人”，在不同的过程里，负责人都是不同的，比如“评审”阶段就有专门的评审负责人，普通人无法成为评审负责人，哪些人在哪些过程里能成为负责人是可以在流程中设置的。而上面提到的提交完条目后，一般情况第一个过程就是要审核刚获取的需求，负责人审核通过后就可以把这个需求从“审核”状态改到“需求分析”阶段了，当然负责人也会改变，“需求分析”过程的负责人就会马上知道自己有事情干了。

　　就这样，经过一个一个的过程，经手了一个一个的负责人，这个需求就逐渐从一个只有一个思想，到有了轮廓，再设计出里面的框架，然后最后被实现。

　　其实，大家都是这么来处理需求的，不同的是，我们通过一个工具来管理这个过程，而有些公司只是就人工来做一下。我们这么做，好处和坏处其实都有，正如之前有个客户问，你们这么做的话，是不是每一个需求的处理效率会降低？对，的确会降低，我们承认，因为这些都是严格的流程，而且是在一个系统中管理，肯定没有他们口头直接说一下快。但是，我们考虑的是我们是在卖产品，牺牲一部分的效率来确保产品的质量，我们觉得划得来，毕竟质量才是最重要。人家虽然速度快，但是问题也来得多，需求多的时候，这个忘做了，那个做错了，或者相互责任推来推去的事情多着了，最终导致产品质量出问题的事情比比皆是。但是我们用了系统以后，就避免了这些事情，实践也证明了我们这么做以后，产品质量是得到保证了的。

　　当然，产品的质量也不是简简单单像我说上面说的“经过一个一个的过程，经手了一个一个的负责人”就能马上实现了，这里还会涉及到很多细节注意点了，待我一一道来。