(word)[模板]系统需求说明书.docVIP

系统需求说明书模板 Version 0.1 核准签名 核准人 项目经理 日期 核准人 系统分析师 日期 核准人 客户 日期 核准人 日期 核准人 日期 核准人 日期  修订历史 日期 版本 描述 作者 2010-11-30 0.1 草稿 谭勇 目录 1 介绍 4 1.1 编写目的 4 1.2 适用范围 4 1.3 文档概述 4 1.4 定义、术语及缩写 4 1.5 参考 4 2 系统定位 5 2.1 问题说明 5 2.2 系统定位 5 2.3 涉众说明 5 3 系统概述 5 3.1 系统总体效果 5 3.2 假设与依赖关系 5 3.3 系统特性 6 3.3.1 系统特性1 6 3.3.2 系统特性2 6 4 其他系统需求 6 4.1 系统质量需求 6 4.1.1 性能 6 4.1.2 可靠性 7 4.1.3 可维护性 7 4.1.4 可用性 7 4.1.5 灵活性 8 4.1.6 可移植性 8 4.1.7 可重用性 8 4.1.8 可测试性 8 4.1.9 易用性 9 4.2 安全性需求 9 4.3 保密性和私密性需求 9 4.4 环境需求 10 4.5 适用的标准 10  介绍 编写目的 [说明编写这份文件的目的，并简要描述本文档的目的。] 适用范围 [说明这份文件的适用范围及其阅读对象，列举软件需求说明所针对的不同读者，例如项目负责人、开发人员、部门主管、对方项目负责人、用户、测试人员或文档的编写人员。提出最适合于每一类型读者阅读文档的建议。] 示范：―――仅供参考，不具备任何实质性的内容。 本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：项目负责人、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。 文档概述 本文档主要描述了XXXXXXXXXX系统项目的系统需求。 定义、术语及缩写 [列出本文档所涉及的专业术语、缩写词及相关定义。 定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个部门创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。] 术语/缩写 定义 参考 [列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。] 文档名称 文档标题 系统定位 问题说明 [概要描述本系统正在解决的问题。] 系统定位 [概要描述本系统的目的和重要性。] 涉众说明 [概要描述本系统的涉众和用户，以及关键的涉众/用户的需要。] 名称 描述 职责 涉众的名称 涉众的简单描述 列出涉众对所开发的系统负有的关键职责，即他们作为涉众的利益。 系统概述 系统总体效果 [应将该系统放在其他相关系统环境和用户环境中进行介绍。如果该系统自成一体，应在此处说明。如果该系统是较大系统的构件，此小节则应说明这些系统如何进行交互，并确定系统之间的相关接口。要显示较大系统的主要构件、互连情况和外部接口，一种简单的方法就是通过框图来表示。] 假设与依赖关系 [列出会影响文档中所述特性的所有因素。列出其变更将引起文档随之变化的假设。例如，有这样一项假设：将为该软件系统指定的硬件提供特定的操作系统。但如果没有提供该操作系统，就将需要更改文档。] 系统特性 [列出并简述系统的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。例如，问题跟踪系统的特性是能够提供趋势报告。当用例模型成型后，更新这里的说明以指代用例。 由于文档将由各种各样的相关人员来复审，所以不应太过详细，应让所有人对此都有大致的了解。但是，应该向团队提供他们创建用例模型所需的必要详细信息。 要有效地管理应用程序的复杂性，对于任何新系统或对现有系统的增量部分，我们建议将功能提炼到较高的程度，这样?25?到?99?项特性较为合理。这些特性为系统定义、规模管理和项目管理提供了基础。每项特性的详细程度都将在用例模型中得到较深入的扩展。 贯穿此节的始终，都应能让用户、操作人员或其他外部系统从外部觉察到每项特性。这些特性应包括功能性的说明以及必须考虑的任何相关的可用性问题。注意要避免设计。使特性说明保持一定的概括程度。侧重于说明所需的功能以及为什么要（而不是如何）实现这些功能。] 系统特性1 系统特性2 其他系统需求 系统质量需求 [本条应描述对系统或子系统质量方面的需求,例如包括性能（支持的用户数、操作响应速度、资源占用约束等）、可靠性(产生正确、一致结果的