医院门诊管理系统需求建议书

医院门诊管理系统需求建议书

2012年3月26日

有关公司：

现需一个医院门诊管理系统，要求具有相关项目经脸的软件公司参与竞标，要求能对该

系统进行合理的编写，保证系统能够稳定运行，并且在预定时间内交付我院使用。

项目目标：

系统分为5个子系统，即(a)挂号管理系统(b)病历管理系统©药品库存管理系统(d)

内部资料管理系统⑴财务管理系统。并且需要保证系统运行稳定准确。

1.工作表述

承包商应执行以下工作任务，及工作要求：

系统应使用本院的局域网，、、等环境

(1)win98win2000swinxpwin7

下，可进行稳定准确的查询，修改、处理功能。

(2)数据录入功能：其中包括在挂号时的患者信息录入，病历管理的录

入处方和内部资料管理中的医师信息的添加。

(3)数据的修改和删除功能：其中包括改号、退号和内部资料管理中的

患者、医师信息的修改和删除功能。

(4)数据查询功能：包括在诊室管理中的药品的模糊查询，对库存不足

的药品报警，内部资料管理中的医师、患者信息的查询中包括单项查询和组合查询。

(5)统计报表功能，财务报表：统计每天患者交款报表和挂号员每天的

交款单。统计患者总人数和总费用。

(6)按处方类别和拼音码分别统计药品的总数和库存剩容量。

(7)按科室名称和是否专家级别分别统计医师总人数信息。日报表：打

印每天的患者人数、就诊科室等，以及医师每天的出诊数，检验、检查、手术每天的执

行次数，以及这些项目的总金额。

(8)合计费用功能：患者凭挂号单到交款处交款，系统根据门诊号码自

动调用患者信息，显示患者的单项费用和总费用，自动找零。

(9)系统管理功能：其中包括用户和内部人员的修改密码功能,根据权

限添加用户和管理员。数据备份功能。

(10)帮助功能：包含医院简介和系统主要实现功能简介。

2交付实物

(1)必须准备一份详细的系统设计报告，以及所用到的技术，用以监测产品

质量。

(2)有关项目进程的书面报告必须在每15天交给本院。报告应简明，并且

重点放在与承约商的原计划和时间表相对应的进程上。报告应涉及到各项活动、取得的

进展、接下来15天的计划、花费的时间与金钱。对于落后进度计划进程的工作项目，应当

提供一份计划，使项目能在原进度计划和预算内完成。

(3)在合同预期内，交付我院一个能够运行正常稳定的完整的系统。并且在

后期一定时间内提供免费维护。

3其他要求

(4)本院会向承包商提供本院的一些业务流程。

(5)承约商必须在执行工作前，获得本院对最终计划的认同。

(6)合同必须以一个商定的价格,给提供满足需求建议书要求工作的承约商

(5)列出工程具体人员的姓名和详细简历，以及他在类似工程的精彩的经历。

(6)必须说明项目所需要的人月，并通过一份详细的工作时间分解和每个被指派于工程

的员工的小时成本费用来验证。此外,所有直接费用逐条列表也必须包括进来。

(7)承包商需列出贵公司的软件能力成熟度(cmmi)等级。

(8)本院将按照以下的标准评价所有承约商的申请书：

a.设计方案(30%)。设计的实用及涉及技术。

b.经验(30%)。被指定工程的承约商和工作人员执行类似工程的经验。

c.成本(30%)。承约商申请中的所列的固定成本。

d.进度计划Q0%)。为了在要求的项目完成日期内或在此日期之前完成项目，承约商

应提出进度计划的详细而全面的连续说明。篇二：项目需求建议书

项目需求建议书(rfp)

a.项目信息

提供关于项目名称、客户名称、项目经理以及项目发起人姓名等方面的一般信息

项目名称:

项目经理：

项目发起人：

客户名称：文件起草人：日期：b.项目目标

描述完成项目的时间、质量要求等方面的信息

c.工作描述（sow）

描述执行项目的具体工作

d.可交付结果

描述执行项目的阶段，完成项目任务的主要交付结果等方面的信息

e.合同类型

描述使用哪种性质的合同

f.付款方式

描述付款的时间、金额、币种、方式等

g.建议书的内容

描述建议书应包拈的具体内容

h.建议书的评价标准

描述评价建议书的主要标准，包括价格、技术方案、项目管理方法、经验与资质等方面

i.提交建议书的时间，地点要求

描述建议书的截止日期、提交的地点等信息

iso9000质量管理体系项目需求建议书（rfp）

a.项目信息

提供关于项目名称、客户名称、项目经理以及项目发起人姓名等方面的T殳信息

项目名称：

项目经理：

项目发起人：

建立iso9000质量管理体系李伟张卫东客户名掰:智能科技公司文件起草人：王

芳日期：2005年8月20日b.项目目标

描述完成项目的时间、质量要求等方面的信息

c.工作描述(sow)

d.可交付结果

e.合同类型

f.付款方式

g.建议书的内容

h.建议书的评价标准

I.提交建议书的时间、地点要求

篇三：项目需求建议书(1)

项目需求建议书

1、项目工作陈述

承约商将执行下面的任务承约商将按照客户的要求在有限的时间内按照客户提供的要

求完成对新房的装修任务。

2、项目的需求承约商须按照《家庭装饰装修工程质量规范》及客户提供的要求

完成装修。项目要求请看附件，承约商需在即日起五天内给出可供选择的方案及效果图。

3、客户供应款项

业主向承约商提供室内装修简易图纸，以及在装修期间业主需要提供的款项。4、合同

类型

合同一式两份,包含价格，相关附件,并标明付款方式。

5、客户付款方式

项目启动前由业主交付定金，定金为总价的50%,交付成果经业主检查达到业主要求

后支付剩下的50%。

6、项目的时间要求

业主希望在一个月内入住新房，所以这个项目需要的完成期是20天，所有可交付成果

必须不迟于20天提供给业主。

7、对承约商项目申请书的要求

承约商必须在即日起5天内向业主提交5份申请书备份。

其内容包括

a.方法。承约商能清晰的理解需求建议书，要详细描述承约商实施项目的方法，要求对

每个任务以及对这些任务如何完成进行详细描述。

b.可交付成果。承约会要提供可交付成果的详细描述。

C.进度计划。列出甘特图或网络图，以及每天要进行的详细任务时间表,以便在要求的

项目完成日期内能够完成项目。

d.经验。叙述承约商最近实施的项目，包括（客户姓名、地址和电话号码等）已备核实。

e.人事安排。列出将被指定为项目主要负责人的姓名和详细简历，以及他们在类似项目中的

成绩。

f.成本。必须说明总成本并提供一份项目的预算清单。

8、申请书的评价标准。

a方案（30%）,即承约商提出的建设方案；

b.经验（30%）,即被指定执行此项目的承约商和主要项目负责人实施类似项目的经验;

c.成本（30%）,即承约商申请书中所列的固定成本；

d.进度计划（10%）,即承约商提供详细的施工计划。

magic小组：张晓东130邓越127楮海林108余光权212篇四：需求建议书

需求建议书（requestforproposal,rfp）

什么是需求建议书⑴

需求建议书是指从客户角度出发，全面、详细地向服务商陈述、表达为了满足其已识别

需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出的用来说明如何满足其

已识别需求的建议书，是客户与服务商建立正式联系的第一份书面文件，又称招标书。需求

建议书一般由客户起草，主要描述客户的需求、条件及对项目彳壬务的具体要求。一份完整的

需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户

供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。

好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然，并非在所有情况

下都需要准备一份正式的需求建议书，当某一企业的需求由内部开发项目予以满足时，这一

过程似乎变得简单多了，此时更多需要的是口头上的交流和信息传递，而不是把宝贵的时间

耽搁在仅仅起到信息传递作用的需求建议书上。例如，某一软件开发公司感到公司原来的财

务分析系统已经远远不能适应日益增加的业务需要时，便可直接要求软件开发小组进行开

发，这时只需口头把相关的要求传达给软件开发小组即可。

［编辑］

需求建议书的主要内容［2］

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

客户必须搜集大量相关资料准备需求建议书，因为it项目实施者需要按照rfp来准备

他们的项目技术方案，并以此参与竞标。rfp中包括项目的目标，也就是用户的期望，也包

括客户要求项目的进度计划；对实施商申请书的表格和内容的规定；客户希望潜在的实施商

提交投标申请书的最后期限；评价申请书的标准等。T分好的rfp应该包括以下一些内容。

1.工作表述

工作表述就是说明项目的工作范围概括客户要求开发商或项目0］队执行的任务或工作

单元，说明项目所涉及的各种事情，哪些必须由开发商或项目团队去完成，哪些由客户自己

去做。例如，一个办公自动化软件系统的具体目标。又如建设一个网站，所需设备的采购任

务，是由客户自己完成，还是由开发商去完成；企业网站上的页面文字，是客户自己撰写,

还是由开发商撰写等。

2.任务要求

需求建议书必须要具体规定开发商需要完成任务的规格和特征如要求涉及大小、数量、

颜色、重量、速度和其他开发商提出的解决方案中，所必须满足的物理参数和操作参数。例

如，建立一个企业网站，可能要求在1000人同时访问的情况下不会产生堵塞的感觉,网

站的浏览页面不低于多少；建立一个自动结账和收款系统，可能要求每天能办理12000

次交易的功能和其他特定的功能,如在开出了发票的30天内没有收到账款，就会自动产生

催款通知。具体的任务要求,可能会成为将来的验收标准。

3.交付物

交付物就是开发商所提供的实体内容，这在需求建议书中应该说明。例如，对于自动结

账和收款系统来说，客户可能要求开发商提供硬件（计算机）、软件（磁盘和一些印刷品）、操

作手册和培训课程。交付物也可能包括客户要求开发商提供定期进度报告或终期报告。

4.客户供应条款

需求建议书还应该列出客户的供应条款。例如，客户需要建立一个网j站，可能需要向

开发商提供企业内部的组织结构及各部门之间业务关系的详］细说明，包括信息流程的类型、

信息流量和发生频率等。

5.表述客户对需求的福认

需求建议书不是对客户需求的最后确认。最后的确认应该在对开发商提出的方案进行评

估之后。例如印刷宣传手册，可能在开印之前要经过客户审定；局域网的建设，在购买材料

和设备之前,客户必须审定开发商的技术方案。这一点在需求建议书中必须向开发商说明。

6.期望的合同类型

Q)合同可以按固定价格订立。这样，开发商实际上就是费用包干。客户只给固定的价

钱，不管开发商实际工作花费多少。开发商必须保证功能的实现和质量要求，超支的风险由

开发商负担。

(2)合同也可以规定开发商不承担风险，即在时间、原材料限制的条件下，不论实际成

本多少，都会给开发商特定的报酬，也就是所谓包工不包料。在我国现阶段的条件下，由于

质量检验和资信度水平不高，这种合同比］较普遍。在需求建议书中，最好说明客户是希望

采用那种类型的合同。

7.期望的付款方式

付款方式可以分为一次性付款和分阶段付款；在开始前付款和结束后付款。一般依项目

的性质来定付款方式。如网页制作，往往在项目末期付款；而架设局域网，一般在方案确认

后，付款30%以便开发商采购，工程结束验收后付满90%,留10%等到使用一段时间以

后确认无问题时付清。具体付款方式需要合同双方办商，但在需求建议书中，客户应该先提

出自己的期望付款方式。

8.要求的进度计划

进度计划的要求可能很粗，如要求在6个月内完成；也可以详细一些，如多长时间内

完成方案设计和审定，多长时间内完成硬件选购与安装，多长时间内完成软件研制、测试与

安装，最后开发商在系统安装调试后，在多长时间内提交所有的系统文件和操作培训。

9.申请书的格式和内容提示

为了便于在几个开发商之间进行比较和评价，申请书应该在形式上采取同一个格式，内

容的结构也应该一致。这样对不同的申请者来说交公平也能减轻客户在评审时的工作量.

客户在需求建议书中可以限定申请书的每一部分采用的文字数量或页数。

10.提交申请书的最后期限

申请书受理的截止日期是必须要交代清楚的。例如，要求开发商在接到需求建议书后多

少个工作口之内（如I周之内、1个月之内等）提交申请书，或大家一律在某月某日之前提交

申请书。这样做的目的是便于同时对众多的申请者进行t匕较、评估,也是为了保持公正，不

给某些开发商以额外的时间和机会。

11.对申请书的评价标准

要告诉开发商客户将根据哪些准则来评价他提交的申请书。这样做的目的，是指导开发

商写好申请书。一般评价标准包括4个方面的内容：

(1)开发商在类似项目中的经验。如他们近期是否在预算内按期完成了类似的项目，客

户对他们是否满意？

(2)开发商提出的技术方案是否合适。如采用哪种类型的计算机软件?数据库的设计、方

法是什么?用来建立管理信息系统的是哪种语言?采用哪些供应商的设备?等等。

(3)进度计划。开发商是否能按照所要求的进度完成项目计划？

(4)成本。如开发商的报价是否合理?成本预算中有无漏算的条款?将来在执行时有没有

可能出现超支，或有无可能因过于节约而导致质量不能保证?有的申请人为了争取合同，在

报价上压低成本，到了执行阶段，或偷工减料，或增加成本，结果导致所建系统的缺陷很多，

或使最终成本大大超出原始的估算。对此需要引起注意。

12.资金总量

开发商总是希望了解客户有多少资金可以用于发展拟议中的真t项目，但客户在需求建

议书中，往往不愿意透露这个信息。其实,客户暗示大约的数字，告诉开发商他打算花多少

钱来办这件事是有好处的，这样可以使开发商能够提交与资金水平相适应的申请书，提高在

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

［编辑］

需求建议书的必要性［2］

需求建议书(rfp)是项目客户与开发商建立正式联系的第一份书面文件，也叫招标书。

一般由项目的客户自己起草，主要描述客户的需求、条件以及对项目任务的具体要求，向可

能的开发商发送。

需求建议书是客户为确保供应商理解项目的需求，并在此基础上提供项目建议书而编制

的需求规范。虽然它不能确保客户据此就能获得理想的解决方案，但却可以帮助客户发现那

些尽可能接近自身需求的系统准备。其

目的是从客户自身的角度出发，通过全面、详细地陈述，使开发商或项目团队理解客户

所希望的是什么,以可行的价格满足客户的已识别的需求。

对于一些预算较少的客户，开发商往往不愿意花精力准备正式的方案建议书，这种情况

下，客户的需求建议书就变得很重要。事实上，项目无论大小，都需要编写需求建议书。第

-，需求建议书需要描述用户的目标与需求。编制需求建议书的过程也是客户进一步明确自

己的目标与需求的过程，并以此建立起客户与供应商进行深入沟通的桥梁。即使因为各种原

因使得供应商看不到或不愿响应需求建议书，这种努力也是值得付出的。

第二，需求建议书可节省选型的时间，并使得对各供应商之间的比较变得更容易。客户

提供给所有竞标供应商的信息都是一样的，避免了跟各开发商的重复沟通，同时,有需求建

议书作为基准，客户可以约束各开发商以一致的格式提交方案建议书，以提高各供应商之间

的可比性。

第三，需求建议书可以避免一些潜在的疏漏。在准备需求建议书时，客户往往会因为太

过关注具体细节而忽略了一些重要的因素。收到需求建设书后，有的供应商可能会主动对这

样的疏漏提出质疑以提醒客户。还有些开发商为了使自己的方案建议书更具有吸引力，甚至

会提出一些需求建议书没有涉及的好想法来拓展客户的思路。

［编辑］

编写需求建议书的一般原则⑵

需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做［到。所以，很多

时候都是由用户与项目小组共同编写。编写项目需求说明的j过程也是项目小组带领客户进

入项目需求启发的过程。编写优秀的项目需求［建议书没有公式化的方法，需要大量的实践

经验。以下是编写需求建议书需要把握的几个原则：

Q)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确，

需要用户的代表来参与确认，由他们检查、决定用户需［求的正确性。没有用户的需求检查

就会导致很多项目实施中的问题出现。例如用户会说："这不是我们要的东西"「你没明白

我们的意思"，等等。

(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环

境)下是可实现的。为