【本篇為《如何有效實現軟體的需求管理》第三篇，（第一篇，第二篇）】
第二階段：需求分析與設計（怎麼去做）
既然需求已經獲取了，也就是說客戶已經跟我們說了要做什麼或者我們自己想出來的一些需要做的功能，好了，那現在就真正開始進入需求管理階段了。
首先就是需求分析階段了，所謂的需求分析，簡單點來說就是把獲取的需求分析一下，看看是否真的是客戶所想的，看看是否是我們產品能做的。 有時候乙個需求就是客戶一句話，但是真正理解起來並不是一句話就能解決的，所以你可能需要再跟客戶確認，了解他們的真實意圖。（下面就是一張經典的需求分析出錯的圖，呵呵，我大學時老師講到過，這次碰巧又被我看到了，就借來一用）
對於乙個需求而言，它不是簡簡單單乙個功能上的操作，它有可能是乙個效能需求，也有可能是安全保密需求，甚至還有可能是使用者介面需求、成本消耗需求、可靠性需求等，所以在需求分析的階段，不是說跟客戶交流幾句話就能把這個需求完全搞清楚的，而且即使搞清楚了這個需求，能不能做（可行性）也不可能一下子想清楚。
所以為了解決這種問題，各種需求分析的方法也相應而生。如果你在大學的時候學過軟體工程的話，可能你會記得像結構化分析方法之類的方法，什麼資料流程圖啊、資料字典啊、判定表啊，等等，也許當初你為了應付考試，就匆匆背了一下，到現在想必也應該忘了，即使你當初很用心地去看了，去理解了，我相信沒有真正在工作中用到的話，你其實沒有真正理解它們。
不過，如果你想從事需求分析相關的工作，我可以告訴你，這些知識還是很有用的，需求分析還是需要用到它們的，當然很多時候你應該不會直接用到這些理論，但是總是間接的用了體現它們思想的工具。（比如uml建模）
今天談的是需求的管理，所以對於怎麼做需求分析這種技術性的活，我不多說了，因為前面也說了，這個靠一篇文章是不能教會的，要真的教會我可能得出一本書了，呵呵。所以我還是側重於如何去管理。
我們自己公司經常用到的需求分析建模工具是freemind，基於思維導圖原理，還行挺好用，之前用它的原因是我們用的需求管理工具techexcel的devspec自帶了這個小工具，用用挺好用，而且可以與需求點以及相關文件做關聯，實時同步需求的變更，所以就用上了，其實以前也用過visio，也挺好的，不過白貓黑貓，能抓老鼠就是好貓，只要適合就行了。（下面是freemind的截圖，功能還是很強大的，下面也會具體談到）
談到建模，也許有人問，為什麼要建模，建模有啥好處，呵呵，這個問題本來不想回答，但是總是有人在問。
一方面，咱們在開發軟體或者硬體，但是你拿到需求後不可能馬上就能給客戶看到這個產品是怎樣的，所以你有必要做個模型出來，讓客戶能看看漲什麼樣子，是不是符合他們的要求，這種就是簡單的建模，對於硬體而言，你可以把縮小版的樣子給客戶看，對於軟體而言，你可以把這個軟體的架構啊，可以實現的功能啊、資料流啊、程式流啊之類的列出來讓客戶去看；
另一方面，我們在實際開發中，可能有很多地方不能實際去驗證，需要通過建模方式模擬驗證，比如原子彈**，我們不可能天天去**一顆原子彈去驗證是否符合設計，而是通過**模擬來驗證，輸入的資料跟真實原子彈的實物資料一樣，然後配合實際的物理與化學邏輯，用工具模擬出**情況。
（未完待續）
如何有效實現軟體的需求管理 2
什麼是軟體需求呢？為什麼它需要管理呢？軟體需求完全嚴格來解釋就是 1 使用者解決問題或達到目標所需條件或權能 capability 2 系統或系統部件要滿足合同 標準 規範或其它正式規定文件所需具有的條件或權能。3 一種反映上面 1 或 2 所述條件或權能的文件說明 也許看起來有點深奧，其實簡單來說...
如何有效實現軟體的需求管理（7）
如何有效實現軟體的需求管理 7 本篇為 如何有效實現軟體的需求管理 第七篇，第一篇，第二篇，第三篇，第四篇，第五篇，第六篇 版本控制 在我們公司的實際需求管理中，需求的版本控制用的地方非常多，比如 第一，因為乙個需求從獲取到最終能拿去開發，中間也需要經歷非常多次的改動。既然有改動，就肯定也會出現類似...
產品經理如何有效進行產品需求管理
需求是整個軟體專案當中最重要一項輸入。軟體開發和傳統生產行業最大的區別在於，需求總是模糊的 主觀的和隨時變化的。相對於電子產品 汽車等製造行業有形的硬體需求，軟體開發的需求的描述和驗收是個難以解決的問題。但是需求又是整個專案能否成功的決定性因素，所以我們必須對需求進行管理，從而使需求成為整個軟體工程...