引言
無論是ERP項目還是小型的軟件開發領域，包含需求、設計、編碼和測試四個階段，其中需求是整個軟件開發的最關鍵的一個輸入，據統計，不成功的項目中有30~40%的問題是由需求造成的。大量的研究表明需求階段發現和糾正錯誤的代價是軟件開發各階段中成本最低的，越是後期的變更，成本越高，良好的需求開發對提高軟件成功率和避免失敗具有重要的意義。
如何正確地獲取用戶的需求，圍繞其進行管理，以便最終交付給用戶符合其期望的產品是需求工程的任務。需求工程的研究產生了如CMM（能力成熟度模型）、UML（統一建模語言）、RUP（Rational統一建模過程）、CASE（用例）等管理方法和開發工具，軟件思想家溫伯格（Gerald M.Weinberg ）先生指出“CMM只是一種標準，UML也只是一種記錄需求的工具，而不是捕獲需求的方法，需求的管理主要還是靠經驗”。準確而有效獲取用戶需求、精確表述用戶需求並得到用戶認可，是軟件項目開發成功的最重要的里程碑之一。本文針對需求開發中存在的風險進行探討總結，整理出其預防措施，期望以後對軟件項目的需求分析進行風險預防、控制等提供參考。
一、什麼是需求?
項目經理博客
1997年IEEE軟件工程標準詞彙表對軟件需求的定義爲：用戶解決問題或達到目標所需的條件或能力。系統或系統部件要滿足合同、標準、規範或其它正式規定文檔所需具有的條件或能力。用通俗地說，“需求”就是用戶的需要，包括用戶要解決的問題、達到的目標，以及實現這些目標所需要的條件，表現形式一般爲文檔形式。需求分爲需求開發和需求管理，而需求開發又分爲需求獲取、需求分析、編寫規格說明書和需求驗證。如圖1所示，整個活動構成軟件開發生命週期的需求分析階段。如何幫助用戶提出準確的需求、理解和分析用戶環境是需求獲取的過程。爲問題涉及的信息、功能及行爲建立模型並將用戶需求精確化、完全化是需求分析的過程，最終形成需求規格說明書是編寫規格說明書的過程，將需求說明書交付用戶並得到用戶認可是需求驗證的過程。需求獲取、分析、編寫需求規格說明和需求驗證並不遵循線性的順序，這些活動是相互隔開、增量和反覆的進行。
二、需求開發四步驟
項目管理者聯盟
1、需求獲取轉自項目管理者聯盟
針對大項目如企業ERP的需求獲取，採取的辦法(1)、成立需求分析小組，劃分任務，細化側重點，爲獲取用戶需求做好準備工作。(2)、訪談用戶獲取問題，瞭解用戶的功能需求同時，還需要注意用戶的非功能需求(如：用戶界面、響應時間、自動恢復時間等)。訪談用戶前，首先要了解和劃分用戶的類型，針對用戶的情況可以劃分組別，詳細描述出他們的個性特點及任務情況。其次，就要選擇好每類的代表，對其進行訪談和調研，每類用戶代表都能對其負責的方面有代表性並能做出決策，2005年我單位準備上ERP系統，當時北京某軟件單位到我司作調研的時候，下屬單位都是選擇行政“一把手”參與調研。每次的交流都需要有記錄，對於交流的結果還可以分類，以便於後續的分析活動開展。項目經理圈子
2、需求分析training.mypm.net
調研人員對於收集的需求信息要做進一步的分析和整理，判斷哪些是軟件必須提供的，哪些是軟件目前無法滿足的，哪些用戶需求會衍生出很多的隱性需求，還有哪些是用戶沒有想到的需求。這是一個需求分析人員消化用戶資料的過程。
這個過程主要通過建立模型來描述用戶的需求，實際上是抽象圖形化的過程。一般用圖形表示系統的整體結構、用原型等方式向用戶提供可視化的界面、用系統可性行分析來說明軟件的效果和效率、用UML描述系統的需求及內部關係。
3、編寫需求規格說明書
需求規格說明書也稱爲功能規格說明、需求協議或系統規格說明，它精確地闡述一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件。它是開發設計的藍本，也是系統測試和用戶文檔的依據。項目管理論壇
4、需求驗證www.mypm.net
需求驗證是爲了確保需求說明書準確無誤、完整地表達必要的質量的一種方式。客戶、分析人員、設計人員、測試人員等利益相關人員經過多次的評審後的需求說明書就可作爲需求管理的基線。用戶和開發方對軟件項目內容的描述是以需求規格說明書作爲基礎，它是軟件驗收時合同雙方確認的重要依據。
三、需求開發中存在的困難以及對策bbs.mypm.net
在軟件項目開發過程中，風險無所不在，如何有效規避風險，尤其是需求開發過程中的風險（需求風險）。本文按着需求開發的過程提供幾條建議：
項目管理論壇
1、需求獲取
問題一：用戶對於自己的需求不太清楚或工作繁忙無暇理清需求。在很多的實際開發過程中，第一種情況就是用戶對自己真正的需求並不十分明確，他們認爲計算機是萬能的，只要簡單地說一說自己想要得到什麼樣的結果就行了。對於自己的業務規則、工作流程都不願說談。筆者在2006年曾準備開發一個醫院的庫房管理系統，當本人開始做需求調查的時候，就是存在用戶無法準確有效地表述功能需求的問題。針對這種情況，其對策是：需求分析人員一定要深入用戶工作場地，仔細查看用戶的資料和報表，與不同層面的用戶交流、溝通，且要多瞭解用戶實際工作的場景，有條件的話，可以做一個“實習生”親身體驗用戶的日常工作。站在用戶的角度幫助用戶分析需求。關注用戶工作的每個細節，搞清用戶的真實需求，以最大可能減少後期地需求變更。第二種情況就是業務人員配合力度不夠。有的用戶日常工作繁忙，他們不願決付出更多的時間和精力向分析人員講解業務。面對這種用戶，其對策是：需求分析人員改變溝通技巧，講清楚軟件需求的重要性，見縫插針，抓住關鍵點，向其諮詢，以用例和模型的方式向其演示，達到用戶和分析人員互相瞭解和理解。 項目管理者聯盟文章
轉自項目管理者聯盟
問題二：用戶與需求分析人員缺乏有效溝通，雙方誤解需求。人們在交流的時候，經常會發生“答非所問，問非所求”的事情，軟件用戶與開發人員缺乏有效溝通方法，交流上存在障礙，用戶與開發人員存在知識背景差異，都從自己的角度，使用自己的專業術語或語言表達方式來描述和理解問題，使得雙方並不能夠很好地就軟件需求達成共識。2005年北京某公司到我公司做調查，對方技術人員常掛在嘴邊的就是“BOM”，但作爲用戶還沒有完全接受這個詞，他們用得最多的是流水號、生產線、配套件等。一般說來，用戶不太容易從計算機的角度去理解自己的需求問題。從而使需求描述的不一致，不規範，多義性。筆者今年夏季爲某事業部編寫庫房管理軟件的時候，筆者採用快速原型化開發了此軟件，雙方出現了誤解的情況，比如：針對“數量”，我理解爲整數，但實際上庫房數據中“數量”就是以小數爲單位，她認爲我應該理解了這個問題，實際上她前面輸入的數據的確都是整數，使用到一定的程度，結果顯示大相徑庭。對策：分析人員需要花更多的時間去了解系統用戶的特點，多學習用戶行業的專業術語，用用戶看得懂的語言來表達需求的內容。其次，分析人員除了需要過硬的專業知識，還要具備較強的溝通交流能力。謙虛、誠懇地向用戶學習，才能探索出用戶的真正需求。如果能在用戶方找到即對生產過程瞭解，又懂計算機知識的行家來爲開發人員與用戶牽線架橋則是最好不過的事情。項目管理者聯盟
問題三：用戶的需求不斷變更 項目管理者聯盟文章
由於需求識別不全、業務發生變化、需求本身錯誤、需求不清楚等原因，隨着客戶對項目的越來越深刻的理解，對他過去提出的需求要求一變再變，面對這種情況：需求人員要意識，做軟件就像裝修房子，永遠可以找到需要增加的東西、需要改變的地方，“需求的變化是永恆，需求不可能是完備的”。因此我們在需求獲取的時候，一方面應該跟用戶講清楚需求開發的重要性，讓用戶明白減少後期的需求變更的重要性，且隨意的需求變更帶來的風險（成本增加、進度延後等）必將由用戶和開發者共同承擔。另一方面也需讓用戶明白：開發者和用戶更多的是戰略合作伙伴關係，其共同的目標是：開發出適合用戶需要的軟件。
training.mypm.net
2、需求分析
項目管理培訓
問題一：主次不分 需求分析人員常站在自身的角度去理解用戶的需求造成主次不分。而實際上不同的系統對系統的功能與非功能性需求要求很不一樣。比如，金融系統一般對系統的安全質量要求比較高。企業ERP系統一般對信息傳遞速度要求高一些。針對這種情況，首先需求分析人員可以借用當前的需求分析工具和圖形的方式，明確用戶的功能需求和非功能需求，特別注意產品性能、使用性、完整性、可靠性等非功能性需求。其次就要充分考慮到哪些需求是相對固定的需求，哪些可能會產生變動的需求，哪些需求會牽一髮而動全身，區分這些需求，設定用戶的每項需求、特性或使用實例的優生級並安排在特定的產品版本或實現步驟中，以應付客戶後期的需求變更。
項目管理者聯盟
問題二：需求分析時間不夠 這個問題非常普通，用戶認爲“我出錢你出力，當然以我的要求爲準”，但實際上不合理的要求會導致項目失敗，拿一個簡單的例子來說明：假如1個人需要幹100天時間才能把某件事情完成，爲了趕進度，現在增加人數，選100個人幹一天把這件事情做完。絕大多數人都會認爲是不可能實現的。軟件項目也是如此，它有一個最短週期，也就是說無論你如何增加資源追趕進度，都無法再縮短時間，在關鍵路徑上增加人力、物力資源，或許還會添亂。一般需求開發工作應占全部工作量的15%。所以用戶方與開發方必須達成共識留足夠的時候給需求分析。
項目管理者聯盟文章
3、需求規格說明編寫training.mypm.net
bbs.mypm.net
問題一：文檔混亂，文字表述過多 需求文檔是需求人員對前期工作的總結。需求人員寫出的文檔混亂，圖形連線錯綜複雜。首先是需要理清思路：需求的描述可以從2個方面來進行描述，一方面是對用戶現行系統的描述，一方面是對系統未來的設想。構成企業信息系統主要包括基本要素：企業的組織結構、流程、數據、商務規則與功能，其中從用戶的角度主要關注流程，是以流程爲中心，通過流程將其他幾個要素貫穿起來，需求分析人員也應該從這個角度來和用戶溝通；從開發者的角度主要關注企業的數據、商務規則與功能，以便於系統的實現；從實施者的角度主要關注企業的組織結構與功能，以便於系統的發佈與實施。企業組織結構是用戶企業業務流程與信息的載體，對分析人員理解企業的業務和系統範圍有幫助；業務流程圖把企業的業務流程與部門職責結合起來了，且形象直觀；企業的數據（各種單據、帳本、報表等）可採用描述分類、格式化；企業商務規則與功能可以採用分類方法進行。其次儘量採用SRS(需求規格說明書)，較好的模板爲IEEE標準830-1998描述的SRS模板，下面是一個常見的需求說明書的模板：
1. 前言(目的、範圍、定義、縮寫詞、略語)
2. 項目概述 （產品描述、產品功能、用戶特點、一般約束、假設和依據）轉自項目管理者聯盟
3. 功能性需求 （功能需求1、功能需求2….）
4. 外部接口 （用戶接口、硬件接口、軟件接口、通信接口）
5. 性能需求
6. 設計約束 （其他標準的約束、硬件的限制）
7. 屬性項目經理圈子
8. 其他需求（數據庫….）
9. 附錄
10. 索引 training.mypm.net
4、需求論證
問題六：需求文檔口頭達到共識，缺乏文字依據。有時候因爲時間緊湊或其他原因，即使達到了一致的共識，多數的用戶單位都不願意在需求文檔上簽字。這種情況有可能導致後期需求不斷變更，需求變更影響軟件開發的進度、成本，甚至有可能使得軟件開發中止。對策：需求分析人員與用戶建立良好的溝通渠道，強調需求文檔書面認可的重要性，期望得到用戶的理解。
blog.mypm.net
總結：
綜上所述，多數軟件項目都是在時間緊、人員少、項目預算有限的條件下完成的。在這些“先天不足”的條件下，如何做到項目進度不延遲、工作量不超期、費用不超支？首先就是關注需求分析。 “良好的開端就成功了一半”，需求分析做好了，對下一步的設計階段工作真正起到指導性作用，規避需求開發過程存在的問題，成功的軟件項目指日可待。