业务需求说明书管理与数据类参考模板.docx

业务需求说明书管理与数据类参考模板.docx

《业务需求说明书管理与数据类参考模板.docx》由会员分享，可在线阅读，更多相关《业务需求说明书管理与数据类参考模板.docx（10页珍藏版）》请在冰豆网上搜索。

业务需求说明书管理与数据类参考模板

某银行

XX业务需求说明书

提出部门：

xxxx部

xxxx年xx月

文档修改记录

章节编号

修订日期

修订内容简述

版本

作者

审核

发布日期

签署记录

部门

负责人

日期

意见

1.引言

1.1目的

（说明编写本业务需求的目的，指出预期的读者。

）

为了让用户和软件开发者双方对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础，特编写本需求。

本文档主要对业务需求进行细致描述，明确业务处理范围，并对要实现的功能、输入输出数据和性能要求进行说明，力求准确、清晰、完整地阐明用户的需求，使业务需求易理解、无二义性、可衡量，是进行需求分析的基础。

本文档预期读者：

⏹xxxx部门

⏹分行信息技术管理部

⏹参与业务需求分析的人员

1.2背景

（依次说明下述内容：

任务提出者、用户；相关业务现状；存在问题；应用目标、作用范围。

）

⏹需求提出者

需求完整名称：

xxxx业务需求说明书

需求提出部门：

xxxx部门

⏹预期使用者

应用部门：

xxxx部门

xxxx部门

使用范围：

全行或总行、分行

⏹市场背景（规范要求：

简明、扼要，无需过多描述）

填写说明：

本部分内容主要介绍项目立项前，目前市场、监管机构对业务实施目标的需求急迫程度和市场的预期判断，国内外同业状况或从而反映出项目蕴含的业务价值。

⏹我行现状

填写说明：

本部分内容主要介绍：

项目立项前该业务管理领域存在的主要问题；

目前管理层或前台部门对业务实施目标的需求急迫程度和市场的预期判断；

本需求对业务发展战略的影响；

本部分内容为2.3内容的概述。

1.3术语和定义

对重要的或是具有特殊意义的业务术语（包括词头和缩写）进行定义，以使读者可以正确的解释业务需求

范例一：

1．反洗钱：

为了预防各种方式掩饰、隐瞒犯罪所得及其收益的来源和性质的洗钱活动而采取相关措施的行为

2.CCBS：

核心银行系统

1.4业务规范与标准

（列出本业务需要遵循的规范与标准。

）

《某银行xx业务规则》

1.5参考资料

填写说明：

列出编写本文档时所参考的资料，主要包括：

⏹参照文件的全部清单，如经核准的计划任务书，上级机关批文、合同等；

⏹列出其他参考资料，如属本项目的其他已发表的文件和主要文献等。

2.需求目标

2.1用户描述

填写说明：

本部分内容描述项目投产后的用户和角色。

该部分内容为必填。

角色：

指系统运行中可以执行某些特定权限操作的一组用户的集合

范例一：

押品的政策制定、日常运营职能分布在不同业务部门，主要用户分布在：

Ø总、分行风险管理部门

Ø总、分行授信管理部门

Ø总、分行经营部门

Ø运营管理部门

涉及的角色：

Ø客户经理

Ø信贷业务主管

Ø分管行长

Ø权证保管

2.2业务价值

填写说明：

描述需求中相关角色所关心的业务价值，建立业务价值与业务目标的关联。

该部分内容为必填。

2.3业务现状

填写说明：

描述业务现行的管理或运营方式。

该部分内容为必填。

2.4业务目标

填写说明：

描述系统实施达成的业务目标。

该部分内容为必填。

范例一

押品管理的业务目标：

1.依托现有的系统,建成全行押品支持平台；

2．实现押品关键风险环节的流程化控制；

3．实现押品从准入到退出全流程数据的采集和集中；

4．初步建立押品的统一视图；

5．建立居住用房地产押品的估值体系和估值方法；

6．实现主要押品价值的动态评估和预警；

7．实现全行押品的统计分析。

2.5约束和假设

（提出达到需求目标的时间要求）

描述涉及哪些业务部门，需要其他业务部门配合的事项是否已沟通落实。

1．外部机构的时间、范围、标准

2．跨部门业务流程关系、业务规则的要求

3．涉及的政策制度、会计核算、定价策略等关键要素

3.需求范围

3.1范围概述

填写说明：

描述本业务需求的概要范围，主要包括功能、数据和区域/机构等几方面。

3.2功能范围

填写说明：

描述需求中功能范围，包括优化功能的范围，该部分内容为必填。

3.3数据范围

（描述需求中涉及到的数据范围，主要包括：

时间范围、境内外机构范围、内部数据或外部数据，数据的业务类型或来源系统，数据形态为结构化或非结构化（影像扫描或多媒体）。

3.4区域/机构范围

填写说明：

描述需求中涉及到的区域和机构。

该部分内容为必填。

描述用户涉及到的区域、机构或部门。

4.功能需求

（描述具体的业务需求，本部分为核心内容，必填）

（为全部需求功能提供一个总体框架性说明，该部分内容为必填。

为了便于描述，可以功能结构图或表格等方式说明，以便预期读者在看到这个功能表的时候，可以马上就有一个整体印象和了解）

4.1功能1（适用于有流程的需求）

4.1.1功能概述

4.1.2业务流程

对流程的每个环节或节点按照以下进行描述

4.1.2.1流程节点1

（如有多个节点可比照增加）

4.1.2.1.1输入

（列出本节点的输入要素）

4.1.2.1.2处理

（体现本节点的处理流程，流程应遵循后面的业务规则）

4.1.2.1.3输出

（包括打印输出及屏幕输出的格式和内容）

4.1.2.1.4业务规则

（描述本节点数据加工或业务处理的规则）

4.2功能2（适用于无流程的需求）

4.2.1功能概述

4.2.2输入

（列出本功能的输入要素）

4.2.3处理

（体现本功能的处理规则）

4.2.4输出

（包括打印输出及屏幕输出的格式和内容）

对报表输出，应明确使用中是否调整报表格式或加工规则，并具体说明有关要求。

4.2.5业务规则

在业务规则基础上同时明确使用该功能的用户类型和数量。

4.3功能3（适用于数据处理的需求）

4.3.1功能概述

4.3.2输入

（描述涉及的源数据业务类型或系统名称）

4.3.3处理

（体现本功能的处理规则、并用文件大小或记录条数描述数据量）

4.3.4输出

（描述涉及的目标数据类型或系统名称）

5.数据库设计

数据库设计描述。

6.附件1

6.1非功能性需求

1、批量数据处理时效性要求：

系统输出T＋N；

2、各层级的用户数：

总行用户数、分行用户数等；

3、可容忍的最大停机时间（小时或天数）；

4、数据在线保存时间、离线保存时间。

6.2数据要求说明书

（需求提出部门和信息中心共同出具）

6.3需求优先级

（对全部需求功能按照重要和紧急程度进行排序）

6.4表单及报表样例

6.5灾备等级评分指标

项目组业务经理签字：

年月日

项目提出部门负责人签字：

年月日

信息管理中心负责人签字：

年月日

相关部门负责人签字：

年月日