建議書的結構和格式
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%)。為了要在專案完成之日或在此日期之前完成專案，開發商應提供詳細的施工計劃。
