需求分析阶段完了以后，是需求设计，然后是需求实现了，过程看起来很简单，但是实际工作不简单，上面谈到的需求管理的几点严格要求一直贯穿着整个过程的始末。

接下来我会结合我们公司实际的流程来介绍一下需求管理的实际实现。

如果看过我之前的文章，应该知道我们公司的背景，我们公司也是做软件开发的，所以对于需求管理这块也是相当重视的。我们是用敏捷的模式来管理整个软件开发的，所以需求管理的阶段也是符合敏捷的模式的，但是对于需求管理的几点严格要求还是基本上也是遵守的。

我们公司是用 TechExcel 的需求管理工具 DevSpec 来管理整个需求过程的，其实我们是买了他们的整套软件生命周期管理的解决方案，名称叫做DevSuite，而DevSpec 是其中一个工具，能与DevSuite 解决方案的其他工具无缝集成，帮助共同管理开发、测试、计划等阶段。


在DevSpec中，对于需求的管理是通过条目化的方式来管理的，所谓的条目化是说一个需求是一个条目，这个条目既包括了对这个需求的描述，还包括了对这个需求的处理过程的跟踪：

对于需求的描述而言，DevSpec是通过属性字段的方式实现的，你可以用字段来尽可能真实描述需求，其中包括标题，状态，负责人，描述，时间，附件等基本字段，当然你还可以大量自定义属性字段和页面来帮助更好地描述这个需求。

对于需求的处理过程而言，
我们知道需求的处理是要有流程的，简单的是从需求分析-->需求设计-->需求实现，复杂点的还需要加上审核，像我上面给大家看过的那个流程图一样， 我这里再贴一下。


不过光有流程其实没用，我相信任何公司的需求处理都会有流程，只是严格不严格，认真不认真的区别罢了，不遵照流程处理的需求有非常高的可能性不成功，所以为了解决这个问题，DevSpec 中专门设计可自定义的工作流程，你可以自己定义需求需要经过哪些流程才能进入开发，而一旦流程定义完成以后，需求的处理会被强制按照流程的进行，你自己想马虎马虎，松懈松懈都没办法做到。

在流程中，DevSpec可以给每个过程设置不同负责人和权限，比如分析这个过程是小王处理，所以只有小王才能看到这个需求并且处理这个需求，其他人如果没有权限看不到这个需求；而小王处理完他的工作后，他不一定有权力把这个需求转到下一个过程，因为需要另外一个人审核以后才能继续下去。

这样子的话，

第一，   你的处理流程会很清晰，这一步处理完了，下一步是什么，一目了然；

第二，   你的管理流程也很透明，现在谁处理，接下来该谁处理，清清楚楚。

第三，   你的权力流程也很明了，什么级别的人能做什么事情都可以设置，哪些该做的不该做的，哪些该看不该看的，都很简单可以设置，避免了一些人看到不该看的内容，做了不该做的事情。

有了这些属性和流程，我们可以正式开始 DevSpec 的需求管理了.