7.设计约束.doc

卷号 卷内编号 密级 分类:REQ 使用者:项目组 ?托普集团,2001 LEDS 项目编号:S054-06-2001 Supplementary Specification Version 1.0 作者:黄煜  文档信息 项目名:LEDS 项目编号:S054-06-2001 标题:Supplementary Specification 作者:黄煜 创建日期:2001-08-17 上次更新日期:2001-08-29 版本:1.0 部门名称:中央研究院 文档状态 文档状态 ■草稿 □正式 文档评审人员 评审时间 修订文档历史记录 日期 版本 说明 作者 2001-8-17 1.0 补充规约 黄煜  目录 1. 简介 3 1.1 目的 3 1.2 范围 3 1.3 定义、首字母缩写词和缩略语 3 1.4 参考资料 3 1.5 概述 3 2. 功能 3 3. 可用性 4 3.1 普通用户使用该系统所需培训时间（Native） 4 3.2 高级用户管理该系统所需培训时间（Remote） 4 3.3 最终用户支持材料 4 4. 可靠性 4 4.1 平均故障间隔时间（MTBF） 4 4.2 平均修复时间（MTTR） 4 4.3 缺陷率 4 5. 性能 4 5.1 静态文本播放性能要求 4 5.2 全彩屏控制性能要求 4 5.3 屏体监测性能要求 4 5.4 每个节目单可包含节目数要求 5 5.5 节目内容切换间隔时间要求 5 5.6 网络文件下载要求 5 6. 可支持性 5 6.1 C++编码标准 5 6.2 功能扩展 5 6.3 语言版本支持 5 7. 设计约束 5 7.1 软件过程流程约束 5 7.2 运行平台约束 5 7.3 编程语言约束 5 7.4 网络带宽约束 5 7.5 可重用性、可扩展性约束 5 7.6 交付日期约束 5 7.7 用户界面设计约束 5 7.8 出错处理约束 6 8. 联机用户文档和帮助系统需求 6 9. 购买的构件 6 10. 接口 6 10.1 用户界面 6 10.2 硬件接口 6 10.3 软件接口 6 10.4 通信接口 7 11. 安全性 7 12. 许可需求 7 13. 法律、版权及其他声明 7 14. 适用的标准 7 Supplementary Specification 简介 目的 下列人员使用补充规约：系统分析员创建并维护补充规约，此规约用作系统分析员、客户和其他开发人员之间的交流媒介。 设计员对类定义职责、操作和属性并且调整类使其适应实施环境时引用补充规约。 实施员实施类时在补充规约中查找输入。 经理计划迭代时在补充规约查找输入。 测试员使用补充规约来核实系统的一致性。 定义、首字母缩写词和缩略语 SDK ：Software Development Kit 软件开发包 参考资料 《TOPGroup Unified Process》 《Rational Unified Process》 《LEDS-Stakeholder Requests》 《LEDS-Glossary》 《LEDS-Vision》 概述 补充规约记录那些在用例模型的用例中不容易体现出来的系统需求功能性需求之外的需求，有时称为非功能性需求说明系统或系统环境的属性。对于软件需求的完整定义，可以将用例和补充规约结合到一起以定义某一“特性”或其他子系统分组的软件需求规约 (SRS)。 系统功能需求描述参见 《LEDS-Use Case Model Survey》、系列《LEDS- Use Case Specification》 WORD格式文档，及 利用Rational Rose 2000 建立的LEDS用例模型。 可用性 普通用户使用该系统所需培训时间（Native） 1天 高级用户管理该系统所需培训时间（Remote） 2~3天 最终用户支持材料 方便、易用的联机帮助系统 详细的软件安装手册、用户操作手册 技术支持热线电话 可靠性 该系统的主控端通过网络连接被控端，进行远程控制，从而实现远端的无人化操作。实际中，在某些环境下，用户要求尽量减少对远端的人工干预，实现一定程度的自动化，因此，对本系统的可靠性提出了较高要求。 平均故障间隔时间（MTBF） 30天 平均修复时间（MTTR） 2小时 缺陷率 50 bugs/KLOC 性能 静态文本播放性能要求 1.文本显示应平滑无跳跃、闪烁感，特别是逐行上卷方式的文本播放； 2.文本的上卷速度、停留时间可控； 3.