腾讯：从概念到产品-需求分析过程全解
以下为《腾讯：从概念到产品-需求分析过程全解》的无排版文字预览，完整格式请下载
下载前请仔细阅读文字预览以及下方图片预览。图片预览是什么样的，下载的文档就是什么样的。
从概念到产品－需求分析过程Something about grammar & literature2开始的话3引子：不仅仅纯技术人文比科技重要！
方法比技能重要！初做者有经验者监督者专家管理者高级专家领导者资深专家4学习态度？一天，三年甲班的杨某某忘了交作业，导师郭靖问他：“为什么没交作业？”
杨某某答曰：“作业为什么要交？交了不一定是自己写的；
写了又不一定会；（不小心破了珍珑的虚竹不好意思地看了逍遥子一眼）
会了又不一定会考；（苦心准备当盟主的左冷禅背后响起闷响）
考了又不一定会过；（白眉鹰王身边秋风吹过阵阵凄凉的落叶）
过了又不一定能毕业；（被古墓派退学的李莫愁脸色一变）
毕业又不一定会找到工作；乐天的令狐冲正在酒醉中没听见）
找得到工作又不一定保得住工作；（萧峰夺门而出）
……？”
只见现场沉默三秒之后，众人联手围殴杨某某……5先从语法课讲起用户是一个或者多个名词；
产品是名词，一般由很多个名词组成；
产品设计过程
功能需求就是找出“动宾短语”的集合
性能需求就是找出“形容词”的集合6订书机为例（仅供参考）产品
订书机: n. 一种装订文件的文具
订书机包括：
杠杆结构：n.
进钉结构；n.
压钉结构；n.
钉书钉(消耗品):n.
用户
用户：n. 使用订书机的人，应大于3周某某；且有手或者类似可以发出至少1kg力量的人。最常用(80%以上)为女性(21-40)。需求
功能需求
装订文件；
Load钉书钉；
Unload钉书钉；
…
性能需求
外观、颜色、省力、材质….7产品设计过程定义好用户
定义好产品
先分析功能需求
再分析性能需求80/20的误区：
产品日趋同质化，
公司之间的差别，
市场竞争的成败，
往往是由性能决定8互联网本质论计算机为什么叫计算机？
互联网其实是一个大数据库
大部分应用都是数据库应用
Search?
B2B、B2C、C2C?
Gaming? Avatar？
Blog?
小部分应用是即时的存储转发类
IM
VoIP复习数据库的知识!9课程概述10课程内容Use Case分析方法
找寻用户
定义产品
发掘功能需求
性能需求的“套路”
需求文档的撰写
产品经理常用“技法”
工作组织方法
常用图表和绘图方法
11需求分析与人文需求分析是一个工业化的写作过程
80％的套路＋20％的创意
好的语XX平：
有利于抓住关键词汇
有利于培养数字敏感
有利于增强形容能力
有利于组织文档结构
有利于提高沟通能力读书吧！
写博客吧！12Use Case分析法13USE-CASE的历史1967年Jacobson在爱立信工作的时候开始使用这种思想
这种想法最早应用于大型交换机系统的需求获取
1971年完成了这种方法的最初原型
1985年推出了改进版，并发布了面向对象的OOSE方法
大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去
它还被广泛的应用于工业领域14需求获取的前提用户必须告诉你他想要什么
你必须完整地了解用户的业务
你必须知道与系统有关的任何人和任何东西
如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现在是怎么工作的
从专家那里了解用户业务的原理和规则
你是去了解要做什么而不是怎么做15首先，您需要把系统看成黑盒一开始就深入细节的产品经理，忙乱而又没有绩效
往往陷入细节的泥坑，甚至是技术细节，甚至UI细节
被层出不穷的需求点和例外处理困扰
控制不住满脑袋乱冒的ideas
请相信！！！！！！！！！！！！！！！！！！！！
系统内部无论多么复杂
他总是可以被“使用说明书”说清楚16Actor17需求分析的第一个问题 谁是这个产品的用户？
或者， 谁是这个产品系统中的角色？18什么是角色(Actor)与系统发生交互作用的、系统之外的任何东西都是角色
可以是人
也可以是机器
角色不等同于使用者
角色存在于系统外部
角色不是活动的准确描述
使用者是行驶某个角色职责的系统的使用人员
如小王是个采购员19角色（续）每个Actor都通过不同的方式使用系统，除非他们是相同的Actor
Actor使用系统的每一种方式就是一个Use Case20角色分类主动角色：Use Case的动作序列是由他先发起的，通常系统返回最后结果
主叫方，采购人员，票据录入员等
被动角色：系统通过调用角色来完成Use Case的动作序列（或其中的某一个动作）
不是初始动作的发起者
当系统需要它们帮助的时候
最终是为了满足主动角色的需要
通常是机器或其他系统Use Case1Use Case221Script22脚本Script脚本是一个角色与系统之间的一组交互作用
通常具有详细的真实数据及实际的期望输出值
一个应用系统可能具有成千上万个脚本
即使同一件事，所得到的脚本可能也会有细微的区别
脚本是描绘Use Case的重要的背景信息23脚本示例1：小王输入他的账号#413597
2：小王输入他的***
3：小王查询98.7.1至98.12.31日之间的平均余额
4：系统显示余额
1：小张输入他的账号#413343
2：小张输入他的***
3：小张查询98.3.1至98.5.31日之间的平均余额
4：系统显示余额
1：小李输入她的账号#346780
2：小李输入她的***
3：小李查询98.7.1至98.12.31日之间的平均余额
4：系统显示余额24脚本与Use Case一个Use Case代表一组潜在的脚本
通过研究一组相似的脚本，可以得到它们内在的逻辑
相似的脚本通常遵循相似的模式工作，并提供相似类型的结果
一个Use Case通常关注某一个目标
例如：查询存折余额Use Case25Use Case26转让群通过Use Case描述系统功能需求一个系统具有无限个潜在的脚本
但一个系统可以被有限的Use Case完整说明
系统的每一个Use Case都必须列举，否则系统将会遗漏功能创建群解散群加入群赞助群邀请加入群群内发言授权群管理27Use Case描述系统提供的交互功能
一个Use Case可以被其他的Use Case调用
Use Case可以组合完成某一项更大的功能
Use Case说明系统需要提供什么而不是怎么提供
用户并不关心你如何给他们提供所需要的功能
Use Case一般是用“动宾”短语命名创建群解散群加入群赞助群邀请加入群群内发言授权群管理28Use CaseUse Case不是分析设计文档
虽然它们支持后续的分析设计工作
Use Case不是操作脚本
它不是用户使用系统时实际操作的具体步骤的记录
虽然它可能是通过操作脚本得来的29Use Case是很好的测试单元Use Case清晰地描述了系统的功能界面
测试人员可以在开发初期制定测试计划
每一个Use Case都严格地说明了系统的某一项功能
它的输入
它的输出
期间的交互作用
Use Case是黑盒测试的基准30Use Case的阐述应该包含Use Case的所有重要细节
应该包括角色与系统交互的关键步骤，可以使用顺序图（Sequence Diagram）
要表述有关角色的信息
要分清哪些是角色所具有的职能、哪些是系统所应提供的
要列清使用这些功能是所应满足的前提条件
如果某些功能具有质量上的要求（如性能），也要列出来创建群Dddddddddddd
Dddddxxafsdfads
Dddddddddddd
Ddddfcadsfasd
ddddccdasdwe31Use Case：标记方法简单Use Case名称32Use Case：主动角色经纪管理系统33Use Case：被动角色经纪管理系统34画Use Case图规则主动角色画在图的左边
被动角色画在图的右边
每个Use Case必须为用户提供确切的功能
Use Case名称必须写在椭圆里面
保持图面整洁
每一张图里不能有太多的Use Case
为每一个Use Case编号便于检索
为Use Case建立目录（编号和名称）便于管理35Use Case
高级概念36Use Case高级概念通过分析Use Case图，分析人员可以找出不同的业务过程之间的共性
扩展、包含、派生、使用等关系
通过这些关系可以降低系统的复杂度
为重用提供了条件
将共性提出来，可以帮助我们发现重复的过程
二次开发应该关注的地方37Actor 的继承类似于Use Case的扩展，角色之间可以继承
其他银行不仅具有储户的所有功能，还有其他的功能38Actor 继承的好处在不丢失信息的前提下，简化了Use Case图
继承说明了角色间的层次关系
派生者继承了父角色的所有能力
父角色不知道派生者39扩展关系：extend扩展关系通常用来表示某一个Use Case的可选择部分
扩展关系允许分析人员在没有改变基Use Case的情况下增加或修改基Use Case的功能
复杂的可替代途径应该使用扩展关系把它们分成多个Use Case
也可以这样看扩展关系：
在基Use Case上插入功能，而基Use Case本身不知道这个扩展40扩展关系(extend )示图41使用关系如果Use Case A包含Use Case B，表示在执行Use Case的动作序列过程中，在某一点上将开始执行Use Case B的动作序列，完成后将回到同一点上继续执行完Use Case A的动作序列
它与扩展关系的区别是：
扩展是可选的
包含是必做的（更象一个子过程）
和扩展关系一样，一个Use Case可以包含很多个子Use Case，也可以被很多个父Use Case所包含42包含关系(include)示例43包含关系(include)示图44关于扩展和包含关系45Use Case发掘实操46Use Case发掘过程定义Actor
发掘Actor使用系统的脚本Script
总结Use Case组合
研究Actor之间的继承关系
研究Use Case之间的include、extend关系
贯穿始终：维护一套词汇表}CE47词汇表！词汇表！词汇表有多重要?
可以建巴别塔
代码中的变量
需求文档的重要组成部分和线索
维护词汇表应该是产品团队最重要的工作之一Buddy？面板联系人？通讯录联系人？
电话好友？手机好友？QQ联系人？邮件好友？
IM联系人？过滤联系人？
48词汇表示例：被叫号码本节所述之被叫号码，其格式要求为：
符合E.164电话号码编号计划规范。
对于PBX分机号码，应为1－8位数字；
对于普通电话号码，合法格式为：
以“+”、“-”分隔的1-21位数字字符串；
可选包含以“+”引导的国家代码；
如+86代表中国，+1代表美国；
必须包含地区代码和电话号码，其间用“-”分隔；
如0755-***；010-***；
如果包含国家代码，则地区代码的长途前缀（如“0”）应省略；
如+86-755-***；+86-10-***
如果某外线号码包含分机号码，其间用“-”分隔；
如0755-***-384；+86-755-***-384
对于中国移动电话号码，合法格式为：
国家代码和移动电话号码
如+86-***
或移动电话号码
如***，在被叫号码中无需根据对外地手机加入0前缀。
不包含Omni PCX交换机的外线拨号前缀。
如某Omni PCX交换机的外线拨号前缀为“9”，但在RTX系统中的电话号码资料中不需要具备这个外线拨号前缀。－《RTX Omni PCX插件软件需求规格说明书.doc》49Use Case的Pattern大部分互联网服务本质上是DB：
增删改查
导入导出
批量操作
计算机应用的基础支撑功能：
安装卸载
启动停止重启动
OAM（运营、管理、监视）50自定义头像的Use Case用户Server组管理员第三方头像CP设置自定义头像从本机设置从网络硬盘设置从第三方系统设置 第三方
头像系统网络硬盘
系统《extend》《extend》《extend》添加第三方CP查看头像运营数据51Use Case阐述52Use Case：开始走向需求规格说明书Use Case图并不是需求文档的必备部分
Use Case分析是过程，不是结果
Use Case阐述，等于：53Use Case阐述的基本四要素进入条件
描述Use Case在何种情况下进入
如用户必须具备什么条件？之前发生了什么？
基本流程
不考虑任何异常例外，没有if then else
从用户角度阐述Use Case如何运作
结束条件
Use Case成功结束后，发生了什么变化
用户发生什么变化？系统发生什么变化？
例外流程
逐个阐述在基本流程中某个环节出现异常时的处理
54Use Case阐述的几个禁止禁止假设系统由哪些技术实现模块组成
“系统从服务器基础DB中删除好友关系”
禁止假设用户可以使用哪些UI界面
“系统弹出错误提示窗口”
禁止使用没有主谓宾的语句
“给出提示”
禁止使用没有任何意义、意义不全的语句
“系统给出状态提示信息”
“系统立即显示”、“等”、“或者”、“其他”、“通常”…
禁止给出没有值域的定义
“系统显示天气温度信息”
55Use Case 阐述的逐步细化 － 1 基本流程a)当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。
b)邮件用户可以按照以下的一个或多个步骤执行：
c)按照发送这或主题整理邮件信息；
d)阅读邮件信息的内容；
e)把邮件信息保存为文件；
f)把邮件信息的附件保存为文件；
g)当邮件用户要求退出管理新来邮件信息时，功能夹终止。56Use Case 阐述的逐步细化 － 2 期望扩展a)当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。[用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。]
b)邮件用户可以按照以下的一个或多个步骤执行：
c)按照发送这或主题整理邮件信息；
d)阅读邮件信息的内容；
e)把邮件信息保存为文件；
f)把邮件信息的附件保存为文件； [用户必须能够看见附件的文件类型]
g)当邮件用户要求退出管理新来邮件信息时，功能夹终止。57Use Case 阐述的逐步细化 － 3 补充值域a)当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。[用户必须能够区分新的、已读过的、未读过的消息。用户还必须能够看见每个消息的发送者、主题和优先级。] {平均每100个同时显示的未读邮件消息中，其中90%的消息主题行少于40个字符。}
b)邮件用户可以按照以下的一个或多个步骤执行：
c)按照发送这或主题整理邮件信息；
d)阅读邮件信息的内容； {平均消息内容包括100字符。}
e)把邮件信息保存为文件；
f)把邮件信息的附件保存为文件； [用户必须能够看见附件的文件类型] {这种情况下，95%的邮件都少于2个附件。}
g)当邮件用户要求退出管理新来邮件信息时，功能夹终止。58Use Case 阐述的逐步细化 － 4 补充发生概率a)当邮件用户要求管理邮件信息时功能夹启动，系统显示信息。[用户必须能够区 内容过长，仅展示头部和尾部部分文字预览，全文请查看图片预览。 89Pareto 图 90一张图胜过百句话UML中的几种图表：
动态的观察系统：
Usecase图
序列图(Sequence Diagram)
协作图(Collaboration Diagram)
状态图(Statechart Diagram)
活动图(Activity Diagram)
静态的观察系统：
部署图(Deployment Diagram)
组件图(Compoment Diagram)
对象图(Object Diagram)
类图(Class Diagram)91更多的…….请参考RUP 2000中文版本
学习各种图表工具
学习工作方法
不是去学UML!
记住：
产品经理的图，应该是用户可看懂的
不是程序设计图
可以不用Visio，用Powerpoint就可以画出来
不会超过One Page的规模，最好是Half a page
92以 马 内 利仁爱、喜乐、和平、忍耐、恩慈、良善、信实、温柔、节制 [文章尾部最后500字内容到此结束,中间部分内容请查看底下的图片预览]请点击下方选择您需要的文档下载。
- 需求分析篇：如何编写系统功能指标
- 售后服务管理制度
- 电网友好型多用电设备协调控制模型与策略_廖正海
- 需求规格说明书(XXXX-SPI-REQ-Tem-SRS)V1.0
- 策划入门指南
- 产品流程七点
- 线上理财产品推广
- 周鸿yN：商业模式不是赚钱模式
- 产品能力总概课
- 清新叶子ppt模板
- 全军武器装备采购信息网快速操作手册
- 产品经理学习笔记
- 运营知识笔记
- 铁路12306app订单界面交互设计优化方案
- 产品迭代计划
- 短视频运营方案（建议）
- 智能手环软件产品策划方案
- 德力DL3960用户手册
- 腾讯：从概念到产品-需求分析过程全解
- 产品从无到有的打造流程
以上为《腾讯：从概念到产品-需求分析过程全解》的无排版文字预览，完整格式请下载
下载前请仔细阅读上面文字预览以及下方图片预览。图片预览是什么样的，下载的文档就是什么样的。