需求之系统用例规约.ppt

* 书写路径步骤的注意事项 主语只能是主执行者或者是系统。 写需求，就是把系统看作一个黑箱，描述它对外提供的功能和约束。 例子： 执行者请求前端系统做某事，前端系统请求后端系统做某事（错误） 执行者请求客户端做某事，客户端请求服务器做某事（错误） * 书写路径步骤的注意事项 使用核心域概念。 路径步骤是功能需求，应该使用核心域的概念来描述。 例子： 系统建立连接，打开连接，执行SQL，从“零件”表查询（错误，因为涉及技术） 系统根据查询条件搜索零件（正确） * 书写路径步骤的注意事项 不要涉及交互设计的细节。 错误例子： 会员从下拉框中选择类别 会员在文本框中输入查询条件 会员单击“确定”按钮 这些界面细节很可能不是需求，只是开发人员选择的解决方案—设计，应该把它们删掉，然后问“为什么”，背后隐藏的才是涉众在意的、真正的需求，也许是非功能需求中的可用性需求“操作次数不超过5次”，也许是非功能需求中的可用性需求“反馈速度应该在3秒以内”。 * 书写路径步骤的注意事项 不要涉及交互设计的细节。 需求是问“不这样行吗”，而不是问“这样行吗”。 * 书写路径步骤的注意事项 不要写系统不能负责的事情。 错误例子： 顾客付款 收银员找零 以上两个是系统无法感知和承诺的。 * 扩展路径 执行者的选择。 执行者需做出选择，选择结果不同，带来的交互也不同。 例子： 1.会员请求查看订单 2.系统反馈会员的订单列表 3.会员可以取消订单 4.会员选择查看订单，请求查看明细 5.系统反馈订单明细 3a.会员取消订单： 3a1.会员请求取消订单 3a2.系统取消订单 * 扩展路径 系统验证。 验证必然有成功有失败，失败的情况下，系统肯定要处理，否则验证就是多余的了。 * 扩展路径 关键步骤失败。 如果不处理关键步骤的失败，执行者无法了解用例的进展。 * 补充约束 字段列表。 字段列表用来描述某个领域概念的细节。 讲座信息=时间+地点+专家+主题+简介 也可以引进一些符号 注册信息=公司+联系人+电话+{联系人地址}* 客房状态={空闲|已预订|占用|维修中} * 补充约束 业务规则。 业务规则描述步骤中系统运算的一些规则。 软工货物送达日期超过计划中的交付日期，扣减15%的金额 合同的总金额不超过买方的信用额度 * 非功能需求 可用性。 如果系统按照程序员的意图工作，并且完成能完成任务，但用户不喜欢用。 人事专员第一次使用时30分钟内能学会添加新员工 * 非功能需求 性能。 性能表示做得多好，性能指标包括速度、容量、能力等。 系统能在0.5秒之内拍摄超速车的照片（速度） 应允许1000个执行者同时使用本用例（容量） 在标准工作负荷下，系统的CPU占用率应少于50%（能力） * 非功能需求 可靠性。 可靠性表示系统的安全性和完整性。可靠性通常用平均无故障时间和平均修复时间表示。 * 非功能需求 可支持性。 可支持性表示系统升级和修复的能力。 95%的紧急错误应能在30工作时内修复 在修复故障时，未修复的相关缺陷平均数应小于0.5 升级新版本时，应保存所有系统设置和个人设置 * 非功能需求 设计约束。 设计约束是在实现系统时必须要遵守的一些约束，包括界面样式、表格格式、平台、语言等。 用oracle数据库保存数据，因为客户已经采购了许多oracle数据库，如果不用，成本就会增加。 * 案例 用例编号：UC1 用例名：执行通知任务 执行者：时间（主） 前置条件：存在待执行的通知任务 后置条件：系统已发出通知 涉众利益： UMLChina：担心发送太慢；担心邮箱被封杀 技术专家：担心通知内容不准确，夸大其词，损害自己的声誉 学员：担心骚扰信息太多 * 案例 基本路径： 1.当到达时间周期是，系统定位下一个发件邮箱以及下一个待执行的通知任务项。 2.系统使用发件邮箱向通知任务项的邮件发送地址发送电子邮件 3.系统记录邮件发送情况 扩展路径： 1a。没有待执行的通知任务项： 1a1：用例结束 1b。没有发件邮箱： 1b1：系统提示没有发件邮箱 * 案例 字段列表： 2.发件邮箱=发件人称呼+发件人地址+用户名+密码+SMTP服务器+POP3服务器 2.通知任务项=邮件地址+称呼 3.邮件发送情况=通知任务项+发送时间+发送邮件+成功与否 业务规则： 1.定位规则：从通知任务中找到正在生效的通知任务，然后从该通知任务中未出现过发送错误的通知任务项中随机抽取一个任务项。发送邮箱定位规则：按字母排序，顺序选择。 非功能需求： *从1到3在30秒以内 设计约束： 无 * 案例 用例编号：UC2 用例名：为公开课创建通知任务 执行者：公司助理（主） 前置条件：无 后置条件：系统已为公开课生成通知任务 涉众利益： UMLChina：担心尺度把握不好引起反感，担心通知不能到达