腾讯从概念到产品 需求分析过程全解.ppt

63 Good News ：天下文章一大抄 ? 在一个产品系统中，性能需求是可以 Copy 的 ? 第一份性能需求是重点，大家一起作 ? 之后的需求文档往往只需改变： – 性能指标 – 可扩展性 – 易用性 – 可延展性 – 安全性 – 兼容性 – 可维护性 – 可移植性 – 可编程性 – 可靠性 – 可测试性 这里简简单单几句话要求， 让开发同事、设计师作半年 …… 64 需求规格说明书 65 没有高质量的需求 软件就象一个巧克力的盒子 你不会知道你将要得到什么 66 高质量需求叙述的特性 ? 正确 ? 可行性 ? 必要性 ? 优先权 ? 明确 ? 可证实 31 Use Case ：标记方法简单 Actor 名称 Use Case 名称 32 Use Case ：主动角色 经纪人 下单 投资人 报价审查 货币存取 经纪管理系统 33 Use Case ：被动角色 经纪人 下单 投资人 报价审查 货币存取 经纪管理系统 银证转账系统 34 画 Use Case 图规则 ? 主动角色画在图的左边 ? 被动角色画在图的右边 ? 每个 Use Case 必须为用户提供确切的功能 ? Use Case 名称必须写在椭圆里面 ? 保持图面整洁 ? 每一张图里不能有太多的 Use Case ? 为每一个 Use Case 编号便于检索 ? 为 Use Case 建立目录（编号和名称）便于管理 35 Use Case 高级概念 36 Use Case 高级概念 ? 通过分析 Use Case 图，分析人员可以找出不同 的业务过程之间的共性 – 扩展、包含、派生、使用等关系 ? 通过这些关系可以降低系统的复杂度 ? 为重用提供了条件 ? 将共性提出来，可以帮助我们发现重复的过程 – 二次开发应该关注的地方 37 Actor 的继承 ? 类似于 Use Case 的扩展， 角色之间可以继承 ? 其他银行不仅具有储户的 所有功能，还有其他的功 能 查询余额 存钱 储户 银行 取钱 费用结算 其他银行 38 Actor 继承的好处 ? 在不丢失信息的前提下，简化了 Use Case 图 ? 继承说明了角色间的层次关系 ? 派生者继承了父角色的所有能力 ? 父角色不知道派生者 39 扩展关系： extend ? 扩展关系通常用来表示某一个 Use Case 的可选择部分 – 扩展关系允许分析人员在没有改变基 Use Case 的情况下增加或修改基 Use Case 的功能 – 复杂的可替代途径应该使用扩展关系把它们分成多个 Use Case ? 也可以这样看扩展关系： – 在基 Use Case 上插入功能，而基 Use Case 本身不知道这个扩展 使用柜员 机 查询余额 《扩展》 用户选择查询余额 40 扩展关系 (extend ) 示图 查询余额 存钱 柜员机用户 柜员机 取钱 使用柜员 机 《扩展》 用户选择查询余额 《扩展》 用户选择存钱 《扩展》 用户选择取钱 41 使用关系 ? 如果 Use Case A 包含 Use Case B ，表示在执行 Use Case 的动作序 列过程中，在某一点上将开始执行 Use Case B 的动作序列，完 成后将回到同一点上继续执行完 Use Case A 的动作序列 ? 它与扩展关系的区别是： – 扩展是可选的 – 包含是必做的（更象一个子过程） ? 和扩展关系一样，一个 Use Case 可以包含很多个子 Use Case ， 也可以被很多个父 Use Case 所包含 存钱 打印单据 《包含》 42 包含关系 (include) 示例 1. 输入员工信息 2. 输入工资额 3. 输入职位 4. 保存 5. 系统进行合法化检查 6. 如果正常，系统建立 新的员工记录 1. 摄像 2. 插入空白卡 3. 新建工卡 包含的插入点 父功能夹 “ 增加新员工 ” 子功能夹 “ 新建工卡 ” 43 包含关系 (include) 示图 查询余额 存钱 柜员机用户 柜员机 取钱 使用柜员 机 《扩展》 用户选择查询余额 《扩展》 用户选择存钱 《扩展》 用户选择取钱 打印单据 《包含》 《包含》 44 关于扩展和包含关系 45 Use Case 发掘实操 46 Use Case 发掘过程 ? 定义 Actor ? 发掘 Actor 使用系统的脚本 Script ? 总结 Use Case 组合 ? 研究 Actor 之间的继承关系 ? 研究 Use Case 之间的 include 、 extend 关系 ? 贯穿始终：维护一套词汇表 }CE 47 词汇表！词汇表！ ? 词汇表有多重要 ? – 可以建巴别塔 – 代码中的变量 – 需求文档的重要组成部分和线索 ? 维护词汇表应该是产品团队最重要的工作之一