第讲需求获取.ppt

4.4 创建框架用例 目的： 为了避免需求工程师过早陷入细节而忽视全局，先创建框架用例再填充，非一次完成每个用例的所有细节。 本活动的目标： 提取框架用例，并通过它们完整地覆盖用户需求面。 * * 创建框架用例 创建框架用例的子活动如下： ①策划并实施用例调查； ②以框架用例记录用例调查的结果； ③创建用例图； ④整合并评审框架用例。 ? 框架用例的主要创建者是需求工程师（团队）。用户和客户是本活动的重要参与者，负责提供相关的信息和咨询，其中至少应有一人能够扮演业务领域专家的角色。 * * 例4.5 框架用例 针对家庭保安系统，其框架用例有?“命令响应”和“传感器监测”。? 用例名：命令响应。 业务目标：响应用户的开关机、复位命令、配置命令及系统运行日志查询命令。 执行者：用户。 业务规则1：在关机、复位及更改配置数据前必须输入正确的用户密码。 业务规则2：处于报警状态时，系统不响应配置命令。 性能需求：用户命令的响应时间小于1.5秒。? 用例名：传感器监测。 业务目标：接收并判别来自传感器的数据是否正常，一旦发现异常即报警。 执行者：各类传感器，警报器，报警电话，显示器。 可靠性需求：误报率小于2%，漏报率小于1%。 * * 例4.6 质量需求清单及调查结果⑴ 类别 质量需求项名称 需求描述 说明 性能 Req-Performance-001 用户命令的响应时间小于1.5秒。 Req-Performance-002 异常发生与报警之间的时间差不超过3秒。 可靠性 Req-Reliability-001 每周7天、每天24小时可用；在硬件无故障的前提下软件正常运行时间比在99.9%以上。 Req-Reliability-002 异常误报率小于2%，漏报率小于1%。 Req-Reliability-003 本软件的任何故障不可导致配置信息和日志数据的丢失。故障后系统在60秒内恢复正常。 易用性 Req-EasyUse-001 用户可自行理解用户手册；通读用户手册后，勿需培训，即可使用本软件。 Req-EasyUse-002 用户在通读安装手册后，勿需培训，通过安装向导即可成功安装本软件。 * * 质量需求清单及调查结果⑵ 类别 质量需求项名称 需求描述 说明 安全性 认证需求 Req-Authentication-001 在通过密码验证后方可使用本软件。 权限控制需求 Req-Authorization-001 在关机、复位、更改配置数据及查看系统运行日志前必须输入正确的用户密码。 审计性需求 Req-Audit-001 本软件需记录系统运行日志，日志信息包括开、关机、复位时间，配置命令执行情况，发生的异常事件，以供审计。 兼容性 与相关标准的兼容性 Req-Compatibility-001 遵循数字家居领域的相关业界标准，包括…… 版本兼容性 Req-Compatibility-002 版本升级时新版本完全兼容旧版本。 * * 质量需求清单及调查结果⑶ 类别 质量需求项名称 需求描述 说明 可配置性 Req-Config-001 设定传感器的数量、类型、安装位置，门窗传感器的灵敏度、烟雾浓度阈值以及报警电话号码等配置参数均可定制；支持不同品牌门窗传感器和烟雾传感器 可扩展性 Req-Extend-001 未来可能的扩展：系统接入Internet，用户可远程发送命令、查看安全状态；扩展视频监控功能。 可伸缩性 Req-Scalability-001 目前最多支持50个传感器；以后增至500个支持楼宇安全监控，要求软件系统不需修改即可适应传感器数量的增大。 互操作性 暂无要求。 本地化与国际化 Req-Intl-001 支持中文和英文两种界面，用户可在任一界面进行语言切换。 可移植性 本软件将来需移植至……环境运行。 * 国防科技大学计算机学院 * 4.4.3 创建用例图 UML用例图可以用来表示执行者与用例之间的关系、用例之间的关系、执行者之间的关系。 需求工程师主要关注执行者与用例之间的关系，待后面适当的时机再对这里创建的初步的用例图进行精化。 例4.7 用例图 例4.5，家庭保安系统的用例有“命令响应”和“传感器监测”，其执行者有“用户”、“传感器”、“控制面板”、“警报器”和“报警电话”。 前两类执行者为主动执行者，后三类为被动执行者。见图4.9。 * * 图4.9 家庭保安系统的（初步）用例图 * * 4.4.4 整合并评审框架用例 整合和评审的目的： 检查所有的框架用例联合起来是否足以覆盖利益相关方的所有功能需求，是否遗漏重要的非功能需求。 完整覆盖的标准： 假设所有用例和非功能需求全部实现，目标软件系统的业务目标和价值是否得以实现？ 是否遗漏了位于目标软件系统的范围之内的功能？ * * 4.5 精化用例