系统概要设计说明书_售前如何写需求说明书？

在项目整个售前阶段中，售前人员要提供很多材料，如“建设方案”、“项目申请报告”、“可行性研究报告”、“需求说明书”、“技术规范书”等，这些材料的核心组成部分，其实都是“需求说明书”。本篇以软件系统需求为例，探讨售前如何编写需求文档。

软件需求说明书SRS(Software Requirements Specification)的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。

（SRS也称为“软件需求规格说明书”，网上很多人认为“软件需求规格说明书”与“软件需求说明书”不同，认为前者面向开发人员，后者面向用户。笔者认为，SRS的国内行业标准译法应是“软件需求规格说明书”，但需求文档的叫法并不重要，关键是它的目标人群、功能。）

需求说明书的功能

需求说明书主要具备以下几个功能：

1、便于与用户、开发人员达成共识：界定清楚软件的边界、功能、性能要求等，并据此与用户、开发人员达成共识；

2、软件设计的依据：是后续设计、开发工作的依据；

3、软件验收测试的依据：是最终测试、验收的依据；

4、需求管控：可以用于鉴别用户需求是否超出边界或是否变更、新增需求。

需求说明书的模板

一份需求说明书具体包含哪些内容、哪些条目？有没有标准的模板呢？

笔者认为，需求说明书并没有标准模板。根据客户所在的行业不同、具体客户要求不同、材料类型不同，就会有不同的模板。而模板通常来源于公司前期的文档或客户给的样例。如果这些也没有，可在网上搜一个模板，满足要求即可。

软件需求说明书有一些标准文档，下面推荐一个基于GB/T 9385-2008的模板，读者可根据自己的需要对条目进行选择：

文档信息

文档标题	XXX项目需求规格说明书
归档日期
所有者

修订历史

版本编号	版本日期	修订内容	备注
V0.1		初始版本
V0.2
V0.3
V0.4
V0.5
V0.6
V0.7
V0.8
V0.9
V1.0

以上还可插入一列作者。

文档编制、审核与批准

	签字	日期
编制
审核
批准

目录

插入目录。

1引言

本部分应当提供整个SRS的概述

1.1 目的

a)描述SRS的目的；

b)说明SRS的预期读者。

1.2范围

a)通过名称识别要生产／开发的软件产品(例如，宿主数据库管理系统(DBMS)、报告生成器等）；

b)必要时，说明软件产品将做或不做什么；

c)描述规定的软件的应用，包括相关的收益、目标和目的；

d)如果上层规格说明（如，系统需求规格说明）存在，与上层规格说明类似的陈述保持一致。

1.3定义、简写和缩略语

本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供。

1.4引用文件

a)提供SRS引用的所有文件的完整清单；

b)标识出每个文件的名称、报告编号（适用时）、日期、出版组织；

c)标明可以获得引用文件的来源。

这些信息可以通过引用附录或引用其他文档的方式提供。

1.5综述

a)描述SRS的其余章条包含的内容；

b)说明SRS是如何组织的。

2总体描述

本章宜描述影响产品及其需求的一般因素，而不叙述具体的需求。相反，它提供需求的背景并使它们更易理解，而在SRS的第3章将详细定义这些需求。

2.1产品描述

本条宜把产品置于其他有关产品的全景之下。如果产品是独立的和完全自我包含的，这里宜如实给予陈述。正如常出现的那样，如果SRS定义的产品是较大系统的组成部分，则本章宜将软件的功能性与较大系统的需求相联系，而且宜识别软件和系统之间的接口。

使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的。

本条也宜描述在各种不同的约束下软件如何运行。如，这些约束可包括：

a)系统接口；

b)用户界面；

c)硬件接口；

d)软件接口；

e)通信接口；

f)内存；

g)运行；

h)现场适应性需求等。

2.1.1系统接口

本条宜列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。

2.1.2用户界面

本条宜规定以下方面：

a) 在软件产品与用户之间每个界面的逻辑特征。这包括完成软件需求所需要的那些配置特征（例如，要求的屏幕显示格式、页面或窗口版式布局、任何报告或菜单的内容、或者可编程功能键的设置）；

b) 优化系统用户界面的所有方面。这可以简单地包括一个针对系统对用户的显示方式系统将做什么和不做什么的清单。例如，可能是一项选择长或短的错误消息方面的需求。如同所有其他需求一样，这些需求宜是可验证的，例如，“经过th培训后，4级打字员能够在Zrnln内执行功能X”，而不是“打字员能够执行功能X”（这也可以在标题为使用方便性章条的软件系统属性中规定）。

2.1.3硬件接口

本条宜规定系统硬件各部件与软件产品之间每个接口的逻辑特征，包括配置特征（端口数量、指令集等），同样也覆盖这些事项，如，支持什么设备、如何支持以及采用什么协议。例如，相对逐行支持，终端支持可能规定为全屏支持。

2.1.4软件接口

本条宜规定对其他软件产品（例如，数据管理系统、操作系统、或数学软件包）的使用，以及与其他应用系统（例如，账户接收系统和一般的会计记帐系统的链接）的接口。对于每个要求的软件产品，宜提供：

a)名称；

b)助记符；

c)规格说明编号；

d)版本号；

e)来源。

对于每个接口，宜提供：

a) 相对此软件产品，接口软件的目的的论述；

b) 按照消息内容和格式对接口的定义，不必要详细描述任何已文件化的接口，但要求引用定义此接口的文件。

2.1.5通信接口

本条宜定义不同的通信接口，如，局域网协议等。

2.1.6内存约束

本条宜规定对主存和辅存的任何适用特征和限制。

2.1.7操作

本条宜规定用户要求正常的和特定的操作，如：

a)用户组织的不同操作模式（如，用户引发的操作）；

b)交互操作的周期和无人值守操作的周期；

c)数据处理支持功能；

d)备份和恢复操作。

注：有时此条规定作为用户界面的一部分。

2.1.8现场适应性需求

a) 对于给定的现场、任务或运行模式（如，网格数、安全限制等），为任何数据或启动顺序定义需求；

b) 针对软件适应特定的安装现场或任务，规定应当修改的特征。

2.2产品功能

本条宜给出软件将执行主要功能的概要。例如，某个会计程序的SRS可在此部分关注顾客账户维护、顾客财务报表及发票准备，而不涉及这些功能要求的大量细节。

有时，本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明（如果存在）中摘录。为了清晰，应当注意：

a) 功能宜以这样的方式组织，以使顾客或第一次阅读该文件的任何读者对功能列表容易理解；

b) 可以使用文本或图示的方法，显示不同的功能及其之间的关系。这样的图示不必显示产品的设计，但简要显示变量之间的逻辑关系。

2.3用户特点

本条宜给出软件产品预期用户的一般特征，包括教育程度、经验、专业技术情况。它不宜指出具体的需求，但宜给出SRS第3章中为何规定某些具体需求的原因。

2.4约束

本条宜给出将会限制开发人员选择的任何其他事项的一般描述。这些包括：

a) 法规政策；

b) 硬件局限（如，信号时间要求）；

c) 与其他应用的接口；

d) 并行操作；

e) 审核功能；

f) 控制功能；

g) 高级语言需求；

h) 信号握手协议(如，XON-XOFF、ACK-NACK)；

i) 可靠性需求；

j) 应用的关键性；

k) 安全和保密安全考虑。

2.5假设和依赖关系

本条宜列出影响SRS规定需求的每个因素。这些因素不是软件设计的限制条件，但是，它们的任何变更可能影响SRS中的需求。例如，某个假设可能是软件产品指定的硬件具有某个特定操作系统，如果事实上该操作系统不能使用，那么SRS将做相应的修改。

2.6需求分配

本条宜识别可能推迟到系统将来版本的需求。

3具体需求

本章宜包括足够详细的所有软件需求，使设计人员能够设计系统以满足这需求，并且使测试人员能够测试该系统满足这些需求。贯穿本章，对于用户、运行人员或其他外部系统，每个规定的需求应当是外部可理解的。这些需求至少应当包括，每个系统输入（激励）、每个系统输出（响应）以及系统通过响应某个输入或支持某个输出所执行的所有功能。由于这通常是SRS篇幅最大和最主要部分，以下原则适用：

a) 规定的具体需求宜符合GB/T 9385-2008 4.4描述的所有特征；

b) 具体需求宜引用较早的相关文件；

c) 所有的需求宜是唯一可标识的；

d) 宜注意需求的组织，使其具有最大的可读性。

在考察组织需求的具体方式之前，了解GB/T 9385-2008 5.4.1到5.4.7组成需求的各个不同项是有益的。

3.1外部接口

本条宜是软件系统所有输入和输出的详细描述。它宜是对GB/T 9385-2008 5.2的接口描述的补充，不宜重复前面已有的信息。

宜包括以下内容和格式：

a) 项的名称；

b) 目的描述；

c) 输入源和输出目的地；

d) 有效范围、准确度和／或容限；

e) 测量单位；

f) 定时；

g) 与其他输入／输出的关系；

h) 屏显格式／组织；

i) 窗口格式／组织；

j) 数据格式；

k) 命令格式；

l) 结束消息。

3.2功能

功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作。一般情况下使用“系统应……”的方式来陈述。

这些包括：

a) 对输入有效性的核查；

b) 操作的准确顺序；

c) 异常情况响应，包括：

1) 溢出；2) 通信设施；3) 错误处理和恢复；

d) 参数影响；

e) 输入与输出的关系，包括：

1) 输入／输出顺序；2) 从输入到输出转换的公式。

尽管将功能需求划分为子功能或子过程可能是适当的，但这并不意味着软件设计同样以这样的方式划分。

3.2.1信息流

3.2.1.1数据流图1

3.2.1.1.1数据实体3.2.1.1.2有关的过程3.2.1.1.3拓扑图

……

3.2.1.n数据流图n3.2.1.n.1数据实体3.2.1.n.2有关的过程3.2.1.n.3拓扑图

3.2.2过程描述

3.2.2.1过程1

3.2.2.1.1输入数据实体3.2.2.1.2过程算法或公式3.2.2.1.3受影响的数据实体

……

3.2.2.m过程m

3.2.2.m.1输入数据实体3.2.2.m.2过程算法或公式3.2.2.m.3受影响的数据实体

3.2.3数据构建规范

3.2.3.1构建1

3.2.3.1.1记录类型3.2.3.1.2组成字段

……

3.2.3.p构建p

3.2.3.p.1记录类型3.2.3.p.2组成字段

3.2.4数据词典

3.2.4.1数据元素1

3.2.4.1.1名称3.2.4.1.2表示法3.2.4.1.3单位／格式3.2.4.1.4精确度／准确度3.2.4.1.5范围

……

3.2.4.q数据元素q

3.2.4.q.1名称3.2.4.q.2表示法3.2.4.q.3单位／格式3.2.4.q.4精确度／准确度3.2.4.g.5范围

3.3性能需求

本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求。静态数量化需求可能包括：

a) 支持的终端数量；

b) 支持同时运行的用户数量；

c) 要处理的信息量和类型。

有时，静态数量需求包含在命名为“能力”的独立部分。

动态数量化需求可能包括，如，在正常和高峰工作负载条件，在某时段内处理的事务处理数、任务数和数据量。

所有这些需求宜以可测量的方式规定。如：

应在小于Is内处理95%的交易量。

而不是：

操作方不需等待事务处理结束。

注：适用于某个具体功能的数量化限制，通常作为该功能处理描述部分予以规定。

3.4数据库逻辑需求

宜规定将置于数据库的任何信息的逻辑需求。这可包括：

a) 不同功能使用的信息类型；

b) 使用频度；

c) 访问能力；

d) 数据实体及其之间的关系；

e) 完整性约束；

f) 数据保存需求。

3.5设计约束

宜规定可能由其他标准、硬件局限等引发的设计约束。

3.5.1标准依从性

本条宜规定来自现存标准或法规的需求。它们可能包括：

a)报告格式；

b)数据命名；

c)会计规程；

d)审核追踪。

例如，可以规定追踪处理活动的软件需求。为了最低满足法规或财务标准，对于某些应用这样的追踪是需要的。例如，审核追踪需求可能规定，对于支付薪金数据库的所有变更，必须在一个追踪文档中记录支付前后的数额。

3.6软件系统属性

有一些软件属性可以作为需求。规定所要求的软件属性是重要的，这样才能客观地验证属性的实现情况。GB/T 9385-2008 5.4.6.1到5.4.6.5给出了部分示例。

3.6.1可靠性

本条宜规定要求的因素，以便建立在交付时软件系统所要求的可靠性。

3.6.2可用性

为了确保整个系统已定义的可用性程度，宜规定所要求的因素，如，检查点、恢复以及重启动。

3.6.3安全保密性

由于事故、恶意访问、使用、修改、破坏或泄露，本条宜规定需要保护软件的因素。这方面可能的具体需求包括：

a)使用某些密码技术；

b)保留某些特定数据组的历史或记录；

c)分配某些功能到不同的模块；

d)在程序的某些域间限制通信；

e)对于关键变量检查数据的完整性。

3.6.4可维护性

本条宜规定与软件本身维护简易性有关的软件属性。可以对模块化、接口和复杂性等有一定的要求。但不宜仅因为是良好设计实践就将其作为需求。

3.6.5可移植性

本条宜规定与软件移植到其他主机和／或操作系统简易性相关的软件属性。这可能包括：

a)依赖主机代码模块的百分比；

b)依赖主机代码的百分比；

c)已证明可移植语言的使用；

d)特定编译器或语言子集的使用；

e)特定操作系统的使用。

3.7具体需求的组织

除了微小的系统之外，任何系统倾向有大量的详细的需求。由此，宜仔细考虑这些需求的组织方式，以最优化可理解性。对于所有的系统不存在单一的最优化组织方式。不同类型的系统SRS的第3章有不同的需求组织方式。GB/T 9385-2008 5.4.7.1到5.4.7.7描述了一些组织方式。

3.7.1系统模式

依赖于运行模式，某些系统的行为显著不同。例如,根据其运行模式:培训、正常运行或者应急,某个控制系统可能具有不同的功能集合。当按照运行模式组织该部分时，宜采用第A.1章或第A.2章的提纲。需求组织方式的选择取决于系统接口和性能是否依赖于运行模式。

3.7.2用户类型

有些系统对不同的用户提供不同的功能集合。例如，对于一般乘客、维护人员和消防人员，电梯控制系统显示不同的能力。当按照用户类别组织该部分时，宜采用第A．3章的提纲。

3.7.3对象

对象是现实世界中的实体，系统具有与其对应的部分。例如，在病人监控系统中，对象包括病人、传感器、护士、房间、医师、医药等。与每个对象相联系的是一组属性（对象具有的）和功能（对象执行的），这些功能也称之为服务、方法或过程。当按照对象组织该部分时，宜采用第A.4章的提纲。应注意，对象组可能共有某些属性和服务，要按照类别把这些组织在一起。

3.7.4特征

系统特征是从外部希望得到的服务，可能要求一系列的输入以产生希望的结果。例如，在电话系统中，系统特征包括本地话务、话务转接、以及会议话务。一般的，系统每个特征按照一系列激励一响应对的方式描述。当按照系统特征组织该部分时，宜采用第A.5章的提纲。

3.7.5激励

某些系统可以根据激励描述其功能的方式最佳地组织其需求。例如，飞机自动着陆系统的功能，可依照动力降低、风向切变、机身摇摆突变、垂直速度限值等，组织到相应的部分。当按照激励方式组织该部分时，宜采用第A．6章的提纲。

3.7.6响应

有些系统可以通过描述其支持产生某个响应的所有功能，最佳地组织其需求。例如，某个人员管理系统的功能，可按照与产生薪金支付有关的所有功能、与产生当前职员清单有关的所有功能，等等，予以组织到相应的部分。宜采用第A.6章的提纲（所有的激励之处由响应替代）。

3.7.7功能层次

当上述组织方式证明没有益处时，可按照共同的输入、共同的输出或者共同的内部数据访问，将系统总体功能性组织成为一个功能层次。数据流图和数据词典可以用来表示功能和数据之间的相互关系。当按照功能层次组织该部分时，宜采用第A.7章的提纲。

3.8附加说明

在编制新的SRS时，在GB/T 9385-2008 5.4.7.7给出的多种组织技术可能都是适用的。在这种情况下，宜依据该系统的特定要求所剪裁出的若干层次来组织特定的需求。例如，第A．8章组织形式结合了用户类别和系统特征。任何附加的需求，可以在SRS的结尾处放在一个独立的部分。

有许多现行可用于帮助需求文档化的符号、方法和自动化支持工具。就大部分而言，它们的有效性是组织的职能。例如，当按照运行模式组织时，限定的状态机或状态图表可能证明是有益的；当按照对象组织时，面向对象的分析可能是有益的；当按照系统特征组织时，激励一响应序列可能证明是有益的；当按照功能结构组织时，数据流图和数据词典可能证明是有益的。

在第A.1章到第A.8章给出的任何提纲中，称为“功能需求I”的那些条目可以用自然语言、伪码、系统定义语言、或用标题为引言、输入、处理、输出4个子部分予以描述。

4附录

附录并不总是实际的SRS的一部分或总是需要的。附录可以包括：

a)输入／输出格式示例，成本分析研究，或者用户调查的结果；

b)有助于读者理解SRS的支持或背景信息；

c)软件所解决的问题描述；

d)对代码和媒体的特殊包装说明，以满足安全、出口、初始装入、或其他需求。

当包括附录时，SRS宜明确地规定附录是否作为需求的部分。

好需求说明书的标准

知道了需求说明书的要素，要写好需求说明书，还应遵循以下标准：

（1）完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。不遗漏任何必要的需求信息，即目标软件的所有功能、性能、设计约束，以及所有的可能情况下的预期行为，均完整地体现在需求说明书中。

（2）正确性

每一项需求都必须准确地陈述其要开发的功能。需求说明书中的功能、性能等描述与用户对软件的期望相一致。

（3）可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

（4）无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。另外，需求说明书的各部分之间不能相互矛盾。

（5）可验证性

需求说明书中的任意一项需求，都存在技术和经济上可行的手段进行验证和确认。

（6）可修改性

需求说明书的格式和组织方式应该保证能够比较容易地增、删和修改，并使修改后的需求说明书能够软较好地保持其他各项属性。

（7）可跟踪性

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，使每项需求与用户的原始需求连起来，并为后续开发和其他文档引用这些需求项提供便利。这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

（本节参考百度百科，引至：王爱平主编，实用软件工程：北京交通大学出版社，2009.09）

编写需求说明书的难点

如果知道了要写哪些内容、要遵照哪些规范，还是无法写出需求说明书，通常可能是以下问题：

1、需求调研不清晰：应继续找用户调研；可参照“IT售前圈”文章《售前如何做好需求调研？》

2、未进行需求分析：可参照“IT售前圈”文章《售前如何做需求分析？》

3、不擅长写材料：笔者会在后续“能写”系列文章中进行阐述。此处简要作个说明，

①写材料要先列出文章的架构，即提纲，需求文档提纲可参照以上需求说明书的模板；

②具体在写每一段文字时，先回答自己写这段话要达到什么目的？或想表达什么内容？

③然后把自己想表达的内容列几个点出来；

④再针对每个点展开描述，把要表达的内容讲清楚即可。

4、如何快速的编写出需求材料：

①要熟练掌握常用类型需求说明书的结构，如流程类的需求，通常包括业务流程、映射的流程图、每个环节说明、环节使用人、操作、每个环节输入输出信息等；

②在调研需求的时候，就要把这些结构所需要的信息都调研清楚；

③最后按照既定的结构，把每部分内容准确的罗列出来。