【优质】urse+2+1：从概念到产品－需求分析过程.ppt

欢迎访问OA支持网站http://8000. 从概念到产品－需求分析过程 Something about grammar literature 引子：不仅仅纯技术 人文比科技重要！ 方法比技能重要！ 学习态度？ 一天，三年甲班的杨过忘了交作业，导师郭靖问他：“为什么没交作业？” 杨过答曰：“作业为什么要交？交了不一定是自己写的； 写了又不一定会；（不小心破了珍珑的虚竹不好意思地看了逍遥子一眼） 会了又不一定会考；（苦心准备当盟主的左冷禅背后响起闷响） 考了又不一定会过；（白眉鹰王身边秋风吹过阵阵凄凉的落叶） 过了又不一定能毕业；（被古墓派退学的李莫愁脸色一变） 毕业又不一定会找到工作；乐天的令狐冲正在酒醉中没听见） 找得到工作又不一定保得住工作；（萧峰夺门而出） ……？” 只见现场沉默三秒之后，众人联手围殴杨过…… 先从语法课讲起 用户是一个或者多个名词； 产品是名词，一般由很多个名词组成； 产品设计过程 功能需求就是找出“动宾短语”的集合 性能需求就是找出“形容词”的集合 订书机为例（仅供参考） 产品 订书机: n. 一种装订文件的文具 订书机包括： 杠杆结构：n. 进钉结构；n. 压钉结构；n. 钉书钉(消耗品):n. 产品设计过程 定义好用户 定义好产品 先分析功能需求 再分析性能需求 互联网本质论 计算机为什么叫计算机？ 互联网其实是一个大数据库 大部分应用都是数据库应用 Search? B2B、B2C、C2C? Gaming? Avatar？ Blog? 小部分应用是即时的存储转发类 IM VoIP 课程内容 Use Case分析方法 找寻用户 定义产品 发掘功能需求 性能需求的“套路” 需求文档的撰写 产品经理常用“技法” 工作组织方法 常用图表和绘图方法 需求分析与人文 需求分析是一个工业化的写作过程 80％的套路＋20％的创意 好的语文水平： 有利于抓住关键词汇 有利于培养数字敏感 有利于增强形容能力 有利于组织文档结构 有利于提高沟通能力 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.