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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一、是概述

背景

目标

产品范围

假设

补充说明

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

二、面向的客户

适用用什么行业

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

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

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

三、涉及岗位