之前把軟件工程中的
測試部分，文檔管理部分都已經做了一些簡單的介紹，因為都是我實際
工作中經常接觸的，所以也算是我的一些經驗吧，不過我也不是每個部分都接觸得很深入，總是有些地方講得不太好的，也請大家諒解，希望大家能提出寶貴經驗，呵呵。
下面是之前講過部分的鏈接（點擊就可以訪問），如果之前沒看過我的文章的話，有空可以看看。
1、【淺談在軟件開發中的開發與測試】
2、【敏捷測試理論以及實踐】
3、【談軟件開發過程管理系統、版本控制系統及它們之間的集成】
4、【文檔管理】
但是軟件工程中除了我已經講過的部分，其實還有幾個部分還沒講了，因為我們公司是用 TechExcel 的 DevSuite 系統的，所以還是借用他們的軟件工程過程圖來給大家講一下。
看下圖，之前講了知識管理（文檔管理），測試管理，開發管理（任務跟蹤），PPM，這篇文章的話，我會講一下需求管理，至于其它幾個部分，比如項目規劃管理，我還在考慮之中，因為有些知識在前面幾篇文章里已經部分提到了，所以講起來可能就重復了。Anyway，先不管了，反正我這篇“需求管理”還是會正常寫下去，謝謝大家閱讀！
PPM
PMI對組合管理的定義為“Project Portfolio management refers to the selection and support of projects or program investments. These investments in projects and programs are guided by the organization’s strategic plan and available resources .”，即項目組合管理是指在可利用的資源和企業戰略計劃的指導下，進行多個項目或項目群投資的選擇和支持。項目組合管理是通過項目評價選擇、多項目組合優化，確保項目符合企業的戰略目標，從而實現企業收益最大化。
項目和項目組合管理（PPM）是項目型組織創新的系統化管理理論和實踐，過去項目管理的理論和工具都是基于單個項目管理的，解決的問題是項目如何使干系人滿意，如何按時、在預算內成功交付項目。對于組織級層面如何管理項目，例如如何使項目目標與組織的業務目標一致，如何跨項目優化利用組織的資金和資源等，一直沒有很好的理論和方法的支持。組合（Portfolio）管理是金融領域的方法論，在2000年左右被引入到項目管理領域，嘗試解決組織級項目管理問題。
自2002年初開始，PPM方法論首先在產品研發管理領域取得了重大成功，并逐漸擴展到IT治理和專業服務領域。這期間，歐美出現了一批非常成功的PPM獨立軟件廠商。從2005年開始，國際上PPM進入整合階段，IBM、CA、HP、Microsoft、Oracle、藍云軟件等國際知名IT企業陸續通過收購進入PPM領域。PPM是未來項目型組織，尤其是IT組織管理優化的方向，這一點已成為業界共識。著名研究機構Forrester Research指出：“PPM已經成為IT企業的ERP”。
什么是軟件需求呢？為什么它需要管理呢？
軟件需求完全嚴格來解釋就是：
（1）用戶解決問題或達到目標所需條件或權能（Capability）。
（2）系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或權能。
（3）一種反映上面（1）或（2）所述條件或權能的文檔說明
也許看起來有點深奧，其實簡單來說，軟件需求就是一個軟件要實現的功能，當然這里所謂的“功能”可能分為兩種情況，一種是有形的，一種是無形的：
● “有形”的應該很好理解，你實際可以用到的功能，比如在Word文檔里能把字加粗。
● “無形”的其實也好理解，雖然你平常用不到，但是還是能感受到的，比如說軟件的運行速度，穩定性，還有比如這個軟件要達到什么目的（比如Word的目的是可以讓你處理文字信息）。
當然，其實最終所有“無形”的需求還是需要靠一個個的“有形”的需求來實現，只是有些“有形“的需求即使實現了客戶也無法直接看到，只有設計、開發與測試才能看到它們。
那為什么要對需求進行管理呢？
軟件需求是隨著計算機的發展而發展的，在計算機發展早期，軟件規模很小，所以當時大家關注的是編碼，而對于需求并不怎么關注，后來隨著“軟件危機”的出現，誕生了軟件工程，而需求階段就是其第一階段，至此，軟件需求（也稱之為需求分析）階段開始慢慢被關注。
大家都知道，“軟件危機”的原因是落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，軟件系統的規模越來越大，復雜程度越來越高，軟件可靠性問題也越來越突出，原來的個人設計、個人使用的方式不再能滿足要求，迫切需要改變軟件生產方式，提高軟件生產率，軟件危機開始爆發。
而軟件需求分析階段作為軟件工程的第一階段，需要為一個軟件的開發搭好最初的框架并且還要考慮好后面可能的修改，所以對于軟件可靠性、易用性、可擴展性和可維護性來說，需求分析階段是及其重要的，直接關系到一個軟件是否能夠成功。
如果一個產品在需求分析階段沒有被設計好的話，在以后的各個階段，開發與維護的成本就會非常高，導致最后失敗的可能性就會非常大，著名的例子比如微軟的Vista，設計初期沒有考慮好兼容性與硬件，導致發布以后發現與其他軟件的兼容性很差，而且硬件要求又很高，很多客戶不買他們的賬，所以最后匆匆收場，趕緊推出Windows 7來，要知道Vista的開發成本估計要接近百億美金了，都還沒怎么賺錢就趕緊推出另外一個產品，足見其失敗了。
所以軟件需求分析階段對于軟件工程而言，已經成為至關重要的階段，其實按照我的理解，它已經成為軟件工程最重要的階段，記住，不是之一。（當然，我這里說的需求分析階段是包含軟件的設計階段的）
一個軟件的成功與否，在需求分析與設計階段已經可以基本上預見了，因為需求分析與設計階段從概念上其實已經把這個產品做出來了，而之后的編碼階段只是去實現它，讓產品能真正可以去用。那這個“實現”階段其實相對來說就不會那么重要了，所以現在很多跨國公司只在總部保留設計部門，研發部門都外包出去，就是這個原因。 “蘋果”就是這樣一個公司，把需求分析與設計工作做好，讓臺灣人去把產品做出來，最后得到一個完美的產品。
既然軟件需求階段已經變成如此重要，那對它的管理也就相應的變得特別重要了，只有把需求設計做好了，產品才有可能成功，所以我們就需要對這個階段進行有效的管理，而且是非常有效的管理！