软件需求说明书规格模板

1、文档编号 文档版本 项目阶段 文档密级××××需求说明书恒星-飞邻研发中心需求说明书编号：编写：校对：审核：标审：批准： 日期：变更记录日期版本说明作者注： 对文档内容增加、 删除或修改均需填写此变更记录，详细记载变更信息，以保证其可追 溯性。1. 引言 61.1. 目的 61.2. 范围 61.3. 参考文档 61.4. 假定和相关性 62. 用例模型概述 92.1. 简介 92.2. 用例模型分层结构 92.3. 用例模型图 93. 需求 93.1. 功能性需求 93.2. 非功能性需求 93.2.1. 系统需求 103.2.2. 性能需求 103.

2、2.3. 安全性需求 103.2.4. 软件质量属性 104. 在线用户文档和帮助系统需求 105. 设计约束 106. 接口 106.1. 用户接口 116.2. 硬件接口 116.3. 软件接口 116.4. 通信接口 117. 许可需求 118. 可应用标准 119. 附录 1：词汇表 错误 ! 未定义书签。10. 简介 错误! 未定义书签。10.1. 目的. 错误! 未定义书签。10.2. 范围. 错误! 未定义书签。10.3. 参考资料 . 错误! 未定义书签。10.4. 概述. 错误! 未定义书签。11. 定义 错误! 未定义书签。11.1. <第一条词汇> . 错误!

3、 未定义书签。11.2. <第二条词汇> . 错误! 未定义书签。11.3. <一组词汇 > . 错误! 未定义书签。1.1.1. <第一组词汇> 错误! 未定义书签。1.1.2. <第二组词汇> 错误! 未定义书签。11.4. <另一组词汇> . 错误! 未定义书签。1.1.3. <第三组词汇> 错误! 未定义书签。1.1.4. <第四组词汇> 错误! 未定义书签。12. 附录 2：用例报告. 1113. 简要说明 1214. 事件流 1214.1. 基本事件流 . 121.1.1. <分支流名称 &g

4、t; 1214.2. 备选事件流 . 121.1.2. <分支流名称 > 1214.3. 特殊需求 . 121.1.3. <特殊需求名称 > 1215. 前置条件 1215.1. <前置条件名称 > . 1316. 后置条件 1316.1. <后置条件名称 > . 1317. 扩展点 1317.1. <扩展点名称 > . 1318. 关系 1319. 用例图 1320. 其他图 1421. 附录 3：数据字典. 1422. 附录 4：界面原型. 141. 引言引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且 如何阅

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

6、语此文档用于定义问题领域的专用术语，并解释用例说明或其他项目文档的读者 可能尚不熟悉的术语。此文档通常可用作非正式的数据字典来收集数据定义，从而 使项目参与人员更好的理解用例说明和其他项目文档。可以采用下面的格式进行说 明：1.5.1 简介词汇表的简介应提供整个文档的概述。请在本节提供读者理解此文档所需的任何信息。1.5.2 目的阐明该词汇表的目的。1.5.3 范围简要说明该词汇表的范围：它的相关项目，以及受到此文档影响的任何其他事 物。1.5.4 参考资料本小节应完整地列出此词汇表中其他部分所引用的所有文档。每个文档应标有 标题、报告号（如果适用） 、日期和发布组织。列出可从中获取这些引用的

7、来源。这 些信息可以通过引用附录或其他文档来提供。1.5.5 概述本小节应说明该词汇表中其他部分所包含的内容，并解释此文档的组织方式。1.5.6 定义此处定义的术语形成了此文档的基础。它们可以按任意顺序定义，但字母顺序 通常最便于查找。第一条词汇 ><第一条词汇 > 的定义在此处提供。应提供读者理解该概念所需的全部信息。第二条词汇 ><第二条词汇 > 的定义在此处提供。应提供读者理解该概念所需的全部信息。一组词汇 >有时，可利用术语分组来提高可读性。例如，如果问题领域包含与建筑项目的 统计和建设两方面都相关的术语（当开发建筑项目管理系统时就会出现这种情

8、况） ， 提供两个不同子领域中的术语会使读者混淆不清。为了解决这种问题，我们采用了 术语分组的方法。 当提供分组术语时， 应提供一段简短说明来帮助读者理解 <一组词 汇>的含义。为了便于查找，同组内的术语应按字母顺序排列。第一组词汇 ><第一组词汇 > 的定义在此处提供。应提供读者理解该概念所需的全部信息。第二组词汇 ><第二组词汇 > 的定义在此处提供。应提供读者理解该概念所需的全部信息。另一组词汇 >第三组词汇 >该术语的定义在此处提供。应提供读者理解该概念所需的全部信息。第四组词汇 >该术语的定义在此处提供。应提供读者理解

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

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

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

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

13、组件可以是购买的组件、重用其他应用程序的组件或本需求范围之外与本系统交互的其他子系统。6.4. 通信接口 描述与其他系统或设备的通信接口，如局域网或远程串行设备。7. 许可需求定义系统必须体现的所有许可证生效需求或其他使用限制需求。8. 可应用标准引用所有应用于系统的标准 （以及标准的特定部分） 。例如，可能包括法律、质量、规章标准以及产业可用性、互操作性、国际化、操作系统兼容性等标准。9. 附录 1：用例报告 描述需求模型中的每个用例。如果没有采用工具进行描述，必须在此逐一进行描述。以下的模板可以做为基础。修正记录日期问题描述作者年/月/日.细节描述作者名注：每个用例前都有一个修正记录9.1 简要说明包含对用例的简要说明9.2 事件流其中包含用例的事件流。虽然子流程指明只有一个层次，但您可以根据需要添 加更多的层次。基本事件流1.1.1. <分支流名称 >9.2.2 备选事件流1.1.2. <分支流名称 >9.3 特殊需求用例的特殊需求。1.1.3. <特殊需求名称 >对特殊需求的简要说明。9.4 前置条件用例的前置条件9.5 < 前置条件名称 >对前置条件的简要说明。9.6 后置条件用例的后置条件。9.7 < 后置条件名称 >对后置条件的简要说明。9.8 扩展点用例的扩展