软件项目需求分析总结

第一篇：软件项目需求分析总结

软件项目需求分析总结

我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况：

客户本身说不清楚

文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。

需求自身经常变动

随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误

毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。

由此出现的问题：

a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。

b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。

c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。

d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事

管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计(软件的成熟度)方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。

f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论

a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。

b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。

c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。

d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生

e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。

f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解

h)最后，需求分析报告一定要双方共同签字确认

第二篇：软件项目需求分析总结

软件项目需求分析总结

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键 总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要是下面几个情况： 客户本身说不清楚 文物网是这样，中彰国际更是这样，但是这不能怪客户，毕竟客户在软件方面的知识要少的多，也没有相关的经验，可能心里只有一个想要的软件的轮廓，于是可能会要求我们去替他们来完整这个轮廓的细节，而我们的能力、我们能否真正站在客户角度去搜集和整理这些需求，就决定了这个需求的完整性和有效性。需求自身经常变动 随着客户对这个项目越来越深刻的理解，那么可能他的需求也会随之改变，这些变化的可能性越大项目风险就会越大，我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求，哪些可能会是产生变动的需求，考虑到他的可变性，这样设计功能和数据库的时候不致因为后面的变动而影响整个工程。分析人员或客户理解有误 毕竟，不是每个分析人员都是专业而合格的，为避免这种情况的发生，需求分析必须要有审核制度，公司自己内部要审核一遍，客户再审一遍，提出意见，修改后双方共同评审签字，确认。由此出现的问题： a)需求分析过于笼统，只关注到面上，没有关注到点上，开发出来的东西在具体的细节上和客户的理解有误差，并且无法严格界定是否属于需求变更。中彰的方案就是这样的。b)需求报告只求我们这方评审通过，不去关心客户的评审，认为只要客户签字认可就行。虽然签字认可能够给日后出现问题时划清我们的责任，但是不能保证使项目实施成功。c)需求分析中含有技术实施上有难度的功能，一味的求全和盲目按照客户的设想，受客户影响过大，毕竟，很多时候，客户的想法在实际实施过程中是不现实的，或者可以有更为简便的方法来替代的。如中彰国际的在线交易功能，后台大批量邮件群发功能。d)对双方已经确定的需求，实现以后并不适合客户使用，需要按照变更手续执行的时候，客户可能会纠缠，提出“你们是专业人士，你们应该事先能提醒我们可能会出现这种问题”并以此来把责任推给我们，而我们又不好完全按照变更手续执行，因为可能激化双方的矛盾，比如508的批量处理功能，因为属于人事管理比较专业的细节问题，需求分析师开始没有对客户业务熟悉到如此细致的地步，而客户也没有过多关注这些细节，导致软件的某些功能不合用，较为繁琐，而重新按着客户的意见修改的话工作量比较大，导致成本增加、工期延长。e)项目的成熟度受客户预算的限制。大部分客户在项目投入上都是有预算的，在成本有上限的前提下，项目的功能设计（软件的成熟度）方面必然受一定影响，毕竟功能越多越完善，相应的开发成本就越高。这种功能上的不完善需要事先告知客户并得到理解。f)此项工作的反复造成思想上的倦怠，使需求分析最后虎头蛇尾。需求分析是一项繁琐枯燥的工作，需要和客户之间不断的商讨、确认和反复，另外由于大部分的客户虽然安排专人负责这项工作，但是该人并不只做这项工作，特别当他被很多其他的事情缠身的时候，而无心细看提交过去的需求报告的时候，他很可能会给你一个错觉，让你认为他已经真正的理解并认可了你的设计。结论 a)需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。b)需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。c)需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。d)需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生 e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。f)需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题 g)帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解 h)最后，需求分析报告一定要双方共同签字确认。

第三篇：软件项目需求调研总结

软件项目需求调研总结

一、需求调研准备：

在需求调研过程中，应该做好三种准备，保持两种心态，做到五种提高：

三种准备

1）调研前应该将所有项目前期资料进行汇总，与相关的前期销售人员进行交流，以便对项目有一个基本轮廓的认识。

2）做好调研前使用资料的准备，如需求调研模板，需求调研问题列表等。

3）做好不怕一切困难的准备。

两种心态

1）保持一种和客户平等合作的心态，确定需求调研是为了给客户解决问题，探讨问题，而不是接受问题，更不是来指导工作的。

2）平静面对需求变更的心态，在需求调研过程中，往往双方对需求理解不一致，造成需求调研前后矛盾，应当心平气和的去引导客户，达到需求理解基本一致。

三种提高

1）首先提高自己业务知识，对于人力资源的标准业务应该基本熟悉。

2）其次应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户。这就需要我们阅读用户所在行业的资料、文章，尽量多选取一些整体性介绍的文章，这样可以在短时间内能够对该行业有一个全面的认识，这样我们就能够较好的和用户进行交流了。

3）需求调研中，学会尽量不使用IT行业的术语，而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语，以便用户能够很好的理解，提高自己的沟通交流能力。

4）提高自己的速记能力，文字表述能力以及归纳，能迅速的记录需求调研核心的问题，总结归纳形成原始的需求调研资料。

5）提高自己的总结能力，书写一份完整的、前后一致的、可追踪的需求报告。

二、需求调研过程的总体流程

需求调研中应遵循一定的流程，而且在调研过程中表现出规范，调研有条不紊，对客户有理有据，调研中资料做好备份，做到有备无患：

三、需求调研过程中注意问题

四、需求报告书写要求及标准

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要简练。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们需求编写者还要努力正确地把握粒度。多个需求尽可能拆分开。

整个需求文档细节上要保持一致。

避免在需求报告中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

需求调研对于系统的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。我希望我们能得到一块“德芙”。

调研概要情况：X项目需求调研开始于2006-3-23结束于2006-6-15，内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干，编写需求规格说明书字数95.4万。

1.把二期项目当作一个新项目来做调研，避免需求细节遗漏。在调研的初期我们曾经有过疑虑，这是一个二期的项目，那么调研的内容是否只针对二期的新需求，对需求内容二期和一期一致的部分就不必调研了?

经过讨论我们还是决定把二期项目当作一个新项目来做调研，即使二期和一期需求内容一致，我们也在调研会上讨论，并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时，发现有不少地方原来以为是二期不必修改的，经过讨论后发现还是需要修改。（往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”）

2.调研团队参加所有子系统的调研会议，可以相互补充避免需求遗漏。这个项目规模比较大，根据业务的类型不同，分成了6个子系统，各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求，但是在调研时，只要可能，我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是，对于子系统之间的业务关系，调研团队都可以有全面的了解，对业务的理解比较透彻全面，并且还可以相互补充遗漏。

3.多人调研，在会议后应该立刻回顾整理统一的会议笔记，消除歧义，避免遗漏。在开调研会时，全体与会人员都各自记自己的会议笔记，会后没有强调当天整理会议笔记（会议进度很紧，每天开会到晚上8、9点钟）。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容，或者同一份需求在几个笔记上记录的内容细节上有差异，事后难以追溯正确的信息。给编写需求文档带来了一些困难，需要再次讨论需求。

4.需求文档编写完成后，在开发阶段也应该做检查和更新，避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后，在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误，导致需要重新修改。

建议：

1、如果在编写需求文档后，开发阶段应该做一边阅读需求文档，一边做需求文档的检查，对于保证需求质量效果会更好。

2、应该指定人负责需求追踪和更新，在开发阶段、测试阶段要保持和用户的需求沟通，这不是一个可有可无的简单工作，很重要，并且会占用责任人50%的工作时间。

3、企业业务管理信息系统的需求调研方法：我认为对调研的组织安排是非常重要的，好的调研安排虽然未必产生质量高的需求，但是一个不遵循调研规律的调研活动，必然是低效的。下面是H项目调研组采取的调研流程，供参考：

4、第一步不是立刻和用户当面讨论需求细节，而是要业务关键用户编写初步的需求报告，提供给开发团队阅读分析。需求报告的内容是，对业务流程的描述，对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系，经常在没有面对面沟通时，关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础，一定要做，有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通，让用户编写。

第四篇：软件项目需求建议书

篇一：软件需求建议书

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

2012年3月26日

有关公司：

现需一个医院门诊管理系统，要求具有相关项目经验的软件公司参与竞标，要求能对该系统进行合理的编写，保证系统能够稳定运行，并且在预定时间内交付我院使用。

项目目标：

系统分为5个子系统，即（a）挂号管理系统(b)病历管理系统(c)药品库存管理系统(d)内部资料管理系统(f)财务管理系统。并且需要保证系统运行稳定准确。

1.工作表述

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

(1)系统应使用本院的局域网，win98、win2000、winxp、win7等环境

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

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

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

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

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

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

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

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

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

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

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

印每天的患者人数、就诊科室等，以及医师每天的出诊数，检验、检查、手术每天的执行次数，以及这些项目的总金额。

(8)合计费用功能：患者凭挂号单到交款处交款，系统根据门诊号码自 动调用患者信息，显示患者的单项费用和总费用，自动找零。

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

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

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

2交付实物

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

质量。

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

重点放在与承约商的原计划和时间表相对应的进程上。报告应涉及到各项活动、取得的进展、接下来15天的计划、花费的时间与金钱。对于落后进度计划进程的工作项目，应当提供一份计划，使项目能在原进度计划和预算内完成。

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

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

3其他要求

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

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

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

付款。

（7）承约商必须最迟在2012年5月1日以前提供给本院两份建议书备份。

（8）本院希望在2012年6月1日前选中一家承约商。这个工程需要完成的

期限是十二个月，从2012年7月1日至2013年7月1日，所有交付物必须不迟于2013年10月1日提供给本院。

（9）本院将按照下面的时间表付款给承约商：当项目完成了1/3时付总额的

1/3；当项目完成了2/3时付总额的2/3；当本人已经满意于项目的100%，并且承约商已履行了全部契约义务时再付出总额的最后1/3。

申请内容

(1)承约商能清晰理解需求建议书，理解什么是被期望达到的要求。承约商应有对每个任务和任务如何完成的详细描述。

(2)承约商将要提供的每一份交付物的描述。

(3)列出条形图或网络图表，列明每周要执行的详细任务的时间表，以便在要求的项目完成日期内能够完成项目。

(4)叙述一下承约商最近已经执行过的相似项目，包括已完成的子系统，以及其他子系统的完成进度。

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

(6)必须说明项目所需要的人月，并通过一份详细的工作时间分解和每个被指派于工程的员工的小时成本费用来验证。此外，所有直接费用逐条列表也必须包括进来。

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

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

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

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

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

d．进度计划(10%)。为了在要求的项目完成日期内或在此日期之前完成项目，承约商应提出进度计划的详细而全面的连续说明。

篇二：软件系统项目建议书完全版

****系统项目建议书

2014年5月

目录

概述....................................................................1 1.1 文档编写目的...........................................................................................................1 1.2 系统建设目标与内容...............................................................................................1 1.2.1 系统建设目标...................................................................................................1 1.2.2 系统建设的主要内容.......................................................................................1 2 系统设计方案.............................................................1 2.1 总体架构设计...........................................................................................................1 2.1.1 系统总体业务架构...........................................................................................1 2.1.2 系统总体软件架构...........................................................................................1 2.1.3 系统总体技术架构...........................................................................................1 2.2 系统组成...................................................................................................................1 2.3 系统数据流...............................................................................................................1 2.4 系统功能...................................................................................................................3 3 系统部署方案.............................................................3 3.1 系统部署架构...........................................................................................................3 3.2 系统环境...................................................................................................................3 3.2.1 软件环境...........................................................................................................4 3.2.2 硬件环境...........................................................................................................4 4 系统界面设计.............................................................4 5 主要技术指标.............................................................4 6 交付成果................................................................6 7 验收策略................................................................6 7.1 系统验收测试的原则...............................................................................................6 7.2 验收测试的具体内容...............................................................................................7 7.3 验收测试的步骤.......................................................................................................7 8 质量保证................................................................8 8.1 软件研制一般要求...................................................................................................8 8.2 软件评审要求...........................................................................................................9 8.3 软件配置管理要求.................................................................................................10 9 售后服务...............................................................10 9.1 培训.........................................................................................................................10 9.2 维护与升级.............................................................................................................10 9.3 质量保证期内的服务.............................................................................................10 9.4 寿命期内维修服务.................................................................................................11 10 开发进度计划............................................................11 11 项目报价...............................................................12 1 概述

1.1 文档编写目的 1.2 系统建设目标与内容

1.2.1 系统建设目标 1.2.2 系统建设的主要内容

系统设计方案 2.1 总体架构设计

2.1.1 系统总体业务架构 2.1.2 系统总体软件架构 2.1.3 系统总体技术架构

2.2 系统组成

2.3 系统数据流

系统详细数据流如下图所示。

2.4 系统功能

系统部署方案 3.1 系统部署架构

表1各子系统部署架构

3.2 系统环境 篇三：需求建议书

题目：

假设你在嘉州新城购买了一套二室二厅一厨一卫，面积大约90平方的新房，先装修入住，请你根据自己的需求对这个房屋装修项目编写项目需求建议书。

项目：房屋装修

需求建议书：

（1）承约商要执行的任务：装修材料的购买、家用设备的安装、装修工程。

① 代购装修材料，如：地砖、涂料等等

② 厨房器具、淋浴设备等的代购

（2）承约商根据国家标准装修，提供装修计划、施工方案，最后装修符合标准的房

子。

（3）本人向承约商提供装修方案。

要求：

①、卧室的颜色以暖色调为主

②、装修后简单、宽敞、采光效果良好

③、卫生间隔成两部分，分为盥洗间和浴室

（4）和承约商签订一个商定的价格，以及满足需求建议书的工作承约商付款合同。

（5）当装修工程完成1／2时付总额的1／2；当装修工程100%完成时，获得本人的

满意后，并且承约商已经全部履行契约义务时再付总额的最后1／2。

（6）希望这个项目在两个月内完成，从5月15日到7月15日，所有的可交付成果 必须不迟于7月15日提供给本人。

（7）承约商必须最迟于4月30日以前向本人提交两份申请书备份。承约商的申请书

至少包括以下内容： 1）承约商能清晰的理解需求建议书，要详细描述承约商的实施装修项目的方法，以及使用的装修材料的具体规格。

2）承约商要提供可交付成果的详细描述。

3）在6月15日向本人反映项目进行的进度。

4）叙述承约商最近实施的项目，包括客户的姓名、地址和电话号码，以备核实。

5）列出将被指定为项目主要负责人的姓名和联系方式，以及工作经验。

（8）申请书的评价标准

1）承约商提出的建设方案（30%）

2）被指定为执行此项目主要负责人的姓名和联系方式，以及类似的工作经验（30%）

3）承约商申请书所列的固定成本（30%）

4）承约商提供的施工计划（10%）

组员：岳红 117 王华 213 周燕飞 126 赵涵玉 223 曾志锦 203 篇四：需求建议书

需求建议书（request for proposal，rfp）

什么是需求建议书[1] 需求建议书是指从客户角度出发，全面、详细地向服务商陈述、表达为了满足其已识别需求所应做的准备工作。也就是说，需求建议书是客户向服务商发出的用来说明如何满足其已识别需求的建议书，是客户与服务商建立正式联系的第一份书面文件，又称招标书。需求建议书一般由客户起草，主要描述客户的需求、条件及对项目任务的具体要求。一份完整的需求建议书主要包括满足其需求的项目的工作自述、对项目的要求、期望的项目目标、客户供应条款、付款方式、契约形式、项目时间、项目申请书的要求等。好的需求建议书能让服务商准确把握客户所期待的产品或服务。当然，并非在所有情况下都需要准备一份正式的需求建议书，当某一企业的需求由内部开发项目予以满足时，这一过程似乎变得简单多了，此时更多需要的是口头上的交流和信息传递，而不是把宝贵的时间耽搁在仅仅起到信息传递作用的需求建议书上。例如，某一软件开发公司感到公司原来的财务分析系统已经远远不能适应日益增加的业务需要时，便可直接要求软件开发小组进行开发，这时只需口头把相关的要求传达给软件开发小组即可。

[编辑] 需求建议书的主要内容[2] 需求建议书一般包含以下主要内容：

客户必须搜集大量相关资料准备需求建议书，因为it项目实施者需要按照rfp来准备他们的项目技术方案，并以此参与竞标。rfp中包括项目的目标，也就是用户的期望，也包括客户要求项目的进度计划；对实施商申请书的表格和内容的规定；客户希望潜在的实施商提交投标申请书的最后期限；评价申请书的标准等。一份好的rfp应该包括以下一些内容。

1．工作表述

工作表述就是说明项目的工作范围，概括客户要求开发商或项目团队执行的任务或工作单元，说明项目所涉及的各种事情，哪些必须由开发商或项目团队去完成，哪些由客户自己去做。例如，一个办公自动化软件系统的具体目标。又如建设一个网站，所需设备的采购任务，是由客户自己完成，还是由开发商去完成；企业网站上的页面文字，是客户自己撰写，还是由开发商撰写等。2．任务要求

需求建议书必须要具体规定开发商需要完成任务的规格和特征，如要求涉及大小、数量、颜色、重量、速度和其他开发商提出的解决方案中，所必须满足的物理参数和操作参数。例如，建立一个企业网站，可能要求在1 000人同时访问的情况下不会产生堵塞的感觉，网

站的浏览页面不低于多少；建立一个自动结账和收款系统，可能要求每天能办理12 000次交易的功能和其他特定的功能，如在开出了发票的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)需求内容应该是明确的。需求不该有歧义，要避免使用一些对于拟订项目需求建议书的人很清楚，但对于其他人模糊不清的词汇。如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁、直观地采用用户熟知的语言，而不要采用计算机术语。

[编辑] 需求建议书例子[2] 例：某企业项目管理软件开发项目需求建议书

有关单位：某企业(甲方)由于业务发展的需要，决定采用项目管理的方式进行管理，为了更有效地对项目的执行过程进行控制，该企业决定开发一套项目管理软件以满足这一需要。

1．工作表述

开发商将执行下面任务：开发项目管理软件。

开发项目管理软件的主要功能包括项目及工作信息的录入、项目网络计划图的绘制、项目时间计划的安排、甘特图计划的制定、项目执行信息的录入与分析及各种计划报表的输出等功能。2．要求

开发商应根据国家有关标准，提供开发计划和实施方案。篇五：软件项目管理项目建议书

湖南文理学院实验报告

时间： 2013 年 11 月 18 日

课程名称： 软件项目管理

实验名称：撰写毕业生就业信息管理系统项目建议书

班级： 姓名： 同组人： 无

指导教师评定： 签名：

一、实验目的掌握项目建议书的格式和写作要求，会结合具体项目写作项目建议书。

二、实验要求

1、结合模拟项目—毕业生就业信息管理系统项目写出项目建议书。

2、提交毕业生就业信息管理系统项目建议书（报告）一份。

三、实验环境 1．硬件：计算机 2．操作系统：windows平台。

3．相关软件：microsoft office软件。

四、实验步骤

1、背景介绍

随着internet的迅猛发展和普及，我国高等院校纷纷建立自己的校园网，使高校的办公，教学和管理工作发生了巨大的变化，并具有了新的特点，对教学管理工作提出了新的要求，也使得基于网络的高校毕业生就业招聘成为可能。通过internet，用人单位和就业者利用网络的便利，不直接见面，采用网络交互地就业联系、就业面试，以及就业意向和合同的签订等工作。我国部分高校目前正在尝试通过网络进行毕业生的就业分配工作，但目前使用的就业网站的开发应用，大多功能相对单一，多局限于就业信息的发布，就业信息的静态统计结果的公布及简单的就业信息查询，其实用性和互动性已经不能满足高校就业形势的需要。随着高校毕业生就业体制改革进程的不断深化和毕业生就业市场的逐步建立，高校毕业生在各种就业活动中求职面窄、择业率低、特别是信息量小的问题越来越突出。如何解决这一问题是摆在各级就业主管部门面前的严峻任务。正是在这种情形下，国务院对做好高校毕业生就业工作做出重要指示，即“要充分利用毕业生就业信息网络，沟通行业间、地区间、学校与用人单位间的信息，在毕业生和用人单位之间牵线搭桥。同时，通过信息反馈，优化高等教育结构，合理

利用有效资源，促进高等教育的健康发展”高校就业系统以招聘和求职系统为核心，以用人单位需求和服务为目标。明确了系统的定位，有利于构建优化网上就业服务体系，有利于不断激活毕业生就业市场，有利于网络资源的充分利用，有利于网上动态管理、杜绝虚假信息、拓宽网上就业服务功能。

2、项目的意义和必要性

毕业生就业信息系统和就业服务体系不完善，毕业生就业主要由学校、人才市场举办招聘会等方式获得信息，与需求方见面，信息渠道比较窄。毕业生的就业指导工作极为薄弱，就业指导教师水平参差不齐，专业的、高素质的就业指导教师太少；缺少优质的就业指导教材。所以，必须加强学生择业的政策咨询和信息服务，逐步建立起信息服务网络，建立毕业生就业网络系统，为实行网上求职择业创造条件和提供服务。目前，建设好大学生的就业网站，不仅仅是政府部门应该关心的问题，作为培养大学生的湖南文理学院也有同样的需求。

解决目前高校就业信息管理中存在的一些问题，如信息传递不方便、不快捷，数据分析及就业指导不及时，学生签约必须到不同部门领表、上交等繁琐的操作等。通过本系统可以使湖南文理学院毕业生就业信息管理工作更加合理化、科学化，提高工作的效率，从根本上改变就业管理工作的方式，通过internet，各院系和学生利用网络的便利，可以直接查询和提交就业信息。在这种系统平台下，可以快速、有效、全面的反映最新的用人单位信息、毕业生基本信息和就业趋势，及时提供高校学生工作管理人员对历届用人单位需求信息的分析统计，及时有效地调查分析大学毕业生的择业趋势和引发的心理问题并进行及时有效的就业指导。可以做到信息的规范管理、科学统计和快速查询，从而减少管理方面的工作量。

3、项目产品或服务的市场预测

（由于这个系统不是学院的直接收益产品，这里不做分析。）

4、项目的规模和期限

基于学院的实际情况，这个毕业生就业信息可以初步分为三个阶段来完成。

第一阶段，着重处理学院现有的问题，把系统运行起来，重点放在用户管理方面，分为用户注册、用户审核和用户登录验证三部分。

第二阶段，注重完成学校的就业信息发布，用户在通过系统注册后，可以查询各种信息。

第三阶段，系统管理，管理可以对学生用户和站内信息进行管理。

5、投资估算

具体相信的投资预算，由专业人员进行。这里只能给出对比其他同类学校信息系统的估算，3个阶段全部完成，大概需要5万人民币。这个估算不包括硬件设备的预算。

6、市场前景及经济效益初步分析

这个系统虽然不是学院的直接收益产品，但其带来的间接效益是毋庸置疑。具体可以表现为：

（1）管理决策的科学化。

传统的决策指示凭经验的大致的估算，无法采集到大量的数据，也无法对采集到的数据进行精确的分析，而毕业生就业管理系统通过internet，各院系和学生利用网络的便利，可以直接查询和提交就业信息，比较全面、及时地采集信息数据、并选定合适的管理模式，做出科学的决策，减少决策失误。

（2）管理工作的高效化。

在这种系统平台下，可以快速、有效、全面的反映最新的用人单位信息、毕业生基本信息和就业趋势，及时提供高校学生工作管理人员对历届用人单位需求信息的分析统计，及时有效地调查分析大学毕业生的择业趋势和引发的心理问题并进行及时有效的就业指导。

（3）网上就业服务体系的优化。

毕业生的就业指导工作极为薄弱，就业指导教师水平参差不齐，专业的、高素质的就业指导教师太少；缺少优质的就业指导教材。而毕业生就业网络系统加强了学生择业的政策咨询和信息服务，逐步建立起信息服务网络，为实行网上求职择业创造条件和提供服务。

（4）网络资源的充分利用。

指导老师可以开辟“求职顾问”，“就业指导”的板块，告诉毕业生就业过程中应该注意的问题，帮助学生完善职业形象；了解劳动关系法规；增强自身的保护意识；提高大学生竞争就业意识和能力。

大学生可以利用就业网络内容丰富、全面的就业信息，最新的国家就业政策和规范，了解国家就业形势，更新就业观念，树立正确职业观和就业观。同时，制作个人简历，实现网上的自荐求职，查询自己感兴趣用人单位的资料，来了解用人单位的情况。

用人单位可以浏览学生所在学校的网站来了解学校的概况及专业设置情况，了解学生专业知识结构和综合素质，并且通过学校就业网站来核对电子简历的诚信度。

（5）毕业生与用人单位的良好沟通

大学生通过查询自己感兴趣用人单位的资料，来了解用人单位的情况。对中意的单位可以投递电子简历。用人单位通过浏览学生所在学校的网站，了解毕业生的信息。有意向的双方可以通过网上面试的方式来进行进一步的沟通，提高学生和用人单位接触频率，促进就业工作开展。为企业和学生提供一个交流平台及更为人性化、个性化的服务。

另外需要注意的是，毕业生就业管理系统的效益一般是无形的，只有经过长期运行后的分析统计才能计算其收益，往往越成熟、科学、优秀的毕业生就业管理系统，带给我们的效益就越大。毕业生就业水平提高了，学校知名度也会随之提高，学校的生源也会越来越好。

综上所述，校方认为建立一个毕业生就业管理系统是非常必要的，请上级领导批示。

7、其他需要说明的问题

随着计算机科学与技术学院学院人数不断增加，毕业生的人数也会逐步增长，毕业生就业管理的难度也在不断加大，所有我们认为建立一个计算机科学与技术学院毕业生就业管理系统是在将来的影响和效益是不可估量。

第五篇：软件需求-案例分析

1、问题描述

许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、该系统所涉及的用户

本系统的用户包含患者、医生以及管理员三类。而且该三类用户各自的特征和所要面对的情景也是截然不同的。

对于患者来说，他们在年龄、计算机使用能力等方面存在较大差异，但面对的情景都一样，就是要预约挂号，挂号成功过后就诊。

对于医生来说，普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。所面对的情景有查看挂号信息，确定要就诊的病人。

对于管理员来说，他们负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。

不同的用户，对系统的要求也不相同。患者希望通过完成注册和登录后能够进行挂号预约，查询医生的出诊信息和个人预约信息，并且能够在规定的时间内完成挂号预约或者取消已有的预约；医生则希望能够在登录系统后可以查看病人的预约情况；而管理员希望可以修改出诊信息和调整预约挂号。这些都是功能性的需求。

同时对于所有用户都希望该系统是易用的，而且能够对自己的信息起到保护即系统安全性的要求，还有比如说系统的性能比较高效，能够及时处理自己的预约申请。当然开发系统的成本如果也能较低就更好了。这些都是非功能需求。

2.2、情景描述的主要成分

 目标和关键成功因素

预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。关键成功因素，要保证系统能够24小时正常稳定的运行，系统里的信息要是实时变化的，即可以预约的医生要和实际在值班的医生要匹配，不能出现挂上号了却没有医生就诊的情况。

 物理上下文和逻辑上下文 物理上下文：医院用于挂号的计算机可以正常的使用，情景中的可以被预约的医生应该是在医院值班的；而对于患者可以选择在医院进行预约，也可选择在家中进行预约，只要在预约时间内能到达医院就可。逻辑上下文：事件发生的条件是患者在系统中进行了预约，然后管理员会根据现有的资源（可以预约的医生）对预约进行处理，如果同意，下一步就是医生就诊；如果没有可以预约的医生或合适的时间，患者的预约就不成功，患者需要重新选择医生或时间进行预约。

 组成情景的主要事件和活动 主要事件：患者预约挂号，管理员对预约挂号的处理，医生就诊。主要活动：患者注册、登录系统，患者在系统中查询可以预约的医生和时间，患者取消已有预约，患者进行就诊；管理员接受或拒绝预约，管理员分配医生；医生查询预约信息。

 涉及的执行者和其他参与者

执行者：医院的医生，预约挂号系统的管理员。其他参与者：医院的相关人员，比如患者，前台咨询员等。

 要使用的信息和资源 要使用的信息和资源包括，可以预约的医生数量，所在科室等，医院中的设备，病房等。 要考虑的约束条件和要使用的规则 约束条件：同一医生同一时间段内只能接受一名患者的预约，根据医疗设备的属性决定是否要排他性的使用。

3、情景需求分析的步骤

需求规格说明输入过程需求目标列表1.目标分析系统模型目标,目的使用情景用户问题实例2.输入事件分析初始系统模型用户,环境事件情景脚本4.输出需求分析3.刻画系统输出情景结构模型系统输出类型信息需求5.社会影响分析Agent目标6.涉众分析需求规格说明

3.1 目标分析

在第2部分情景描述的主要成分中已经对目标进行了分析，即：预约挂号情景的目标是“让患者能够及时的挂号，并能顺利的就诊”，而可能的子目标包括：患者能够注册账号，患者能够登录账号，患者能够查询预约记录，患者能够取消已有预约，患者能够查询出诊信息。3.2 输入事件分析

对于该系统的输入事件可能会包括如下情况：初始使用该系统的用户需要先注册，而对于已经注册的用户在使用系统预约挂号时首先要登录系统。这是最基本的两个输入事件。3.3 刻画系统输出

对于系统输出我们要考虑系统输出的形式，比如消息显示，对话框等形式。不如用户在登录系统是输入的用户名和密码不匹配的时候要给出对应的提示信息，比如用户名未注册或密码不对等。在提交预约挂号申请后系统也应给出预约成功与否的提示。3.4输出需求分析

对于输出需求要根据用户的输入给出对应的输出。比如用户输入查询请求，那么系统应该能够给出详细的信息。系统只给出对应的输出还不够，同时要考虑输出的信息是否合适。比如用户要查询眼科医生的资料，系统的输出就应该只是眼科医生的信息，而没有必要把所有医生的信息都输出。3.5 社会影响分析

在进行社会影响分析时要同时考虑到积极和消极两个方面的问题。系统是否可以提高效率，减少人员的工作量。同时也要考虑过多的自动化是否会削弱人对整个系统的意识，导致人对意外处理的能力降低，比如系统临时出现问题，是否有一套应急措施使医院日常工作能够正常的进行。

4、需求说明文档

基于之前构建的模型，并参照IEEE 830-1998标准模板，撰写的系统需求说明文档如下。

4.1 引言

引言部分将对本文档的编写目的、系统的开发目的、名词定义以及参考资料进行说明，并对文档的后续内容进行概述。4.1.1 编写目的

网上预约挂号系统是基于Web开发技术完成的网站。为了更好的设计并实现这一系统，对系统进行需求建模和分析是十分必要的。因此，基于之前构建的各类模型，撰写系统的需求说明文档，并将其作为后续项目设计、项目开发和项目测试的指导。

本文档连同之前构建的模型，可用来与客户进一步明确需求，同时可供项目经理、设计人员、开发人员参考。4.1.2 系统目的

许多医院存在高峰期挂号排队时间长，就诊等待时间长，倒号现象频发的问题。因此，构建一个网上预约挂号系统，通过推荐患者使用该系统进行出诊信息查询和医生预约，可以缓解就诊压力、节约患者的时间，并且可以在一定程度上保证预约者和就诊者一致，有利于提高医院的服务质量。4.1.3 名词定义  患者预约系统

网上预约挂号系统的子系统，主要用于为患者提供预约挂号、信息查询等功能。 医生工作查询系统

网上预约挂号系统的子系统，主要用于为医生提供各时段预约患者的信息。 医务管理系统

网上预约挂号系统的子系统，主要用于为管理员提供出诊信息修改、预约挂号调整等功能。 账号控制系统

网上预约挂号系统的子系统，主要用于用户账号的注册及登录控制。 安全保障系统

网上预约挂号系统的子系统，主要用于保障系统的程序、网络及数据库安全。4.1.4 参考资料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吴双兵,刘伟.网上预约挂号系统设计与实现[J].医学信息学杂志, 2015, 36(1):36-39.4.1.5 文档概述

需求说明文档主要分为三个部分。本节属于引言部分，主要用于对文档本身进行定义和描述。文档的第二部分为系统的整体描述，包括系统的预期目标、限制条件以及用户的需求、特征。文档的第三部分是需求说明，包含对系统需求的明确定义。

4.2 整体描述

本节将对系统预期、用户需求、用户特征、条件与限制、假定与依赖以及需求分配进行说明。

4.2.1 系统预期

为了方便用户在不需安装任何软件的情况下使用系统，本系统整体采用B/S结构，用户可以通过浏览器对其进行访问。4.2.2 用户需求

参照之前完成的目标模型，对用户的需求进行整理和定义。由于系统整体较为复杂，因此本小节只包含已构建目标模型的功能性需求和非功能性需求。 功能性需求

1.患者进行预约选择

为了实现患者进行预约选择的目标，系统应完成的需求如下。（1）系统拥有患者预约页面以及预约按钮：

系统的预约页面可以显示未来1至3天的出诊医生及其所有可被预约的出诊时段。其中，尚未被预约的时段拥有预约按钮；已被预约的时段无法被其他患者预约，因此无预约按钮。（2）系统接收到预约请求：

当患者点击预约按钮，系统可以接收到预约请求。（3）患者被告知预约选择结果：

系统可以对患者是否预约成功进行判定，如果成功则跳转至信息确认页面，否则弹出对话框给予患者相应提示。2.患者确认预约信息

为了实现患者确认预约信息的目标，系统应完成的需求如下。（1）系统拥有预约信息确认页面以及预约提交按钮：

系统的预约信息确认页面会显示预约的医生和时段，患者的个人信息，以及预约提交按钮，患者可以在提交预约前核对这些信息。（2）系统接收到预约提交请求：

当患者点击提交按钮，系统可以接收到预约提交请求。（3）患者被告知预约提交结果：

系统可以对预约是否提交成功进行判定，并弹出对话框给予患者相应提示。 非功能性需求 1.安全的系统

为了保证预约挂号系统的安全性，系统应完成的需求如下。（1）用户程序安全：

系统应明确区分不同类别用户的权限。并且在用户登录时，输入的密码不可见、不可复制。（2）系统网络安全：

系统应采取安全的网络传输协议，网络数据在被传输前应进行加密。（3）数据库安全：

数据库中存储的数据应具备完整性，且密码应在加密后被存储到数据库中。此外，数据库中的数据应该可以被备份和恢复。2.低成本的系统 为了保证预约挂号系统的低成本，系统应完成的需求如下。（1）系统开发成本低：

开发团队应具备合理的项目管理，且在开发前应尽可能明确系统的需求。（2）系统运营成本低：

系统在运行过程中，应该尽可能少的占用资源。（3）系统维护成本低：

系统应该健壮可靠，出现问题后应该易于修复，且系统的功能应该易于扩展。考虑到系统健壮可靠与系统开发成本低存在一定的冲突，因此需要进行一定的权衡。4.2.3 用户特征

本系统的用户包含患者、医生以及管理员三类，其特征如下。 患者

个体间在年龄、计算机使用能力等方面存在较大差异。 医生

普遍具备较高的学历，在医疗方面具备专业知识，有一定的计算机使用能力。 管理员

负责对出诊信息进行管理，是医院工作的安排者，具备较强的计算机使用能力。4.2.4 条件与限制

为了保证系统的可移植性和可扩展性，本系统应使用Java语言进行开发。4.2.5 假定与依赖

本系统假定提供的大、中、小三种字体大小可以满足不同患者的需求，并且患者可以在系统的引导和提示下正常使用系统。4.2.6 需求分配

由于文档中并未列出系统的全部需求，因此无法对所有需求进行优先级排序。但已经列出的均为系统较为核心的功能性需求和非功能性需求，应具有高优先级。

4.3 需求说明

需求说明部分将参照之前完成的模型，对系统结构、对象模型以及操作过程模型进行详细描述。

4.3.1 系统结构

本部分将主要参照图 3-1所示的责任模型，根据主体对需求进行划分。考虑到系统较为复杂，因此只列出主体“患者预约系统”的相关需求。 患者预约系统

系统拥有患者预约页面以及预约按钮。

系统接收到预约请求。

患者被告知预约选择结果。

系统拥有预约信息确认页面及预约提交按钮。

系统接收到预约提交请求。

患者被告知预约提交的结果。4.3.2 对象模型

本部分将主要对图 4-1所示的对象模型的结构进行解释。

网上预约挂号系统可以被详细划分为患者预约系统、医生工作查询系统、医务管理系统、账号控制系统、安全保障系统等五个子系统。患者预约系统、医生工作查询系统、医务管理系统的使用者分别为患者、医生和管理员，这些用户通过系统提供的页面与系统进行交互。

对象模型中所涉及的名词在4.1.3小节中有具体解释。4.3.3 操作过程模型

本部分将主要对图 5-1，图 5-3和图 5-4所示的操作过程模型进行说明，并以表格的形式列出各操作过程的参与主体及对应需求。 患者进行预约选择

患者点击预约按钮后，患者预约系统会收到患者的预约请求，并触发预约验证操作，得到预约验证结果。接下来，患者预约系统会以得出的预约结果为基础，进行预约结果判定，进而执行页面跳转或消息框弹出操作。 患者确认预约信息

患者点击提交按钮后，患者预约系统会收到患者的预约提交请求，并触发预约提交操作。接下来，患者预约系统会根据提交结果弹出包含相应信息的提示框。

以上部分涉及到的操作过程及与之对应的主体、需求如下表所示。

以上部分涉及到的操作过程及与之对应的主体、需求如表 4-1所示。

操作 预约验证 参与主体

对应需求

患者预约系统 系统接收到预约请求，患者被告知预约选择结果

预约结果判定 患者预约系统 患者被告知预约选择结果 预约提交 患者预约系统 系统接收到预约提交请求，患者被告知预约提交结果