【本篇爲《如何有效實現軟件的需求管理》第四篇，（第一篇，第二篇，第三篇，第四篇，第五篇，第六篇，第七篇，第八篇）】
第二階段：需求分析與設計（怎麼去做）
既然需求已經獲取了，也就是說客戶已經跟我們說了要做什麼或者我們自己想出來的一些需要做的功能，好了，那現在就真正開始進入需求管理階段了。
首先就是需求分析階段了，所謂的需求分析，簡單點來說就是把獲取的需求分析一下，看看是否真的是客戶所想的，看看是否是我們產品能做的。 有時候一個需求就是客戶一句話，但是真正理解起來並不是一句話就能解決的，所以你可能需要再跟客戶確認，瞭解他們的真實意圖。（下面就是一張經典的需求分析出錯的圖，呵呵，我大學時老師講到過，這次碰巧又被我看到了，就借來一用）
對於一個需求而言，它不是簡簡單單一個功能上的操作，它有可能是一個性能需求，也有可能是安全保密需求，甚至還有可能是用戶接口需求、成本消耗需求、可靠性需求等，所以在需求分析的階段，不是說跟客戶交流幾句話就能把這個需求完全搞清楚的，而且即使搞清楚了這個需求，能不能做（可行性）也不可能一下子想清楚。
所以爲了解決這種問題，各種需求分析的方法也相應而生。如果你在大學的時候學過軟件工程的話，可能你會記得像結構化分析方法之類的方法，什麼數據流程圖啊、數據字典啊、判定表啊，等等，也許當初你爲了應付考試，就匆匆背了一下，到現在想必也應該忘了，即使你當初很用心地去看了，去理解了，我相信沒有真正在工作中用到的話，你其實沒有真正理解它們。
不過，如果你想從事需求分析相關的工作，我可以告訴你，這些知識還是很有用的，需求分析還是需要用到它們的，當然很多時候你應該不會直接用到這些理論，但是總是間接的用了體現它們思想的工具。（比如UML建模）
今天談的是需求的管理，所以對於怎麼做需求分析這種技術性的活，我不多說了，因爲前面也說了，這個靠一篇文章是不能教會的，要真的教會我可能得出一本書了，呵呵。所以我還是側重於去講如何來管理整個過程，包括需求分析階段，也包括之後的需求設計和需求實現階段。
上面提到建模，也許有人問，爲什麼要建模，建模有啥好處，呵呵，這個問題本來不想回答，但是總是有人在問。
一方面，咱們在開發軟件或者硬件，但是你拿到需求後不可能馬上就能給客戶看到這個產品是怎樣的，所以你有必要做個模型出來，讓客戶能看看漲什麼樣子，是不是符合他們的要求，這種就是簡單的建模，對於硬件而言，你可以把縮小版的樣子給客戶看，對於軟件而言，你可以把這個軟件的架構啊，可以實現的功能啊、數據流啊、程序流啊之類的列出來讓客戶去看；
另一方面，我們在實際開發中，可能有很多地方不能實際去驗證，需要通過建模方式模擬驗證，比如原子彈爆炸，我們不可能天天去爆炸一顆原子彈去驗證是否符合設計，而是通過仿真模擬來驗證，輸入的數據跟真實原子彈的實物數據一樣，然後配合實際的物理與化學邏輯，用工具模擬出爆炸情況。
我們自己公司經常用到的需求分析建模工具是FreeMind，基於思維導圖原理，還行挺好用，之前用它的原因是我們用的需求管理工具 TechExcel 的 DevSpec 自帶了這個小工具，用用挺好用，就用上了，其實以前也用過Visio，也挺好的，不過白貓黑貓，能抓老鼠就是好貓，只要適合就行了。（下面是FreeMind的截圖，功能還是很強大的）
第三階段：需求評審（能不能做、做得好不好）
這個階段放在第三階段，其實我是爲了配合這篇文章的，實際需求的評審出現在整個需求過程的很多階段，比如你獲取需求以後，需要評審一下，覺得這個需求要不要；你需求分析完了以後，也要評審一下，看看可行性、看看時間與成本；你需求設計以後，還是需要評審一下，看看是否設計合理。。。，所以評審貫穿與需求的始末，有了評審，才能保證你的產品在健康的道路上前進。
第四階段：需求實現（開始做/讓誰去做）
這個階段其實嚴格來說不算在需求過程裏，而是在開發階段，不過因爲總是是把需求讓開發去實現，或多或少總是有點關係，所以我也把它放進來，但是後面可能會較少提及這個階段。
（未完待續）
