作 者：
完成日期：
签 收 人：
签收日期：

修改情况记录：
版本号 修改批准人 修改人 安装日期 签收人

目录
1 引言 1
1.1 编写目的 1
1.2 范围 1
1.3 定义 1
1.4 参考资料 1
2 项目概述 2
2.1 产品描述 2
2.2 产品功能 2
2.3 用户特点 2
2.4 一般约束 2
2.5 假设和依据 3
3 具体需求 3
3.1 功能需求 3
3.1.1 功能需求1 3
3.1.2 功能需求2 4
3.1.n 功能需求n 5
3.2 外部接口需求 5
3.2.1 用户接口 5
3.2.2 硬件接口 5
3.2.3 软件接口 5
3.2.4 通信接口 6
3.3 性能需求 6
3.4 设计约束 6
3.4.1 其他标准的约束 6
3.4.2 硬件的限制 7
3.5 属性 7
3.5.1 可用性 7
3.5.2 安全性 7
3.5.3 可维护性 7
3.5.4 可转移 ＼转换性 8
3.5.5 警告 8
3.6 其他需求 8
3.6.1 数据库 8
3.6.2 操作 8
3.6.3 场合适应性需求 9
4 附录 9

1 引言
1.1 编写目的
说明编写这份软件需求说明书的目的，指出预期的读者范围。
1.2 范围
说明：
a． 待开发的软件系统的名称；
b． 说明软件将干什么，如果需要的话，还要说明软件产品不干什么；
c． 描述所说明的软件的应用。应当：
1） 尽可能精确地描述所有相关的利益、目的、以及最终目标。
2） 如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。
1.3 定义
列出本文件中用到的专门术语的定义和缩写词的原词组。
1.4 参考资料
列出要用到的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 项目概述
2.1 产品描述
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2 产品功能
本条是为将要完成的软件功能提供一个摘要。例如，对于一个记帐程序来说，需求说明可以用这部分来描述：客房帐目维护、客房财务报表和发票制作，而不必把功能所要求的大量的细节描写出来。
有时，如果存在较高层次的规格说明时，则功能摘要可从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意：
a． 编制功能的一种方法是制作功能表，以便客房或者第一次读这个文件的人都可以理解；
b． 用方框图来表达不同的功能和它们的关系也是有帮助的。但应牢记，这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具。
2.3 用户特点
列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。
2.4 一般约束
本条对设计系统时限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括：
a． 管理方针；
b． 硬件的限制；
c． 与其他应用间的接口；
d． 并行操作；
e． 审查功能；
f． 控制功能；
g． 所需的高级语言；
h． 通信协议；
i． 应用的临界点；
j． 安全和保密方面的考虑。
2.5 假设和依据
本条列出影响需求说明中陈述的需求的每一个因素。这些因此不是软件的设计约束，但是它们的改变可能影响到需求说明中的需求。例如：假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，需求说明就要进行相应的改变。
3 具体需求
3.1 功能需求
3.1.1 功能需求1
对于每一类功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。由四个部分组成：
a． 引言
描述的是功能要达到的目标、所彩的方法和技术，还应清楚说明功能意图的由来和背景。
b． 输入
1) 详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）；
2) 操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整；
3) 指明引用接口说明或接口控制文件的参考资料。
c． 加工
定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明：
1) 输入数据的有效性检查；
2) 操作的顺序，包括事件的时间设定；
3) 响应，例如，溢出、通信故障、错误处理等；
4) 受操作影响的参数；
5) 降级运行的要求；
6) 用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；
7) 输出数据的有效性检查。
d． 输出
1) 详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；
2) 有关接口说明或接口控制文件的参考资料。
此外，对着重于输入输出行为的系统来说，需求说明应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。也就是说，这种情况犹如有限状态机。
3.1.2 功能需求2
．．．．．．
3.1.n 功能需求n
3.2 外部接口需求
3.2.1 用户接口
提供用户使用软件产品时的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求：
a． 对屏幕格式的要求；
b． 报表或菜单的页面打印格式和内容；
c． 输入输出的相对时间；
d． 程序功能键的可用性。
3.2.2 硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。
3.2.3 软件接口
在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或数学软件包），以及同其他应用系统之间的接口。对每一个所需的软件产品，要提供如下内容：
a． 名字；
b． 助记符；
c． 规格说明号；
d． 版本号；
e． 来源。
对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。
3.2.4 通信接口
指定各种通信接口。例如，局部网络的协议等等。
3.3 性能需求
从整体来说，本条应具体说明软件、或人与软件交互的静态或动态数值需求。
A． 静态数值需求可能包括：
1) 支持的终端数；
2) 支持并行操作的用户数；
3) 处理的文卷和记录数；
4) 表和文卷的大小。
B． 动态数值需求可能包括：欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。
所有这些需求都必须用可以度量的术语来叙述。例如，95％的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。
3.4 设计约束
设计约束受其他标准、硬件限制等方面的影响。
3.4.1 其他标准的约束
本项将指定由现有的标准或规则派生的要求。例如：
a． 报表格式；
b． 数据命名；
c． 财务处理；
d． 审计追踪，等等。
3.4.2 硬件的限制
本项包括在各种硬件约束下运行的软件要求，例如，应该包括：
a． 硬件配置的特点（接口数，指令系统等）；
b． 内存储器和辅助存储器的容量。
3.5 属性
在软件的需求之中有若干个属性，以下指出其中的几个（注意：对这些决不应理解为是一个完整的清单）。
3.5.1 可用性
可以指定一些因素，如检查点、恢复和再启动等，以保证整个系统有一个确定的可用性级别。
3.5.2 安全性
指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括：
a． 利用可靠的密码技术；
b． 掌握特定的记录或历史数据集；
c． 给不同的模块分配不同的功能；
d． 限定一个程序中某些区域的通信；
e． 计算临界值的检查和。
3.5.3 可维护性
规定若干需求以确保软件是可维护的。例如：
a． 软件模块所需要的特殊的耦合矩阵；
b． 为微型装置指定特殊的数据＼程序分割要求。
3.5.4 可转移 ＼转换性
规定把软件从一种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束等等。
3.5.5 警告
指定所需属性十分重要，它使得人们能用规定的方法去进行客观的验证。
3.6 其他需求
根据软件和用户组织的特性等，某些需求放在下面各项中描述。
3.6.1 数据库
本项对作为产品的一部分进行开发的数据库规定一些需求，它们可能包括：
a． 在功能需求中标识的信息类别；
b． 使用的频率；
c． 存取能力；
d． 数据元素和文卷描述符；
e． 数据元素、记录和文卷的关系；
f． 静态和动态的组织；
g． 数据保存要求。
注：如果使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里详细说明其用法。
3.6.2 操作
这里说明用户要求的常规的和特殊的操作。
A． 在用户组织之中各种方式的操作。例如，用户初始化操作；
B． 交互作用操作的周期和无人操作的周期；
C． 数据处理运行功能；
D． 后援和恢复操作。
注：这里的内容有时是用户接口的一部分。
3.6.3 场合适应性需求
这里包括：
a． 对给定场合或相关任务或操作方式的任何数据或初始化顺序的需求进行定义。例如，栅值，安全界限等等。
b． 指出场合或相关任务为特点，这里可以被修改以使软件适合特殊配制的要求。
4 附录
对一个实际的需求规格说明来说，若有必要应该编写附录。附录中可能包括：
a． 输入输出格式样本，成本分析研究的描述或用户调查结果；
b． 有助于理解需求说明的背景信息；
c． 软件所解决问题的描述；
d． 用户历史、背景、经历和操作特点；
e． 交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善；
f． 特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。
注：当包括附录时，需求说明必须明确地说明附录是不是需求要考虑的部分。

如何写软件项目需求说明书(2008-11-10 17:04:18)标签：杂谈 分类：软件项目需求

进入软件开发行业也有一段时间了，大大小小项目也接触了一些，对于怎么写好项目需求文档做一下总结，发表一下自己的看法。

1 获取需求：

作为需求方也就是甲方，通过语言描述或文档的方式将需求（系统需要提供的功能）提交给开发人员（需

求分析人员）。

获得需求的方式可以有多种多样：电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招

标书)，其实这些方法都是GET方式，我们可以通过以下两类技术手段来达到：GET(获取)和PUSH(引导、反

馈、激发)相互结合的方式来得到我们真正的需求，而这两个过程都是必须交互进行的，一般我们可以筛

选一名非常有经验(包括谈判技巧、深厚的业务和技术背景、人缘很好、勤奋努力)的人士担任需求工程

师，长期在客户那里工作。

2 需求分析人员，

（1）根据客户提供的文档或语言描述，将需求按功能划分，以用例图的方式表达系统提供的功能模块及

功能模块之间的关系，完成用例图后与客户确认大的功能模块，并对每个功能模块做进一步的沟通

详细记录用户所提供的关键性的描述，此过程需要系统分析人员对客户进行引导。

（2）对每个功能模块进行详细分析与描述，具体信息包括：用户角色、功能说描述、IPO的方式进行描

述（即输入项、输出项、处理）、要提供必要的功能说明，如果使文档更加直观，更容易让客户理

解，可以用UI的方式表达输入输出，配合必要的描述，这样对于客户更加容易理解，需要与客户进

行大量的沟通确认。

（3）编写数据字典：在需求阶段，很难使团队的思路一致，建立一个合适的机制是完全必要的，这就是

数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定

义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术

语。分析和设计工具通常包括数据字典组件。

（4）关于文档具体表述的格式与形式，要根据所要表达的功能来确定，最重要的是把事情描述清楚,

这事最终的目的；

(5) 需求文档确定后，设计人员根据这份需求文档进行系统的设计工作了。

软件需求说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。假如任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。

1。完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

2。正确性

每一项需求都必须准确地陈述其要开发的功能。做出正确判定的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

3。可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

4。必要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

5。划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。假如把所有的需求都看作同样重要，那么项目治理者在开发或节省预算或调度中就丧失控制

6。无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

7。可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。假如需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。