需求建議書rfp

需求建議書是指從客户角度出發，全面、詳細地向服務商陳述、表達為了滿足其已識別需求所應做的準備工作。也就是説，需求建議書是客户向服務商發出的用來説明如何滿足其已識別需求的建議書，是客户與服務商建立正式聯繫的第一份書面文件，又稱招標書。需求建議書一般由客户起草，主要描述客户的需求、條件及對項目任務的具體要求。一份完整的需求建議書主要包括滿足其需求的項目的工作自述、對項目的要求、期望的項目目標、客户供應條款、付款方式、契約形式、項目時間、項目申請書的要求等。

好的需求建議書能讓服務商準確把握客户所期待的產品或服務。當然，並非在所有情況下都需要準備一份正式的需求建議書，當某一企業的需求由內部開發項目予以滿足時，這一過程似乎變得簡單多了，此時更多需要的是口頭上的交流和信息傳遞，而不是把寶貴的時間耽擱在僅僅起到信息傳遞作用的需求建議書上。例如，某一軟件開發公司感到公司原來的財務分析系統已經遠遠不能適應日益增加的業務需要時，便可直接要求軟件開發小組進行開發，這時只需口頭把相關的要求傳達給軟件開發小組即可。

[編輯]需求建議書的主要內容[2]

需求建議書一般包含以下主要內容：

客户必須蒐集大量相關資料準備需求建議書，因為IT項目實施者需要按照RFP來準備他們的項目技術方案，並以此參與競標。RFP中包括項目的目標，也就是用户的期望，也包括客户要求項目的進度計劃;對實施商申請書的表格和內容的規定;客户希望潛在的實施商提交投標申請書的最後期限;評價申請書的標準等。一份好的RFP應該包括以下一些內容。

1．工作表述

工作表述就是説明項目的工作範圍，概括客户要求開發商或項目團隊執行的任務或工作單元，説明項目所涉及的各種事情，哪些必須由開發商或項目團隊去完成，哪些由客户自己去做。例如，一個辦公自動化軟件系統的具體目標。又如建設一個網站，所需設備的採購任務，是由客户自己完成，還是由開發商去完成;企業網站上的頁面文字，是客户自己撰寫，還是由開發商撰寫等。

2．任務要求

需求建議書必須要具體規定開發商需要完成任務的規格和特徵，如要求涉及大孝數量、顏色、重量、速度和其他開發商提出的解決方案中，所必須滿足的物理參數和操作參數。例如，建立一個企業網站，可能要求在1 000人同時訪問的情況下不會產生堵塞的感覺，網站的瀏覽頁面不低於多少;建立一個自動結賬和收款系統，可能要求每天能辦理12 000次交易的功能和其他特定的功能，如在開出了發票的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項目，但客户在需求建議書中，往往不願意透露這個信息。其實，客户暗示大約的數字，告訴開發商他打算花多少錢來辦這件事是有好處的，這樣可以使開發商能夠提交與資金水平相適應的申請書，提高在項目準備階段的工作效率。

[編輯]需求建議書的必要性[2]

需求建議書(RFP)是項目客户與開發商建立正式聯繫的第一份書面文件，也叫招標書。一般由項目的客户自己起草，主要描述客户的需求、條件以及對項目任務的具體要求，向可能的開發商發送。

需求建議書是客户為確保供應商理解項目的需求，並在此基礎上提供項目建議書而編制的需求規範。雖然它不能確保客户據此就能獲得理想的解決方案，但卻可以幫助客户發現那些儘可能接近自身需求的系統準備。其

目的是從客户自身的角度出發，通過全面、詳細地陳述，使開發商或項目團隊理解客户所希望的是什麼，以可行的價格滿足客户的已識別的需求。

對於一些預算較少的客户，開發商往往不願意花精力準備正式的方案建議書，這種情況下，客户的需求建議書就變得很重要。事實上，項目無論大小，都需要編寫需求建議書。

第一，需求建議書需要描述用户的目標與需求。編制需求建議書的過程也是客户進一步明確自己的目標與需求的過程，並以此建立起客户與供應商進行深人溝通的橋樑。即使因為各種原因使得供應商看不到或不願響應需求建議書，這種努力也是值得付出的。

第二，需求建議書可節省選型的時間，並使得對各供應商之間的比較變得更容易。客户提供給所有競標供應商的信息都是一樣的，避免了跟各開發商的重複溝通，同時，有需求建議書作為基準，客户可以約束各開發商以一致的格式提交方案建議書，以提高各供應商之間的可比性。

第三，需求建議書可以避免一些潛在的疏漏。在準備需求建議書時，客户往往會因為太過關注具體細節而忽略了一些重要的因素。收到需求建議書後，有的供應商可能會主動對這樣的疏漏提出質疑以提醒客户。還有些開發商為了使自己的方案建議書更具有吸引力，甚至會提出一些需求建議書沒有涉及的好想法來拓展客户的思路。

[編輯]編寫需求建議書的一般原則[2]

需求建議書應該由用户編寫，但各種客觀因素的限制，實際上很難做[到。所以，很多時候都是由用户與項目小組共同編寫。編寫項目需求説明的J過程也是項目小組帶領客户進入項目需求啟發的過程。編寫優秀的項目需求[建議書沒有公式化的方法，需要大量的實踐經驗。以下是編寫需求建議書需要把握的幾個原則：

(1)需求應該是正確的。每個需求必須精確描述要交付的功能。確定需求內容是否正確，需要用户的代表來參與確認，由他們檢查、決定用户需[求的正確性。沒有用户的需求檢查就會導致很多項目實施中的問題出現。例如用户會説：“這不是我們要的東西”;“你沒明白我們的意思”，等等。

(2)需求應該是可行的。項目的需求應該在有限的資源(已知的能力、有限的系統及其環境)下是可實現的。為了避免需求的不可行性，在需求分析階段應該有核心技術人員參與，檢查在技術上什麼能做、什麼不能做，哪些需要額外的付出等。

(3)需求內容應該是必要的。需求建議書中的每個需求都應該有相應[的出處，即説明什麼是客户確實需要的，什麼要順應於外部的需求、接口或標準。如果不能標識出處，則可能這個需求不是真正需要的。

(4)需求內容應該有優先權。優先權是由客户或其代理及項目小組共同商討後建立的。如果所有的需求都被視為同等重要，那麼在開發中遇到預t算削減、計劃超時或組員的離開而導致新的需求時，項目經理將無所適從。一般優先權有以下三個級別。

1)高優先權，表明需求必須體現在本階段項目的成果中或這個產品的版本中。

2)中優先權，表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中。

3)低優先權，表明有它很好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。

(5)需求內容應該是明確的。需求不該有歧義，要避免使用一些對於擬訂項目需求建議書的人很清楚，但對於其他人模糊不清的詞彙。如：用户友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔、直觀地採用用户熟知的語言，而不要採用計算機術語。