软件需求规格说明书模版

文件变化记录单

*变化状态：A——增加，M——修改，D——删除

文件批准单

1.     引言

提出对软件需求规格说明书的纵览，帮助读者理解文档如何编写并且如何阅读和解释。

1.1         编写目的

对产品（也可能是项目，但是我们统称为产品）进行定义，在该文档中详尽说明这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明书只与整个系统的一部分有关，那么只定义文档中说明的部分或子系统。

1.2         文档约定

描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。例如，说明高层需求的优先级是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有优先级。

1.3         预期的读者和阅读建议

列举软件需求规格说明书所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员等。描述文档中剩余部分的内容及其组织结构。提出最适合每一类型读者阅读文档的建议。

1.4         产品的范围

提供对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目范围文档，而不是将其内容复制到这里。

1.5         参考资料

列举编写软件需求规格说明书时所参考的资料或其它来源。可能包括用户界面风格指导、合同、标准、系统需求规格说明书、用户需求、相关产品的软件需求规格说明书。这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。

2.     综合描述

这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。

2.1         产品的前景

描述软件需求规格说明书中所定义的产品的背景和起源。说明该产品是否是产品系列中的下一个成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个全新的产品。

如果软件需求规格说明书定义了大系统的一个组成部分，那么就要说明这部分软件是怎样与整个系统相关联的，并且要定义出两者之间的接口。建议使用系统结构图或者实体关系图表示。

2.2         产品的功能

概述产品所具有的主要功能，详细内容在第4节描述，所以这里只需要概括总结，例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系。

建议使用数据流程图（DFD）的顶层图或类图来实现图形化。

2.3         用户类和特征

确定可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。

2.4         运行环境

描述软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或者与其共存的应用程序。

2.5         设计和实现上的限制

确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。可能的限制包括：

w  必须使用或者避免的特定技术、工具、编程语言、数据库；

w  经费、进度、资源等方面的限制；

w  所要求的开发规范或标准；

w  企业策略、政府法规或工业标准；

w  硬件限制，例如定时需求或存储器限制；

w  数据转换格式标准。

w  其它。

2.6         假设和依赖

列举出在对软件需求规格说明书影响需求陈述的假设因素。可能包括打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另外一个分析员却不这么认为。如果这些假设不正确、不一致或者被更改，都会使项目受到影响。

此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖哪个项目能否按时提供正确的组件。如果这些依赖已经记录到其它文档（如项目计划）中了，那么在此就可以参考其它文档。

2.7         关键点

说明本软件需求规格说明书中的关键点（例如：关键功能、关键算法和所涉及的关键技术等）。

3.     外部接口需求

确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接口。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应该把这些外部接口的详细要求并入到这一部分的实例中。

3.1         用户界面

陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可能要包括的一些特征：

w  将要采用的图形用户界面标准或产品系列的风格；

w  屏幕布局或解决方案的限制；

w  将出现在每个屏幕的标准按钮、功能或导航链接；

w  快捷键；

w  错误信息显示标准。

对于用户界面的细节，例如特定对话框的布局，建议写入一个独立的用户界面规格说明中，不要写入软件需求规格说明书中。

3.2         硬件接口

描述系统中软件和硬件每个接口的特征。可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。

3.3         软件接口

描述产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或信息的目的，描述所需要的服务以及内部组件通信的性质，确定将在组件之间共享的数据。如果必须用一种特殊的方法来实现数据共享机制，那么就必须把它定义为一种实现上的限制。

3.4         通信接口

描述与产品所使用的通信功能相关的需求，包括电子邮件、WEB浏览器、网络通信标准或协议及电子表格等，定义相关的信息格式、规定通信安全或加密问题、数据传输速率和同步通信机制。

4.     功能需求

4.1         功能分类

[将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。也可以用功能结构图表示]

 

4.2         系统特性Feature A

4.2.1 说明和优先级

提出对该系统特性的简短说明并指出该特性的优先级是高、中还是低。

4.2.2 功能需求

详细列出与该特性相关的功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的用例执行任务。描述产品如何响应可预知的出错条件或非法输入或动作。

4.2.2.1       功能 function A.1

（1）说明

本功能的简要说明

（2）角色

   本功能的执行人员

（3）前置条件

   该功能启动的前提条件

（4）输入

描述本功能的输入信息（包括需要访问的存储信息）。

（5）过程

对本功能将做什么进行详细的描述。

（6）输出

描述本功能的输出信息（包括需要访问的存储信息）。

（7）后置条件

   该功能结束的退出条件

（8）业务规则

列举出与该功能相关的操作规则。例如什么人在特定环境下可以进行何种操作。

4.2.2.2       function A.1 图书借阅

（1）说明

借阅人通过此功能向系统查询并提交借书请求

（2）角色

   借阅人

（3）前置条件

w  借阅人借阅证件在有效期内

w  借阅人没有逾期未归还的图书

（4）输入

借阅证

（5）过程

（6）输出

费用记录

借阅定单

（7）后置条件

w  创建借书定单

w  更新借阅人借阅记录

（8）业务规则

每次每人至少选择一本,至多选择三本

 

4.3         系统特性Feature B

………

5.     非功能需求

5.1         性能需求

阐述不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员做出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系；还要定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。也可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们集中在一起陈述。例如：“在运行WINDOWS 2000的450MHZ Pentium II 的计算机上，当系统至少有50%的空闲资源时，95%的目录数据库查询必须在两秒内完成”。

5.2         安全性需求

陈述与系统安全性、完整性或私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。明确产品必须满足的安全性或保密性策略。一个软件系统的安全需求的范例如下：“每个用户在第一次登录之后，必须更改他的最初登录密码。最初的登录密码不能重用。”

5.3         软件质量属性

详尽陈述与客户或开发人员至关重要的质量特性。这些特性必须是确定、定量的并可验证的。至少应指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植性优于有效性。

5.4         其它需求

定义至今未出现的需求。例如国际化需求、法律上的需求、有关操作、管理、维护、安装、配置、启动、关闭、修复、容错、登录、监控等等方面的需求。说明本产品在可使用性、可维护性、可移植性、可靠性和安全性等方面的要求。

6.     数据字典

6.1         实体关系图

6.2         实体定义

指出数据项名、定义、项结构组成、项范围、项类型。

 

7.     业务规则与业务算法

7.1         业务规则

列举出有关产品的所有操作规则。例如什么人在特定环境下可以进行何种操作。这些规则不是功能需求，但它们可以暗示某些功能需求执行这些规则。业务规则的范例如下：

“只有持有管理员密码的用户才能执行100元以上的退款操作”。

 

借出规则说明: 读者已借书数未超过最大借书数、该书有库存，而且该读者拥有借阅该书的权限，则执行该操作。

 

罚款规则说明：

1.超期罚款：超期天数＊超期罚款率。

2.丢失罚款：图书价格＊丢失赔率

7.2         算法说明

用于实施系统计算功能的公式和算法的描述，类似于业务规则。如某神州行套餐的计费标准说明。

a.　每个主要算法的概况；

b.　用于每个主要算法的详细公式。

 

附录A：分析模型（也可以纳入 4功能需求章节中描述）

包括或涉及到相关的分析模型的位置，例如数据流图、类图、状态转换图等。

顶层数据流图：

第1层数据流图：

第2层数据流图：

附录B：待确定问题的列表

编辑一张在软件需求规格说明书中待确定问题的列表，其中每一表项都是编上号的，以便跟踪调查。

附录C：编写文档的原则

编写文档时，要求具有本规范规定的所有条目如果某条目无内容，则填写“无”，并在可能的情况下说明理由。必要时，可增加适当的条目。

编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是技术术语的方式得以改进。你在编写需求文档时，应牢记以下几点建议：

Ø  保持语句和段落的简短；

Ø  采用主动语态的表达方式；

Ø  语法正确，句子完整；

Ø  使用的术语与词汇表中所定义的术语一致；

Ø  避免模糊的、主观的术语如用户友好、容易、简单、迅速、有效、许多、最新技术、优越的、可接受的、健壮的等等；

Ø  避免使用比较性的词汇如提高、最大化、最小化、最佳化等。定量说明所需要提高的程度或者说清一些参数可以接受的最大值和最小值。含糊的语句表达将引起需求的不可验证。

Ø  由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的需求影响了设计。如果你能用不同的方法来满足需求，并且这种方法是可接受的，那么需求的详细程度也就足够了。然而，如果评审需求规格说明书的设计人员对客户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。

Ø  需求文档的编写人员总是力求寻找到恰如其分的需求详细程度。一个有益的原则就是编写单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求，那么就达到了合理的详细程度。如果你预想的测试很多并且很分散，那么就要将一些集合在一起的需求分离开。

Ø  必须以相同的详细程度编写每个需求文档。

Ø  不应该把多个需求集中在一个冗长的叙述段落中。在需求中，诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。不要在需求说明中使用“和/或”，“等等”之类的连词。

Ø  不应该出现需求的冗余。

 

 

第二篇：软件需求规格说明书模板V1.1

修订历史

版本 说明 编制 批准 批准日期

1.1 初次编写 SEPG

目 录

1. 引言 1

1.1. 背景 1

1.2. 参考资料 1

1.3. 假定和约束 1

1.4. 用户的特点 1

2. 功能需求 1

2.1. 系统范围 1

2.2. 系统体系结构（二层架构的系统可剪裁本小节）

2.3. 系统总体流程 2

2.4. 需求分析 2

2.4.1. XXXXXXX(功能需求名称) 2

2.4.1.1. 功能描述 2

2.4.1.2. 业务建模 2

2.4.1.3. 用例描述 3

2.4.1.4. 用户界面 5

2.4.2. XXXXXXX(功能需求名称) 5

3. 非功能需求 5

3.1. 性能要求 5

3.1.1. 精度 5

3.1.2. 时间特性要求 6

3.1.3. 输人输出要求 6

3.2. 数据管理能力要求 6

3.3. 安全保密性要求 6

3.4. 灵活性要求 6

3.5. 其他专门要求 6

4. 运行环境规定 6

4.1. 设备 6

4.2. 支持软件 7

4.3. 接口 7

4.4. 控制 7

5. 需求跟踪 7

6. 签批单 7

1. 引言 1

1.1. 背景

说明：

a．待开发的软件系统的名称；

b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

C．该软件系统同其他系统或其他机构的基本的相互来往关系。

1.2. 参考资料

列出本说明书中引用和参考的资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文；

b．属于本项目的其他已发表的文件；

c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

1.3. 假定和约束[可选]

列出进行本软件开发工作的假定和约束，例如经费限制、开发期限、设备条件、用户的资料准备和交流上的问题等。

1.4. 用户的特点[可选]

列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。

2. 功能需求

2.1. 系统范围

明确概要地说明用户对系统、产品高层次的目标要求，如系统开发的意图、应用目标、作用范围以及其他相关的背景材料。

如果所定义的产品是一个更大系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。

2.2. 系统体系结构（二层架构的系统可剪裁本小节）[可选]

以图+文本结合的方式描述系统的总体架构。

以下应提供系统总体架构图：

以下对系统总体架构进行描述：

2.3. 系统总体流程

以图+文本结合的方式说明系统的总体流程。

图一是计划合同管理系统的总体流程图。

图一

2.4. 需求分析

需求分析的目的是获取或描述系统需求中的每一个功能需求，并通过分析确定系统能够做什么？谁来使用这个系统？

· 建立用例模型：发现角色和用例，并确定角色之间的关系、用例之间的关系，以及角色与用例之间的相互关系

· 描述用例：角色与系统如何交互的规格说明。

2.4.1. XXXXXXX(功能需求名称)

2.4.1.1. 功能描述

功能编号：

功能需求：从用户业务的角度描述功能需求。

2.4.1.2. 业务建模

从可视化的角度--用例图--描述功能需求

图二是综合计划管理系统合同编辑业务的功能需求用例图。

图二

2.4.1.3. 用例描述

以文本的方式描述每一个用例中角色与系统相互交互的规格说明。

1、 XXXXXX(用例名称)

描述对象 描述内容

标识符 用例的唯一标识符

说明 对用例的概要说明

参与者 与该用例相关的参与者列表，以及参与者的特点

频度 参与者访问此用例的频率

状态 通常分为：进行中、等待审查、通过审查或未通过审查

前置条件 一个条件列表，如果其中包含条件，则这些条件必须在访问用例之前得到满足

后置条件 一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后得到满足

被扩展的用例 此用例所扩展的用例（如果存在）

被包含的用例 此用例所包含的用例（如果存在）

基本操作流程 参与者在用例中所遵循的主逻辑路径，即当各项工作都正常进行时用例的工作方式 可选操作流程 在变更工作方式、出现异常或发生错误的情况下所遵循的路径

修改历史记录 修改人 ： 修改日期：修改原因：

问题 如果存在，则为与此用例的开发相关的问题或操作项目的列表

以下是综合计划管理系统中的合同编辑功能需求中的合同增加用例描述：

描述对象 描述内容

标识符 IPMS0101

说明 增加一条合同记录

参与者 合同编辑人员--熟悉合同管理业务

频度

状态 通过审查

前置条件 1. 参与者具有合同增加的权限2. 参与者已选取对应的计划记录3. 当前计划总投资≥SUM(该计划下已签合同价)

后置条件 1. 数据库中更加一条合同纪律2. 可执行合同原件扫描用例3. 可执行合同付款增加用例4. 可执行合同修改和合同删除用例

被扩展的用例 无

被包含的用例 无

基本操作流程 请参见图三的合同增加流程

可选操作流程 当用户确认合同增加时发现异常时，系统提示合同增加无效的提示

修改历史记录 修改人 ： 修改日期：修改原因：

问题 1. 合同编码的具体约定2. 合同类型、资金来源、合同受委托方字典表的具体设计

图三 合同增加活动流程

2、XXXXX(用例名称)

……

2.4.1.4. 用户界面

概要描述功能对应的用户界面风格，采用原型生命周期的项目也可以提供原型界面拷贝。

2.4.2. XXXXXXX(功能需求名称)

……

3. 非功能需求

3.1. 性能要求

3.1.1. 精度[可选]

说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。

3.1.2. 时间特性要求

说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和界面更新传送时间等的要求。

3.1.3. 输人输出要求

解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

3.2. 数据管理能力要求[可选]

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。

3.3. 安全保密性要求

用户对系统所应具备的故障处理能力、处理方式及故障后的系统恢复、数据恢复等要求，对系统防止机密数据被非法侵入、修改及丢失的要求。

3.4. 灵活性要求[可选]

说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．操作方式上的变化；

b．运行环境的变化；

c．同其他软件的接口的变化；

d．精度和有效时限的变化；

e．计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.5. 其他专门要求[可选]

如用户单位对使用方便的要求，对可维护性、可补充性、易读性、可靠性、异常处理要求、运行环境可转换性的特殊要求等。

4. 运行环境规定

4.1. 设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：

a．处理器型号及内存容量；

b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；

c．输入及输出设备的型号和数量，联机或脱机；

d．数据通信设备的型号和数量；

e．功能键及其他专用硬件

4.2. 支持软件

列出支持软件,包括网络和硬件设备平台、操作系统平台、数据库系统平台以及编译（或汇编）程序和测试支持软件等。

4.3. 接口[可选]

说明该软件同其他软件之间的接口、数据通信协议等。

4.4. 控制[可选]

说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。

5. 需求跟踪

需求跟踪的主要目的是保证所有的需求都得到分析，以承诺需求-分析需求对应表（PRS_SRS表）的方式描述已分析需求对已承诺需求的覆盖情况。PRS_SRS表的格式请参见软件需求管理过程规范（SUPL-MANU-SRS-001）。

6. 签批单

我已阅读上述软件需求规格说明书，我将严格遵守说明书中的条款，并保证全力支持该规格说明书的实施。

执行主管:

日期

技术主管:

日期

项目组长:

日期

用户代表:

日期

开发人员代表:

日期

小组成员:

日期

小组成员:

日期