第一篇：软件项目开发需求报告
软件需求分析格式_如何写需求分析报告 软件需求说明书 1 引言
1.1 编写目的：阐明编写需求说明书的目的，指明读者对象。1.2 项目背景：应包括
● 项目的委托单位、开心单位和主管部门；
● 该软件系统与其他系统的关系。
1.3 定义：列出文档中所用到的专门术语的定义和缩写词的愿文。
1.4 参考资料：可包括
● 项目经核准的计划任务书、合同或上级机关的批文
● 文档所引用的资料、规范等
● 列出这些资料的、标题、编号、发表日期、出版单位或资料来源 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件与限制 3 数据描述 3.1 表态数据
3.2 动态数据：包括输入数据和输出数据。3.3 数据库描述：给出使用数据库的名称和类型。3.4 数据词典 3.5 数据采集 4 功能需求 4.1功能划分 4.2功能描述 5 性能需求 5.1 数据精确度
5.2 时间特性：如响应时间、更新处理时间、数据转换与传输时间、运行时间等。
5.3 适应性：在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。6 运行需求
6.1 用户界面：如屏幕格式、报表格式、菜单格式、输入输出时间等。6.2 硬件接口 6.3 软件接口 6.4 故障处理 7 其他需求
如可使用性、安全保密、可维护性、可移植性等。
需求分析的格式 需求分析要对目标系统提出完整的、准确的、清晰的和具体的要求。
1．综合需求： 项目 说明 备注
1）功能要求 描述软件用来做什么
能够进行度量衡的相互转换，如：长度公制之间的转换，公制和英制的转换等。能够添加或创建新的度量衡。能够按照用户自己的需要进行排序。能够作为其他软件的插件或辅助工具使用。能够知道度量衡所应用的范围，如：国家，行业等。
2）性能要求 软件能达到什么性能
数据的最大存储量，数据的转换要有连续性，软件对每项操作的响应时间，更新处理时间，数据转换和传送时间，软件的输入输出数据精度，软件失败和成功的定义。
3）运行要求
软件能正常运行在微软中文版WINDOWS系列的可以独立运行的安装包或可执行文件
开发软件的开发工具清单。是否需要外部存储器和数据通信接口。
4）升级要求
是否可以升级，是否可以进行扩充。是否容易进行维护。能够作为什么软件的插件或辅助工具使用。如何添加新的公式
5）对应关系
用户需求和软件功能的对应关系 说明每一个模块对应实现什么功能。
2．数据要求： 项目 说明 备注
1）数据输入
来源、准确性、取值范围、格式、非法值的处理、出错信息
2）数据输出 目的地、准确性、数值范围、格式、非法值的处理、出错信息
输出的数据可以修改，如：1米=100厘米=1000毫米，将100厘米改为90厘米时，相应的1米就自动改为0.9米，1000毫米变为900毫米。
3）数据存储 最大存储量
4）数据的安全性 访问的权限
5）数据备份 能否导入和导出
可以将输出的数据保存为文本格式
6）数据流图
在分析过程中得出的数据流图
7）数据筛选
能够将选择的几个度量单位进行汇总
8）主要算法
简要描述软件的主要算法
3．界面要求：请参照“界面样式图” 项目 说明 备注
1）软件名称 为软件起一个名字 可以发挥自己的想象力
2）功能模块
有几个功能模块，分别是什么
3）颜色
采用什么底色，窗口是什么颜色
4）字体
字型、大小，字间距，颜色
5）按钮
颜色、字型、大小、样式
4．软件描述：从用户的角度来描述软件，相当于一份初步的用户手册。项目 说明 备注
1）功能描述
能实现，不能实现什么需求 应用范围。什么人员可以使用
2）性能描述
最低配置，操作系统，需要安装什么辅助软件
3）操作步骤 如何使用软件 主要步骤和方法
4）用户责任
用户在操作过程中的注意事项 出现问题时如何解决 如何写需求分析报告
近来学校的一些科研项目又在申报了，一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下，写到这里。本文涉及到的是需求分析部分的书写，主要是根据国家标准文档中的要求来的。
在互联网公司或者一些敏捷开发的公司里，其实大家都是秉承着重开发，重讨论，而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档，而是在严格的文档流程中解脱出来，只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短，版本发布快等特点决定的。而在实际的兼职项目的时候，同学们就要注意了，最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析，虽然这份需求说明可能不是按照某些标准文档而来的，描述清楚每个功能达到的效果，而这个效果一定要让客户点头确认，而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中，是重视文档流程的，一部一部来。所以还是看情况来对待文档的深度和标准。
一、目录： 目录要用word的 “引用”—>”目录”，自动生成目录，一般都是要三级目录。通常这部分基本都不需要改结构，直接更新页码即可。
二、内容部分。国家标准软件需求说明书G856T-88下载 1引言 1.1编写目的
说明编写这份软件需求说明书的目的，指出预期的读者。（这部分说明需求分析报告的概况，例如：本X需求分析报告是为S系统而编写的。 S系统的两句话概述。 本X报告旨在使U1（需求者）明确S系统的要求和细节，给U2(开发人员)了解需求实现的难度和困难，最终提供给U3（审核人、管理者）讨论和审核，达到沟通效果）
1.2背景 说明：
a． 待开发的软件系统的名称； b． 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；
c． 该软件系统同其他系统或其他机构的基本的相互来往关系。
（这部分可以将a,b,c分为2部分，例子如下： 1.2.1项目概况
本需求分析报告所预期开发的软件系统是:S。S是（不是则无）SS系统的某一个功能子模块，S和S1、S2等系统之间的联系，以及概述其他系统的状态等等。1.2.2任务分配
a.任务提出者：xxx b.软件开发者：xx c.产品使用者：xx d.文档编写者：xx e.预期产品使用者：xx）1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
（这部分很简单，就是描述专业词汇，比如
1.XML(Extensible Markup Language)即可扩展标记语言,它与HTML一样,都是SGML(Standard Generalized Markup Language,标准通用标记语言)。2.Word2, 解释。。）
1.4参考资料
列出用得着的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文； b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2任务概述 2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|（本模块开发主要是为SS的整体服务，完成SS工作中的XX部分以及相关的工作。其涉及的范围就是，从下达A、B命令后，到给出C结果的过程。具体描述：B1，来完成B11功能；B2，来完成B22功能； 等等。本部分是（否）耦合在分词工具包其他部分中的，主要为嵌入方式和先后方式相互交互。图
图1.该系统的组成同其他各部分的联系和接口）
2.2用户的特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束
（例如：二次开发和系统调用人员：具有很高的专业知识水平，理解XX的运行机制。可以对开放代码进行阅读和分析，以完成其系统独特的需求，提供给这部分用户开放API手册和Debug版本的源代码即可；预期这部分用户会占本系统总用户量的多大部分。
xx使用者：具有一定的计算机操作能力和知识，了解xx领域的相关概念和用途。提供给这部分用户操作手册即可。预期这部分使用者主要是来简单的xx操作。
维护人员：具有较高的计算机专业水平，可以对常见的系统Bug进行追踪和分析，具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。等等）
2.3假定和约束
列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。（这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设，以使得你可以在什么样的情况和时间范围内完成工作。工期约束，经费约束，人员约束，地理约束，设备约束等几个方面列举说明。）3需求规定 3.1对功能的规定
用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。（例如： INPUT输入 PROCESS处理 OUTPUT输出 LOAD负载量
A 预处理,做怎样的动作，AA CC B BBBB Bb v C CCCC cc v
表
一、xx模块IPO表 对IPO表的简单文字描述。）
3.2对性能的规定 3.2.1精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。（例如：
Xx目标处理：1Byt–10M，包括左右边界值。yy精度范围：„.ZZ的精度：由于xx的特殊性，本系统均采用xx型来进行字符统计运算，概率部分以及其他比率部分精度精确到0.0x%。）
3.2.2时间特性要求
说明对于该软件的时间特性要求，如对： a． 响应时间； b． 更新处理时间；
c． 数据的转换和传送时间； d． 解题时间；等的要求。(这部分只要一一列举就可以：
由于xxx过程中，需要大量xxxx操作或怎样，故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求，如下： a． xx响应时间：xxms左右； b． yy更新处理时间：yy；
c． zz数据的转换和传送时间：zz； d． vv解题时间：vv。等等)3.2.3灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a． 操作方式上的变化； b． 运行环境的变化；
c． 同其他软件的接口的变化； d． 精度和有效时限的变化； e． 计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
（这部分按列举来即可，由于本模块第一目的是用于xxx，其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时，该软件对这些变化的适应能力。具体情况如下： f． 操作方式上的变化：采用集成运行制和独立运行制两种模式，集成运行制是把本模块嵌入到分词工具包的主框架中，提供给用户具有一定UI的可操作软件；独立运行制是可以独立运行于后台，并提供给各种程序调用的模式的工作方式，以增强其生命力。
g． 运行环境的变化：主采用Windows平台的编译版本运行和调试，在时间允许的情况下，同步开发支持SUSE Linux的服务器版本。；
h． 同其他软件的接口的变化：在尽量保证接口不出现变动的情况下，允许接口的重载和再定义。但接口的命名规则是统一的；
i． 精度和有效时限的变化：精度在必须调整的条件下，可以上下浮动10个百分点；有效时限则依据现实的测试情况允许稍大范围的变化。
j． 计划的变化或改进：工作时间安排会存在必然的浮动，这部分要协同分词工具包课题设计组其他成员一同来进行商定，前期的计划可以稍微有些变动，后期的安排尽量按照计划执行。等等）3.3输人输出要求
解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。
（这部分可以把输入输出分为 3.3.1输入要求和3.3.2输出要求，如下给出一个单元的例子。XXX输出
数据名称：XXX输出数据 实际含义：用于XX,表示XXXX 数据类型：Character(字符串)数据格式：XX 数据约束：由于xxx,，大小在xx以内）
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。（根据实际系统要求列举即可 Name名称 Number数量 Size大小 Increase增长
词典xx xx xxxx 并行执行，其大小依据实际xx大文本而增长）
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
（包括软件压力，内存不足，硬件损坏等，这部分可以根据百度到其常见故障。）3.6其他专门要求
如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
（例如安全保密性：密钥更换等； 预期扩展：扩展兼容等；OS更换：Slackware转SUSE等）
4运行环境规定 4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：
a． 处理器型号及内存容量；
b． 外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；
c． 输入及输出设备的型号和数量，联机或脱机； d． 数据通信设备的型号和数量； e． 功能键及其他专用硬件（列举说明即可）4.2支持软件
列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。（操作系统和版本：xxxx 支撑环境和版本：xxxx 备用IDE环境和版本：xxxx 与该软件有关的软件组件：xxxx 后续可能扩展环境：xxxx）4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。(例如：
a．用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式，分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件，以xxxx方式调用函数。如下图2所示。图2.软件接口调用图 b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx)4.4控制
说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。(例如：
下面通过图表的形式，将本模块以及涉及到本模块的软件模块的运行方法、控制信号，以及这些控制信号的来源，其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块，具体情况如下： 图3.控制流程图
图3的具体说明情况如下表所示： Name模块名称 Method运行方式 Signal控制信号 Forward控制去向
主程序模块 运行框架 用户调用或运行 1.调用xx模块 2.调用xx方法 3.调用标准输出模块
xxx模块 xxx xxx调用 Xxx模块)
第二篇：软件项目需求建议书
篇一：软件需求建议书
医院门诊管理系统需求建议书
2022年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）承约商必须最迟在2022年5月1日以前提供给本院两份建议书备份。
（8）本院希望在2022年6月1日前选中一家承约商。这个工程需要完成的
期限是十二个月，从2022年7月1日至2022年7月1日，所有交付物必须不迟于2022年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%)。为了在要求的项目完成日期内或在此日期之前完成项目，承约商应提出进度计划的详细而全面的连续说明。
篇二：软件系统项目建议书完全版
****系统项目建议书
2022年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．要求
开发商应根据国家有关标准，提供开发计划和实施方案。篇五：软件项目管理项目建议书
湖南文理学院实验报告
时间： 2022 年 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 获取需求：
作为需求方也就是甲方，通过语言描述或文档的方式将需求（系统需要提供的功能）提交给开发人员（需求分析人员）。
获得需求的方式可以有多种多样：电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书)，其实这些方法都是GET方式，我们可以通过以下两类技术手段来达到：GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求，而这两个过程都是必须交互进行的，一般我们可以筛选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程师，长期在客户那里工作。2 需求分析人员
（1）根据客户提供的文档或语言描述，将需求按功能划分，以用例图的方式表达系统提供的功能模块及功能模块之间的关系，完成用例图后与客户确认大的功能模块，并对每个功能模块做进一步的沟通详细记录用户所提供的关键性的描述，此过程需要系统分析人员对客户进行引导。
（2）对每个功能模块进行详细分析与描述，具体信息包括：用户角色、功能说描述、IPO的方式进行描述（即输入项、输出项、处理）、要提供必要的功能说明，如果使文档更加直观，更容易让客户理解，可以用UI的方式表达输入输出，配合必要的描述，这样对于客户更加容易理解，需要与客户进行大量的沟通确认。
（3）编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。
（4）关于文档具体表述的格式与形式，要根据所要表达的功能来确定，最重要的是把事情描述清楚,这事最终的目的；
(5)需求文档确定后，设计人员根据这份需求文档进行系统的设计工作了。
第四篇：软件项目开发可行性分析报告
网络硬盘文件资源管理系统开发与设计可行性研究报告
1、引言
1.1编写目的随着网络技术的日益普及和信息化建设的重视，网络硬盘作为一种新型安全的网络存储系统，主要适用于个人文件存储，可以用作个人的一个网络Ｕ盘，网络硬盘是一块专属的存储空间，用户通过上网登录网站的方式，可方便上传、下载文件。只要能上网，就可以用网络硬盘登录到服务器上进行个人文件的上传、删除及文件目录的新建、修改、共享等操作，随时随地存储自已的个人文件。而且不用担心文件丢失的状况，安全方便。
1.2项目背景
1.2.1 项目名称：网络硬盘文件资源管理系统
1.2.2 用户:网络存储用户
1.2.3 说明：很多用户把重要文件存储在自己的手机或电脑的硬盘上，结果因为手机、电脑的丢失导致这些重要文件也都丢失了，在很多时候，文件的价值往往比手机和电脑本身还要高。而且网络硬盘可以用作个人的一个网络Ｕ盘，无论在家里，办公室里或旅馆里，只要能上网，可以通过网络硬盘调用自己的文件或记事本；网络硬盘是一块专属的存储空间，用户通过上网登录网站的方式，可方便上传、下载文件，而独特的外链功能更突破了传统存储的概念。只要能上网，就可以用网络硬盘登录到服务器上进行个人文件的上传、下载、删除及文件目录的新建、修改、删除、文件预览等操作，随时随地存储自已的个人文件。
2、可行性研究的前提
2.1要求
2.1.1 功能要求
用户能登陆注册，用户文件空间界面必须以文件目录的形式展示文件列表，目录结构清晰。能实现文件批量选择上传，操作必须要方便快捷简单，常用格式文件必须要能打开预览。为方便操作，文件夹能打包压缩下载。用户能对文件实现批量操作。能设置外链文件。
2.1.2 性能要求
为了满足储户的要求，系统必须要有高的运作速度，用户的操作事件，系统必须能快速及时作出响应，迅速处理各项数据、信息。所以要求很高的信息量速度和大的主存容量；由于要存贮大量文件和数据，也还要有足够大的磁盘容量；安全性也是系统最重要的性能需求之一，文件管理系统系统必须有可靠的安全措施，以保证储户的存储安全。
2.1.3完成期限
初步确定开发期为2个月，系统计划于2022年低正式完成2.2目标
网络硬盘是一种类似U盘的一种文件存储系统，所以，第一、系统必须要稳定、安全，保证上传的文件不丢失，能正确下载。第二、文件浏览界面必须要友好，能提供清晰的文件目录列表。第三、必须要有方便快捷的操作，保证良好的用户体验。
2.3可行性研究方法
采用归纳方法：通过对现在流行、大型的网络硬盘系统详细研究与比较来获取自己系统需求分析所需资料，在对这些系统的设计、制造和运行状况进行分析研究的基础上,根据所设计的系统的功能要求进行多次选择,然后对少数几个同类系统作出相应修正，最后得出一个理想的系统。
3、对现有系统的分析
当前大多数网盘都还没有实现对文件的预览功能，有部分实现了对图片的预览功能，但实现对文档、音乐、视频预览的确很少。给予用户的体验不足，达不到用户所期待的功能。基于这种原因，我所实现的系统能对图片、文档、音乐、视频的预览以及文件夹的压缩下载。
4、技术可行性分析
网络硬盘文件系统的实现技术有多种,可以采用传统的客户机/服务器型的B/S型架构,即文件内容放在远程的服务器上,用户通过在其他计算机上登陆服务器。进入网络硬盘系统。由于受条件所限制，数据库服务器端采用大型数据库系统,这有利于缩短大批量数据的吞吐时间,使整个系统管理规范化,数据的完整性、安全性得到保障.应用服务器端采用中间件计算模式(IBMWebSphereApplicationServer),分模块层次结构,多模块分立,允许系统的分布处理,以提高系统的工作效率。所使用的技术主要是S2SH（struts2、hibernate、spring）以及javascript、jquery、css、html，这些技术都已经开设过课程，我也已经掌握了。开发系统的计算机硬件已经非常普及，所以完全没有问题；现在的计算机各方面的技术都非常成熟，相对来说开发此系统的技术也要求比较简单，因此在技术方面是可行的。
5、经济可行性分析
可以通过推广发布广告、个人付费、流量收费来维持网盘的运营，并通过网盘服务带来大量用户到其他关联产业。经济上市是没什么问题的。
6、社会因素可行性分析
6.1法律因素
全部软件购买正版；机器设置通过正当途径购得；所有软件都用正版，技术资料都由提出方保管，数据信息均可保证合法来源。所以，在法律方面是可行的。
6.2用户使用可行性
开发的系统操作要非常简单，以便适合大人小孩老人各类人们都可以很方便操作使用。
第五篇：软件项目开发风险
1.计划编制风险：
1.1 计划、资源和产品定义完全靠客户或者上层领导的口头命令，并且不完全一致；
1.2 计划是优化的，但是是不现实的；
1.3 计划忽略了必要的任务；
1.4 计划基于使用特定的小组成员，而那个小组成员基本上指望不上；
1.5 在限定时间内无法建立成已定规模的产品；
1.6 产品规模比估计的大；
1.7 进度已经拖延的项目在重新评估时过于优化和忽略项目历史；
1.8 过度的进度压力造成生产率下降；
1.9 目标日期提前，没有相应调整产品范围和可用资源；
1.10 一个任务的拖延导致相关任务的连锁反应；
1.11 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多；组织和管理：
2.1 项目缺乏一个有凝聚力的最高领导人；
2.2 由于前期乏力，项目长时间搁置；
2.3 解雇和削减开支导致项目小组能力下降；
2.4 仅由管理层或市场人员来进行技术决策，导致计划进度延长；
2.5 低效的项目组结构降低生产率；
2.6 管理层审查/决策的周期比预期时间长；
2.7 预算削减打乱项目计划；
2.8 管理层做出了打击项目积极性的决定；
2.9 非技术的第三方工作比预期延长（预算批准、设备采购批准……）
2.10 计划性太差，无法适应期望的开发速度；
2.11 项目计划由于压力而放弃，导致开发混乱，低效；
2.12 管理层强调英雄主义，而忽略客观确切的状态报告，降低发现和改正问题的能力； 3 开发环境：
3.1 设施没有及时到位；
3.2 设施到位，但是不配套；
3.3 设施拥挤，杂乱或者破损；
3.4 开发工具没有及时到位；
3.5 开发工具不如期望那样有效，开发人员需要时间创建工作环境或者切换新的工具；
3.6 开发工具的选择不是基于技术需求，不能提供计划所需要的性能；
3.7 新开发工具的学习比预期的长，内容多；最终用户：
4.1 最终用户坚持新的需求；
4.2 最终用户对于最后交付产品不满意，要求重新设计和重做；
4.3 最终用户不买进项目产品，无法提供后续支持；
4.4 最终用户的意见没有被采纳，造成产品最终无法满足用户期望，而必须重做； 5 客户：
5.1 客户坚持新的需求；
5.2 客户对规划、原型和规格的审核/决策周期比预期要长；；
5.3 客户没有或不能参加规划、原型、规格阶段的评审，导致需求不稳定和耗时的变更；
5.4 客户坚持技术决策导致进度计划延长；
5.5 客户对于开发进度管理过细，导致实际进度变慢；
5.6 客户提供的组件无法和开发产品匹配，导致额外的设计和集成工作；
5.7 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户管理管理工作；
5.8 客户要求的支持工具和环境不兼容，性能差或者功能不完善，导致生产率下降；
5.9 客户不接受交付的软件，尽管已经满足了所有的规格；
5.10 客户期望的开发速度是开发人员无法达到的；承包商：
6.1 承包商没有按承诺交付组件；
6.2 承包商递交的组件质量低下无法接收，必须花费时间改进质量；
6.3 承包商没有买进项目开发所需要的公举，进而无法提供需要的性能水平；需求：
7.1 需求已经成为项目的基准，但是变化还在继续；
7.2 需求定义欠佳，而进一步的定义会扩展项目范畴；
7.3 添加额外的需求；
7.4 产品定义含糊的部分比预期需要更多时间；产品：
8.1 错误发生几率高的模块需要比预期更多的测试，设计和实现工作；
8.2 校正质量低下不可接受的产品，需要比预期更多的测试，设计和实现工作；
8.3 在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期；
8.4 由于软件功能的错误，需要重新设计和实现；
8.5 开发额外不需要的功能，延长了计划进度；
8.6 要满足产品规模和进度要求，需要比预期更多的事件，包括重新设计和实现工作；
8.7 严格要求与现有系统兼容，需要进行比预期更多的事件进行测试，设计和实现工作；
8.8 要求在不同操作系统下运行将花费比预期更长的时间；
8.9 在不熟悉或没有经验的软件环境中运行产生没有预料的问题；
8.10 在不熟悉或者没有经验的硬件环境中运行产生没有预料的问题；
8.11 开发一种对组织全新的模块将比预期花费更长的时间；
8.12 依赖于正在开发中的技术将延长计划进度；外部环境：
9.1 产品依赖于政府规章，而规章的改变是不可避免的；
9.2 产品依赖于草拟中的技术标准，而最后的标准是不可预期的；人员：
10.1 招聘人员所花费时间比预期长；
10.2 做为先决条件的任务不能万丞，比如培训，其他项目的万丞，工作许可证； 10.3 开发人员和管理层关系不佳导致决策缓慢，影响全局；
10.4 项目组乘员没有全身心投入项目，进而无法达到需要的产品性能水平；
10.5 缺乏激励机制，士气低下，降低了生产能力；
10.6 缺乏必要的规范，增加了工作失误和重复工作；
10.7 某些人需要更多时间适应不熟悉的软件工具和环境；
10.8 某些人需要更多时间适应不熟悉的硬件工具和环境；
10.9 某些人需要更多时间适应不熟悉的编程语言；
10.10 项目结束前，合同制人员离开团队；
10.11 项目结束前，雇员辞职；
10.12 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；
10.13 项目组成员不能有效地一起工作；
10.14 由于项目组成员的冲突，导致沟通不畅，设计欠佳，接口错误和额外的重复工作； 10.15 有问题的成员没有调离项目组，损害了项目组其他成员的积极性；
10.16 项目组的最佳人员没有加入项目组；
10.17 项目组的最佳人员已经加入项目组，但是因为政治或其他原因没有合理使用； 10.18 关键人员只能兼职参与；
10.19 项目人员不足；
10.20 人员工作的进展比预期的慢；
10.21 任务的分配合人员技能不匹配；
10.22 项目管理人员的怠工导致计划和进度失控；
10.23 技术人员怠工导致工作遗漏或质量低下，工作需要重做；设计和实现：
11.1 设计过于简单，无法确定主要事件，并导致重新设计和实现；
11.2 设计过于复杂，导致一些不必要工作，并影响效率；
11.3 设计质量低下，导致重复设计和实现；
11.4 采用不熟悉的方法，导致额外的培训时间，并重犯以前的错误；
11.5 产品采用低级语言来实现，导致生产率比预期低；
11.6 一些必要的功能无法是用现有的代码和库实现，开发人员必需使用新的库或者自行开发所需要的功能；
11.7 代码和库质量低下，导致需要额外的测试，错误修正或重做；
11.8 过高估计增强型工具对项目进度的节省量；
11.9 分别开发的模块无法有效集成，需要重新设计或者重做；过程
12.1 大量纸面工作导致进展比预期慢；
12.2 进度跟踪不准确，导致无法预知项目是否已经落后计划进度；
12.3 前期的质量保证行为不真实，导致后期的重复工作；
12.4 质量跟踪不准确，导致无法得知影响进度的质量问题；
