通過高級項目經理5天課程的培訓，個人感覺對于原先的工作實踐有了一個很好的指導，從原先的實踐上升了一個層次，對于實踐有了一個很好的理論指導。

　　我想很多人可能會與我同感，一個項目做了很久，感覺總是做不完，就像一個“無底洞”。你想加人盡快完成這個項目，而用戶總是有新的需求要項目開發(fā)方來做，就像用戶是一個不知廉恥的要求者，而開發(fā)方是在苦苦接收的接受者。實際上，這里涉及到一個需求管理的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由需求管理來決定的。那么，到底什么是需求管理，從這幾天的學習中，我從理論上對此問題做了一個分析，表達一些自已的想法。

　　影響項目的最后成功的因素是多方面的，包括項目管理的九大知識領域(包括項目的整體管理、范圍管理、時間管理、費用管理、質量管理、溝通管理、成本管理、人力資源管理、采購管理)。然而，要這九大知識領域對項目成功產生的影響的輕重程度上進行比較的話，我個人認為其中項目范圍管理中的需求管理是最為重要的。本文主要講述范圍管理中的需求管理部分。

　　需求管理是軟件項目中一項十分重要的工作，據調查顯示在眾多失敗的軟件項目中，由于需求原因導致的約占了很大的一部分，本人從事的工作經歷中有好2次就是因為需求不明確，導致最終的系統(tǒng)不可控，項目陷入困境。因此，需求工作將對軟件項目能否最終實現(xiàn)產生至關重要的影響。雖然如此，在項目開發(fā)工作中，很多人對需求的認識還遠遠不夠，從本人參與或接觸到的一些項目來看，小到幾萬元，大到上千萬元的軟件項目的需求都或多多少的存在問題。

　　有的是開發(fā)者本身不重視原因,有的是技術原因、有的是人員組織原因、有的是溝通原因、有的是機制原因，以上種種原因都表明做好軟件需求開發(fā)是一項系統(tǒng)工作，而不是簡單的技術工作，只有系統(tǒng)的了解和掌握需求的基本概念、方法、手段、評估標準、風險等相關知識，并在實踐中加以應用，才能真正做好需求的開發(fā)和管理工作。在軟件項目的開發(fā)過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發(fā)，維護，用戶的經驗在增加，對使用軟件的感受有變化，以及整個行業(yè)的新動態(tài)，都為軟件帶來不斷完善功能，優(yōu)化性能，提高用戶友好性的要求。在軟件項目管理過程中，項目經理經常面對用戶的需求變更。如果不能有效處理這些需求變更，項目計劃會一再調整，軟件交付日期一再拖延，項目研發(fā)人員的士氣將越來越低落，將直接導致項目成本增加、質量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。

　　下面主要針對需求開發(fā)及需求管理兩個方面對需求進行分析。

　　1. 需求開發(fā)，從目前我們的實際工作情況來看按順序主要分成如下幾個部分:

　　Ø 請教行業(yè)專家

　　行業(yè)客戶對信息化的需求越來越細化，對專業(yè)性以及行業(yè)能力的全面性要求越來越高，惟有深入行業(yè)，洞察其需求，研發(fā)出更適合客戶需求的產品，才能成功。因此有必要先請這方面的行業(yè)專家對于客戶的業(yè)務需求進行從流程上的梳理。為什么請行業(yè)專家，而不是直接請客戶進行交談，得到其實需求，個人認為主要是因為目前各政府部門、企事業(yè)單位對于信息化與業(yè)需求的整合這一塊缺少經驗，大部分情況還不能完全整理出完善、清晰的系統(tǒng)需求來。只有通過行業(yè)專家對其實業(yè)務流程進行梳理，一方面更容易與客戶產生共鳴，另一方面也可以大大減少因為知識方面的差異導致錯識需求的產生。

　　Ø 和客戶交談

　　你要面對“正確”的客戶區(qū)分不同層次的客戶需求,要面對不同層級，不同部門的客戶，把客戶分類,區(qū)分需求的優(yōu)先級別.如果你做的項目業(yè)務是你熟悉的，那還好，如果是你不熟悉的，一定要花點精力學習一下這個行業(yè)業(yè)務的背景資料,這也是我上面談到的先請行業(yè)專家的原因。畢竟，客戶是不可能給你系統(tǒng)地介紹業(yè)務的。只有你通曉了行業(yè)業(yè)務，才能和用戶交流，并正確而有效地引導客戶，做好需求分析，你不能指望客戶能明確地說出需求。當然，這也是系統(tǒng)分析人員的職責所在。在開始做需求的時候，你最后花一點時間搞清楚你接觸的客戶是不是做實際業(yè)務的客戶，如果你面對的客戶不是將來的系統(tǒng)的實際使用者。你就有點麻煩了。可能他是客戶公司派過來的IT部的人，他會提一大堆東西，而這些東西可能根本不是實際業(yè)務需要的功能，而他一般還會興致勃勃地給你一些技術實現(xiàn)的建議。這個時候你就要小心了，如果你聽了他的話，你可能在最后才發(fā)現(xiàn)，你花了大量精力解決的問題，其實并不是客戶真正需要的。而你真正需要關注的，卻做得遠遠不夠。

　　Ø 參考其他類似軟件和系統(tǒng)

　　在經過與客戶的溝通，并形成初步的需求之后,不要急成正式的需求，請先參考一下以前的一些系統(tǒng)，去理解一下了解到的需求與原先系統(tǒng)的差異，并去發(fā)現(xiàn)是否有些需求會產生錯識需求。

　　Ø 業(yè)務建模

　　為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。

　　Ø 需求整理并形成需求規(guī)格說明書

　　需求規(guī)格說明書的模板我想每家公司都是不一樣的，也沒有必要都一樣，但我認為每個需求規(guī)格說明書至少應包括

　　軟件需求一旦通過了評審,就應該基線化,納入配置管理庫.而在配置管理庫中的文檔或代碼不能再輕易進行修改.當有需求要進行變更的時候,就必須提出申請,寫需求變更計劃,審核通過,才有權限進行需求變更.然后配置管理員一定要做好需求的跟蹤.,凡是跟變更需求有牽連的開發(fā)人員和測試人員都要同步的通知到和及時讓他們做好相應部分的各類文檔的修改。

　　Ø 需求變更管理

　　需求的變更管理我個人認為是最容易出問題，一般項目做不完也主要是由此產生。需求變更的出現(xiàn)主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改變他們的工作方式;或者要開發(fā)的系統(tǒng)對用戶來說也是個未知數(shù)，他們以前沒有過相關的使用經驗。隨著開發(fā)工作的不斷進展，系統(tǒng)開始展現(xiàn)功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)。如何有效的管理需求變更，下面是我公司目前的做法。公司采用Test Director作為需求管理工具，需求人員每次與客戶溝通后形成需求調查表，統(tǒng)一錄入Test Director,并進行綜合及整理后形成需求規(guī)格說明書， 之后由研發(fā)部、產品部、及銷售代表(如果有客戶參加就更好了)進行需求評審，建立需求基線。制訂簡單、有效的變更控制流程，并形成文檔。在建立了需求基線后提出的所有變更都必須遵循變更控制流程進行控制，同時每一筆重要的需求變更都需要客戶簽字確認才認為需求變更生效。需求變更后，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。因為Test Director提供了需求變更記錄，可以幫助我們形成良好的文檔，便于進行管理。