需求管理是軟件項目中一項十分重要的工作，據調查顯示在眾多失敗的軟件項目中，由于需求原因導致的約占了很大的一部分，本人從事的工作經歷中有好２次就是因為需求不明確，導致最終的系統不可控，項目陷入困境。因此，需求工作將對軟件項目能否最終實現產生至關重要的影響。雖然如此，在項目開發工作中，很多人對需求的認識還遠遠不夠，從本人參與或接觸到的一些項目來看，小到幾萬元，大到上千萬元的軟件項目的需求都或多多少的存在問題。
有的是開發者本身不重視原因,有的是技術原因、有的是人員組織原因、有的是溝通原因、有的是機制原因，以上種種原因都表明做好軟件需求開發是一項系統工作，而不是簡單的技術工作，只有系統的了解和掌握需求的基本概念、方法、手段、評估標準、風險等相關知識，并在實踐中加以應用，才能真正做好需求的開發和管理工作。在軟件項目的開發過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發，維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業的新動態，都為軟件帶來不斷完善功能，優化性能，提高用戶友好性的要求。在軟件項目管理過程中，項目經理經常面對用戶的需求變更。如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發人員的士氣將越來越低落，將直接導致項目成本增加、質量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。
行業客戶對信息化的需求越來越細化，對專業性以及行業能力的全面性要求越來越高，惟有深入行業，洞察其需求，研發出更適合客戶需求的產品，才能成功。因此有必要先請這方面的行業專家對于客戶的業務需求進行從流程上的梳理。為什么請行業專家，而不是直接請客戶進行交談，得到其實需求，個人認為主要是因為目前各政府部門、企事業單位對于信息化與業需求的整合這一塊缺少經驗，大部分情況還不能完全整理出完善、清晰的系統需求來。只有通過行業專家對其實業務流程進行梳理，一方面更容易與客戶產生共鳴，另一方面也可以大大減少因為知識方面的差異導致錯識需求的產生。
你要面對“正確”的客戶區分不同層次的客戶需求,要面對不同層級，不同部門的客戶，把客戶分類,區分需求的優先級別.如果你做的項目業務是你熟悉的，那還好，如果是你不熟悉的，一定要花點精力學習一下這個行業業務的背景資料,這也是我上面談到的先請行業專家的原因。畢竟，客戶是不可能給你系統地介紹業務的。只有你通曉了行業業務，才能和用戶交流，并正確而有效地引導客戶，做好需求分析，你不能指望客戶能明確地說出需求。當然，這也是系統分析人員的職責所在。在開始做需求的時候，你最后花一點時間搞清楚你接觸的客戶是不是做實際業務的客戶，如果你面對的客戶不是將來的系統的實際使用者。你就有點麻煩了。可能他是客戶公司派過來的IT部的人，他會提一大堆東西，而這些東西可能根本不是實際業務需要的功能，而他一般還會興致勃勃地給你一些技術實現的建議。這個時候你就要小心了，如果你聽了他的話，你可能在最后才發現，你花了大量精力解決的問題，其實并不是客戶真正需要的。而你真正需要關注的，卻做得遠遠不夠。
參考其他類似軟件和系統
在經過與客戶的溝通，并形成初步的需求之后,不要急成正式的需求，請先參考一下以前的一些系統，去理解一下了解到的需求與原先系統的差異，并去發現是否有些需求會產生錯識需求。
業務建模
為需求建立模型，需求的圖形分析模型是軟件需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。
需求整理并形成需求規格說明書
需求規格說明書的模板我想每家公司都是不一樣的，也沒有必要都一樣，但我認為每個需求規格說明書至少應包括
軟件需求一旦通過了評審,就應該基線化,納入配置管理庫.而在配置管理庫中的文檔或代碼不能再輕易進行修改.當有需求要進行變更的時候,就必須提出申請,寫需求變更計劃,審核通過,才有權限進行需求變更.然后配置管理員一定要做好需求的跟蹤.,凡是跟變更需求有牽連的開發人員和測試人員都要同步的通知到和及時讓他們做好相應部分的各類文檔的修改。
需求變更管理
需求的變更管理我個人認為是最容易出問題，一般項目做不完也主要是由此產生。需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改變他們的工作方式;或者要開發的系統對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著開發工作的不斷進展，系統開始展現功能的雛形，用戶對系統的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現。如何有效的管理需求變更，下面是我公司目前的做法。公司采用Test Director作為需求管理工具，需求人員每次與客戶溝通后形成需求調查表，統一錄入Test Director,并進行綜合及整理后形成需求規格說明書， 之后由研發部、產品部、及銷售代表（如果有客戶參加就更好了）進行需求評審，建立需求基線。制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循變更控制流程進行控制，同時每一筆重要的需求變更都需要客戶簽字確認才認為需求變更生效。需求變更后，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。因為Test Director提供了需求變更記錄，可以幫助我們形成良好的文檔，便于進行管理。
2. 需求管理
首先要針對需求做出分析，隨后應用于產品并提出方案。需求分析的模型正是產品的原型樣本，優秀的需求管理提高了這樣的可能性：它使最終產品更接近于解決需求，提高了用戶對產品的滿意度，從而使產品成為真正優質合格的產品。從這層意義上說，需求管理是產品質量的基礎。
需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。
需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。
需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據需求文檔進行開發。
需求變更控制是指依據“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。
根據上面描述的具體方法及步驟，由于需求分析的參與人員、業務模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風險,應引起項目相關干系人的注意。這些風險主要表現如下：
1）用戶不能正確表達自身的需求。在實際開發過程中，常常碰到用戶對自己真正的需求并不是十分明確的情況，他們認為計算機是萬能的，只要簡單的說說自己想干什么就是把需求說明白了，而對業務的規則、工作流程卻不愿多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花費更多的時間和精力與用戶交流，幫助他們梳理思路，搞清用戶的真實需求。從另一方面來看，他們對于計算機的理解肯定不是很到位，而我們如何引導，正確梳理出正確的需求就需要先從工作業務流程出發，而不是先從計算機方面來考慮問題。
2）業務人員配合力度不夠。有的用戶日常工作繁忙，他們不愿意付出更多的時間和精力向分析人員講解業務，這樣會加大分析人員的工作難度和工作量，也可能導致因業務需求不足而使系統無法使用。針對此類問題我們一般的做法是在項目開始階段先確定好一個與客戶溝通過的需求調研計劃，當然這樣還是經常會有變動，但相對來講從責任上來講，客戶也會有一定的壓力，因為如果不配合可能會導致系統進度的延誤，其實這也不是客戶希望看到的。
3）用戶需求的不斷變更。由于需求識別不全、業務發生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發生變化，因此，我們要認識到，軟件開發的過程實際上是同變化做斗爭的過程，需求變化是每個開發人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發生了需求變化，就不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等等，需求的變化就像是萬惡之源，為項目的正常的進展帶來不盡的麻煩。針對這類需求變更的問題，個人認為是影響進度的最大的敵人，目前我們的做法是每次根據客戶的需求整理出一個書面的文件，由客戶簽字確認。當然這里還有一個很重要的問題就是不是每個需求都是必須做的，我們要學習如何拒絕客戶。
4）需求的完整程度。需求如何做到沒有遺漏？這是一個大問題，大的系統要想窮舉需求幾乎是不可能的，即使小的系統，新的需求也總會不時地冒出來。一個系統很難確定明確的范圍并把所有需求一次性提出來，這會導致開發人員在項目進展中去不斷完善需求，先建立系統結構再完成需求說明，造成返工的可能性很大，會給開發人員帶來挫折感，降低他們完成項目的信心。
5）需求的細化程度。需求到底描述到多細，才算可以結束了？雖然國家標準有需求說明的編寫規范，但具體到某一個需求上，很難給出一個具體的指標，可謂仁者見仁，智者見智，并沒有定論。需求越細，周期越長，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求也越高，相反，需求越粗，開發人員在技術設計時不清楚的地方就越多，影響技術設計。
6）需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說明產生了不同的理解；另一方面是指同一讀者能用不同的方式來解釋某個需求說明。多義性會使用戶和開發人員等項目參與者產生不同的期望，也會使開發、測試人員為不同的理解而浪費時間，帶來不可避免的后果便是返工重做。
7）忽略了用戶的特點分析。分析人員往往容易忽略了系統用戶的特點，系統是由不同的人使用其不同的特性，使用頻繁程度有所差異，使用者受教育程度和經驗水平不盡相同。如果忽略這些的話，將會導致有的用戶對產品感到失望。
8）需求開發的時間保障。為了確保需求的正確性和完整性，項目負責人往往堅持要在需求階段花費較多的時間，但用戶和開發部門的領導卻會因為項目遲遲看不到實際成果而焦慮，他們往往會強迫項目盡快往前推進，需求開發人員也會被需求的復雜和善變折騰的筋疲力盡，他們也希望盡快結束需求階段。
在實際的工作中，我列了一些需要關注的問題，以避免一些不必要的麻煩。
1）抓住決策者最迫切和最關心的問題，引起重視。用戶方決策者對項目的關心重視程度是項目能否順利開展的關鍵，決策者的真實意圖也是用戶方的最終需求，因此，在開發過程中要利用一切機會了解決策者關心的問題，同時也要讓他們了解項目的情況。在諸如談判、專題匯報、協調會議、領導視察、階段性成果演示等過程中用簡短明確的語言或文字抓住領導最關心的問題，引導他們了解和重視項目的開發，當決策者認識到項目的重要性時，需求分析工作在人力、物力、時間上就有了保障。
2）建立組織保障，明確的責任分工。項目開發一般都會成立相應的項目組或工程組，目前，常見的組織形式是：產品管理組、質量與測試組、程序開發組、用戶代表組和后勤保障組，各組的主要分工是：產品管理組負責確定和設置項目目標，根據需求的優先級確定功能規范，向相關人員通報項目進展。程序管理組負責系統分析，根據軟件開發標準協調日常開發工作確保及時交付開發任務，控制項目進度。程序開發組負責按照功能規范要求交付軟件系統。質量與測試組負責保證系統符合功能規范的要求，測試工作與開發工作是獨立并行的。用戶代表組負責代表用戶方提出需求，負責軟件的用戶方測試。后勤保障組負責確保項目順利進行的后勤保障工作。
3）建立良好的溝通環境和氛圍。分析人員與用戶溝通的程度關系到需求分析的質量，因此建立一個良好的溝通氛圍、處理好分析人員與用戶之間的關系顯得尤其重要，一般情況，用戶作為投資方會有一些心理優勢，希望他們的意見得到足夠的重視，分析人員應該充分的認識到這一點，做好心理準備，盡量避免與他們發生爭執，因為我們的目的是幫助用戶說出他們的最終需要。在溝通時分析人員應注意以下幾個方面：1）態度上要尊重對方，但不謙恭。謙恭可能會讓用戶一時感到滿意，但對長期合作并沒有好處，尤其是在發生沖突的時候，用戶會習慣性地感到自己的優勢，而忽略分析人員地意見。2）分析人員要努力適應不同用戶的語言表達方式。每個人都有自己的表達方式，所以優秀的分析人員應該是一個優秀的“傾聽者”，他們能很快的適應用戶的語言風格，理解他們的意思。 3）善于表達自己，善于提問。分析人員在開口前應該先讓對方充分表達他的意思，在領會了后，自己再說，盡量不要搶話。4）工作外的交流有助于增進理解，加強溝通。
4）需求質量控制要制度化需求的變化是軟件項目不可避免的事實，因此需求質量控制是一項艱苦的工作，要保證該項工作的順利實施，就必須有制度保證，這個制度可以在項目質量控制方案中制定，該方案主要是具體化、定量化的描述用戶要求，形成全面、一致、規范的軟件需求分析規格說明書，明確需求分析規格說明書的工作程序和要素，規范開發活動，為后續軟件設計、實現、測試、評審及驗收提供依據。在方案中要明確項目組各部門關于需求質量控制的職責，制定需求分析的工作程序，包括編制需求分析工作計劃、編制《需求分析說明書》、《需求分析規格說明書》的評審和確認、《需求分析規格說明書》修改控制、確定需求質量控制的質量記錄文檔規范等內容。
本文論述圍繞于需求管理,需求管理是開發工作有效進行的確證。很明顯需求管理是一種很高層次的系統行為，涉及整個開發過程和產品本身。需求管理首先要針對需求做出分析，隨后應用于產品并提出方案。需求分析的模型正是產品的原型樣本，優秀的需求管理提高了這樣的可能性：它使最終產品更接近于解決需求，提高了用戶對產品的滿意度，從而使產品成為真正優質合格的產品。從這層意義上說，需求管理是產品質量的基礎。