软件需求说明书规格模板

1、文档编号： 文档版本： 项目阶段： 文档密级： 需需 求求 说说 明明 书书 恒星-飞邻研发中心 . . * 需求说明书需求说明书 编号：编号： 编写：编写： 校对：校对： 审核：审核： 标审：标审： 批准：批准： 日期：日期： . . 变更记录变更记录 日期日期版本版本说明说明作者作者 注：对文档内容增加、删除或修改均需填写此变更记录，详细记载变更信息，以保证其可 追溯性。 . . 目 录 1.引言 .4 1.1.目的.4 1.2.范围.4 1.3.参考文档.4 1.4.假定和相关性.4 2.用例模型概述 .5 2.1.简介.5 2.2.用例模型分层结构.5 2.3.用例模型图.5 3.需求

2、 .6 3.1.功能性需求.6 3.2.非功能性需求.6 3.2.1.系统需求 .6 3.2.2.性能需求 .6 3.2.3.安全性需求 .6 3.2.4.软件质量属性 .7 4.在线用户文档和帮助系统需求 .7 5.设计约束 .7 6.接口 .7 6.1.用户接口.7 6.2.硬件接口.8 6.3.软件接口.8 6.4.通信接口.8 7.许可需求 .8 8.可应用标准 .8 9.附录 1：词汇表.9 10.简介 .9 . . 10.1.目的.9 10.2.范围.9 10.3.参考资料.9 10.4.概述.10 11.定义 .10 11.1.10 11.2.10 11.3.10 1.1.1.

3、.10 1.1.2. .11 11.4.11 1.1.3. .11 1.1.4. .11 12.附录 2：用例报告.12 13.简要说明 .12 14.事件流 .12 14.1.基本事件流.13 1.1.1. .13 14.2.备选事件流.13 1.1.2. .13 14.3.特殊需求.13 1.1.3. .13 15.前置条件 .13 15.1.13 16.后置条件 .14 16.1.14 17.扩展点 .14 17.1.14 . . 18.关系 .14 19.用例图 .15 20.其他图 .15 21.附录 3：数据字典.16 22.附录 4：界面原型.17 . . 1. 引言 引言提出了

4、对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且 如何阅读和解释。 1.1. 目的 指定这个软件需求规格说明的目的。软件需求规格说明应该完整地描述确定的 应用或子系统的所有外部行为，以及非功能性需求、设计约束和其他必要因素，提 供一个完整、全面的软件需求描述。 1.2. 范围 对软件需求规格说明适用的软件系统、特征或子系统分组、与其相关的用例模 型以及其他所有受到这个文档的影响或影响这个文档的一切进行简明描述。 1.3. 参考文档 给出一个列出所有与项目有关的引用或支持这个项目的可应用文档的清单。 1.4. 假定和相关性 这一部分描述所有关键技术可行性、子系统或者组件的可得到性或其他

5、与项目 有关的假定，这个文档描述的软件的生存能力可能以其为基础。 1.5. 术语 此文档用于定义问题领域的专用术语，并解释用例说明或其他项目文档的读者 可能尚不熟悉的术语。此文档通常可用作非正式的数据字典来收集数据定义，从而 使项目参与人员更好的理解用例说明和其他项目文档。可以采用下面的格式进行说 明： . . 1.5.11.5.1 简介 词汇表的简介应提供整个文档的概述。请在本节提供读者理解此文档所需的任 何信息。 1.5.2 目的 阐明该词汇表的目的。 1.5.3 范围 简要说明该词汇表的范围：它的相关项目，以及受到此文档影响的任何其他事 物。 1.5.4 参考资料 本小节应完整地列出此词

6、汇表中其他部分所引用的所有文档。每个文档应标有 标题、报告号（如果适用） 、日期和发布组织。列出可从中获取这些引用的来源。 这些信息可以通过引用附录或其他文档来提供。 1.5.5 概述 本小节应说明该词汇表中其他部分所包含的内容，并解释此文档的组织方式。 1.5.6 定义 此处定义的术语形成了此文档的基础。它们可以按任意顺序定义，但字母顺序 通常最便于查找。 1.5.7 的定义在此处提供。应提供读者理解该概念所需的全部信息。 . . 1.5.8 的定义在此处提供。应提供读者理解该概念所需的全部信息。 1.5.9 有时，可利用术语分组来提高可读性。例如，如果问题领域包含与建筑项目的 统计和建设两

7、方面都相关的术语（当开发建筑项目管理系统时就会出现这种情况） ， 提供两个不同子领域中的术语会使读者混淆不清。为了解决这种问题，我们采用了 术语分组的方法。当提供分组术语时，应提供一段简短说明来帮助读者理解的含义。为了便于查找，同组内的术语应按字母顺序排列。 1.5.9.1 的定义在此处提供。应提供读者理解该概念所需的全部信息。 1.5.9.2 的定义在此处提供。应提供读者理解该概念所需的全部信息。 1.5.10 1.5.10.1 该术语的定义在此处提供。应提供读者理解该概念所需的全部信息。 1.5.10.2 该术语的定义在此处提供。应提供读者理解该概念所需的全部信息。 . . 2.用例模型概

8、述 2.1. 简介 对用例模型的简介。 2.2. 用例模型分层结构 本部分分层显示用例包，解释它们之间的依赖关系，并循环显示各用例包的内 容。如果模型的包分为多个级别，则首先显示那些位于顶级的包。然后再向下依次 显示这些包中的包，直至层次最低的那些包。对于各包来说，包括： 名称。 一个简要说明，解释该包在系统中的功能和角色。此说明必须让所有要使用该 包的开发人员看懂。 该包所拥有的用例列表，包括各用例的名称及简要说明。 该包所拥有的主角列表，包括各主角的名称及简要说明。 该包所拥有关系的列表，包括各种关系的名称及简要说明。 直属该包的包列表，其中各包都按上述分层方式显示。 2.3. 用例模型图

9、 其中包括了整个用例模型的图（主要是用例图）。 3. 需求 3.1. 功能性需求 这部分描述系统的功能型需求，这些需求用自然语言风格表示。 这部分可以采用建模工具来进行描述，描述将主要以用例报告的方式进行。用 例报告应包括的内容见附录 1。 3.2. 非功能性需求 在软件需求规格说明的这一部分，大多数非功能性需求都是用自然语言描述的。 但非功能性需求也可以包含在用例报告的特殊需求中。 . . 3.2.1. 系统需求 描述为支持系统应用所必须的所有系统需求，包括操作系统、网络平台、配置、 外设以及软件等。 3.2.2. 性能需求 性能需求包括用户负载因素、带宽或通信能力、吞吐量、准确度、可靠性或

10、在 某些负载条件下的响应时间等。 3.2.3. 安全性需求 详尽陈述与系统安全性、完整性或与私人问题相关的需求。这些问题将会影响 到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。 明确产品必须满足的安全性或保密性策略。 3.2.4. 软件质量属性 详尽陈述与客户或开发人员至关重要的其它产品质量特性。这些特性必须是确 定、定量的并在可能时是可验证的。至少应指明不同属性的相对侧重点。质量属性 包括：有效性、效率、灵活性、完整性、互操作性、可靠性、健壮性、可用性等。 4. 在线用户文档和帮助系统需求 列举出与软件相关的用户文档部分，如：用户手册、在线帮助、教程。明确所 有已知

11、用户档的交付格式或标准。 5. 设计约束 这部分要指明对所构建系统的所有设计约束。设计约束代表强制性设计决策， 必须服从。例如包括软件语言、软件过程需求、预定的开发工具、体系结构和设计 约束、购买的第三方组件等。 6. 接口 这部分定义系统必须支持的接口。这一部分应该包含足够的说明、协议、端口 . . 和逻辑地址等，以便根据接口需求开发和验证软件。 6.1. 用户接口 描述软件要实现的用户界面。用绘图工具绘制的图片或者交互式的可执行原型 来进行描述，如果有必要，可以对界面进行文字说明。 6.2. 硬件接口 定义软件必须支持的硬件接口，包括逻辑结构、物理地址和预期的行为。 6.3. 软件接口 描

12、述软件系统与其他组件的软件接口。其他组件可以是购买的组件、重用其他 应用程序的组件或本需求范围之外与本系统交互的其他子系统。 6.4. 通信接口 描述与其他系统或设备的通信接口，如局域网或远程串行设备。 7. 许可需求 定义系统必须体现的所有许可证生效需求或其他使用限制需求。 8. 可应用标准 引用所有应用于系统的标准（以及标准的特定部分） 。例如，可能包括法律、 质量、规章标准以及产业可用性、互操作性、国际化、操作系统兼容性等标准。 9. 附录 1：用例报告 描述需求模型中的每个用例。如果没有采用工具进行描述，必须在此逐一进行 描述。以下的模板可以做为基础。 修正记录 . . 日期问题描述作

13、者 年/月/日.细节描述作者名 注：每个用例前都有一个修正记录 9.1 简要说明 包含对用例的简要说明。 9.2 事件流 其中包含用例的事件流。虽然子流程指明只有一个层次，但您可以根据需要添 加更多的层次。 9.2.19.2.1 基本事件流基本事件流 1.1.1. 9.2.2 备选事件流 1.1.2. 9.3 特殊需求 用例的特殊需求。 1.1.3. 对特殊需求的简要说明。 9.4 前置条件 用例的前置条件。 . . 9.5 对前置条件的简要说明。 9.6 后置条件 用例的后置条件。 9.7 对后置条件的简要说明。 9.8 扩展点 用例的扩展点。 9.9 定义扩展点在事件流中的位置。 9.10 关系 其中包含涉