項目需求識別

出自 MBA智库百科(https://wiki.mbalib.com/)

　　項目需求識別是項目生命周期的最初階段。它開始於對需求、問題或機會的識別，結束於項目需求建議書(RequestforProposal，RFP)的發佈。如圖1所示：

　　圖 項目需求識別過程

　　項目需求是整個項目的基礎。因此，正確識別並認識項目需求是項目成功的必要條件之一。

　　項目需求如果要得到批准通常必須具有以下一個或多個原因：

　　1.市場需求(例如，某汽車公司針對市場上汽油短缺的情況，批准一個項目，研製更省油的汽車)；

　　2.商業需要(例如，一個培訓公司批准開發一個新的課程來增加收人)；

　　3.顧客要求(例如，某電力公司批准一個項目，建立新的變電站向一個新的工業開發區提供電力資源)；

　　4.技術領先需求(例如，一家電子公司在電腦記憶體不斷增加的情況下，批准開發一個新的視頻游戲機)；

　　5.法律要求(例如，一家塗料生產商授權一個項目來建立該公司處理有毒物質的指導方針)；

　　6.社會需求(例如，一個發展中國家的某民間組織批准一個項目，向霍亂高發的低收入社區提供飲用水系統、公共廁所和衛生教育)。

　　除了利益相關方明確提出的需求外，還經常會有很多模糊的甚至是隱含的需求。如果不能識別出所有的需求並對這些需求進行甄別、管理，可能會對整個項目的後期工作產生嚴重的影響。

　　●按照是否能夠確定是本項目需求來劃分

　　1.待定需求

　　待定需求一般是利益相關方不能確定，或者是雖然能夠明確描述但是無法確定是否包含在項目範圍中的需求。有時待定需求會隨著時間的推移而成為確定需求，但是在還沒有確定階段，待定需求一般不包含在最終的需求建議書中，如果必須包含在需求建議書中，需要作如下處理：

　　(1)對產生“待定”一詞的條件進行描述，使得問題能被解決；

　　(2)描述必須乾什麼事，以刪除這個“待定”。

　　包含有“待定”一詞的任何需求建議書的項目文件應該註意以下兩點：

　　(1)標識與此特定文件有關的版本號或敘述其專門的發佈號；

　　(2)拒絕對任何仍標識有“待定”一詞的需求建議書章節的許諾。

　　2.確定需求

　　通過與利益相關方的接觸，交流、查看利益相關方提供的文檔等溝通方式，確定利益相關方關於項目的明確的且應該包含在項目範圍內的需求。這些需求需要採用各種方法、明確地用文檔的方式描述出來，在經過用戶確認後即成為制定項目範圍、項目目標以及項目計劃的基礎。確定的需求一般是主要利益相關方提出、必須在項目中實現的需求，識別及確定需求的方法有多種，可以根據不同的問題採用不同的方法，最終得到清晰明確的需求描述。

　　●按照需求是否具有可執行和可描述特點來劃分

　　1.明確需求

　　明確需求是能夠清晰描述並能夠為項目利益相關方所共同理解的需求。明確需求只是可以明確地描述和提出的需求，不一定就是所有項目利益相關方達成共識要在項目中實現的確定需求。明確需求可能包括確定需求，也可能包括待定需求，

　　2.模糊需求(用戶的軟性需求)

　　有些時候，利益相關方無法將需求明確描述出來，需要需求調研人員在充分瞭解利益相關方的環境、相關工作、相關愛好等方面的基礎上，理解利益相關方可能的需求，再將需求明確地描述出來。模糊需求是一種含而不露的需求，是一種我們知道確有其事卻因其變化不定而無法定義或定位的需求；模糊需求極難定義，也很難研究。在需求識別過程中，識別出利益相關方的模糊需求，並明確表述是一件非常困難的事情，也是優秀的專業人員和平庸的從業者的一個重要區別。

　　例如，如果業主需要設計一座安全且能住人的住宅，許多建築師可以勝任這份工作。對於住宅建設，建築規範有明確的規定，安全等級標準也有清楚的界定。但如果業主增加一項要求，如“非常舒適”，也許只有少數建築師才能勝任此工作。因為“非常舒適”是軟性標準，人跟人不同，無法統一界定。

　　3.隱含需求

　　有些時候，分析由確定需求衍生出的隱含需求，並識別利益相關方沒有明確提出來的隱含需求(有可能是實現利益相關方需求的前提條件)這一點往往容易被忽略掉，因而經常會因為對隱含需求考慮得不夠充分而引起需求變更。隱含需求的存在經常是因為問題提出者認為這些都是調研者理所當然應該知道的，不需要特別說明。這種情況在調研用戶業務情況的時候經常發生，一般用戶在闡述業務情況的時候會認為調研者對業務比較瞭解，不需要交流一些工作慣例或規定，這就經常導致調研者對需求的理解趨於片面化，無法掌握利益相關方的隱含需求，也就無法成功地完成需求識別的任務。

　　●按項目需求的時效性區分

　　1.現在需求

　　現在需求是在項目進行時就已經具備實現條件的需求。這些需求可能是確定的，也可能是待定的，但最終項目需要實現的確定需求一定是現在需求。

　　2.未來需求

　　與待定需求不同，未來需求是利益相關方能夠明確描述，但是由於在項目需求識別時還不需要，或者是在需求識別時還不具備滿足利益相關方期望的條件等原因，而不必包含在項目需求範圍中的利益相關方需求。未來需求雖然不用馬上實現，但是在項目識別時需要對此類需求進行記錄和管理，以此作為項目在制定解決方案時的參照。優秀的項目解決方案一般都會考慮到項目成果未來的發展，為項目成果未來的發展提供開放的、可兼容和可擴展的介面，以便當未來需求變為當前需求時，當前項目成果還可以繼續利用。

　　總之，在需求識別的過程中，不僅僅要描述確定需求，還要識別出利益相關方的模糊需求和隱含需求，將模糊需求和隱含需求明確化，使之成為確定需求。識別待定需求和未來需求對項目的發展也是極其重要的。對識別出來的需求分類，併進行有效管理，是對成功的項目需求識別的基本要求。

　　項目利益相關方是積极參与項目或者其利益在項目執行過程中或完成後受到積極或消極影響的個人或組織，一般包括項目經理、項目團隊成員、顧客、執行組織、項目發起人等，除了這些，還有很多不同名稱和種類的項目利益相關方：內部的和外部的利益相關方、業主和資金提供者、供應商和承包商、項目團隊成員及其家庭成員、政府代理和媒體、市民個人、臨時性的或永久性的游說組織以及整個社會。

　　下麵我們先以房地產開發項目為例，來看看如何識別並確認項目利益相關方的需求。

　　對於不同的項目利益相關方，需要識別的需求類型也不同；對於房地產開發項目的項目利益相關方來說，不同的利益相關方的需求不同。

　　承包商的需求可能包括：

　　合理的價格；

　　按合同及時驗收付款；

　　有效的溝通；

　　受到尊重；

　　範圍及驗收標準明確。

　　業主的需求可能包括：

　　房屋結構設計合理，實用性好(可能包括房屋朝向、層高、使用面積等)；

　　生活配套設施完備(例如小區內或小區附近需要有車庫、商場、學校等)；

　　小區環境建設(例如需要綠化面積達到40％等)；

　　工程質量符合相關部門要求；

　　工程按時交付；

　　工程造價儘可能降低。

　　對於房地產項目來說，主要有下述方面的需求識別：

　　項目發起人的項目需求識別；

　　項目經理實施項目的組織的需求識別；

　　合作的承包商的項目需求識別；

　　業主的項目需求識別；

　　項目所在地政府的項目需求識別；

　　其他諸如項目所在地層民、商業企業等的項目需求識別。

　　以上幾個方面的需求識別完成後，經過相關的確認步驟，將形成項目目標。

　　雖然我們拿房地產項目來試圖解釋項目需求識別，但事實上對於大多數項目來說，項目需求識別的第一個步驟是識別項目利益相關方。確定哪些個人或組織是項目的主要利益相關方是比較困難的過程；同時利益相關方的角色和職責可能會有交叉，因此識別項目需求的過程就更加複雜。

　　項目需求識別的過程主要是確定主要項目利益相關方的要求和期望。一般來說，項目需求識別對象應該是所有項目利益相關方，但是因為不同項目利益相關方在項目中的作用不同，所以一般會主要識別主要項目利益相關方(如客戶)的要求和期望。

　　我們下麵以IT項目為例，詳細描述項目需求的識別方法。

　　●組成表法

　　組成表是最基本和常用的需求識別方法，也常用來描述項目的某一方面的屬性，一般是根據分類對目標進行羅列。

　　例如新產品開發者需要設法把某一類產品能夠滿足的需求全部列出來，但在羅列這些需求時他們常常會發現許多以前所未知的需求。組成表是一張包含了產品滿足需求的所有方式的表格，它能使我們看到現有產品的各種變動是如何更有效地滿足這些需求的。組成表中所獲得的用戶需求往往是千差萬別的，為此，進行新產品構思時需要對這些需求進行相應的核查與分析。這一工作可以採用“需求分析核查表”的形式進行（見表1）。

　　如果有兩個以上低X分值和兩個以上低Y分值，那麼面臨的需求很可能是待定需求；

　　如果有兩個以上高X分值和兩個以上高Y分值，那麼面臨的需求很可能是模糊需求；

　　如果有兩個以上低X分值和兩個以上高Y分值，那麼面臨的需求很可能是確定需求；

　　如果有兩個以上高X分值和兩個以上低Y分值，那麼面臨的需求很可能是未來需求。

　　●問題分析法PAM(Problem Analysis Method)

　　PAM是通過分析研究用戶和專家提出的意見而進行構思的方法，它一方面要收集用戶意見；另一方面要將收集到的意見中的問題抽出來，進行分類統計，以確定問題的嚴重程度、出場頻繁程度，針對問題進行分析，尋找適當的解決方法。問題包含不滿意，也就是隱含著改進，孕育著新構思，可以激發創新思維。

　　例如，在電腦軟體開發方法中的PAM的基本思想是：考慮到輸入、輸出數據結構，指導系統的分解，在系統分析指導下逐步綜合。這一方法的具體步驟是：從輸入、輸出數據結構導出基本處理框，分析這些處理框之間的先後關係，按先後關係逐步綜合處理框，直到畫出整個系統的PAD圖。從上述步驟中可以看出，這一方法本質上是綜合的自底向上的方法，但在逐步綜合之前已進行了有目的的分解，這個目的就是充分考慮系統的輸入、輸出數據結構。這一方法在日本較為流行，軟體開發的成功率也很高。

　　●差異分析法

　　差異分析法是通過分析現有產品與項目需求目標在哪些地方存在相同和差異來更好地獲知需求的方法。使用差異分析法的前提條件一般是已經有現有產品或參照系統，並且利益相關方對現有產品或參照系統具有足夠的瞭解，可以將現有產品或參照系統的屬性作為比較條件。通過差異分析，項目利益相關方將對需求有更好的理解，同時可以對項目結果有更清晰的認識，從而可以查找出需求中的不足，提出更符合項目要求的新的需求。

　　●原型法(Prototyping)

　　原型法的使用過程是建立模型的過程，該模型能夠示範目標產品、服務或系統的特征。使用原型法可以幫助確定需求，證明系統在技術上是可行的，推廣目標系統的思想。使用原型法的步驟一般是：

　　確定基本需求；

　　根據基本需求設計、開發模型；

　　項目利益相關方使用、評價模型；

　　使用原型作為最終系統的技術藍圖，不斷修改、完善模型。

　　原型法的主要優點在於：它是一種支持用戶的方法，使得用戶在系統生存周期的設計階段起到積極的作用；它能減少系統開發的風險，特別是在大型項目的開發中，由於對項目需求的分析難以一次完成，應用原型法效果更為明顯。原型法的概念既適用於系統的重新開發，也適用於對系統的修改；原型法不僅可以用於對開發項目中的電腦方面進行設計，也可用於製作系統的工作模型。近年來，原型法的思想被應用於很多產品的開發活動中。

　　●其他方法

　　在特定的項目領域還可以採用其他特定的方法，例如在信息系統開發項目中採用面向對象方法、系統用例法、生命周期法等。

　　需求識別分析過程根據採用的需求識別分析方法不同而不同，我們還是以IT項目為例，描述需求的分析過程：

　　●使用繪製關聯圖等方法描述項目需求

　　在需求識別的過程中，對於初步整理的需求需要不斷採用各種方法進行歸納、整理，關聯圖就是整理項目需求的一個方法。所謂關聯圖，是把若於個存在的問題及其因素間的因果關係用箭頭連接起來的一種圖示工具，是一種關聯分析說明圖。通過關聯圖可以找出因素之間的因果關係，便於統觀全局，分析並擬定解決問題的措施和計劃。

　　項目人員針對不同方面的需求可以採用不同的方法進行描述，以清晰、明確地描述所有需求。需求描述可以採用文檔、原型等多種方式。

　　●分析需求的可行性

　　在允許的成本、性能、進度要求下，分析每項需求實現的可行性，明確與每項需求實現相聯繫的風險，與其他需求的衝突，對項目環境、項目團隊的要求以及技術要求等。

　　●確定需求優先順序

　　以利益相關方要求、每項需求對項目整體影響等為基礎，應用分析方法來確定使用實例、產品特性或單項需求實現的優先順序別。以優先順序為基礎確定產品版本將包括哪些特性或哪類需求，並制定出對不同優先順序別的需求的實現方案。當允許需求變更時，應在特定的版本中加人每一項變更，併在那個版本計劃中作出需要的變更。

　　●建立需求模型

　　如果需要，應為需求建立模型。建立需求的圖形分析模型通常是對需求規格說明極好的補充。它們能提供不同的信息與關係以有助於找到不正確的、不一致的、遺漏的和冗餘的需求。在軟體項目中，這樣的模型包括數據流圖、實體關係圖、狀態變換圖、對象類及交互作用圖等。

　　●編寫數據字典

　　數據字典是軟體項目中常用的名詞，也是軟體項目中必須完成的一個文檔。在其他類型的項目中，編寫完善的數據字典也是項目需求的一個良好補充。數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求識別階段，數據字典至少應定義客戶數據項以確保客戶與開發小組使用一致的定義和術語。分析和設計工具通常包括數據字典組件。

　　●應用質量功能調配

　　質量功能調配是一種高級系統技術，它將產品特性、屬性與對客戶的重要性聯繫起來。該技術提供了一種分析方法以明確哪些是客戶最為關註的特性。它將需求分為三類：期望需求，即客戶或許並未提及，但如若缺少會讓他們感到不滿意的需求；普通需求；興奮需求，即實現了會給客戶帶來驚喜，但若沒有實現也不會受到責備的需求。

　　●需求變更

　　在需求識別過程中，甚至是在需求識別階段結束後，經常會遇到利益相關方要求對需求進行變更的情況。從這一角度來看，可以說需求識別貫穿了項目建設過程的始終。在項目結束前的任何階段中，都有可能進行需求變更。但是，對需求的變更不能是隨意的，應該進行嚴格的管理。(1)要求對變更的代價進行真實可靠的評估。有時，當人們面臨更好也更昂貴的方案時，會作出不同的選擇，而這時對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，項目利益相關方有權利要求項目人員通過分析給出一個真實可信的評估，包括影響、成本和得失等評估。項目人員不能由於不想實施變更而隨意誇大評估成本。(2)對需求變更進行有效控制：將變更的需求描述文檔作為需求文檔的升級或補充文檔進行管理，同時對需求形成後的項目開發按照項目規定程式進行管理，例如制定各種實施計劃，安排資源，進行有效開發，並對實施結果進行評估等，

　　●需求確認

　　需求確認前，項目利益相關方要對需求進行評審。需求文檔的評審是一項精益求精的技術，可以發現二義性或不確定的需求，那些定義不清的需求不能作為後期項目開展的依據。一般需求評審需要項目利益相關方組成評審小組，通過評審會議，甚至通過對需求的測試而最終被項目利益相關方認可。這種需求評審經常不會一次通過，可能需要經過項目人員對未通過的需求文檔進行修改完善、再提交給評審小組、再次召開評審會議等幾次反覆過程才能最終完成。評審的結果一般是在“需求分析報告”上簽字確認，這通常被認為是利益相關方同意需求分析的標誌行為。然而實際操作中，項目利益相關方往往認為不可能在項目的早期就瞭解所有的需求，而且毫無疑問需求將會出現變更。但是在“需求分析報告”上簽字確認是終止早期需求分析過程的正確方法。需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上雙方都明確的句號，並有助於形成一個持續良好的客戶與開發人員的關係，為項目的成功奠定堅實的基礎。

　　需求識別過程的結果是一份正式的需求建議書。正式的需求建議書一般包括以下內容：

　　工作表述，主要是客戶當前工作描述，涉及確定工作範圍；

　　客戶要求的詳細描述，必要的時候可以採用流程圖等方式詳細說明；

　　客戶期望的結果或產品描述；

　　客戶對結果或產品其他方面的描述，例如安全性等；

　　客戶對需求的確認；

　　客戶要求的合同類型以及合同內容等；

　　客戶要求的付款方式；令客戶要求的進度計劃以及項目實施方式；

　　客戶要求的建議書的具體格式；

　　客戶要求的提交建議書的最後日期；

　　客戶要求的評價建議書的標準。

　　上述內容，根據具體項目的要求以及特點確定，並不是每個項目建議書都必須包括以上內容。一般來說，上述前五項是必須的，其他可以根據客戶的要求和項目特點確定是否包含在需求建議書中。

　　許多組織一開始都採用標準描述的需求規格說明書模板，但是模板不是萬能的，有時要根據項目特點對模板進行適當的改動。案例模板一一列出了軟體需求說明書需要包含的內容。

　　不管項目來自於何種渠道，都需要作好用戶需求的識別，否則，項目風險會大大增加。

　　從客戶所在的角度而言，識別需求是項目啟動過程和整個項目生命期的最初活動，客戶通過識別商業或市場需求、機會，確定投資方向和項目機會。在這個過程中，將為項目的目標確定、可行性分析和項目立項提供直接、有效的依據。例如，一個企業發現其資源利用率很低、財務浪費嚴重、管理比較混亂，準備啟動ERP系統。但是，在這之前，必須要調查清楚當前企業資源利用的實際情況，以及對企業管理和成本造成的影響程度，儘量確定問題的數量和等級，看是否真的需要建立ERP系統。一旦已經確定了相關問題和需求，並證實了上ERP系統將會獲得很大的收益後，才可以開始準備需求建議書。

　　從開發方的角度而言，識別需求是得到客戶需求建議書後，項目團隊從技術實現、項目實施的角度識別客戶的實際存在的問題、基本意圖和真實想法，從而與客戶有效地溝通，準確分析需求和問題，為制定可行、合理、正確的技術及實施解決方案提供依據。

　　如果是軟體企業自行選擇開發的面向特定市場的項目，更需要認真分析其實際需求。

• 項目需求