什麼事需求建議書
需求建議書（Request For Proposal，RFP）需求建議書是指從客戶角度出發，全面、詳細地向服務商陳述、表達為了滿足其已識別需求所應做的準備工作。也就是說，需求建議書是客戶向服務商發出的用來說明如何滿足其已識別需求的建議書，是客戶與服務商建立正式聯繫的第一份書面文件，又稱招標書。需求建議書一般由客戶起草，主要描述客戶的需求、條件及對項目任務的具體要求。一份完整的需求建議書主要包括滿足其需求的項目的工作自述、對項目的要求、期望的項目目標、客戶供應條款、付款方式、契約形式、項目時間、項目申請書的要求等。
好的需求建議書能讓服務商準確把握客戶所期待的產品或服務。當然，並非在所有情況下都需要準備一份正式的需求建議書，當某一企業的需求由內部開發項目予以滿足時，這一過程似乎變得簡單多了，此時更多需要的是口頭上的交流和信息傳遞，而不是把寶貴的時間耽擱在僅僅起到信息傳遞作用的需求建議書上。例如，某一軟體開發公司感到公司原來的財務分析系統已經遠遠不能適應日益增加的業務需要時，便可直接要求軟體開發小組進行開發，這時只需口頭把相關的要求傳達給軟體開發小組即可。
需求建議書的主要內容
需求建議書一般包含以下主要內容：
客戶必須搜集大量相關資料準備需求建議書，因為IT項目實施者需要按照RFP來準備他們的項目技術方案，並以此參與競標。RFP中包括項目的目標，也就是用戶的期望，也包括客戶要求項目的進度計劃；對實施商申請書的表格和內容的規定；客戶希望潛在的實施商提交投標申請書的最後期限；評價申請書的標準等。一份好的RFP應該包括以下一些內容。
1．工作說明
工作表述就是說明項目的工作範圍，概括客戶要求開發商或項目團隊執行的任務或工作單元，說明項目所涉及的各種事情，哪些必須由開發商或項目團隊去完成，哪些由客戶自己去做。例如，一個辦公自動化軟體系統的具體目標。又如建設一個網站，所需設備的採購任務，是由客戶自己完成，還是由開發商去完成；企業網站上的頁面文字，是客戶自己撰寫，還是由開發商撰寫等。
2．需求說明
需求建議書必須要具體規定開發商需要完成任務的規格和特征，如要求涉及大小、數量、顏色、重量、速度和其他開發商提出的解決方案中，所必須滿足的物理參數和操作參數。例如，建立一個企業網站，可能要求在1000人同時訪問的情況下不會產生堵塞的感覺，網站的瀏覽頁面不低於多少；建立一個自動結賬和收款系統，可能要求每天能辦理12000次交易的功能和其他特定的功能，如在開出了發票的30天內沒有收到賬款，就會自動產生催款通知。具體的任務要求，可能會成為將來的驗收標準。
3．產品交付
產品交付就是開發商所提供的實體內容，這在需求建議書中應該說明。例如，對於自動結賬和收款系統來說，客戶可能要求開發商提供硬體(電腦)、軟體(磁碟和一些印刷品)、操作手冊和培訓課程。產品交付也可能包括客戶要求開發商提供定期進度報告或終期報告。
4．客戶供應條款
需求建議書還應該列出客戶的供應條款。例如，客戶需要建立一個網J站，可能需要向開發商提供企業內部的組織結構及各部門之間業務關係的詳]細說明，包括信息流程的類型、信息流量和發生頻率等。
5．表述客戶對需求的確認
需求建議書不是對客戶需求的最後確認。最後的確認應該在對開發商提出的方案進行評估之後。例如印刷宣傳手冊，可能在開印之前要經過客戶審定；區域網的建設，在購買材料和設備之前，客戶必須審定開發商的技術方案。這一點在需求建議書中必須向開發商說明。
6．期望的合同類型
(1)合同可以按固定價格訂立。這樣，開發商實際上就是費用包乾。客戶只給固定的價錢，不管開發商實際工作花費多少。開發商必須保證功能的實現和質量要求，超支的風險由開發商負擔。
(2)合同也可以規定開發商不承擔風險，即在時間、原材料限制的條件下，不論實際成本多少，都會給開發商特定的報酬，也就是所謂包工不包料。在我國現階段的條件下，由於質量檢驗和資信度水平不高，這種合同比]較普遍。在需求建議書中，最好說明客戶是希望採用那種類型的合同。
7．期望的付款方式
付款方式可以分為一次性付款和分階段付款；在開始前付款和結束後付款。一般依項目的性質來定付款方式。如網頁製作，往往在項目末期付款；而架設區域網，一般在方案確認後，付款30％以便開發商採購，工程結束驗收後付滿90％，留10％等到使用一段時間以後確認無問題時付清。具體付款方式需要合同雙方協商，但在需求建議書中，客戶應該先提出自己的期望付款方式。
8．交付時程
交付時程的要求可能很粗，如要求在6個月內完成；也可以詳細一些，如多長時間內完成方案設計和審定，多長時間內完成硬體選購與安裝，多長時間內完成軟體研發、測試與安裝，最後開發商在系統安裝調測後，在多長時間內提交所有的系統文件和操作訓練。
9．申請書的格式和內容提示
為了便於在幾個開發商之間進行比較和評價，申請書應該在形式上採取同一個格式，內容的結構也應該一致。這樣對不同的申請者來說比較公平，也能減輕客戶在評審時的工作量。客戶在需求建議書中可以限定申請書的每一部分採用的文字數量或頁數。
10．提交申請書的最後期限
申請書受理的截止日期是必須要交代清楚的。例如，要求開發商在接到需求建議書後多少個工作口之內(如l周之內、1個月之內等)提交申請書，或大家一律在某月某日之前提交申請書。這樣做的目的是便於同時對眾多的申請者進行比較、評估，也是為了保持公正，不給某些開發商以額外的時間和機會。
11．對申請書的審核標準
要告訴開發商客戶將根據哪些準則來審核他提交的申請書。這樣做的目的，是指導開發商寫好申請書。一般審核標準包括4個方面的內容：
(1)開發商在類似項目中的經驗。如他們近期是否在預算內按期完成了類似的項目，客戶對他們是否滿意?
(2)開發商提出的技術方案是否合適。如採用哪種類型的電腦軟體?資料庫的設計、方法是什麼?用來建立管理信息系統的是哪種語言?採用哪些供應商的設備?等等。
(3)進度計劃。開發商是否能按照所要求的進度完成項目計劃
(4)成本。如開發商的報價是否合理?成本預算中有無漏算的條款?將來在執行時有沒有可能出現超支，或有無可能因過於節約而導致質量不能保證?有的申請人為了爭取合同，在報價上壓低成本，到了執行階段，或偷工減料，或增加成本，結果導致所建系統的缺陷很多，或使最終成本大大超出原始的估算。對此需要引起註意。
12．資金總量
開發商總是希望瞭解客戶有多少資金可以用於發展擬議中的真T項目，但客戶在需求建議書中，往往不願意透露這個信息。其實，客戶暗示大約的數字，告訴開發商他打算花多少錢來辦這件事是有好處的，這樣可以使開發商能夠提交與資金水平相適應的申請書，提高在項目準備階段的工作效率
主要章節與範例：
壹、專案說明
一、簡介
二、專案名稱(例如自動化倉儲建置案)
三、專案目的(期望進出貨物管理達到自動化的效果)
四、專案目標(整合物流、人員控管落實資源共享之平台)
五、專案範圍(包含人事、財務、倉儲等系統)
六、專案時程(各項文件交付時間、硬體安裝時間、軟體開發期程、測試等工作項目之時程)
貳、現況說明(此章節可有可無，如果有舊系統或待整合之系統可簡述)
一、單位組織架構與職掌(簡述單位組織並描述工作職掌與其業務行為)
二、現行軟、硬體架構說明(如果已有運行中之系統，簡述其架構與功能)
三、現行系統使用量、瓶頸、效能之說明(可簡述舊平台之現況與新平台之期望)
參、專案需求說明
一、技術需求(簡述相容性、資訊安全、整合測試、系統備援等)
二、軟體需求(包含通用性、一致性、完整性等需符合通用語言、Y2K、民國百年序等標準)
三、硬體需求(包含資料庫、網頁伺服器硬體規格，建議效能說明、備援機制等也都要考量)
四、維運需求(需明白描述後續保固、維護相關說明)
PS.若軟、硬體由第三方協力商提供，需留意文字上保固與原廠保固之陷阱。
肆、專案管理說明
一、專案人員組成(描述專案經理、系統工程師、開發人員的素質與要求)
二、專案服務要求(描述人員調派、品質保證、工具使用、駐點服務及緊急應變之能力等)
三、專案管理需求(各類文件管理、定期專案會議、不定期緊急會議及時程追蹤等規畫)
四、服務異動管理(需說明雙方責任歸屬、人員及時程重新規劃等)
五、教育訓練執行(需包含技術與非技術面之教育訓練及明訂由原廠或承包商執行)
伍、產品交付與時程
一、交付內容清單(應說明軟硬體含開發工具之交付狀況、各類文件標準書寫規格及數量等)
二、交付時程(明訂交付時間，利如：各期交付或是全案驗收等)
陸、驗收及保固
一、驗收方式與原則(需明訂為分期驗收或全案驗收)
二、驗收清單(完整明列出RFP所要求項目是否有達到並完成交付，尤其是原始碼之權責釐清)
三、付款方式(需明訂為分期付款或全案驗收後付款，並訂定保證金規範)
四、保固及維護(需明訂保固起算日、叫修回覆時間、保固及維護範圍及由原廠或承包商執行)
柒、版權宣告
一、資料保護(本案所有相關文件、資料，未經正式同意不得轉載、複製、使用等需明文規範)
二、智慧財產權規範(本案所有自行開發或使用第三方之軟體，均需遵守智財權之規範)
三、本案標的物(本案所涉及之範圍，需由雙方訂定智財權之擁有者，使用權、修改權之規範)
四、保密切結(本案相關所有人員均需簽署保密切結，並訂定損害賠償之規範)
參考來源：
0 留言