《ATM机系统》.docVIP

ATM机系统 补充规约 版本 1.0 修订历史记录 日期 版本 说明 作者 2002/5/6 1.0 初稿 傅纯一 目录 1. 简介 2 1.1 目的 2 1.2 范围 2 1.3 定义、首字母缩写词和缩略语 2 1.4 参考资料 2 1.5 概述 2 2. 功能 2 2.1 功能性需求一 2 3. 可用性 2 3.1 可用性需求一 2 4. 可靠性 2 4.1 可靠性需求一 2 5. 性能 2 5.1 性能需求一 2 6. 可支持性 2 6.1 可支持性需求一 2 7. 设计约束 2 7.1 设计约束一 2 8. 联机用户文档和帮助系统需求 2 9. 购买的构件 2 10. 接口 2 10.1 用户界面 2 10.2 硬件接口 2 10.3 软件接口 2 10.4 通信接口 2 11. 许可需求 2 12. 法律、版权及其他声明 2 13. 适用的标准 2 补充规约 简介 [补充规约的简介应提供整个文档的概述。它应包括此补充规约的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。 此补充规约获取不便于在用例模型的用例中获取的系统需求。这些需求包括： 法律和法规上的需求，包括应用标准。 要构建的系统的质量属性，包括可用性需求、可靠性需求、性能需求和可支持性需求。 其他需求，如操作系统及环境、兼容性需求和设计约束。] 目的 [阐明此补充规约的目的。] 范围 [简要说明此补充规约的范围、它的相关项目，以及受到此文档影响的任何其他事物。] 定义、首字母缩写词和缩略语 [本小节应提供正确解释此补充规约所需的全部术语的定义、首字母缩写词和缩略语。?这些信息可以通过引用项目词汇表来提供。] 参考资料 [此小节应完整列出补充规约中其他部分所引用的所有文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。] 概述 [此小节应说明补充规约其他部分所包含的内容，并解释文档的组织方式。] 功能 [此节为以自然语言风格表达的需求说明为此设计的系统功能性需求。对于许多应用程序，此节会成为 SRS 包的主体部分，所以应仔细考虑此节的组织方式。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。功能性需求可以包括特性集、功能和安全性。 当利用应用程序开发工具（如需求工具、建模工具等）来获取功能性时，此节文档将引用获取相应数据的方法，并指出用来获取数据的工具的位置和名称。] 功能性需求一 [需求说明。] 可用性 [此节应包括所有影响可用性的需求。例如： 指出普通用户和高级用户要高效地执行特定操作所需的培训时间 指出典型任务的可评测任务次数，或者 指出在符合公认的可用性标准（如 IBM 的 CUA 标准和 Microsoft 的 GUI 标准）方面的需求] 可用性需求一 需求说明。 可靠性 [对系统可靠性的需求应在此处说明。建议如下： 可用性 – 指出可用时间百分比 ( xx.xx%)、使用小时数、维护访问权、降级模式操作等。 平均故障间隔时间 (MTBF) – 通常表示为小时数，但也可表示为天数、月数或年数。 平均修复时间 (MTTR) – 系统在发生故障后可以暂停运行的时间。 精确度 – 指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）。 最高错误或缺陷率 – 通常表示为 bugs/KLOC（每千行代码的错误数目）或 bugs/function-point（每个功能点的错误数目）。 错误或缺陷率 – 按照小错误、大错误和严重错误来分类：需求中必须对“严重”错误进行界定（例如：数据完全丢失或完全不能使用系统的某部分功能）。] 可靠性需求一 [需求说明。] 性能 [此节应概述系统的性能特征。其中需包括具体的响应时间。如果可行，按名称引用相关用例。 对事务的响应时间（平均、最长） 吞吐量（例如每秒处理的事务数） 容量（例如系统可以容纳的客户或事务数） 降级模式（当系统以某种形式降级时可接受的运行模式） 资源利用情况：内存、磁盘、通信等。] 性能需求一 [需求说明。] 可支持性 [此节应列出将提高所构建系统的可支持性或可维护性的所有需求，其中包括编码标准、命名约定、类库、维护访问权和维护实用程序。] 可支持性需求一 [需求说明。] 设计约束 [此节应列出所构建系统的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、构架及设计约束、购买的构件、类库等。] 设计约束一 [需求说明。] 联机用户文档和帮助系统需求 [如果存在对联机用户文档、帮助系统、关于声明的帮助等的需求，请在此说明。] 购买的构件 [此节说明在系统中使用的