做軟件項目，客戶是上帝，同時也是惡魔。在做需求管理的時候，需要謹慎對待客戶提出的每一個需求。對於一些合理有用需求需要重視，對於一些只是沒有實現可行性的理想中的需求，請果斷拒絕，並說明原由，盡可能說服客戶。下面是一個軟件項目管理者的經驗分享，希望對大家的需求管理的工作有所幫助。

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

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

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

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

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

請教行業專家

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

參考其他類似軟件和系統

在經過與客戶的溝通，並形成初步的需求之後,不要急成正式的需求，請先參考一下以前的一些系統，去理解一下了解到的需求與原先系統的差異，並去發現是否有些需求會產生錯識需求。項目經理博客

業務建模

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

需求整理並形成需求規格說明書

需求規格說明書的模板我想每家公司都是不一樣的，也沒有必要都一樣，但我認為每個需求規格說明書至少應包括，軟件需求一旦通過了評審,就應該基線化,納入配置管理庫.而在配置管理庫中的文檔或代碼不能再輕易進行修改.當有需求要進行變更的時候,就必須提出申請,寫需求變更計劃,審核通過,才有權限進行需求變更.然後配置管理員一定要做好需求的跟蹤,凡是跟變更需求有牽連的開發人員和測試人員都要同步的通知到和及時讓他們做好相應部分的各類文檔的修改。

需求變更管理

需求的變更管理我個人認為是最容易出問題，一般項目做不完也主要是由此產生。需求變更的出現主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什麽。用戶常常以為自己清楚，但實際上他們提出的需求只是依據當前的工作所需，而采用的新設備、新技術通常會改變他們的工作方式;或者要開發的系統對用戶來說也是個未知數，他們以前沒有過相關的使用經驗。隨著開發工作的不斷進展，系統開始展現功能的雛形，用戶對系統的了解也逐步深入。於是，他們可能會想到各種新的功能和特色，或對以前提出的要求進行改動。

他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現。如何有效的管理需求變更，下面是我公司目前的做法。公司利用需求管理工具，需求人員每次與客戶溝通後形成需求調查表，統一錄入需求管理工具,並進行綜合及整理後形成需求規格說明書， 之後由研發部、產品部、及銷售代表(如果有客戶參加就更好了)進行需求評審，建立需求基線。制訂簡單、有效的變更控制流程，並形成文檔。在建立了需求基線後提出的所有變更都必須遵循變更控制流程進行控制，同時每一筆重要的需求變更都需要客戶簽字確認才認為需求變更生效。需求變更後，受影響的軟件計劃、產品、活動都要進行相應的變更，以保持和更新的需求一致。因為需求管理工具提供了需求變更記錄，可以幫助我們形成良好的文檔，便於進行管理。

和客戶交談

你要面對“正確”的客戶區分不同層次的客戶需求,要面對不同層級，不同部門的客戶，把客戶分類,區分需求的優先級別.如果你做的項目業務是你熟悉的，那還好，如果是你不熟悉的，一定要花點精力學習一下這個行業業務的背景資料,這也是我上面談到的先請行業專家的原因。畢竟，客戶是不可能給你系統地介紹業務的。只有你通曉了行業業務，才能和用戶交流，並正確而有效地引導客戶，做好需求分析，你不能指望客戶能明確地說出需求。當然，這也是系統分析人員的職責所在。在開始做需求的時候，你最後花一點時間搞清楚你接觸的客戶是不是做實際業務的客戶，如果你面對的客戶不是將來的系統的實際使用者。你就有點麻煩了。

可能他是客戶公司派過來的IT部的人，他會提一大堆東西，而這些東西可能根本不是實際業務需要的功能，而他一般還會興致勃勃地給你一些技術實現的建議。這個時候你就要小心了，如果你聽了他的話，你可能在最後才發現，你花了大量精力解決的問題，其實並不是客戶真正需要的。而你真正需要關註的，卻做得遠遠不夠。

因此，做好軟件項目需求管理，做好需求分析很重要。懂得如何辨別客戶真實需求也很重要。有時候一個軟件項目成敗，就在於需求分析的好壞了。細想一下，做需求分析，還真是既要專業技術強，又要溝通能力和理解能力。做需求分析，沒有經驗的小菜鳥，多少要吃些苦頭的。

本文轉載自拓源優課：www.toyoke.com

軟件項目的需求管理經驗分享