03客户名称项目名称需求规格说明书.docx
- 文档编号:30665145
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:12
- 大小:20.32KB
03客户名称项目名称需求规格说明书.docx
《03客户名称项目名称需求规格说明书.docx》由会员分享,可在线阅读,更多相关《03客户名称项目名称需求规格说明书.docx(12页珍藏版)》请在冰豆网上搜索。
03客户名称项目名称需求规格说明书
XXX客户名称
XXXX综合信息系统项目
需求规格说明书
制订
制订日期
批准
批准日期
执行日期
终止日期
版本
页数
修订历史
版本号
更新日期
修订作者
主要修订摘要
目录
1概述5
1.1目的5
1.2背景5
1.3参考资料5
1.4术语和缩略语5
2任务概述5
2.1目标5
2.2项目产品体系结构图5
2.3项目产品功能描述6
2.4系统特点6
3约束条件6
3.1用户情况6
3.2运行环境6
3.3硬件环境6
3.4软件环境6
3.5限制条件7
3.6假设和依赖7
4用户原系统情况7
4.1运行环境7
4.2体系结构7
4.3业务处理方式7
4.4系统特点7
5业务流程8
6功能需求8
6.1功能需求1(以实际的需求名代替)8
6.1.1简要描述8
6.1.2事件流程8
6.1.2.1基本流程8
6.1.2.2异常流程8
6.1.2.3特殊需求8
6.1.3前置条件8
6.1.4后置条件8
6.2功能需求2(以实际的需求名代替)8
7数据描述8
8非功能需求9
8.1适用性需求9
8.2可靠性需求9
8.3安全性需求9
8.4性能需求9
8.5可支持性需求10
9辅助部分10
9.1未确定问题10
9.2需求的优先级10
9.3开发成本估算10
9.4风险分析11
10遵循的法律法规11
1概述
1.1目的
说明编写这份报告的目的,指出预期的读者。
例如:
本《客户名称项目名称需求规格说明书》(以下简称<需求规格说明书>)是客户名称与我公司就项目名称进行项目范围的约定文档。
本<需求规格说明书>是双方进行项目名称推进的依据,对项目交付内容进行约定,同时是制定项目进度计划的依据,是我公司进行项目开发的依据。
本<需求规格说明书>的读者包括但不限于客户名称项目经理、我公司本项目经理、需求分析师、总体架构师、系统工程师、测试工程师、开发工程师、部署工程师。
本文档具有保密性要求,双方遵守保密约定,文档的保密期限不随项目终结而结束。
双方的文档阅读者不可随意发放本文档。
1.2背景
指出待开发的软件系统的名称;行业情况;本项目的提出背景、任务提出者、开发者、用户;该软件系统同其他系统的相互关系。
例如:
本项目交付系统名称为“电子采购平台”。
华电集团是中央五大发电集团之一,每年的采购额度在43亿元人民币左右。
目前集团各下属电厂的采购由区域公司负责,采购的方式和手段都相对薄弱,为有效加强集团管控、降低采购成本、提升采购人员的工作效率、提高管理能力,采购的信息化成为现阶段集团信息化必然过程。
本项目的提出者为华电招标公司。
由华电招标公司是本项目的直接管理者和执行者。
本项目系统与集团下属电厂的物资系统有数据交互接口,需要定时进行数据交互。
1.3参考资料
列出编写本报告时参考的文件(如经批准的计划或合同、上级机关的批文等)、资料、技术标准,以及他们的作者、标题、编号、发布日期和出版单位。
编号
资料名称
简介
作者
日期
出版单位
列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的网址。
网点
简介
1.4术语和缩略语
列出本报告中用到的专门术语、缩略语的定义,对于重要的或是有特殊意义的名词进行解释。
例如:
竞价采购:
询价采购:
招标采购:
直接采购:
协议采购:
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围。
解释被开发软件与其他有关软件之间的关系。
例如:
本项目系统的应用目标是将所有集团及下属企业的采购统一管理起来,使各级采购人员可以开展采购业务;各级领导者可以在系统中采购业务审批..
本项目系统的使用范围为各级单位的物资采购部门,业务范围只涉及到采购业务,目前招标业务部分在系统中进行,评标过程在系统外实现。
2.2项目产品体系结构图
说明本项目产品与其它产品的关系,可以用图表的形式。
比如,本项目产品是否是一个大的产品的组成部分,是否要替换已有的产品,或者是一个独立的产品。
如果与其它产品有关系,它们之间的关系要在此描述。
2.3项目产品功能描述
说明项目产品必须具备的主要功能(仅作简单介绍)。
如果使用了建模技术,用高层的数据流图或用例图(UseCaseDiagram)来描述会更加有效。
2.3.1功能一
2.3.2情况说明
2.4系统特点
如果是产品开发,应列出本软件的特点,与老版本软件(如果有的话)的不同之处,与市场上同类软件(如果有的话)的比较。
如果是针对合同开发,则应列出本软件的最终特点。
3约束条件
3.1用户情况
介绍本项目的用户(或潜在用户)的情况,包括:
1.用户的技术水平;
2.最终使用部门、技术支持部门、参与测试验收的部门;
3.2运行环境
说明项目产品将在什么样的环境下操作,包括硬件平台、操作系统及版本、必须安装的软件部件和应用软件等。
3.3硬件环境
列出满足系统需求所必须的最低硬件配置、推荐硬件配置(如主机、显示器、存储设备、外部设备等)以及其它特殊设备。
或列出用户期望或现有的设备环境。
以及与其他系统的硬件接口。
3.4软件环境
列出满足系统需求或用户期望或现有的操作系统、网络软件、数据库系统、中间件以及其它特殊软件要求。
以及与其他系统的软件接口。
3.5限制条件
描述项目产品可能存在的限制条件以及与其它受影响的组和个人的约定,包括硬件条件、软件限制、交付产品、人力资源、交付日期、里程碑等。
举例:
项目产品必须在IBMPC或100%兼容的计算机上运行,计算机最低内存64M、最小硬盘空闲空间10G。
操作系统是WIN2000及更高版本。
软件源代码必须用C/C++编写。
3.6假设和依赖
列出所有会影响项目需求实现的假设因素(相对于已知的事实而言)。
例如,本项目产品计划要使用某些第三方软件产品或商业软件产品,虽然目前还未得到这些软件,但我们可以假设这些软件一定能够得到。
如果这些假设不正确、或发生改变,会影响项目的开发,因此,这些假设往往又是一种风险。
如果项目的开发或项目产品的使用要依靠其它外部因素,比如与其它产品共用的软件包、准备重用的软件构件等,也要在此说明。
4用户原系统情况
如果用户存在原有系统,介绍用户原来使用系统的主要情况,包括主要的不足。
如果用户不存在或不关心原有系统,本章节可省略。
4.1运行环境
用户存在原有系统的运行环境。
4.2体系结构
用户存在原有系统的体系结构。
4.3业务处理方式
用户存在原有系统的业务处理方式。
4.4系统特点
用户存在原有系统的特点。
5业务流程
描述系统实现的业务流程,包括角色、业务处理过程。
用powerdesigner做业务流程图
6功能需求
6.1报销管理(以实际的需求名代替)
6.1.1简要描述
简明描述该需求点的作用和目的。
谁使用这个功能
业务流程
组织机构
1、部门划分
2、角色岗位划分
3、人员权限
业务流程
1、业务流程
2、流程环节描述
业务表单
1、字段
2、字段内容、类型
3、展现要求
6.1.2事件流程
描述参与者的操作和系统的响应,重点指明需要做什么事情,而不是如何完成这些事情。
6.1.2.1基本流程
描述正常情况下的处理流程。
6.1.2.2异常流程
描述异常情况下的处理流程
6.1.2.3特殊需求
描述用户要求的不符合流程的要求。
6.1.3前置条件
描述触发该事务的必要条件。
6.1.4后置条件
描述该事务完成时,必需满足的条件。
.
6.2功能需求2(以实际的需求名代替)
按照需求1的格式依次描述,直到所有的需求。
7数据描述
描述系统输入、输出涉及的数据情况说明,如外部数据接口、界面展示或打印的数据、表项等。
8非功能需求
8.1适用性需求
描述系统被预想的不同级别用户(如文盲用户、初学者、普通用户、高级用户等)的学习和可操作能力。
建议从以下方面(不限于)进行描述:
●指明为了使用户能够完成简单任务以及完成普通日常工作所需要的培训时间;
●指明典型终端用户可能的典型任务的可度量时间;
●比较新系统与目前用户团体熟悉的或正在使用的系统的适用性;
●指明是否制作在线帮助系统、向导、工具说明、用户手册以及其它形式的文档和帮助,以及所需特征;
●人机界面开发的要求或规范。
8.2可靠性需求
描述用户能够接受的或期望系统运转程度,建议从以下几个方面(不限于)阐述:
●可用性:
如5×8,7×24;
●平均修复时间;
●准确性;
●最大错误或缺陷率(如:
错误数/千行代码);
●错误分类原则;
●故障处理原则。
8.3安全性需求
描述客户要求的或者应该满足的安全性。
8.4性能需求
性能需求通常包括以下几类(不限于):
●事务的响应时间或效率:
平均值、最大值;
●吞吐量:
每秒事务数;
●容量:
系统可容纳的客户总数或事务总数;
●数据精度;
●容错能力;
●可恢复能力;
●退化模式:
当系统被降级时,可接受的运转模式。
8.5可支持性需求
可支持性是指为了升级或修复,软件的被修改能力。
即对系统设计的灵活性和拓展性的要求。
9辅助部分
9.1未确定问题
说明目前尚未确定的问题及处理的计划。
9.2需求的优先级
将所有的功能需求或用例(如果需求分析结果是使用用例),按高、中、低的优先级分类。
列出章节号即可,例如6.2需求2(以实际的需求名代替)
功能需求/使用用例
优先级
高/中/低
对高、中、低的解释如下:
优先级
解释
高
关键的功能,必须在本次项目开发中实现。
中
增强性功能,可以在下一个项目版本中实现。
低
功能或性能的提高,属于美化性质的功能,如果有时间,可以实现。
9.3开发成本估算
以列表的方式估算出各功能需求所需的开发人时和费用。
功能需求/用例
工时
费用
9.4风险分析
根据需求,分析风险。
包括,需求可实现性、需求变动、时间压力、技术复杂度、人力资源不足等。
功能需求/用例
风险
风险级别
高/中/低
10遵循的法律法规
变更记录
注:
对该文件内容增加、删除或修改均需填写此变更记录,详细记载变更信息,以实现追溯。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 03 客户 名称 项目 需求 规格 说明书
![提示](https://static.bdocx.com/images/bang_tan.gif)