需求建议书rfp

需求建议书rfp

需求建议书rfp

需求建议书是指从客户角度出发，全面、详细地向服务商陈述、表达为了满足其已识别需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出的用来说明如何满足其已识别需求的建议书，是客户与服务商建立正式联系的第一份书面文件，又称招标书。需求建议书一般由客户起草，主要描述客户的需求、条件及对项目任务的具体要求。一份完整的需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。

好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然，并非在所有情况下都需要准备一份正式的需求建议书，当某一企业的需求由内部开发项目予以满足时，这一过程似乎变得简单多了，此时更多需要的是口头上的交流和信息传递，而不是把宝贵的时间耽搁在仅仅起到信息传递作用的需求建议书上。例如，某一软件开发公司感到公司原来的财务分析系统已经远远不能适应日益增加的业务需要时，便可直接要求软件开发小组进行开发，这时只需口头把相关的要求传达给软件开发小组即可。

[编辑]需求建议书的主要内容[2]

需求建议书一般包含以下主要内容：

客户必须搜集大量相关资料准备需求建议书，因为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 项目，但客户在需求建议书中，往往不愿意透露这个信息。其实，客户暗示大约的数字，告诉开发商他打算花多少钱来办这件事是有好处的，这样可以使开发商能够提交与资金水平相适应的申请书，提高在

项目准备阶段的工作效率。

[编辑]需求建议书的必要性[2]

需求建议书(RFP)是项目客户与开发商建立正式联系的第一份书面文件，也叫招标书。一般由项目的客户自己起草，主要描述客户的需求、条件以及对项目任务的具体要求，向可能的开发商发送。

需求建议书是客户为确保供应商理解项目的需求，并在此基础上提供项目建议书而编制的需求规范。虽然它不能确保客户据此就能获得理想的解决方案，但却可以帮助客户发现那些尽可能接近自身需求的系统准备。其

目的是从客户自身的角度出发，通过全面、详细地陈述，使开发商或项目团队理解客户所希望的是什么，以可行的价格满足客户的已识别的需求。

对于一些预算较少的客户，开发商往往不愿意花精力准备正式的方案建议书，这种情况下，客户的需求建议书就变得很重要。事实上，项目无论大小，都需要编写需求建议书。

第一，需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是客户进一步明确自己的目标与需求的过程，并以此建立起客户与供应商进行深人沟通的桥梁。即使因为各种原因使得供应商看不到或不愿响应需求建议书，这种努力也是值得付出的。

第二，需求建议书可节省选型的时间，并使得对各供应商之间的比较变得更容易。客户提供给所有竞标供应商的信息都是一样的，避免了跟各开发商的重复沟通，同时，有需求建议书作为基准，客户可

以约束各开发商以一致的格式提交方案建议书，以提高各供应商之间的可比性。

第三，需求建议书可以避免一些潜在的疏漏。在准备需求建议书时，客户往往会因为太过关注具体细节而忽略了一些重要的因素。收到需求建议书后，有的供应商可能会主动对这样的疏漏提出质疑以提醒客户。还有些开发商为了使自己的方案建议书更具有吸引力，甚至会提出一些需求建议书没有涉及的好想法来拓展客户的思路。

[编辑]编写需求建议书的一般原则[2]

需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做[到。所以，很多时候都是由用户与项目小组共同编写。编写项目需求说明的J过程也是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求[建议书没有公式化的方法，需要大量的实践经验。以下是编写需求建议书需要把握的几个原则：

(1)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确，需要用户的代表来参与确认，由他们检查、决定用户需[求的正确性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说：“这不是我们要的东西”;“你没明白我们的意思”，等等。

(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环境)下是可实现的。为了避免需求的不可行性，在需求分析阶段应该有核心技术人员参与，检查在技术上什么能做、什么不能做，哪些需要额外的付出等。

(3)需求内容应该是必要的。需求建议书中的每个需求都应该有相应[的出处，即说明什么是客户确实需要的，什么要顺应于外部的需求、接口或标准。如果不能标识出处，则可能这个需求不是真正需要的。

(4)需求内容应该有优先权。优先权是由客户或其代理及项目小组共同商讨后建立的。如果所有的需求都被视为同等重要，那么在开发中遇到预t算削减、计划超时或组员的离开而导致新的需求时，项目经理将无所适从。一般优先权有以下三个级别。

1)高优先权，表明需求必须体现在本阶段项目的成果中或这个产品的版本中。

2)中优先权，表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中。

3)低优先权，表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

(5)需求内容应该是明确的。需求不该有歧义，要避免使用一些对于拟订项目需求建议书的人很清楚，但对于其他人模糊不清的词汇。如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁、直观地采用用户熟知的语言，而不要采用计算机术语。