从概念到产品-需求分析过程分析.ppt

* Use Case 阐述的逐步细化 － 4 补充发生概率 a)当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。[用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。] {平均每100个同时显示的未读邮件消息中，其中90%的消息主题行少于40个字符。} b)邮件用户可以按照以下的一个或多个步骤执行： c)按照发送这或主题整理邮件信息；(在这种情况下，有超过60%做了此项操作。) d)阅读邮件信息的内容； {平均消息内容包括100字符。} e)把邮件信息保存为文件；(在这种情况下，少于5%做了此项操作。) f)把邮件信息的附件保存为文件； [用户必须能够看见附件的文件类型] {这种情况下，95%的邮件都少于2个附件。} (在这种情况下，有少于30%做了此项操作。) g)当邮件用户要求退出管理新来邮件信息时，功能夹终止。 * Use Case阐述后 发现词汇，并给以定义 详细的解释，值域的描述 形成需求文档中的“定义” 发现功能需求和性能需求 整理文字，形成功能需求规格说明和性能需求说明 * 性能需求 * 性能需求的Pattern 性能指标 易用性 安全性 兼容性 可扩展性 可维护性 可延展性 可移植性 可编程性 可靠性 可测试性 产品关注 技术关注 * 性能需求的专业化撰写态度 产品经理应忘记自己懂技术、交互 从用户、市场角度把要求提出来 弄清楚自己的专业发展方向 User-Oriented，Market-Oriented 其他的，不妨“扮猪吃老虎” * Good News：天下文章一大抄 在一个产品系统中，性能需求是可以Copy的 第一份性能需求是重点，大家一起作 之后的需求文档往往只需改变： 性能指标 可扩展性 易用性 可延展性 安全性 兼容性 可维护性 可移植性 可编程性 可靠性 可测试性 这里简简单单几句话要求， 让开发同事、设计师作半年…… * 需求规格说明书 * 没有高质量的需求 软件就象一个巧克力的盒子 你不会知道你将要得到什么 * 高质量需求叙述的特性 正确 可行性 必要性 优先权 明确 可证实 * 高质量需求叙述的特性 1/6 正确： 每个需求必须精确描述要交付的功能。 正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。 只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。 * 转让群 通过Use Case描述系统功能需求 一个系统具有无限个潜在的脚本 但一个系统可以被有限的Use Case完整说明 系统的每一个Use Case都必须列举，否则系统将会遗漏功能 创建群 解散群 加入群 赞助群 邀请加入群 群内发言 授权群管理 * Use Case 描述系统提供的交互功能 一个Use Case可以被其他的Use Case调用 Use Case可以组合完成某一项更大的功能 Use Case说明系统需要提供什么而不是怎么提供 用户并不关心你如何给他们提供所需要的功能 Use Case一般是用“动宾”短语命名 创建群 解散群 加入群 赞助群 邀请加入群 群内发言 授权群管理 * Use Case Use Case不是分析设计文档 虽然它们支持后续的分析设计工作 Use Case不是操作脚本 它不是用户使用系统时实际操作的具体步骤的记录 虽然它可能是通过操作脚本得来的 * 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图规则 主动角色画在图的左边 被动角色画在图的右边