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

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

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

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

1. 本次需求可能是针对一个全新领域的新产品，或只是旧产品的一次小升级；
2. 本次需求是希望开发一个通用的产品，或本次需求只是签约客户的具体需求
3. 所面向的领域及相关领域目前基本还是手工作业，所面向的领域及相关领域已充斥着杂七杂八的系统；
4. 编写者可能是领域专家，对领域非常熟悉，或者情况并不是这样，编写者有许多未理解问题，需要硬着头皮去编写；

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

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

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

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

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

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

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

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

一、是概述

背景

目标

产品范围

假设

补充说明

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

二、面向的客户

适用用什么行业

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

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

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

三、涉及岗位

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

四、其它干系人

五、基础的对象或数据

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

菜品的分类

菜品的配方

价格……、

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

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

六、业务单据

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

七、业务报表

八、涉及的系统

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

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

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

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

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

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

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

九、流程

注意列举全

十、流程详细

对每一流程分别进行说明

流程图

    基本流程图

    泳道流程图

流程说明 ：

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

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

十一、业务场景描述

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

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

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

   环境、

时间

   人物

   触发事件

   过程与活动

   结果

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

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

十二、业务规则

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

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

租金附加扣除计算规则

个税计算规则

十三、与其它工作的关联

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

关联说明

十四、分析评估

业务的评估

业务把握的评价

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

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

十五、业务愿景

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

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

十六、业务术语

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

 术语表

十七、附录

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

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

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

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

  相关系统演示的录像

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

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