业务需求文件模版v12.docx
《业务需求文件模版v12.docx》由会员分享，可在线阅读，更多相关《业务需求文件模版v12.docx（10页珍藏版）》请在冰豆网上搜索。
业务需求文件模版v12
无锡地铁集团有限公司
业务需求书
编制
：
审核
：
修订历史
版本/状态
作者
审核人
起止日期
备注
注：
状态有新编、修订、发布；1.0版本为发布的起始版本，之前编0.x版本；备注填写编制或修订的内容。
目录
1介绍1
1.1文档概述1
1.2目标1
1.3范围1
1.4定义、术语及缩写2
1.5参考2
2业务概述2
2.1用户现状/业界当前系统2
2.2业务目标2
2.3业务过程分解2
2.4本业务模型与其他系统的关系3
2.5业务边界定义3
3业务需求分析3
3.1组织结构3
3.1.1部门组织机构概况4
3.1.2岗位职责概况4
3.2<子业务1>名称4
3.2.1业务流程5
3.2.2干系人的关注目标6
3.2.3业务规则6
3.2.4操作界面说明7
3.2.5数据实体7
3.3<子业务2>名称7
3.3.1业务流程及流程描述7
3.3.2干系人的关注目标7
3.3.3业务规则7
3.3.4操作界面说明7
3.3.5数据实体7
3.4业务信息表单8
3.4.1业务1表单调查表8
3.5业务接口8
3.6业务规则8
4基础数据说明8
5非功能需求8
5.1性能9
5.2权限管理9
5.3紧急性9
5.4期望上线时间9
5.5不允许发生的事件9
6附录9
6.1附录1：
供应商与产品9
6.2附录2：
待确定问题的列表10
1介绍
【本文档应主要描述业务处理过程和用户要求（包括功能要求和非功能要求），为后继的分析和技术需求书编制奠定基础。
】
1.1文档概述
【本文档主要描述了XXXXXXXXXX系统项目的业务需求说明。
】
本文档首先从项目背景、现有业务类型、服务对象等方面概要描述业务需求，其次从组织结构、接口、规则等方面描述业务需求分析情况，然后进一步详细描述业务内容、业务信息表单以及有待进一步确定的问题。
1.2目标
【说明编写这份文件的目的，并简要描述本文档的目的。
】
示范：
―――仅供参考，不具备任何实质性的内容。
本文档作为XX部门与XX部门之间就XX需求理解达成一致共识的基础文件，作为双方界定项目范围、签定协议的主要基础，也作为本项目验收的主要依据。
同时，本文档也作为本部门XX项目组后继工作开展（包括制定合理可行的项目计划、优秀的系统设计、开发高质量的程序等）的基础，供双方项目主管负责人、项目操作人员、技术开发人员、测试人员等理解需求之用。
1.3范围
【说明这份文件的适用范围及其阅读对象，列举业务需求说明所针对的不同读者，例如项目负责人、开发人员、部门主管、对方项目负责人、用户、测试人员或文档的编写人员。
提出最适合于每一类型读者阅读文档的建议。
】
示范：
―――仅供参考，不具备任何实质性的内容。
本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：
项目负责人、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。
1.4定义、术语及缩写
【列出本文档所涉及的专业术语、缩写词及相关定义。
】
【定义所有必要的术语，以便可以正确地解释软件需求规格说明，包括词头和缩写。
】
术语/缩写
定义
1.5参考
【列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。
】
文档名称
文档标题
2业务概述
2.1用户现状/业界当前系统
【概要描述本系统的项目背景和起源。
若用图表更能清楚描述项目背景，则建议在用自然文字描述业务的同时，辅以图形、表格来更精确地描述业务。
用于老系统改进时，主要阐述用户现状（组织架构、IT应用现状等）；用于新项目时，需要简单阐述业界同类系统所提供的功能。
】
【描述部门的业务服务对象，请根据实际需要进行进一步详细注释、描述。
】
2.2业务目标
【阐述本项目具体实现的业务目标，即解决的业务问题，是业务需求的出发点和核心所在。
】
2.3业务过程分解
【根据业务目标进行业务过程分解，主要包括：
主流程、配合过程、辅助过程等。
】
2.4本业务模型与其他系统的关系
【阐述本系统/模块与其他模块或系统可能存在的关系，可以用关系图表示。
】
2.5业务边界定义
【描述部门的业务范围，以便确定系统边界。
】
可选。
根据实际情况撰写，例如：
乘务管理与运营生产管理的业务边界。
3业务需求分析
【本章节将根据需求调研以及部门的业务处理流程，为业务系统建立一个视图，为进一步的需求分析和系统分析提供相关环境背景。
注意，这部分不应包括详细的功能需求和项目计划信息。
】
【需求说明书说清楚了如下问题：
业务的办理流程是什么？
业务办理条件是什么？
操作员通过怎么样的界面（简单描述要求）办理该业务？
系统最后操作哪些数据、生成哪些表单？
详细描述需要说清楚如下四个要素：
该功能的业务流程，该功能的业务规则,该功能的操作界面,该功能涉及的业务实体。
业务流程：
业务流程说明这个功能的办理步骤、以及每个步骤有哪些角色参与。
建议业务流程用活动图并辅以文字加以描述。
业务规则：
业务规则是指业务办理过程中的一些约束条件，包括前台界面校验规则和后台业务逻辑规则。
业务规则一般用文字描述，建议紧接着业务流程图，针对业务流程图中的每个操作环节，逐一描述其业务规则。
操作界面：
操作界面是要说明，系统建成之后，用户面对的操作界面的布局以及界面元素。
业务需求阶段可不做详细描述。
业务实体：
业务实体是指业务流程中的各个环节操作的表单、数据等对象。
】
3.1组织结构
【描述本部门的组织结构和职能部门职责。
建议先以框图形式画出系统所涉及的本部门的组织结构，然后以表格形式详细说明每个职能部门及其下属作业单元的具体职责。
】
3.1.1部门组织机构概况
表格1【XXX部门】组织机构调查表（图形式）
部门名称
职能总述
下设机构（科室）名称
主要职能简述
3.1.2岗位职责概况
表格2【XXX部门】岗位职责【XXX岗位职责名称】调查表
机构科室名称
岗位名称
岗位职责
科室1
科室2
科室3
3.2<子业务1>名称
【简述该子业务的业务目标】
对于某一业务的需求描述要包括以下四个方面。
但层级结构可由撰写者根据实际情况自由调整，如流程图针对业务1只有一幅，业务规则、操作说明、数据实体可以再分开业务1-1，业务1-2进行描述。
3.2.1业务流程
【业务流程说明这个业务的办理步骤、以及每个步骤有哪些角色参与。
建议业务流程用活动图并辅以文字加以描述。
若业务流程图中某些环节是系统外实现，进行标识即可，或某些环节不在本章节阐述，则注明具体分析的章节所在。
】
注：
也可以用表格形式来说明业务处理过程，具体如下：
表格3【XXX业务流程名称】业务流程调查表（表格式）
主管部门（科室）
名称
序号
重点工作环节
责任人（岗位）
责任部门
需提供的业务报表
产生的业务报表
备注
3.2.1.1<子业务1>流程图
【以流程图的形式表示系统的业务1的流程和涉及到的职能部门及岗位。
】
3.2.1.2<子业务1>流程描述
【用自然语言的形式描述3.1.1.1流程图中的业务处理过程，以使读者对业务细节有进一步的了解。
处理过程信息包括：
业务所涉及到的职能部门、岗位，该业务需要提供的业务报表，所产生的业务报表、业务处理的步骤以及该业务所受约束。
】
3.2.1.3<岗位>职责执行过程
<岗位1>名称
职责执行过程可以采用职责执行流程图的方式表达，并填写下表。
表格4【xxxx职责】职责执行调查表
岗位职责
业务往来部门
业务往来岗位
执行职责的工作步骤：
1.
2.
3．
约束条件：
（此项为可选）
接收的业务信息
产生的业务信息
3.2.1.4假设与依赖关系
【列出子业务1的所有假设与依赖关系】
3.2.2干系人的关注目标
【阐述本业务的各类干系人对本业务的数据、功能、性能等各种需求的关注点和关注程度】
3.2.3业务规则
【业务规则是指业务办理过程中的一些约束条件，包括输入数据的校验规则和业务处理的逻辑规则。
】
【业务规则一般用文字或特定表达式描述，建议紧接着业务流程图，针对业务流程图中的每个操作环节，逐一描述其业务规则。
】
3.2.4操作界面说明
【操作界面是要申明：
系统建成之后，用户面对的操作界面的特定业务要求。
】
3.2.5数据实体
【数据实体是指业务流程中的各个环节操作的表单、业务数据等对象。
其中涉及到的基础数据应加以注释，并在“基础数据说明”章节进行统一说明。
需求阶段明确了数据实体以及数据实体的来源非常有利于后续的数据库设计。
】
3.3<子业务2>名称
同上
3.3.1业务流程及流程描述
3.3.2干系人的关注目标
3.3.3业务规则
3.3.4操作界面说明
3.3.5数据实体
3.4业务信息表单
【请详细列出在业务需求描述中所涉及到的表单名称、使用流程。
】
3.4.1业务1表单调查表
3.4.1.1业务1表单基本信息
表格5业务表单调查表
序号
业务表格名称
用途
来源
去向
使用时间段
使用人数预计
实时或预先生成
备注
【各个业务表单可作为附件提供，也可以作为一个小节摘录在调查表下方】
3.5业务接口
【表达业务流程之间、业务流程内部的接口。
】
3.6业务规则
【列举出新项目系统的所有操作规则，例如什么人在特定环境下可以进行何种操作。
这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。
如果涉及非常多的业务规则，需要单独作为一章来描述，也可以在3.1节中结合业务描述进行规则阐述。
】
4基础数据说明
【对该系统/模块上述业务中所需要的基础数据的说明，以及需要补充说明的数据来源（可能来自用户录入、其他模块、其他外部系统）】
5非功能需求
5.1性能
【业务访问量的估算（包括各类用户数的估算），各个模块的用户数量大致估算、系统使用高峰时段/低峰时段的用户数/操作频度、大数据报表查询频度与时间跨度范围等】
5.2权限管理
【每个功能的用户授权范围】
5.3紧急性
【该需求在本部门、分子公司内所处的紧要程度以及所有已提交需求中的序列，重要程度采取5分制，从1（低）-5（高），项目序列不可重号】
5.4期望上线时间
【期望项目上线时间，该时间仅作为收集的一个信息项，不作为项目立项与否以及项目最终的考核目标，集团信息管理部将综合各部门、分子公司所有的需求以及自身资源分配情况统一安排实施计划。
】
5.5不允许发生的事件
6附录
【一些附件内容、其他说明或待考虑问题等需要补充的内容。
】
6.1附录1：
供应商与产品
【若了解到业界有成熟供应商或成熟产品套件，可在下表列出】
序号
公司名称
产品名称
案例单位
联系人
电话
邮箱
官网
6.2附录2：
待确定问题的列表
【编辑一张在需求说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。
】
【注：
以上只是列出了在编写业务需求说明书时可能需要编写的内容，请根据实际编写需要进行增删。
】
升级会员 