需求分析过程幻灯片.pptVIP

欢迎访问OA支持网站http://8000. 从概念到产品－需求分析过程 Something about grammar literature 先从语法课讲起 用户是一个或者多个名词； 产品是名词，一般由很多个名词组成； 产品设计过程 功能需求就是找出“动宾短语”的集合 性能需求就是找出“形容词”的集合 订书机为例（仅供参考） 产品 订书机: n. 一种装订文件的文具 订书机包括： 杠杆结构：n. 进钉结构；n. 压钉结构；n. 钉书钉(消耗品):n. 产品设计过程 定义好用户 定义好产品 先分析功能需求 再分析性能需求 课程内容 Use Case分析方法 找寻用户 定义产品 发掘功能需求 性能需求的“套路” 需求文档的撰写 产品经理常用“技法” 工作组织方法 常用图表和绘图方法 USE-CASE的历史 1967年Jacobson在爱立信工作的时候开始使用这种思想 这种想法最早应用于大型交换机系统的需求获取 1971年完成了这种方法的最初原型 1985年推出了改进版，并发布了面向对象的OOSE方法 大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去 它还被广泛的应用于工业领域 需求获取的前提 用户必须告诉你他想要什么 你必须完整地了解用户的业务 你必须知道与系统有关的任何人和任何东西 如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现在是怎么工作的 从专家那里了解用户业务的原理和规则 你是去了解要做什么而不是怎么做 首先，您需要把系统看成黑盒 一开始就深入细节的产品经理，忙乱而又没有绩效 往往陷入细节的泥坑，甚至是技术细节，甚至UI细节 被层出不穷的需求点和例外处理困扰 控制不住满脑袋乱冒的ideas 请相信！！！！！！！！！！！！！！！！！！！！ 系统内部无论多么复杂 他总是可以被“使用说明书”说清楚 需求分析的第一个问题 谁是这个产品的用户？ 或者，谁是这个产品系统中的角色？ 什么是角色(Actor) 与系统发生交互作用的、系统之外的任何东西都是角色 可以是人 也可以是机器 角色不等同于使用者 角色存在于系统外部 角色不是活动的准确描述 使用者是行驶某个角色职责的系统的使用人员 如小王是个采购员 角色（续） 每个Actor都通过不同的方式使用系统，除非他们是相同的Actor Actor使用系统的每一种方式就是一个Use Case 角色分类 主动角色：Use Case的动作序列是由他先发起的，通常系统返回最后结果 主叫方，采购人员，票据录入员等 被动角色：系统通过调用角色来完成Use Case的动作序列（或其中的某一个动作） 不是初始动作的发起者 当系统需要它们帮助的时候 最终是为了满足主动角色的需要 通常是机器或其他系统 脚本Script 脚本是一个角色与系统之间的一组交互作用 通常具有详细的真实数据及实际的期望输出值 一个应用系统可能具有成千上万个脚本 即使同一件事，所得到的脚本可能也会有细微的区别 脚本是描绘Use Case的重要的背景信息 脚本示例 1：小王输入他的账号#413597 2：小王输入他的密码#119823 3：小王查询98.7.1至98.12.31日之间的平均余额 4：系统显示余额 1：小张输入他的账号#413343 2：小张输入他的密码#646788 3：小张查询98.3.1至98.5.31日之间的平均余额 4：系统显示余额 1：小李输入她的账号#346780 2：小李输入她的密码#435645 3：小李查询98.7.1至98.12.31日之间的平均余额 4：系统显示余额 脚本与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清晰地描述了系统的功能界面 测试人员可以在开发初期