需求分析用例 PPT课件

1 怎样描述用例 用例图是由哪些要素组成的 用例之间有什么样的关系 1 2 3 4 怎样撰写需求文档 基于用例的需求建模方法 2 采用 基于用例的方法 来识别和获取需求 是从外部的角度来看系统功能 建立系统的用例模型 整个工作的焦点集中在从用户的角度说明系统能够干什么 完全不考虑具体的实现细节 从而达到准确地理解客户需求的目的 基于用例的需求建模方法 3 用例图 4 用例图 用例图描述了系统的功能以及如何使用一个系统用例图显示谁将是相关的用户 用户希望系统提供什么服务用例图常用来描述系统以及子系统帮助开发团队以一种可视化的方法理解系统的功能需求 5 用例图的组成 用例图包含6个元素参与者 Actor 用例 UseCase 关联关系 Association 包含关系 Include 扩展关系 Extend 泛化关系 Generalization 6 参与者 参与者是指系统以外的 需要使用系统或与系统交互的事物 包括 人 设备 外部系统等 7 如何识别系统的参与者 谁将使用该系统的主要功能谁将需要该系统的支持以完成其工作谁将需要维护 管理该系统系统需要处理哪些硬件设备与该系统交互的是什么系统谁或什么系统对本系统产生的结果感兴趣 8 参与者间的关系 参与者是类 所以参与者之间可以具有类之间的关系在用例图中 使用泛化关系来描述多个参与者之间的公共行为 9 什么是用例 针对某个特定的外部用角 系统通过与其交互而执行的 能够产生可观测的 有价值的结果的一个动作序列 例 到数据库取某字段 对客户是不可理解和验证的 例 登录系统和输入密码哪个是有效的用例 10 如何表示用例 UML中用例用椭圆表示 用例命名的基本原则是 从参与者的角度出发进行命名使用动词加宾语的结构 尽量使用行业术语 登录 身份验证 交钱 报销 11 用例之间的关系 用例与参与者之间有关联 association 关系 用例之间的关系有 泛化 generalization 包含 include 扩展 extend 12 关联关系 Association 表示参与者在用例中的参与 也就是参与者实例与用例实例之间的相互通信 不同的参与者可以访问相同的用例 13 泛化关系是一般和特殊的关系子用例表示父用例的特殊形式子用例从父用例处继承行为和属性 还可以添加行为或覆盖 改变继承的行为 泛化关系 Generalization 14 同一业务目的 父用例 的不同技术实现 各个子用例 泛化关系 Generalization 15 在包含关系中 基本用例吸收了被包含的用例的行为 如果没有后者它将是不完整的 包含关系 include 包含关系的特点包含用例执行 则被包含用例必须执行 16 什么时候使用包含关系 如果两个以上的用例有大量一致的功能 则可以将这个功能分解到另一个用例中 实现功能代码的复用 其他用例可以和这个用例建立包含关系 包含关系使得我们在一个用例中局部化多个用况中共同的活动序列 这样 可以避免多次描述同一事件流 当这个共同的序列发生变化时 这样就显现出优势 即只需要在一个地方进行改动 包含关系 include 17 扩展用例被定义为基础用例的增量扩展扩展关系是把新的行为加入到已有的用例中去 扩展关系 extend 18 扩展关系的特点基础用例没有扩展用例也是完整的用例基础用例被执行时 一般不会涉及扩展用例 只有特定的条件发生 扩展用例才可能被执行 这是与包含关系的差别 扩展关系 extend 19 几种关系的比较 20 实例分析 语音邮箱系统 目标 构建一个语音邮箱系统问题描述 语音邮箱系统中 可以为每个系统用户 邮箱主人 分配一个语音邮箱号码 进行留言时 拨打语音邮箱系统的主号码 在听到提示音 请输入邮箱号 后 输入语音邮箱号 听到主人设定的问候语后 进行留言然后挂断电话 邮箱主人拨打语音邮箱系统的主号码 在听到提示音 请输入邮箱号 后 输入语音邮箱号 听到主人设定的问候语后 输入密码 进行邮箱管理 此时系统提供三种服务 1 接收信息 2 更改问候语 3 更改密码 其中接收留言包括收听新留言 存储留言 删除留言等 21 实例分析 语音邮箱系统 续 1 找出actor和外部系统 确定系统边界 参与者 呼叫者 邮箱用户2 主要功能分析 参与者期望的系统行为等 1 呼叫者保留信息 留言 2 邮箱用户管理信息 收听 存储 删除 3 邮箱用户更改问候语 4 邮箱用户更改密码 22 实例分析 语音邮箱系统 续 3 初步找到的用例呼叫者 保留信息邮箱主人 接收信息 更改问候语 更改密码4 进一步寻找用例邮箱主人 登录邮箱呼叫者 邮箱主人 拨打邮箱号码5 分析用例之间的关系本例较为简单 只使用 包含关系 即可 23 实例分析 语音邮箱系统 续 6 绘制初步用例图 24 绘制正确的用例图 用例是有意义的目标 25 系统需要处理的 由系统生成 绘制正确的用例图 26 绘制正确的用例图 用户的观点而非系统的观点 27 绘制正确的用例图 用例命名规则 命名用例一般是用 动词 名词 的方式 但要注意动词要选择有实际意义的词 而不要用一些对理解用例没有帮助的词 比如不要用这些动词 进行 使用 复制 加载 重复 可以使用 检索 打印 查询 名词不要选择那些意义不明确的词 数据 报表 表格 表单 系统 而应该用 成绩单 订单 零件 28 绘制正确的用例图 不要把步骤当用例 把执行者的动作当用例 把系统的活动当用例 29 要点 用例的粒度 1 用例要有路径 路径要有步骤 而这一切都是可观测的最常犯错误 粒度过细 陷入功能分解过细的粒度 一般都会导致技术语言的描述 而不再是业务语言 30 用例粒度 2 把步骤当用例把系统活动当用例 31 要点 用例的粒度 2 四轮马车 C Create R Read U Update D Delete 所有业务最终对会成为CRUD CRUD能为Actor提供价值 CRUD掩盖业务 锐变成关系数据库的建模 系统就是数据的增删改查 关心数据的存储和维护 反而忽略了用户的目的 32 要点 用例的粒度 3 如果确实是CRUD 如果CRUD不涉及复杂的交互 一个用例 管理 即可不管是C R U D 都是为了完成 管理 目标甚至很多种的基本数据管理都可以用一个用例表示 33 绘制正确的用例图 什么是完整的用例图 一个完整的用例图至少由三个部分组成 一个角色一个地方一件事情 比如描述一次网上购物 完整的用例图至少要包括 登录 检索 加入购物车 和 付款 34 UML用例图 绘图的建议 防止过度图形化用例的重点在于书写文本 而不是图和用例关系 不要花很多小时甚至几天讨论用例图和用例关系 35 用例的描述 用例描述是指对一个用例的功能进行的文字描述 是参与者与系统交互动作序列的说明 用例描述采用自然语言和同一种语法形式 一个简单的执行步骤描述参与者与系统的交互行为 要易于理解 其读者是开发人员 用户 项目经理 测试人员等 36 用例的描述 用例的描述应包含的内容用例的目标用例是怎么启动的参与者和用例之间的消息是如何传送的用例中除了主路径外 其他路径是什么用例结束后的系统状态其他需要描述的内容 描述用例时的原则是尽可能写得 充分 而不是形式化 完整或漂亮 37 用例的描述 38 脚本 脚本 scenario 指贯穿用例的一条单一路径 用于显示用例中的某个特殊情况 脚本是用例的实例 每个用例都包括一个主要脚本和多个次要脚本 脚本用具体的文字描述来表示 39 脚本 例 从绵阳去北京的过程可以有多种 场景 坐飞机 订票 去机场 登机 坐火车 买票 去车站 检票 驾车 用例 订货脚本1 订货进行顺利的脚本脚本2 相关货源不足的脚本脚本3 涉及购货者的信用卡被拒的脚本 40 语音邮箱系统 用例描述 用例1 拨打邮箱号参与者 呼叫者前置条件 呼叫者访问语音邮件系统后置条件 语音邮件系统发出问候语基本路径 1 呼叫者拨打语音邮件系统的主号码 2 语音邮件系统发出提示音 输入邮箱号码并加 号 3 呼叫者输入接收者的邮箱号 4 语音邮件系统发出问候语 已进入XX的邮箱 请留言 41 用例2 保留信息参与者 呼叫者前置条件 呼叫者完成邮箱号输入操作后置条件 语音邮件系统将记录的信息存放在接收者的邮箱中基本路径 1 呼叫者说出信息 2 呼叫者挂断电话 3 系统将记录的信息存放在接收者的邮箱中 语音邮箱系统 用例描述 42 用例3 登录系统参与者 邮箱用户前置条件 邮箱用户完成邮箱号输入操作后置条件 语音邮件系统播放邮箱菜单基本路径 1 邮箱用户键入密码并后跟 键 默认号码与邮箱号相同 2 语音邮件系统播放邮箱菜单 按1键接收信息 按2键更改密码 按3键更改问候语 扩展路径 1a 密码输入错误1a1 语音提示错误 请重新输入密码1a2 返回1 语音邮箱系统 用例描述 43 用例4 接收信息参与者 邮箱用户前置条件 邮箱用户完成登录操作 后置条件 语音邮件系统播放信息基本路径 1 邮箱用户选择 接收信息 菜单选项 2 语音邮件系统播放信息菜单 按1收听当前信息 按2存储当前信息 按3删除当前信息 按4返回邮箱菜单 3 邮箱用户选择 收听当前信息 菜单选项 4 语音邮件系统播放当前新信息 若无新信息 播放当前已有信息 注意 只播放 不删除 5 语音邮件系统播放信息菜单 6 用户选择 删除当前信息 则信息被永久删除 7 继续执行第3步 语音邮箱系统 用例描述 44 扩展路径 6a 用户选择 存储当前信息 6a1 当前信息从新信息队列中删除并添加到旧信息队列中 语音邮箱系统 用例描述 45 46 47 理清责任 48 49 50 51 Usecase WithdrawcashActor customer主事件流 储户插入ATM卡 并输入密码储户按 取款 按钮 并输入取款数目储户取走现金 ATM卡 收据储户离开 Usecase WithdrawcashActor customer主事件流 ATM系统获得ATM卡和密码设置交易类型为 取款 ATM系统获得取款金额输出现金 收据和ATM卡系统复位 书写用例文档 ATM系统 取款 用例的两个错误描述 只描述了actor的行为 只描述了System的行为 52 Usecase WithdrawcashActor customer主事件流 储户通过读卡机插入ATM卡ATM系统从卡上读取银行ID 账号 加密密码 并通过主银行系统验证银行ID和账号储户输入密码 ATM系统根据加密密码对输入密码进行验证储户按 取款 按钮 并输入取款数目 该数目应该为 5的倍数ATM系统通知主银行系统 传递账号和金额 并接收返回的确认信息和账户余额ATM系统输出现金 ATM卡和收据ATM系统记录交易到日志文件 ATM系统 取款 用例的正确描述 书写用例文档 53 54 55 56 UseCase BuySomething参与者 Customer主事件流 1 系统显示ID和密码窗口 2 顾客键入ID和密码 然后按OK键 3 系统验证顾客ID和密码 并显示个人信息窗口 4 顾客键入姓名 街道地址 城市 邮政编码 电话号码 然后按OK键 5 系统验证用户是否为老顾客 6 系统显示可以卖的商品列表 7 顾客在准备购买的商品图片上单击 并在图片旁边输入要购买的数量 选购商品完毕后按Done按钮 8 系统通过库存系统验证要购买的商品是否有足够库存 后续描述省略 书写用例文档 57 UseCase BuySomething参与者 Customer主事件流 1 顾客使用ID和密码进入系统 2 系统验证顾客身份 3 顾客提供姓名 地址 电话号码 4 系统验证顾客是否为老顾客 5 顾客选择要购买的商品和数量 6 系统通过库存系统验证要购买的商品是否有足够库存 后续描述省略 问题 对用户界面的描述过于详细 对于需求文档来说 详细的用户描述对获取需求并无帮助 书写用例文档 58 寻找用例的方法 找出系统外部的参与者和外部系统 确定系统的边界和范围 确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化 包含 扩展等关系处理系统行为的公共或变更部分 编制每一个用例的脚本 绘制用例图 区分主事件流和异常情况的事件流 如果需要 可以把表示异常情况的事件流作为单独的用例处理 细化用例图 解决用例间的重复与冲突问题 59 用例vsNFR 用例不是需求的全部与每个用例有关的非功能 特殊 需求可以放在用例文本的格式模版中 与用例的动作功能描述形成互补 NFR在用例文本描述之外 制作一份单独的文档 表格或数据库 列举除了用例之外的所有其他软件需求 NFR 补充规约等 60 软件需求规约 SRS 61 用例编号 用例名 前置条件后置条件涉众利益基本路径1 2 3 扩展2a 2a1 字段列表业务规则非功能需求设计约束待解决问题 使用用例组织的需求文档 62 总结 用例是最重要的一种需求形式 消除需求不明确 不一致 不完整的重要手段和关键技术 软件需求 FR NFR 用例 NFR需