在軟體開發過程中需求的重要性無需長篇累牘來描述，可以說在軟體開發過程中所有的一切都將圍繞需求展開。那麼在軟體開發過程有效地進行需求管理，將對軟體最終的成功與否起到至關重要的作用。問題的關鍵是：我們如何做好需求管理？
首先，讓我們一起來共同認識一下「需求」。「需求」-軟體開發時應滿足的功能與非功能性要求(維基百科中關於軟體需求的定義)。就我個人而言，我所認為的需求就是人們為了滿足某種目標而產生的某種慾望或希望，有了目標就產生了需要，有了需要就提出了諸多要求來實現目標，需求就這樣不斷豐滿起來，宛如少女成長一般逐漸豐富起來。那麼需求管理則是為了更好地對需求進行規範處理，通過有意識地梳理不同組織、人物與型別的需求，從而形成完整的需求體系結構，基於體系化的管理理念實現對分散、凌亂的需求進行管理，幫助軟體開發有序開展工作，最終取得軟體產品或專案的成功。需求管理從理論上來講主要分為三個層次：採集、分析與管理。其中採集階段希望通過有效地溝通手段，了解到使用者內心的想法與要求；而分析階段則側重對使用者的要求與想法進行深層次的剖析，強調**要求的動機與背後的故事，希望運用分析手段有效地實現對需求控制與駕奴；那麼管理則強調以科學、理論及高效的管理理念，實現對需求全生命週期的控制，形成完整的需求血統分析結構，重點在對需求進行「管」，防止需求在發展過程中迷失自我以控制軟體開發風險。
在業界諸多的需求管理理念與方**層面習慣將需求劃分為：業務需求、使用者(產品)需求、功能需求等三大維度。業務需求強調對業務生產環境進行全面而細緻的分析與理解，簡而言之就是分析「做什麼」階段；產品需求則側重於對業務需求結合實際情況總結與梳理出相應的資訊化解決辦法，可以理解為"怎麼做"階段；而功能需求則重在將產品需求結合具體資訊化技術進行「落地」，通過將需求以形象化、立體化、真實化地功能與手段呈現在系統中，此階段可以理解為「如何做」階段。「做什麼」側重於對事情的前因後果分析，「怎麼做」考驗的是需求分析人員提煉總結能力，而「如何做」則對需求分析人員提出了更高的要求，它全面考查分析人員對資訊架構、使用者體驗與業務流程等一系列素質及素養。所以還是那句谷話「站著說話不腰痛」，事情說說簡單，做起來卻未必能夠如你所願。
前面我們對需求的不同維度進行了乙個簡短的分析與了解，那麼回到我們的核心問題上來，即「需求分析與管理，我到底該怎麼來開展呢！」，其實這個問題本身就是乙個偽命題，因為需求分析與管理是一門系統的學科，融合了管理、諮詢、統計、數學等多方面的知識，對人員素質要求也相對較高。有人會問「這麼說起來，那需求管理我們還能不能搞定它呢！」，其實個人理解事情總有它的複雜性，我們不可能將事情考慮得面面俱到，只要我們遵循2/8原則，再輔助運用好一些相應的方法與技巧，逐步、逐層地推進需求分析與管理工作，一旦事情順暢通達起來，自然而然就會得心應手。那下面我們就一起來分享個人對需求分析與管理方面的一些淺顯的看法與理解，將主要從需求方**、需求管理理念與需求分析常見問題幾個層面來進行簡單地描述，與大家一起共同學習成長。具體內容如下所述
(一)需求方**
管理學中有一種重要的觀點便是"方法比什麼都重要"，同時在我們實際工作中無數次經歷證明這一定律確實管用。在我們進行需求分析工作時產生的很多困境往往是由於我們沒有通過正確的方法去做事，缺少了明確的方向指引，導致事情到最後越來越複雜，慢慢地失控了！那在需求分析與管理過程中，具體有哪些科學、先進的方**來幫助我們，個人簡單總結大概以下幾種型別：
a.物件導向分析方**(rup)
b.面向過程分析方**(資料流等)
c.敏捷需求分析管理 d.
zachman框架
上述方**看起來名頭都很大，讓人感覺無法駕馭！不用擔心，那就用我們用比較形象的語言來對它進行簡單的歸納與總結吧！rup需求方**，我們用「五維**法」來對它表述，此種方法強調的是從人、事、物、因、規等五個維度對需求涉及業務進行深入分析後得出系統「業務需求」，然後採用用例場景描述與細化的技術，將業務場景進行形象化表達、總結與提練，形成系統的「產品需求」，在上述二種需求分析到位後才逐漸推進「功能需求」的分析與設計，整體上分為三個階段完成系統的需求分析工作。而敏捷需求分析則強調以「使用者故事」的方式進行需求分析組織工作，配合以用例形象化、立體化、顯性化的手段，以「迭代」方式分層分階段並配合部分輕量級文件推進需求工作穩步前進。而zachman
框架大家可能比較陌生，個人對它的總結就是通過描述「什麼人在什麼時間、什麼地點通過運用什麼樣的行為與資料達到什麼樣的動機」的方式來進行需求分析工作，從「組織、位置、時間、行為、動機、資料」等六個維度進行需求分析，並結合「系統分析師、系統客戶、架構師、設計師、開發人員」等角色檢視層面去形成乙個立體的需求分析網路結構，全面覆蓋系統需求內容。
那是不是我們在實際工作中就需要運用到上述所有的方**來指導工作呢！不然，個人建議結合專案實際情況來選擇合適的需求分析方**來指導工作。對「業務流程貫穿建設過程、傳統企業資訊化」等型別專案，則建議使用"五維**法"來指導工作。而對「諮詢式、bi類」專案更多建議採用「敏捷需求分析」方法來引導。具體選擇哪種方法還需要結合具體實際情況綜合而定，決定權在你手中，我們只選對的，不選牛的。
(二)需求管理理念
「磨刀不誤砍柴功」，前面我們選擇好了合適的需求方**來指導我們開展需求工作。但剛有方**似乎還少點什麼東西？對，我們少的就是需求管理的「理念」。在個人看來需求管理的核心信念應該是"關注細節"，不論是需求前的通過「文件考古」來熟悉了解行業背景與專業術語也好，還是進行使用者訪談、調查問卷、資料分析等工作來強化需求分析結果，都離不開乙個「細」字，沒有大量細緻、認真的工作進行積累與鋪墊是很難出色地完成好需求分析與管理工作。同時需求管理工作個人認為可以從「需求內容有沒有、需求分析質量幾何、需求結果傳播控制」等三個階段進行重點關注，我們只有先解決了「有」的問題，才能來重點關注「高質量」內容，最後只有通過強有力的手段來控制需求「不失真」地進行傳播，最終才能確保系統建設達到客戶的預期。
(三)需求分析常見問題
前面我們講了一大堆的理論與看法，暫時讓我們回歸到現實過程中來吧！ 在大家的日常需求分析過程中，常常會出現一些問題或疑惹，它們干擾我們高效、優質地完成需求分析工作內容，那我們該怎麼辦呢！先讓我們來看看到底是何方神聖在阻止我們，具體問題如下：
a.在與客戶溝通過程中存在盲點，我們該怎麼解決呢？
還是那句老話，「細節決定成敗」，對於此類問題我們必須從需求源頭、過程管控、事後複檢幾個方面來強化工作內容！解決上述問題我們的建議是：
b.怎麼樣才能做好一次使用者訪談呢? 使用者訪談該注意哪些方面工作？
我們可以從以下幾點開始著手解決問題
1.進行資料收集與前期研究工作，了解相關業務知識；
2.了解客戶組織架構並進行使用者訪談樣本選擇；
3.制定明確的使用者訪談計畫，確定使用者訪談的物件、時間與地點；
4.訪談前與訪談物件進行溝通共同確定訪談問題大綱；
5.確定訪談需要達到的目標，並緊緊圍繞目標進行問題設計，並對相關問題有自己的理解；
6.在訪談過程中以聽為主，避免引導客戶思維；
同樣在進行訪談過程中，還需要注意一些事項，具體見下圖：
c.在需求採集過程， 客戶配合度不高，工作開展不順利？
那麼就讓我們從對客戶組織架構進行全面了解，對系統使用者進行「畫象」，對「畫象」使用者進行分析，獲取其中部分使用者支援；經過對同類解決方案的分析，提供初步的需求產出物交由客戶簽字確認與商務合作加大客情關係投入力度，錄求客戶高層領導的支援；分析客戶不配合原因，有針對性地進行需求採集工作等內容上著手解決吧！
d.在需求採集過程， 客戶只提意見，其它一概回答不清楚、不明白？
這種客戶屬於「極品」級，那麼我們就以迭代的方式開展需求採集工作；適當採用敏捷方法進行需求獲取；結合系統原型 法激發客戶需求；以諮詢方式式對客戶思維與需求進行引導去開展工作，希望能夠解決一些問題。
e.在需求採集過程， 客戶與使用者不一樣，該怎麼辦？
很多系統都存在此類問題，個人建議對於此種情況以客戶意見為主，尊重使用者訴求，注重使用者體驗工作；在資源許可的情況下，組織使用者大會，聽取多方面的聲音；
在必要的前題條件下，對使用者進行**訪談或發放使用者調查問卷。
淺顯與深奧
專案管理類與工程類的過程域已經講過多遍了，在每次講課前,總要花費很多時間來備課,每次備課,每次講課都會有新的體會.然而仍然對cmmi中的有些概念不能準確把握,很是鬱悶.忽然想起來了 簡單就是美 這句話,模型是實踐的總結,不是理論的總結,我也有10多年的軟體工程經驗了,也讀了n多的書,為什麼仍然在查閱...
需求管理與分析 需求池
產品經理 會聆聽使用者聲音進行需求收集 但是真正的需求需要我們去優化。真正優化的應該是從需求的收集 到最終形成功能融入到產品 中的這個過程。下面做乙個簡單科學的流程。一 需求收集 從使用者 市場 競品 同事 朋友等渠道無差別收集各類問題 建議 與想法，另外通過資料分析和解讀出來的需求也可以新增進去。...
需求管理與分析 需求池
產品經理會聆聽使用者聲音進行需求收集，但是真正的需求需要我們去優化。真正優化的應該是從需求的收集到最終形成功能融入到產品中的這個過程。下面做乙個簡單科學的流程。一 需求收集 從使用者 市場 競品 同事 朋友等渠道無差別收集各類問題 建議 與想法，另外通過資料分析和解讀出來的需求也可以新增進去。盡量詳...