从概念到产品需求分析过程知识课件.pptVIP

* Good News：天下文章一大抄 在一个产品系统中，性能需求是可以Copy的 第一份性能需求是重点，大家一起作 之后的需求文档往往只需改变： 性能指标 可扩展性 易用性 可延展性 安全性 兼容性 可维护性 可移植性 可编程性 可靠性 可测试性 这里简简单单几句话要求， 让开发同事、设计师作半年…… * 需求规格说明书 * 没有高质量的需求 软件就象一个巧克力的盒子 你不会知道你将要得到什么 * 高质量需求叙述的特性 正确 可行性 必要性 优先权 明确 可证实 * Use Case：标记方法简单 Actor名称 Use Case名称 * Use Case：主动角色 经纪人 下单 投资人 报价审查 货币存取 经纪管理系统 * Use Case：被动角色 经纪人 下单 投资人 报价审查 货币存取 经纪管理系统 银证转账系统 * 画Use Case图规则 主动角色画在图的左边 被动角色画在图的右边 每个Use Case必须为用户提供确切的功能 Use Case名称必须写在椭圆里面 保持图面整洁 每一张图里不能有太多的Use Case 为每一个Use Case编号便于检索 为Use Case建立目录（编号和名称）便于管理 * Use Case 高级概念 * Use Case高级概念 通过分析Use Case图，分析人员可以找出不同的业务过程之间的共性 扩展、包含、派生、使用等关系 通过这些关系可以降低系统的复杂度 为重用提供了条件 将共性提出来，可以帮助我们发现重复的过程 二次开发应该关注的地方 * Actor 的继承 类似于Use Case的扩展，角色之间可以继承 其他银行不仅具有储户的所有功能，还有其他的功能 * Actor 继承的好处 在不丢失信息的前提下，简化了Use Case图 继承说明了角色间的层次关系 派生者继承了父角色的所有能力 父角色不知道派生者 * 扩展关系：extend 扩展关系通常用来表示某一个Use Case的可选择部分 扩展关系允许分析人员在没有改变基Use Case的情况下增加或修改基Use Case的功能 复杂的可替代途径应该使用扩展关系把它们分成多个Use Case 也可以这样看扩展关系： 在基Use Case上插入功能，而基Use Case本身不知道这个扩展 * 扩展关系(extend )示图 * 使用关系 如果Use Case A包含Use Case B，表示在执行Use Case的动作序列过程中，在某一点上将开始执行Use Case B的动作序列，完成后将回到同一点上继续执行完Use Case A的动作序列 它与扩展关系的区别是： 扩展是可选的 包含是必做的（更象一个子过程） 和扩展关系一样，一个Use Case可以包含很多个子Use Case，也可以被很多个父Use Case所包含 * 包含关系(include)示例 * 包含关系(include)示图 * 关于扩展和包含关系 * Use Case发掘实操 * Use Case发掘过程 定义Actor 发掘Actor使用系统的脚本Script 总结Use Case组合 研究Actor之间的继承关系 研究Use Case之间的include、extend关系 贯穿始终：维护一套词汇表 }CE * 词汇表！词汇表！ 词汇表有多重要? 可以建巴别塔 代码中的变量 需求文档的重要组成部分和线索 维护词汇表应该是产品团队最重要的工作之一 Buddy？面板联系人？通讯录联系人？ 电话好友？手机好友？QQ联系人？邮件好友？ IM联系人？过滤联系人？ * 词汇表示例：被叫号码 本节所述之被叫号码，其格式要求为： 符合E.164电话号码编号计划规范。 对于PBX分机号码，应为1－8位数字； 对于普通电话号码，合法格式为： 以“+”、“-”分隔的1-21位数字字符串； 可选包含以“+”引导的国家代码； 如+86代表中国，+1代表美国； 必须包含地区代码和电话号码，其间用“-”分隔； 如0755010 如果包含国家代码，则地区代码的长途前缀（如“0”）应省略； 如+86-755+86-10如果某外线号码包含分机号码，其间用“-”分隔； 如0755384；+86-755384 对于中国移动电话号码，合法格式为： 国家代码和移动电话号码 如+86或移动电话号码 在被叫号码中无需根据对外地手机加入0前缀。 不包含Omni PCX交换机的外线拨号前缀。 如某Omni PCX交换机的外线拨号前缀为“9”，但在RTX系统中的电话号码资料中不需要具备这个外线拨号前缀。 －《R