需求建議書

需求建議書RFP（request for proposal）是指從顧客的角度出發，全面詳細地闡述為了滿足識別出的需要而進行的一份提供了詳細信息的檔案。在大多數情況下，不需要準備正式的需求建議書，而是通過口頭的的表達。

書寫要求

書寫RFP要認真負責、嚴肅對待，內容具體，語言精練，要滿足如下要求：

1．在第一行正中寫"建議書"三個字。

2．寫接受建議對方的名稱。

3．正文：

（1）建議的原因或出發點，便於對方考慮。

（2）建議的具體事項。

4．表達建議者的願望。

5．結尾寫表示敬意的話，如"此致敬禮"等語。

6．寫上建議者的名稱和寫建議書的日期。

格式結構

1. 標題
2. 稱謂
3. 正文（開頭部分，主體部分，結尾部分）
4. 署名及時間

指導方針

需求建議書必須說明項目目標（project objective）或目的，包括任何可能對承約商有用的合理信息或背景信息，以便承約商可以準備相應的建議書。對外起草一份正式的需求建議書，有如下的指導方針：
（1）必須提供工作陳述（statement of work,SOW）
（2）必須包含客戶要求（customer requirements）定義好規格和屬性。
（3）應當說明客戶期望承約商或者項目團隊提供什麼樣的交付物。
（4）應當列明任何應由客戶提供的物品。
（5）說明需要客戶審批的內容。
（6）可以表明顧客欲採用的契約類型。
（7）可以表明顧客欲採用的付款方式。
（8）表明項目完成所要求的進度計畫。
（9）指導並說明承約商申請書的格式和內容。
（10）指出客戶希望潛在承約商提交申請書的最後期限。
（11）可以包含評價標準。

必要性

需求建議書(RFP)是項目客戶與開發商建立正式聯繫的第一份書面檔案，也叫招標書。一般由項目的客戶自己起草，主要描述客戶的需求、條件以及對項目任務的具體要求，向可能的開發商傳送。 需求建議書是客戶為確保供應商理解項目的需求，並在此基礎上提供項目建議書而編制的需求規範。雖然它不能確保客戶據此就能獲得理想的解決方案，但卻可以幫助客戶發現那些儘可能接近自身需求的系統準備。其 目的是從客戶自身的角度出發，通過全面、詳細地陳述，使開發商或項目團隊理解客戶所希望的是什麼，以可行的價格滿足客戶的已識別的需求。
對於一些預算較少的客戶，開發商往往不願意花精力準備正式的方案建議書，這種情況下，客戶的需求建議書就變得很重要。事實上，項目無論大小，都需要編寫需求建議書。
第一，需求建議書需要描述用戶的目標與需求。編制需求建議書的過程也是客戶進一步明確自己的目標與需求的過程，並以此建立起客戶與供應商進行深人溝通的橋樑。即使因為各種原因使得供應商看不到或不願回響需求建議書，這種努力也是值得付出的。
第二，需求建議書可節省選型的時間，並使得對各供應商之間的比較變得更容易。客戶提供給所有競標供應商的信息都是一樣的，避免了跟各開發商的重複溝通，同時，有需求建議書作為基準，客戶可以約束各開發商以一致的格式提交方案建議書，以提高各供應商之間的可比性。
第三，需求建議書可以避免一些潛在的疏漏。在準備需求建議書時，客戶往往會因為太過關注具體細節而忽略了一些重要的因素。收到需求建議書後，有的供應商可能會主動對這樣的疏漏提出質疑以提醒客戶。還有些開發商為了使自己的方案建議書更具有吸引力，甚至會提出一些需求建議書沒有涉及的好想法來拓展客戶的思路。

一般原則

需求建議書應該由用戶編寫，但各種客觀因素的限制，實際上很難做到。所以，很多時候都是由用戶與項目小組共同編寫。編寫項目需求說明的J過程也是項目小組帶領客戶進入項目需求啟發的過程。編寫優秀的項目需求[建議書沒有公式化的方法，需要大量的實踐經驗。以下是編寫需求建議書需要把握的幾個原則：
(1)需求應該是正確的。每個需求必須精確描述要交付的功能。確定需求內容是否正確，需要用戶的代表來參與確認，由他們檢查、決定用戶需[求的正確性。沒有用戶的需求檢查就會導致很多項目實施中的問題出現。例如用戶會說：“這不是我們要的東西”；“你沒明白我們的意思”，等等。
(2)需求應該是可行的。項目的需求應該在有限的資源(已知的能力、有限的系統及其環境)下是可實現的。為了避免需求的不可行性，在需求分析階段應該有核心技術人員參與，檢查在技術上什麼能做、什麼不能做，哪些需要額外的付出等。
(3)需求內容應該是必要的。需求建議書中的每個需求都應該有相應[的出處，即說明什麼是客戶確實需要的，什麼要順應於外部的需求、接口或標準。如果不能標識出處，則可能這個需求不是真正需要的。
(4)需求內容應該有優先權。優先權是由客戶或其代理及項目小組共同商討後建立的。如果所有的需求都被視為同等重要，那么在開發中遇到預t算削減、計畫逾時或組員的離開而導致新的需求時，項目經理將無所適從。一般優先權有以下三個級別。
1)高優先權，表明需求必須體現於本階段項目的成果中或這個產品的版本中。
2)中優先權，表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中。
3)低優先權，表明有它很好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。
(5)需求內容應該是明確的。需求不該有歧義，要避免使用一些對於擬訂項目需求建議書的人很清楚，但對於其他人模糊不清的辭彙。如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔、直觀地採用用戶熟知的語言，而不要採用計算機術語。

範例

例：某企業項目管理軟體開發項目需求建議書
有關單位：某企業(甲方)由於業務發展的需要，決定採用項目管理的方式進行管理，為了更有效地對項目的執行過程進行控制，該企業決定開發一套項目管理軟體以滿足這一需要。　
1．工作表述
開發商將執行下面任務：開發項目管理軟體。
開發項目管理軟體的主要功能包括項目及工作信息的錄入、項目網路計畫圖的繪製、項目時間計畫的安排、甘特圖計畫的制定、項目執行信息的錄入與分析及各種計畫報表的輸出等功能。
2．要求
開發商應根據國家有關標準，提供開發計畫和實施方案。
3．交付物
符合甲方要求的項目管理軟體。
4．甲方提供的條款
甲方將幫助開發商熟悉項目管理流程。
5．契約類型
契約必須以一個商定的價格，給提供滿足需求建議書要求工作的開發商付款。
6．到期日
開發商必須在2004年11月30日以前提交5份申請書備份。
7．時間表
甲方希望在2004年12月25日前選中一家開發商。這個項目需要完成的時限是20—25周，從2005年1月1日開始實施項目，要求軟體正式驗收前試運行4周以上的時間，並根據試運行情況進行適當修改。
8．付款方式
當項目完成了1/3時付總額的1/3。
當項目完成了2/3時再付總額的1/3。
當甲方已經滿意於項目100%的完成，並且開發商已經履行了全部契約義務時再付出總額的1/3。
9．申請書內容(開發商的申請書至少包括如下內容)
(1)方法。開發商能清晰地理解需求建議書，理解什麼是被期望達到的要求。而且要詳細描述開發商領導項目的方法，要求對每個任務的詳細描述，任務如何完成的詳細描述。
(2)交付物。開發商要提供交付物的詳細描述。
(3)進度計畫。列出甘特圖或網路圖表，列出每月要執行的詳細任務的時間表，以便在要求的項目完成日期內能夠完成項目。
(4)經驗。敘述一下開發商最近已經執行的項目，包括客戶姓名、地址和電話號碼。
(5)人事安排。列出將被指定為項目主要負責人的姓名和詳細簡歷，以及他們在類似項目中的成績。
(6)成本。必須說明總成本並提供一份項目的預算清單。
10．申請書評價標準
(1)方案(30%)。開發商提出建設方案。
(2)經驗(30%)。被指定執行此項目的開發商和主要負責人的執行類
似項目的經驗。
(3)成本(30%)。開發商申請書中所列的固定成本。
(4)進度計畫(10%)。為了要在項目完成之日或在此日期之前完成項目，開發商應提供詳細的施工計畫。