业务需求说明书模板.doc

1 引言31.1 编写目的31.2 范围31.3 项目背景31.4 主要业务名词和术语定义31.5 参考文献32 需求概述32.1 用户现状/业界当前系统32.2 业务目标42.3 业务过程分解42.4 本业务模型与其他系统的关系42.5 业务边界定义43 详细需求43.1 子业务143.1.1 业务流程43.1.2 干系人的关注目标53.1.3 业务规则53.1.4 操作界面说明53.1.5 数据实体53.2 子业务253.2.1 业务流程63.2.2 干系人的关注目标63.2.3 业务规则63.2.4 操作界面说明63.2.5 数据实体64 基础数据说明65 非功能需求65.1 性能65.2 易用性75.3 可维护性75.4 可移植性75.4.1 硬件环境75.4.2 软件环境75.5 故障处理要求75.6 安全性75.7 不允许发生的事件86 附录8业务需求说明书1 引言需求说明书说清楚了“四要素”，实际上就说清楚了如下问题：业务的办理流程是什么？业务办理条件是什么？操作员通过怎么样的界面（简单描述要求）办理该业务？系统最后操作哪些数据、生成哪些表单？1.1 编写目的可选1.2 范围可选1.3 项目背景可选1.4 主要业务名词和术语定义1.5 参考文献 2 需求概述2.1 用户现状/业界当前系统可选。用于老系统改进时，主要阐述用户现状（组织架构、it现状等）；用于新课题的研究时，简单阐述业界同类系统所提供的功能2.2 业务目标阐述本模块具体是实现的业务目标，即解决的业务问题，是业务需求的出发点和核心所在。2.3 业务过程分解根据业务目标进行业务过程分解，主要包括：主流程、配合过程、辅助过程等。2.4 本业务模型与其他系统的关系阐述本系统/模块与QONE其他模块或客户系统可能存在的关系，可以用关系图表示2.5 业务边界定义可选。根据实际情况撰写，例如：成本管理与财务管理的业务边界。3 详细需求3.1 子业务1简述该子业务的业务目标对于某一业务的需求描述要包括以下四个方面。但层级结构可由撰写者根据实际情况自由调整，如流程图针对业务1只有一幅，业务规则、操作说明、数据实体可以再分开业务1-1，业务1-2进行描述。3.1.1 业务流程业务流程说明这个业务的办理步骤、以及每个步骤有哪些角色参与。建议业务流程用活动图并辅以文字加以描述。若业务流程图中某些环节是系统外实现，进行标识即可，或某些环节不在本章节阐述，则注明具体分析的章节所在。3.1.2 干系人的关注目标阐述本业务的各类干系人对本业务的数据、功能、性能等各种需求的关注点和关注程度3.1.3 业务规则业务规则是指业务办理过程中的一些约束条件，包括输入数据的校验规则和业务处理的逻辑规则。业务规则一般用文字或特定表达式描述，建议紧接着业务流程图，针对业务流程图中的每个操作环节，逐一描述其业务规则。3.1.4 操作界面说明操作界面是要申明：系统建成之后，用户面对的操作界面的特定业务要求。3.1.5 数据实体数据实体是指业务流程中的各个环节操作的表单、业务数据等对象。其中涉及到的基础数据应加以注释，并在“基础数据说明”章节进行统一说明。需求阶段明确了数据实体以及数据实体的来源非常有利于后续的数据库设计。3.2 子业务2 同上3.2.1 业务流程3.2.2 干系人的关注目标3.2.3 业务规则3.2.4 操作界面说明3.2.5 数据实体4 基础数据说明 对该系统/模块上述业务中所需要的基础数据的说明，以及需要补充说明的数据来源（可能来自用户录入、OQNE其他模块、其他外部系统）5 非功能需求本章节可统一维护5.1 性能可能包括：1、 基于对基本数据的估算（例如每个客户的平均项目数、每个项目的平均任务数等）2、 业务访问量的估算（包括各类用户数的估算、各类高中低频率访问事件的估算），以下只是示例：l 对于低频率事件，最大并发用户数按照合计用户数*10%来计算；l 对于中频率事件，最大并发用户数按照合计用户数*20%来计算；l 对于高频率事件，最大并发用户数按照合计用户数*50%来计算。l 低频事件中对于使用web方式进行积分账户等查询的业务，最大并发用户数按照合计用户数的1%来计算；l 要求用户的网络访问延时不能大于5秒。3、 网络传输数据的估算4、 关键业务处理时间的要求5、 与外部接口的性能要求如果涉及到与外部系统有接口，则对关键交互信息的传输时间进行估算5.2 易用性例如：操作应尽可能简洁，要求员工不用培训或较短时间培训，即能基本掌握日常操作，同时要求操作流程简单易懂及人性化等。5.3 可维护性5.4 可移植性5.4.1 硬件环境n 支持多核处理器5.4.2 软件环境n 跨操作系统平台、跨浏览器5.5 故障处理要求5.