详细设计说明书示例_业务需求说明书的参照样本（B）

说“业务需求说明书”就是假定工作会分成需求与分析二个阶段，多数实践中二者是合并为一个阶段。

业务需求工作涉及需求调研、需求的获取、需求整理与分析等等工作，今天我们先讲最后需求说明书怎么写，目的是提供一个内容的参照样本。

业务需求说明书的编写的前置的场景各不相同：

1. 本次需求可能是针对一个全新领域的新产品，或只是旧产品的一次小升级；

2. 本次需求是希望开发一个通用的产品，或本次需求只是签约客户的具体需求

3. 所面向的领域及相关领域目前基本还是手工作业，所面向的领域及相关领域已充斥着杂七杂八的系统；

4. 编写者可能是领域专家，对领域非常熟悉，或者情况并不是这样，编写者有许多未理解问题，需要硬着头皮去编写；

这些都影响着编写的内容与形式，并可能需要一些具体的策略。事实上，业务需求说明可根据管理的要求、参与人共同的语境来对内容进行裁剪或形式调整

实践中，最常见的是客户或开发方人员编写了一个文档，文档以条目列举了需求，每一条目内容说明一项需求，有了这份文档业务需求工作就算完成了。这也未尝不可，但你要知晓可能存在的问题：

——这种方式多是想到什么写什么，不知道漏掉什么

——有疑问时，资料可能未充分揭示，无法分析所列需求的合理性。

——文档可能过于模糊，容易产生歧义，有争论时支持不了什么定论。

这种方式下还有一种做法是列举了一堆的要求，如任务调度实现工作人员的负荷均衡，基本没说业务场景或业务逻辑，这种方式最多只是业务愿景或业务要求，还算不上业务需求。与这种做法相对应的说法是“业务需求说明就是要明确做什么”，这种说法太过于简单，忘掉无妨。

一般情况下，人们更容易关注到功效，但功效只是体现于系统能力的输出，有什么样的输出决定于系统。构建一个什么样的系统是在分析、设计阶段才决定，但业务需求要描述出它的原始面貌。

在不考虑缩减内容的情况下，业务需求说明书的描写内容应该是领域工作所涉及到的所有因素。在TOB的领域，这也形成相对结构化的方式。我们先给出一个样本。

一、是概述

背景

目标

产品范围

假设

补充说明

在工程项目周期中如果有变更前期的文档，如可行性分析、立项书等，相互内容要保持一致，或就放入前期文档。

二、面向的客户

适用用什么行业

适用于什么类型企业、什么层级的企业

相关的企业的组织、部门构架图，可为VISIO图

开发产品时，这部分可以示例的语气来说，除非你概括一个通用组织、部门构架

三、涉及岗位

序号	部门	岗位	岗位职责	岗位人员画像	其它
			1 2 3	职业习性上的特征。	分白班、夜班二班倒

企业岗位设置是灵活的，同样内容的工作，不同企业设置的岗位并不相同，如果是开发产品，应该是以一种设置最多且相互不重叠的岗位的情况来讲，也可以是虚拟出岗位的最小公倍数来讲

四、其它干系人

序号	干系人	关系与影响	其它说明

五、基础的对象或数据

比如，餐饮业的系统，就需要对出品进行描述：

菜品的分类

菜品的配方

价格……、

其它的如材料、产品、服务、设备等都可能是这里描述的对象。

不同的对象具有不同 的描述属性，这得具体地定

六、业务单据

序号	单据名称	用途	应用岗位	前置单据数据	编制逻辑	数据量	备注
						每月2000张

如果与上一节的内容分不清，记住上一节的是描述一个对象，本节的是描述一项业务处理

七、业务报表

序号	报表名称	用途	编制岗位	阅读岗位	编制逻辑	数据量	备注
						每月2000张

八、涉及的系统

目前工作所涉及的系统，这就分二种情况：

一种情况是本领域的旧系统，本次就是要更系统

那得对旧系统进行相对详细的介绍

可以将系统的各部分对应拆解在其它各章节说明，或者集中简单地进行如下说明

一级菜单	……	明细菜单	功能说明	主要页面	优点	缺点	建议
				截图 可放附录

第二种情况是完成 了本领域部分功能，或与本领域有交互的

完成本领域部分功能的：用上述方法进行说明

与本领域有交互的：建议放入相关的系统说明，

九、流程

序号	流程名称	用途	流程说明	备注

注意列举全

十、流程详细

对每一流程分别进行说明

流程图

    基本流程图

    泳道流程图

流程说明 ：

序号	步骤名称	操作者	输入	操作处理	输出	备注
		出纳岗		应用***单据
		系统

对流程的每一步骤的说明：

操作中涉及到的通用的部分放入业务规则

十一、业务场景描述

这部分不是体系里的一部分，而是说九、十节的对位替换描写方式

或者以一个整体流程作为一个业务场景来描写，或者将流程的各个环节作为关联的多个场景来分别写，这取决于各环节的独立性、是否也嵌入其它流程里。

场景化的描述简单地说就是故事化地讲解

   环境、

时间

   人物

   触发事件

   过程与活动

   结果

内含逻辑其实也一样，只是描写更具象化一些。

我的建议是如果领域的业务逻辑相对较浅，可以应用这种方式。如果业务逻辑复杂，还是用回标准方式，描述上多注意现场性(参见《需求的现场性》一文)  

十二、业务规则

描述通用的、可重用的处理过程

比如你要开发一个新个税的系统，那么每一专项附加扣除可扣除额的计算逻辑、个税的计算逻辑就可以分别作为业务规则在此说明

租金附加扣除计算规则

个税计算规则

十三、与其它工作的关联

相关的其它工作领域，可以用VISIO画个关联图：

关联说明

来源工作领域	来源系统	目的工作领域	目的系统	传输数据	传输规则
销售	手工	库存	库管系统	销售出库单 销售退货单 销售换货单

十四、分析评估

业务的评估

标题	内容
业务重点说明
业务难点说明
业务工作量大的地方
业务……说明

业务把握的评价

如果是产品的的需求，可增加本部分的评价

序号	业务	通用性评价	可能的变化形式	目前的理解把握程度	备注
	流程1			没有清晰理解
	流程2的3步骤

如果这个内容太多，可以试试分散于前面的各章节分别去写 

十五、业务愿景

序号	讲话人	讲话内容	备注

对会议或其它交流中，客户领导，或用户，或其它干系人所说过的重要的讲话进行记录。可以是简要的记录。

重要的讲话是客户认为是重要，如他们反复说的那些。有些讲话自己认为不重要，那可能是觉得问题其实很容易解决，如果不是这样，那你应该怀疑自己的判断。

十六、业务术语

对所涉及到的业务术语进行说明

 术语表

序号	术语	别名	解释

十七、附录

  记载业务单据里的单据样张图样

  记载业务报表里的报表样张图样

  记载相关系统里的页面截图

  愿景里客户重要讲话的录音

  相关系统演示的录像

实践中你可以裁剪调整上述的内容。如果存在重要的但上面未列到的领域里的重要事项，你应该把它加进来，比如你所设计的是仓储管理系统，那么你可以增加下述对象的描述：仓库、货区、货位、存储器、装运路线等。

这里我们所给出的样本是以自然语言、图、表为基础，为了专业性的体现，有人可能在此阶段就寻求某种统一的建模语言来写，如果过程需要与客户反复交互确认，建议还是别自寻找烦恼。另外还是要问，这种那种的建模语言真的让你的说明更清楚？从实践来说，包括所有的阶段，见过以某建模思想贯彻下来，取得不一样成果，而不只是得到表面几个形式的吗？