
Version 0.1
核准签名
| 核准人 | 项目经理 | 日期 | |
| 核准人 | 系统分析师 | 日期 | |
| 核准人 | 客户 | 日期 | |
| 核准人 | 日期 | ||
| 核准人 | 日期 | ||
| 核准人 | 日期 |
| 日期 | 版本 | 描述 | 作者 |
| 2010-09-11 | 0.1 | 草稿 | 谭勇 |
[本文档应主要描述业务处理过程和用户要求(包括功能要求和非功能要求),为后继的分析和需求规格说明书编制奠定基础。]
[在正式编写文档时,请删除内容要求部分。]
文档概述
本文档主要描述了XXXXXXXXXX系统项目的软件业务需求说明。
本文档首先从项目背景、现有业务类型、服务对象等方面概要描述系统,其次从组织结构、接口、规则等方面描述系统的业务需求分析情况,然后进一步详细描述系统的业务内容、业务信息表单以及有待进一步确定的问题。
目标
[说明编写这份文件的目的,并简要描述本文档的目的。]
示范:―――仅供参考,不具备任何实质性的内容。
本文档作为XX部门与XX部门之间就XX需求理解达成一致共识的基础文件,作为双方界定项目范围、签定协议的主要基础,也作为本项目验收的主要依据。同时,本文档也作为本部门XX项目组后继工作开展(包括制定合理可行的项目计划、优秀的系统设计、开发高质量的程序等)的基础,供双方项目主管负责人、项目操作人员、技术开发人员、测试人员等理解需求之用。
范围
[说明这份文件的适用范围及其阅读对象,列举软件需求说明所针对的不同读者,例如项目负责人、开发人员、部门主管、对方项目负责人、用户、测试人员或文档的编写人员。提出最适合于每一类型读者阅读文档的建议。]
示范:―――仅供参考,不具备任何实质性的内容。
本文档适用于所有与本项目有关的软件开发阶段及其相关人员,其中:项目负责人、技术开发人员(包括分析人员、设计人员、程序人员)、测试人员应重点阅读本文档各部分,其他人员可选择性阅读本文档。
定义、术语及缩写
[列出本文档所涉及的专业术语、缩写词及相关定义。
定义所有必要的术语,以便读者可以正确地解释软件需求规格说明,包括词头和缩写。你可能希望为整个部门创建一张跨越多项项目的词汇表,并且只包括特定于单一项目的软件需求规格说明中的术语。]
| 术语/缩写 | 定义 |
[列出本文的参考文件清单,包括出版单位、作者、版本、日期等信息。]
| 文档名称 | 文档标题 |
项目背景
[概要描述本系统的项目背景和起源。若用图表更能清楚描述项目背景,则建议在用自然文字描述业务的同时,辅以图形、表格来更精确地描述业务。]
现有业务概述
2.1.1业务类型
[描述部门业务所属的业务类型,请根据实际需要进行进一步详细注释、描述。]
2.1.2业务服务对象
[描述部门的业务服务对象,请根据实际需要进行进一步详细注释、描述。]
2.1.3业务范围
[描述部门的业务范围,以便确定系统边界。]
2.1.4主要业务特点
[描述部门的主要业务特点,请根据实际需要进行进一步详细注释、描述。]
3业务需求分析
[本章节将根据需求调研以及部门的业务处理流程,为业务系统建立一个视图,为进一步的需求分析和系统分析提供相关环境背景。注意,这部分不应包括详细的功能需求和项目计划信息。]
组织结构
[描述本部门的组织结构和职能部门职责。建议先以框图形式画出系统所涉及的本部门的组织结构,然后以表格形式详细说明每个职能部门及其下属作业单元的具体职责。]
3.1.1部门组织机构概况
表1 [XXX部门]组织机构调查表(图形式)
| 部门名称 | |
| 职能总述 | |
| 下设机构(科室)名称 | 主要职能简述 |
表2 [XXX部门]岗位职责[XXX岗位职责名称]调查表
| 机构科室名称 | 岗位名称 | 岗位职责 |
| 科室1 | ||
| 科室2 | ||
| 科室3 | ||
[从整个业务层次高度给出业务分包,为以后的概要设计、划分子系统提供依据。]
3.1.3<业务1>名称
3.2.1.1<业务1>流程图
[以流程图的形式表示系统的业务1的流程和涉及到的职能部门及岗位。建议采用协作图或者顺序图+活动图的形式给出业务处理流程。]
3.2.1.2<业务1>流程描述
[用自然语言的形式描述3.2.1.1流程图中的业务处理过程,以使读者对业务细节有进一步的了解。处理过程信息包括:业务所涉及到的职能部门、岗位,该业务需要提供的业务报表,所产生的业务报表、业务处理的步骤以及该业务所受约束。]
注:也可以用表格形式来说明业务处理过程,具体如下:
表3 [XXX业务流程名称]业务流程调查表(表格式)
| 主管部门(科室)名称 | |||||||
| 序号 | 重点工作环节 | 责任人(岗位) | 责任部门 | 需提供的业务报表 | 产生的业务报表 | 备注 | |
<岗位1>名称
职责执行过程可以采用职责执行流程图或 UML视图的方式表达,并填写下表。
表4 [xxxx职责]职责执行调查表
| 岗位职责 | ||||
| 业务往来部门 | 业务往来岗位 | |||
| 执行职责的工作步骤: 1. 2. 3. | ||||
| 约束条件:(此项为可选) | ||||
| 接收的业务信息 | 产生的业务信息 | |||
[列出业务1的所有假设与依赖关系,比如:某国际报送业务流程会依赖于当地机构是否支持EDI呈报。]
3.1.4<业务2>名称
[结构同上3.2.1。]
3.1.5<业务n>名称
[结构同上3.2.1。]
业务信息表单
[请详细列出在业务需求描述中所涉及到的表单名称、表单结构(字段名称、长度、数据类型等)、使用流程。]
3.1.6业务1表单调查表
3.3.1.1业务1表单基本信息
表5 业务表单调查表
| 序号 | 业务表格名称 | 用途 | 来源 | 去向 | 备注 |
| 序号 | 业务字段名称 | 类型 | 字段描述 |
3.1.7业务2表单调查表
3.3.2.1业务2表单基本信息
[结构同上3.3.1.1。]
3.3.2.2业务2信息表单关系
[结构同上3.3.1.2。]
业务接口
[以数据接口图的形式表达业务流程之间、业务流程内部的接口。]
业务规则
[列举出新产品的所有操作规则,例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求,但它们可以暗示某些功能需求执行这些规则。如果涉及非常多的业务规则,需要单独作为一章来描述,也可以在3.2章节中结合业务描述进行规则阐述。]
4附录
附录1:待确定问题的列表
[编辑一张在需求说明中待确定问题的列表,其中每一表项都是编上号的,以便于跟踪调查。]
[注:以上只是列出了在编写业务需求说明书时可能需要编写的内容,请根据实际编写需要进行增删。]
