需求建议书RFP（request for proposal）是指从顾客的角度出发，全面详细地阐述为了满足识别出的需要而进行的一份提供了详细信息的文件。在大多数情况下，不需要准备正式的需求建议书，而是通过口头的形式表达。

书写RFP要认真负责、严肃对待，内容具体，语言精练，要满足如下要求：

2．写接受建议对方的名称。

3．正文：

（1）建议的原因或出发点，便于对方考虑。

（2）建议的具体事项。

4．表达建议者的愿望。

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%)。为了要在项目完成之日或在此日期之前完成项目，开发商应提供详细的施工计划。