需求规格说明书(HLX-SPI-RD-Tem-SRS-V1.0).docVIP

文件类别：模板[过程文件/使用指南/相关模板/参考案例] 文件版本：1.0 文件编号： [PROCESS/GUIDE/TEMPLATE/CASE]_[PP/PMC/…]_ 需求规格说明书 受控状态：受控 文档密级：普通 文档状态：[ ] 草案 [√]正式发布 [ ]正在修订 变更履历 序号 版本 变更描述 修订人/日期 审核/日期 批准/日期 目 录 1 前言 4 1.1 目的 4 1.2 项目信息 4 1.3 范围 4 1.4 术语 4 1.5 参考文献 4 2 整体说明 4 3 非功能需求 5 3.1 运行环境 5 3.2 可用性 5 3.2.1 前言 目的 项目信息 说明： 待开发的软件系统的名称； 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； 该软件系统同其他系统或其他机构的基本的相互来往关系。 范围 说明本文档所描述的范围和受其影响的事物和文档。 术语 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 参考文献 列出用得着的参考资料，如： 本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 整体说明 提供本文详述的各种需求的背景，以使这些需求便于理解。所包括的内容有： 目的：叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。 产品架构：解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张图来说明该系统的组成和本产品同其他各部分的联系和接口。 用户特点： 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。 假设与依赖关系：说明所有重要的技术可行性假设、子系统或构件可用性假设，或者可作为此需求规格说明书所述软件可行性的基础的其他与项目有关的假设。 非功能需求 运行环境 说明产品需要的运行环境，例如：硬件、软件、通讯等的配置。 可用性 此节应包括所有影响可用性的需求。例如， 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数或根据用户已知或喜欢的其他系统确定新系统的可用性需求 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求 安全性 确定需要保护的数据； 确定各种数据所受到的安全威胁的类型： 意外的损坏或破坏 故意的损坏或破坏 商业间谍行为 欺骗 黑客行为 病毒 是否有一般性的政策可能会影响该系统的安全性设计； 确定哪些人可能是这些威胁的来源； 确定任何特殊的安全性需求，尤其是对以下方面的需求： 对系统的访问 对数据的加密 可审核性 可靠性 对系统可靠性的需求应在此处说明。建议如下： 可用性 - 指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 平均故障间隔时间 (MTBF) - 通常表示为小时数，但也可表示为天数、月数或年数。 平均修复时间 (MTTR) - 系统在发生故障后可以暂停运行的时间。 精确度 - 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 最高错误或缺陷率 - 通常表示为 bugs/KLOC（每千行代码的错误数目）或 bugs/function-point（每个功能点的错误数目）。 错误或缺陷率 - 按照小错误、大错误和严重错误来分类：需求中必须对“严重”错误进行界定（例如：数据完全丢失或完全不能使用系统的某部分功能）。 性能 [此节应概述系统的性能特征。其中需包括具体的响应时间。如果可行，按名称引用相关用例。 对事务的响应时间（平均、最长） 吞吐量（例如每秒处理的事务数） 容量（例如系统可以容纳的客户或事务数） 降级模式（当系统以某种形式降级时可接受的运行模式） 资源利用情况：内存、磁盘、通信等。] 可支持性 [此节应列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标准、命名约定、类库、维护访问权和维护实用程序。] 设计约束 [此节应列出所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。] 联机用户文档和帮助系统需求 [如果存