资源描述
【项目名称】立项说明书
1. 摘要
提示:用简练的语言说明本项目“是什么”,“什么用途”。根据经验,概念罗嗦含糊的项目很难被审核人员接受。所以项目定义一定要简练且清晰。
2. 项目介绍
2.1. 项目背景
提示:从内因、外因两方面阐述项目开发背景,重点说明“为什么”要开发本项目。
o 内因方面着重考虑:短期、长期发展战略。
o 外因方面着重考虑:市场需求及发展趋势。
o 时间
o 如果是合同项目,请说明项目的来源。
2.2. 项目主要功能和特色
提示:
o 给出项目的主要功能列表
o 说明本项目的特色
o 说明本项目如何满足用户的需求,以及用户带来什么好处。
2.2.1. 主要功能
功能清单
2.2.1.1.
2.2.2. 特色
系统核心功能及价值
2.3. 用户特色
列出本软件的最终用户特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使用频度。
2.4. 项目范围
o 说明本项目“适用的领域”和“不适用的领域”。
o 说明本项目“应当包含的内容”和“不包含的内容”。
2.5. 市场规模与发展趋势
o 分析市场发展历史与发展趋势,说明本项目处于市场什么发展阶段。
o 本项目和同类项目的价格分析
o 统计当前市场的总额、竞争对手所占的份额,分析本项目能占多少份额。
注意:引用数据应用写明数据来源,最好有直观的图表。如果市面上没有类似工具,本点可以不用写
2.6. 项目发展目标
说明本项目的短期目标和长期目标。目标必须清晰并且可以度量。
2.7. 市场运营计划
/*如果有涉及运营方式请填写运营计划,如活动*/
o 运营模式:线上运营/线下运营/联盟/其它渠道
o 运时间:时间计划
o 运营流程
o 推广方式
o 运营目标:预估运营效果
3. 系统分析
3.1. 可行性分析
3.1.1. 技术的可行性
技术可行性分析至少要考虑以下几方面因素:
(1)在给定的时间内能否实现需求说明中的功能。如果不能,要说明原因,并声明建议:是否可以通过增加资源满足客户需求。
(2)产品的质量如何?有些应用对实时性要求很高,如果软件运行慢如蜗牛,即使功能具备也毫无实用价值;有些应用对产品的正确性与精确性要求极高。
(3)产品的生产率如何?如果生产率低下,会逐渐丧失竞争力。在统计产品总的开发时间时,不能漏掉用于维护的时间。如果软件的质量不好,将会导致维护的代价很高,是得不偿失的事。
技术可行性分析可以简单地表述为:做得了吗?做得好吗?做得快吗?
3.1.2. 经济的可行性
(1)成本与收益(成效)的分析,这个最容易理解,如果成本高于收益(成效)则表明经济可行性欠佳。
(2)当遇到多种解决(开发)方案时,从短期与长远利益的分析出发,对各种方案给出明确答案。
3.1.2.1. 成本分析
方案
方案描述
成本
成本分析
成效
3.1.2.2. 成本/效益分析
方案
成本
效益
成本/效益分析
3.1.3. 资源的可行性
资源上的可行性包括人力资源和系统资源。人力资源,在当前人员结构下,可投入几个人月周期(需结合需求分析);系统资源,泛指当前可调配的其他资源。
3.2. 需求分析
3.2.1. 功能需求
阐述本项目面向的消费群体(客户)的特征,本项目要实现什么功能。本段落只要填写立项项目的概要需求即可,而非详细需求,需求内容的页数控制在两页内。
3.2.2. 系统需求
提示:非功能性需求(没有可不说明)
(1)精度:说明对该产品的输入、输出数据精度的要求;
(2)时间特性:响应时间、更新处理时间、数据的转换与传送时间等;
(3)灵活性:操作方式、运行环境、提供接口等;
(4)输入输出要求:解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等,类似数据字典;
(5)数据管理能力要求:说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算;
(6)故障处理要求:列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。如当故障发生时应通知谁。
(7)其他专门要求:如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
3.2.3. 安全需求
保证数据安全性,从多方面着手,包括系统管理、权限管理、角色管理。
(1)管理员要落实到个人,限制管理员个数;
(2)适时给出安全提示;
(3)操作员应具备基本的计算机维护常识
3.2.4. 用户界面需求
用户界面是人与计算机之间的媒介。用户界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式。
(1)对用户工作效率有显著影响的元素包括:输入输出方式、交互方式、功能分布。
(2)影响用户对系统友好性评价的元素则有:颜色、字体大小、界面布局等,这种划分不是绝对的,产品界面作为一个整体,其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度,甚至影响用户的工作效率,而使用户最终放弃使用系统。
可参照:可用性工程学、人机工程学、认知心理学、美学、色彩理论等方面。
3.2.5. 运行环境需求
(1)设备:列出运行该产品所需要的硬件设备;
(2)支持软件:列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等;
(3)接口:说明该产品同其他软件之间的接口、数据通信协议等;
(4)控制:说明控制该产品的运行的方法和控制信号,并说明这些控制信号的来源。
4. 文档说明
4.1. 读者对象
需求提出方、项目开发组成员、系统测试人员、项目管理员。可参照下面内容填写:
“需求提出方、项目开发组成员(需求分析员、主程、程序员、系统测试人员、项目管理员等、立项审核人等。”
4.2. 编写目的
经过需求方和开发方的共同评审确认后,作为实施的依据。可参照下面内容填写:
“经过需求方和开发方的共同评审确认并经立项确认通过后,作为项目实施及验收的依据。”
4.3. 参考文献
提示:列出本文档的所有参考文献(可以是非正式出版物),格式如下:
[标识符] 作者,文献名称,出版单位(或归属单位),日期
例如:
[AAA] 作者,《立项调查报告》,机构名称,日期
[BBB] 作者,《立项可行性分析报告》,机构名称,日期
4.4. 术语与缩写解释
缩写、术语
解 释
SPP
精简并行过程,Simplified Parallel Process
PIM
立项管理,Project Initialization Management
…
展开阅读全文