需求规格说明书HLXSPIRDTemSRSV.doc

文件类别：模板文件版本：1.0 文件编号： 需求规格说明书需求规格说明书 受控状态：受控 文档密级：普通 文档状态： 草案 正式发布 正在修订 变更履历变更履历 序号序号版本版本变更描述变更描述修订人修订人/ /日期日期审核审核/ /日期日期批准批准/ /日期日期 1 2 3 4 5 6 7 8 9 10 目目 录录 1 1前言前言 4 4 1.1目的.4 1.2项目信息.4 1.3范围.4 1.4术语.4 1.5参考文献.4 2 2整体说明整体说明 4 4 3 3非功能需求非功能需求 5 5 3.1运行环境.5 3.2可用性.5 3.2.1 5 3.3安全性.5 3.3.1 5 3.4可靠性.6 3.4.1 6 3.5性能.6 3.5.1 6 3.6可支持性.6 3.6.1 6 3.7设计约束.7 3.7.1 7 3.8联机用户文档和帮助系统需求.7 3.9购买的构件.7 3.10接口/界面7 3.10.1用户界面/报表格式 .7 3.10.2硬件接口 7 3.10.3软件接口 7 3.10.4通信接口 7 3.11许可需求.8 3.12法律、版权及其他声明.8 3.13适用的标准.8 4 4功能需求功能需求 8 8 4.1功能需求一 8 4.1.1用例 ID 用例一.8 5 5开发环境的配置开发环境的配置 9 9 6 6运行环境的配置运行环境的配置 9 9 7 7测试环境的配置测试环境的配置 1010 8 8未决事宜未决事宜 1010 9 9附件附件: : 1010 1 1前言前言 1.11.1目的目的 此处描述了编制本文档的目的，指出预期的读者。 1.21.2项目信息项目信息 说明： 待开发的软件系统的名称； 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； 该软件系统同其他系统或其他机构的基本的相互来往关系。 1.31.3范围范围 说明本文档所描述的范围和受其影响的事物和文档。 1.41.4术语术语 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.51.5参考文献参考文献 列出撰写需求规格说明书时使用到的参考文献 列出用得着的参考资料，如：本文件中各处引用的文件、资料、包括所要用到的 软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够 得到这些文件资料的来源。 2 2整体说明整体说明 提供本文详述的各种需求的背景，以使这些需求便于理解。所包括的内容有： 目的：叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明 的有关该软件开发的背景材料。 产品架构：解释被开发软件与其他有关软件之间的关系。如果本软件产品是一 项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个 更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间 的关系，为此可使用一张图来说明该系统的组成和本产品同其他各部分的联系 和接口。 用户特点： 列出本软件的最终用户的特点，充分说明操作人员、维护人员的 教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重 要约束。 假设与依赖关系：说明所有重要的技术可行性假设、子系统或构件可用性假设， 或者可作为此需求规格说明书所述软件可行性的基础的其他与项目有关的假设。 3 3非功能需求非功能需求 3.13.1运行环境运行环境 说明产品需要的运行环境，例如：硬件、软件、通讯等的配置。 （这部分内容必须有。） 3.23.2可用性可用性 此节应包括所有影响可用性的需求。例如， 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统 的可用性需求 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标 准）方面的需求 （这部分内容必须有。） 3.2.1 在此给出需求说明。 3.33.3安全性安全性 确定需要保护的数据； 确定各种数据所受到的安全威胁的类型： 意外的损坏或破坏 故意的损坏或破坏 商业间谍行为 欺骗 黑客行为 病毒 是否有一般性的政策可能会影响该系统的安全性设计； 确定哪些人可能是这些威胁的来源； 确定任何特殊的安全性需求，尤其是对以下方面的需求： 对系统的访问 对数据的加密 可审核性 （这部分内容必须有。） 3.3.1 在此给出需求说明。 3.43.4可靠性可靠性 对系统可靠性的需求应在此处说明。建议如下： 可用性 - 指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模 式操作等。 平均故障间隔时间 (MTBF) - 通常表示为小时数，但也可表示为天数、月数或 年数。 平均修复时间 (MTTR) - 系统在发生故障后可以暂停运行的时间。 精确度 - 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知 的标准）。 最高错误或缺陷率 - 通常表示为 bugs/KLOC（每千行代码的错误数目）或 bugs/function-point（每个功能点的错误数目）。 错误或缺陷率 - 按照小错误、大错误和严重错误来分类：需求中必须对“严重” 错误进行界定（例如：数据完全丢失或完全不能使用系统的某部分功能）。 3.4.1 在此给出需求说明。 3.53.5性能性能 此节应概述系统的性能特征。其中需包括具体的响应时间。如果可行，按名称引用 相关用例。 对事务的响应时间（平均、最长） 吞吐量（例如每秒处理的事务数） 容量（例如系统可以容纳的客户或事务数） 降级模式（当系统以某种形式降级时可接受的运行模式） 资源利用情况：内存、磁盘、通信等。 3.5.1 在此给出需求说明。 3.63.6可支持性可支持性 此节应列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标 准、命名约定、类库、维护访问权和维护实用程序。 3.6.1 在此给出需求说明。 3.73.7设计约束设计约束 此节应列出所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计 决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购 买的构件、类库等。 3.7.1 在此给出需求说明。 3.83.8联机用户文档和帮助系统需求联机用户文档和帮助系统需求 如果存在对联机用户文档、帮助系统、关于声明的帮助等的需求，请在此说明。 3.93.9购买的构件购买的构件 此节说明在系统中使用的所有购入构件、所有适用的许可或使用限制，以及所有相 关的兼容性及互操作性或接口标准。 3.103.10 接口接口/ /界面界面 此节规定应用程序必须支持的接口/界面。它应非常具体，包含协议、端口和逻辑 地址等，以便于按照接口/界面需求开发并检验软件。 3.10.1 用户界面用户界面/报表格式报表格式 说明软件将实现的用户界面/报表格式。 3.10.2 硬件接口硬件接口 此节指出软件所支持的所有硬件接口，其中包括逻辑结构、物理地址、预期行为等。 3.10.3 软件接口软件接口 此节说明软件系统中与其他构件之间的软件接口。这些构件可以是购入的构件、取 自其他应用程序重新利用的构件，也可以是为此 SRS 范围之外的子系统开发，但该软 件应用程序必须与之交互的构件。 3.10.4 通信接口通信接口 说明与其他系统或设备（如局域网、远程串行设备等）的所有通信接口。 3.113.11 许可需求许可需求 定义所有许可执行需求或软件将体现的其他使用限制需求。 3.123.12 法律、版权及其他声明法律、版权及其他声明 此节说明软件涉及的所有必需的法律免责声明、保证、版权声明、专利声明、字标、 商标或徽标符合性问题。 3.133.13 适用的标准适用的标准 通过引用，此节说明了所有适用的标准以及适用于所述系统的相应标准的具体部分。 例如，其中可以包括法律、质量及法规标准；业界在可用性、互操作性、国际化、操作 系统相容性等方面的标准。 4 4功能需求功能需求 4.14.1 功能需求一功能需求一 用例图可以借助可视化建模工具（如 Rational Rose）来开发。用例报告（带有所 有特征）可以用 Rational SoDA 来生成。有关详细信息，请参见Rational Unified Process 中的工具向导。 可以增加时序图,状态图. 4.1.1用例用例 ID 用例一用例一 这一节应包括所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些 需求的系统，并使测试人员能够测试该系统是否满足这些需求。 以自然语言风格表达的需求说明为此设计的系统功能性需求。通常按特性来组织， 但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。 当利用应用程序开发工具（如需求工具、建模工具等）来获取功能时，文档将引用 获取相应数据的方法，并指出用来获取数据的工具的位置和名称。 必须让用户、设计人员、测试人员对需求的理解无二义性。 需求编号生成规则参考需求开发过程文件（HLX-SPI-RD-Proc-Doc）中相关模 板文件需求ID编写规范部分。 4.1.1.1 简要说明简要说明 说明中应简要表述用例的作用和目的。一个段落即足以作此说明。 4.1.1.2 事件流事件流 描述需求的事件流 4.1.1.3 业务规则业务规则 特殊需求通常是非功能性需求，它为一个用例所专有，但很难或很自然的在用例 的事件流文本中表述。特殊需求的示例包括法律或法规方面的需求、应用程序标准和所 构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。此外，其他需求 如操作系统及环境、兼容性需求和设计约束也应在此节中记录。 运行模式，频率,输 入,输出量等信息。 4.1.1.4 功能关联功能关联 描述本功能中与其他功能有关联的地方。例如该功能中的某些特性会影响到哪些功 能的业务规则或操作等 4.1.1.5 非功能需求非功能需求 功能的非功能性需求包括：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性 和高效性 5 5开发环境的配置开发环境的配置 提示：提示：说明本系统应当在什么样的环境下开发，有什么强制要求和建议？ 类别标准配置最低配置 计算机硬件 软件 网络通信 其它 6 6运行环境的配置运行环境的配置 提示：提示：说明本系统应当在什么样的环境下运行，有什么强制要求和建议？ 类别标准配置最低配置 计算机硬件 软