腾讯：从概念到产品-需求分析过程62873.ppt

* 性能需求的Pattern 性能指标 易用性 安全性 兼容性 可扩展性 可维护性 可延展性 可移植性 可编程性 可靠性 可测试性 产品关注 技术关注 * 性能需求的专业化撰写态度 产品经理应忘记自己懂技术、交互 从用户、市场角度把要求提出来 弄清楚自己的专业发展方向 User-Oriented，Market-Oriented 其他的，不妨“扮猪吃老虎” * Good News：天下文章一大抄 在一个产品系统中，性能需求是可以Copy的 第一份性能需求是重点，大家一起作 之后的需求文档往往只需改变： 性能指标 可扩展性 易用性 可延展性 安全性 兼容性 可维护性 可移植性 可编程性 可靠性 可测试性 这里简简单单几句话要求， 让开发同事、设计师作半年…… * 需求规格说明书 * 没有高质量的需求 软件就象一个巧克力的盒子 你不会知道你将要得到什么 * 高质量需求叙述的特性 正确 可行性 必要性 优先权 明确 可证实 * 高质量需求叙述的特性 1/6 正确： 每个需求必须精确描述要交付的功能。 正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。 只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。 * 高质量需求叙述的特性 2/6 可行性： 在已知的能力、有限的系统及其环境中每个需求必须是可实现的。 为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，这个开发人员应能检查 在技术上什么能做什么不能做 哪些需要需要额外的付出或者和其他的权衡。 在抽象阶段应该有市场人员参与。 * Use Case是很好的测试单元 Use Case清晰地描述了系统的功能界面 测试人员可以在开发初期制定测试计划 每一个Use Case都严格地说明了系统的某一项功能 它的输入 它的输出 期间的交互作用 Use Case是黑盒测试的基准 * Use Case的阐述 应该包含Use Case的所有重要细节 应该包括角色与系统交互的关键步骤，可以使用顺序图（Sequence Diagram） 要表述有关角色的信息 要分清哪些是角色所具有的职能、哪些是系统所应提供的 要列清使用这些功能是所应满足的前提条件 如果某些功能具有质量上的要求（如性能），也要列出来 创建群 Dddddddddddd Dddddxxafsdfads Dddddddddddd Ddddfcadsfasd ddddccdasdwe * 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的动作序列 它与扩展关系的区别是： 扩展是可选的 包含是必做的（更象一个子过程） 和扩展关系一样，一