《[模板]业务需求说明书.docx》由会员分享，可在线阅读，更多相关《[模板]业务需求说明书.docx（10页珍藏版）》请在三一文库上搜索。
1、业务需求说明书模板Version: 0.1业务需求说明书模板Version 0.1核准签名核准人项目经理日期核准人系统分析师日期核准人客户日期核准人日期核准人日期核准人日期修订历史日期版本描述作者2010-09-110.1草稿谭勇目 录1介绍41.1文档概述41.2目标41.3范围41.4定义、术语及缩写41.5参考52业务概述52.1项目背景52.2现有业务概述52.2.1业务类型52.2.2业务服务对象52.2.3业务范围52.2.4主要业务特点53业务需求分析63.1组织结构63.1.1部门组织机构概况63.1.2岗位职责概况63.2业务描述73.2.1<业务1>名称73.2
2、.2<业务2>名称83.2.3<业务n>名称83.3业务信息表单83.3.1业务1表单调查表83.3.2业务2表单调查表93.4业务接口93.5业务规则94附录104.1附录1：待确定问题的列表101 介绍本文档应主要描述业务处理过程和用户要求（包括功能要求和非功能要求），为后继的分析和需求规格说明书编制奠定基础。在正式编写文档时，请删除内容要求部分。1.1 文档概述本文档主要描述了XXXXXXXXXX系统项目的软件业务需求说明。本文档首先从项目背景、现有业务类型、服务对象等方面概要描述系统，其次从组织结构、接口、规则等方面描述系统的业务需求分析情况，然后进一步详细描述
3、系统的业务内容、业务信息表单以及有待进一步确定的问题。1.2 目标说明编写这份文件的目的，并简要描述本文档的目的。示范：仅供参考，不具备任何实质性的内容。本文档作为XX部门与XX部门之间就XX需求理解达成一致共识的基础文件，作为双方界定项目范围、签定协议的主要基础，也作为本项目验收的主要依据。同时，本文档也作为本部门XX项目组后继工作开展（包括制定合理可行的项目计划、优秀的系统设计、开发高质量的程序等）的基础，供双方项目主管负责人、项目操作人员、技术开发人员、测试人员等理解需求之用。1.3 范围说明这份文件的适用范围及其阅读对象，列举软件需求说明所针对的不同读者，例如项目负责人、开发人员、部门
4、主管、对方项目负责人、用户、测试人员或文档的编写人员。提出最适合于每一类型读者阅读文档的建议。 示范：仅供参考，不具备任何实质性的内容。本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：项目负责人、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。1.4 定义、术语及缩写列出本文档所涉及的专业术语、缩写词及相关定义。定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个部门创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。术语/缩写定义1.5 参考列出本
5、文的参考文件清单，包括出版单位、作者、版本、日期等信息。文档名称文档标题2 业务概述2.1 项目背景概要描述本系统的项目背景和起源。若用图表更能清楚描述项目背景，则建议在用自然文字描述业务的同时，辅以图形、表格来更精确地描述业务。2.2 现有业务概述2.2.1 业务类型描述部门业务所属的业务类型，请根据实际需要进行进一步详细注释、描述。2.2.2 业务服务对象描述部门的业务服务对象，请根据实际需要进行进一步详细注释、描述。2.2.3 业务范围描述部门的业务范围，以便确定系统边界。2.2.4 主要业务特点描述部门的主要业务特点，请根据实际需要进行进一步详细注释、描述。3 业务需求分析本章节将根据
6、需求调研以及部门的业务处理流程，为业务系统建立一个视图，为进一步的需求分析和系统分析提供相关环境背景。注意，这部分不应包括详细的功能需求和项目计划信息。3.1 组织结构描述本部门的组织结构和职能部门职责。建议先以框图形式画出系统所涉及的本部门的组织结构，然后以表格形式详细说明每个职能部门及其下属作业单元的具体职责。3.1.1 部门组织机构概况表Error! Bookmark not defined. XXX部门组织机构调查表（图形式）部门名称 职能总述 下设机构（科室）名称主要职能简述 3.1.2 岗位职
7、责概况表2 XXX部门岗位职责XXX岗位职责名称调查表机构科室名称岗位名称岗位职责科室1 科室2 科室3 3.2 业务描述从整个业务层次高度给出业务分包，为以后的概要设计、划分子系统提供依据。 3.2.1 <业务1>名称3.2.1.1<业务1>流程图以流程图的形式表示系统的业务1的流程和涉及到的职能部门及岗位。建议采用协作图或者顺序图活动图的形式给出业务处理流程。3.2.1.2<业务1>流程描述用自然语言的形式描述3.2.
8、1.1流程图中的业务处理过程，以使读者对业务细节有进一步的了解。处理过程信息包括：业务所涉及到的职能部门、岗位，该业务需要提供的业务报表，所产生的业务报表、业务处理的步骤以及该业务所受约束。注：也可以用表格形式来说明业务处理过程，具体如下：表3 XXX业务流程名称业务流程调查表（表格式）主管部门（科室）名称 序号重点工作环节责任人(岗位)责任部门需提供的业务报表产生的业务报表备注 &#
9、160; 3.2.1.3<岗位>职责执行过程<岗位1>名称职责执行过程可以采用职责执行流程图或 UML视图的方式表达，并填写下表。表4 xxxx职责职责执行调查表岗位职责 业务往来部门 业务往来岗位 执行职责的工作步骤：1. 2. 3约束条件：（此项为可选）接收的业务信息产生的业务信息 3.2.1.4假设与依赖关系列出业务1的所有假设与依赖关系，比如：某国际报送业务流程会依赖于当
10、地机构是否支持EDI呈报。3.2.2 <业务2>名称结构同上3.2.1。3.2.3 <业务n>名称结构同上3.2.1。3.3 业务信息表单请详细列出在业务需求描述中所涉及到的表单名称、表单结构（字段名称、长度、数据类型等）、使用流程。3.3.1 业务1表单调查表3.3.1.1业务1表单基本信息表5 业务表单调查表序号业务表格名称用途来源去向备注 表6XXXX表字段信息调查表序号业务字段名称类型字段描述
11、60; 3.3.1.2业务1信息表单关系3.3.2 业务2表单调查表3.3.2.1业务2表单基本信息结构同上3.3.1.1。3.3.2.2业务2信息表单关系结构同上3.3.1.2。3.4 业务接口以数据接口图的形式表达业务流程之间、业务流程内部的接口。3.5 业务规则列举出新产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。如果涉及非常多的业务规则，需要单独作为一章来描述，也可以在3.2章节中结合业务描述进行规则阐述。4 附录4.1 附录1：待确定问题的列表编辑一张在需求说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。注：以上只是列出了在编写业务需求说明书时可能需要编写的内容，请根据实际编写需要进行增删。机密10/10