第二阶段：需求分析与设计（怎么去做）

 

既然需求已经获取了，也是说客户已经跟我们说了要做什么或者我们自己想出来的一些需要做的功能，好了，那现在真正开始进入需求管理阶段了。

首先是需求分析阶段了，所谓的需求分析，简单点来说是把获取的需求分析一下，看看是否真的是客户所想的，看看是否是我们产品能做的。 有时候一个需求是客户一句话，但是真正理解起来并不是一句话能解决的，所以你可能需要再跟客户确认，了解他们的真实意图。（下面是一张经典的需求分析出错的图，呵呵，我大学时老师讲到过，这次碰巧又被我看到了，借来一用）

对于一个需求而言，它不是简简单单一个功能上的操作，它有可能是一个性能需求，也有可能是安全保密需求，甚至还有可能是用户接口需求、成本消耗需求、可靠性需求等，所以在需求分析的阶段，不是说跟客户交流几句话能把这个需求完全搞清楚的，而且即使搞清楚了这个需求，能不能做（可行性）也不可能一下子想清楚。

所以为了解决这种问题，各种需求分析的方法也相应而生。如果你在大学的时候学过软件工程的话，可能你会记得像结构化分析方法之类的方法，什么数据流程图啊、数据字典啊、判定表啊，等等，也许当初你为了应付考试，匆匆背了一下，到现在想必也应该忘了，即使你当初很用心地去看了，去理解了，我相信没有真正在工作中用到的话，你其实没有真正理解它们。

不过，如果你想从事需求分析相关的工作，我可以告诉你，这些知识还是很有用的，需求分析还是需要用到它们的，当然很多时候你应该不会直接用到这些理论，但是总是间接的用了体现它们思想的工具。（比如UML建模）

谈的是需求的管理，所以对于怎么做需求分析这种技术性的活，我不多说了，因为前面也说了，这个靠一篇文章是不能教会的，要真的教会我可能得出一本书了，呵呵。所以我还是侧重于去讲如何来管理整个过程，包括需求分析阶段，也包括之后的需求设计和需求实现阶段。

上面提到建模，也许有人问，为什么要建模，建模有啥好处，呵呵，这个问题本来不想回答，但是总是有人在问。

一方面，咱们在开发软件或者硬件，但是你拿到需求后不可能马上能给客户看到这个产品是怎样的，所以你有必要做个模型出来，让客户能看看涨什么样子，是不是符合他们的要求，这种是简单的建模，对于硬件而言，你可以把缩小版的样子给客户看，对于软件而言，你可以把这个软件的架构啊，可以实现的功能啊、数据流啊、程序流啊之类的列出来让客户去看；

另一方面，我们在实际开发中，可能有很多地方不能实际去验证，需要通过建模方式模拟验证，比如原子弹爆炸，我们不可能天天去爆炸一颗原子弹去验证是否符合设计，而是通过仿真模拟来验证，输入的数据跟真实原子弹的实物数据一样，然后配合实际的物理与化学逻辑，用工具模拟出爆炸情况。

我们自己公司经常用到的需求分析建模工具是FreeMind，基于思维导图原理，还行挺好用，之前用它的原因是我们用的需求管理工具TechExcel的DevSpec自带了这个小工具，用用挺好用，用上了，其实以前也用过Visio，也挺好的，不过白猫黑猫，能抓老鼠是好猫，只要适合行了。（下面是FreeMind的截图，功能还是很强大的，下面也会具体谈到）

第三阶段：需求评审（能不能做、做得好不好）

这个阶段放在第三阶段，其实我是为了配合这篇文章的，实际需求的评审出现在整个需求过程的很多阶段，比如你获取需求以后，需要评审一下，觉得这个需求要不要；你需求分析完了以后，也要评审一下，看看可行性、看看时间与成本；你需求设计以后，还是需要评审一下，看看是否设计合理。。。，所以评审贯穿与需求的始末，有了评审，才能保证你的产品在健康的道路上前进。

第四阶段：需求实现（开始做/让谁去做）

这个阶段其实严格来说不算在需求过程里，而是在开发阶段，不过因为总是是把需求让开发去实现，或多或少总是有点关系，所以我也把它放进来，但是后面可能会较少提及这个阶段。