文档介绍：[ 业务需求项目名称]
业务需求说明书
文件编号:
业务环节:
需求版本:
文件名称:
编写人:
编写日期:
处室负责人:
审核日期:
分管局长:
批准日期:
青岛地税业务需求组
修订记录
修订人
修订日期
修订内容
目录
1. 前言 4
. 编写目的 4
. 范围 4
. 定义、缩写词、略语 4
. 参考资料 4
2. 项目概述 4
. 功能描述 4
. 用户特点 5
. 约束 5
3. 功能需求 5
. 边界范围 5
. 业务需求内容 6
. < 功能需求1 > 6
. 功能概述 6
. 概要流程图 6
. 输入信息 6
. 业务前提 6
. 操作岗位 6
. 业务流程及处理规则 6
. 相关环节处理说明 7
. 特殊操作要求 7
. 输出信息 7
. 查询及统计要求 7
. < 功能需求X > 7
. 查询及统计要求 7
4. 非功能需求 8
. 性能需求 8
. 设计约束 8
. 其他标准的约束 8
. 环境的限制 8
. 属性 8
. 可用性 8
. 安全性 8
. 可维护性 9
. 灵活性 9
. 故障处理 9
. 外部接口需求 9
. 用户接口 9
. 硬件接口 9
. 软件接口 9
. 通信接口 9
. 其他需求 10
. 数据 10
. 操作 10
前言
编写目的
[ 说明编写这份软件需求的目的,指出预期的读者]
范围
[ 待开发软件系统的名称;说明该需求的提出者(市局业务处室或基层局);说明该软件将干什么,如果需要的话,还要说明该软件不干什么。]
定义、缩写词、略语
[ 本条中必须提供全部需求的术语、缩写词及略语的定义,以便对需求进行适当的解释。(可作为附件,注明附件编号) ]
参考资料
[ 在需求中各处参照的文件的全部清单,如税法、法规、文件等规定等,要求注明文件文号,文件名称,来源文献名,等。例如: XXXX字2006(XX)号,文件名(可作为附件,注明附件编号) ]
项目概述
功能描述
[ 为了使业务需求更易于理解,对本文所涉及的业务环节给出总体概述。叙述软件开发意图,应用目标、作用范围,解释该软件与其他有关软件之间的关系。如果本软件是一项独立的,而且全部内容自含,请说明。如果是一个更大系统的一个组成部分,说明与大系统中其他组成部分之间的关系。表述方式
可为业务功能框架,主要业务流程以及与其它业务环节之间的主要关系图,编写时可根据需要增、减。]
用户特点
[ 列出软件的最终用户的特点,充分说明操作人员、维护人员的经验、岗位特点、操作水平等,如果用户为临时或者操作水平差的用户,应明确要求系统包含如何完成基本功能的提示,既在线提示或向导性指示;说明软件预期使用频繁程度、重要程度(分为高、中、低三类)。]
约束
[ 对设计系统时限制开发者的一些项目(在开发商进入项目时完成),包括:硬件限制、应用间接口标准、并行操作、语言、通信协议、安全及保密方面的考虑、临界点、开发期限等。]
功能需求
本章包括在设计开发时业务需要的全部细节(本次编写工作的主要内容)。是需求说明说中篇幅最大和最重要的部分。要求按照实施方案规定的准则(可验证性、无二义性、业务闭合性等),对每个细节作具体描述。
应注意:按照符合逻辑和可读易懂的方式组织;详细描述每一个需求,使该需求所达到的目标能够在以后测试过程中进行客观验证。
边界范围
[ 功能边界图]
业务需求内容
[ 功能需求1 ]
功能概述
[ 描述该功能要实现的主要业务内容,内容要高度概括,为以后软件开发人员了解和掌握业务有非常大的帮助]
概要流程图
[ 流程图,图例要清除的说明业务流程,不能有任何遗漏及业务不闭合现象]
输入信息
[ ①该项业务输入的表、证、单、书及其他资料。(表、证、单、书作附件)]
[ ②其它环节或系统提供进入本流程的数据信息]
业务前提
[ 在本功能模块开始前的必要准备和前置条件,即在什么前提下启动此流程]
操作岗位
[ 对业务流程涉及的岗位进行列举]
业务流程及处理规则
[ 该项业务具体处理流程描述,可配以图例说明,可提供流程图(Word图表、Visio图表)。可根据实际情况进行其他方位的