产品经理需求分析方法和文档书写规范
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
§ 域的划分 § 域间交互
§ 场景描述
- 界面 - 操作（按钮、链接） - 结果展示
12
13
订单状态图示
§ 订单状态图
-
主状态图 子状态图 § 与子流程相关 § 考虑系统间的交互
-
14
流程说明文档的书写要点
§ 业务规则
-
流程中使用的业务规则
§ 输入 § 处理过程 § 输出 § 关联流程
3
需求获取的前提
§ 用户必须告诉你他想要什么 § 你必须完整地了解用户的业务 § 你必须知道与系统有关的任何人和任何东西 § 如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现 在是怎么工作的 § 需要了解人最普遍的心理活动 § 你是去了解要做什么而不是怎么做
Use Case与脚本
§ 一个Use Case代表一组潜在的脚本 § 通过研究一组相似的脚本，可以得到它们内在的逻辑 § 相似的脚本通常遵循相似的模式工作，并提供相似类型的结果 § 一个Use Case通常关注某一个目标
脚 本
用例
24
USE CASE
§ 描述系统提供的交互功能
20
什么是角色（Actor）
§ 与系统发生交互作用的、系统外的任何东西都是角色
- -
可以是人 也可以是机器
§ 角色不等同于使用者 § 角色存在于系统外部 § 角色不是活动的准确描述 § 使用者是行驶某个角色职责的系统的使用人员
-
21
我是角色Actor！
如小周是个组织者
角色的作用
§ 常用书写Use Case的工具：Visio，ROSE等
28
性能需求
§ 性能指标 § 易用性 § 安全性 § 兼容性 § 可扩展性 § 可维护性 § 可延展性 § 可移植性 § 可编程性 § 可靠性 § 可测试性
29
产品关注
技术关注
产品经理如何处理性能需求
- -
一个Use Case可以被其他的Use Case调用 Use Case可以组合完成某一项更大的功能
§ Use Case说明系统需要提供什么而不是怎么提供
-
用户并不关心你如何给他们提供所需要的功能
§ Use Case一般是用“动宾”短语命名 § 系统的每一个Use Case都必须列举，否则系统将会遗漏功能
5
再者，你要控制系统复杂性
系统内部无论多么复杂 - 他总是可以被“使用说明书”说清楚 - 用户没有耐心，需要直接了当
-
最后，有好的文字水平去控制
§ 需求分析是一个工业化的写作过程：80％的套路＋20％的创意 模式化的路子: § 定义好用户 § 定义好产品 § 先分析功能需求 § 再分析性能需求
8
产品概念设计要素
SQVID原则 § 简单（Simple） § 定性（Qualitative） § 愿景（Visional） § 个性（Individual） § 动态（Dynamic）
9
通过概念设计去表现产品
§ 产品概念是什么
- - -
怎么表现 包含哪些 与哪些有关联
§ 角色与操作
- -
描述 登录 注册流程 用QQ\新浪微博账号登陆 忘记密码流程
优先级 1 1 2 1
§ 需求优先级
18
设计工具
§ Axure RP的发音是』Ack-sure』，RP则是』Rapid Prototyping』快速 原型的缩写。RP是一个快速绘制Wireframe 和Prototyping的工具，主 要用来定义应用程序的需求与规格，以及设计使用者界面与功能，使用者 包括User Experience Designers、商业分析师、信息架构师、Usability Expert与产品经理等专业人士。 § 在Axure RP中建立Wireframe和Prototype可以帮助您快速且有效地分析 需求、验证设计并传达给所有参与者，以确保在有限的项目时间与资源下 ，开发出有用和可用的应用程序。 § Axure RP 结合了广受欢迎的简报与图标工具中简易操作的特性和其它必 要的功能。这样一来，商务专家就可以在不需要大量的文件制作下快速的 建立prototype，而项目成员与项目关系人也可以在不中断开发的情况下 轻松完成prototype。
31
高质量文档的标准
§ 概念、逻辑表述正确 § 可行性高 § 必要性 § 确定的优先级 § 需求清楚明确 § 需求可证实 § 完整性 § 一致性 § 可修改性 § 可追踪性
32
不同阶段的文档
§ 第一个阶段的文档是市场需求文档（产品经理提供） § 第二个阶段的文档是功能需求文档（产品经理提供） § 第三个阶段的文档是测试用例文档（测试人员编写） § 第四个阶段的文档是项目安排计划表（项目经理安排） § 下一个阶段的文档是详细设计说明书（技术架构组提供） § 再下一个阶段的文档是数据库设计及模块设计说明书（技术开发组提供）
7
以电子商务的交易系统为例
电子商务网站交易系统的目的和原则
目的： § 实现对订单的统一管理和跟踪 § 减少交互，提升交易管理性能 § 支持多渠道，实现复杂流程的调度 § 统一基础数据，可复用的订单模板 § 利用订单的信息进行经营性分析 设计原则： § 未来可同时承接多渠道订单 § 拆分主订单流程，减少分支流程 § 主订单状态简单，与其他系统耦合 § 订单数据的可扩展性高 § 订单积累可用于广泛的数据分析
定义 订单是消费者与出售者直接进行交易的契约，包括交易实 体、交易人和交易过程 状态是根据时间序列变化的标记，订单状态即订单在不同 流程时间点的枚举变量
11
交易流程图示
§ 流程简介
-
说明流程的使用场景，流程的总体说明 § 主流程图
- 普通流程图
§ 单向的 § 可变流
- 跨域的流程图
用例（USE CASE）的历史
§ 1967年Jacobson在爱立信工作的时候开始使用这种思想 § 这种想法最早应用于大型交换机系统的需求获取 § 1971年完成了这种方法的最初原型 § 1985年推出了改进版，并发布了面向对象的OOSE方法 § 大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去 § 它还被广泛的应用于工业领域
§ 产品经理应忘记自己懂技术、交互
§ 从用户、市场角度把需求提出来 § 弄清楚自己的专业发展方向，指标决定
§ 好消息是：大部分这种需求开发工程师和软件测试人员都帮你搞定了 § 你所做的就是找最好的测试人员帮你获取性能指标
30
为何需求高质量的文档
§ 没有高质量的需求文档，软件就像掉进泥沼的巨象，越挣扎陷得越 深入。——《人月神话》
33
=====
文档模版======
34
产品确认和项目安排（Microsoft project）
35
产品设计过程中的工具一览
基本工具 概念分析 原型设计
需求管理
37
汇集智慧，传播理念
产品经理系统分析方法与设计文档规范
王晟 2012年9月
Deeper Wider Farther
产品定位思考
定位思考的四个步骤： § 观看 § 验证 § 想象 § 展示
2
定位思考六要素
§ 谁？——与人有关的角色的相关作用； § 有多少？——涉及数量预估是多少； § 什么时候？——关于计划和安排的挑战； § 在那里？——有关方向和彼此配合的挑战？ § 结果怎样？——事情之间如何相互影响？ § 为什么？ ——展望全景的挑战？
25
USE CASE 是基础测试单元
§ Use Case清晰地描述了系统的功能界面 § 测试人员可以在开发初期制定测试计划 § 每一个Use Case都严格地说明了系统的某一项功能
- - -
它的输入 它的输出 期间的交互作用
§ Use Case是黑盒测试的基准（Benchmark）
16
功能说明与流程说明的区别
§ 流程说明
- - -
风险 1
风险级别 高
整体性 以流程为核心，重点描述流程的变化 下一个阶段的文档是功能说明文档 完整性 以功能为核心，重点描述系统的功能
§ 模块划分 § 功能描述 § 风险评估
2
较高
§ 功能说明
- -
3
较高
描述 监控策略 改善策略 S N S 社 区 引 导 购 物， 一期完成后，通过 引 导 购 物 放 在 2 消费的内容需要与纯 运营策略，监测用 期完成，一期主 粹自己发起打架的情 户在社区中的消费 要 LBS 的社区服 况。 倾向，再确定二期 务部分。 引导消费的内容。 线下消费产生内容比 上线前需要运营配 通过运营活动或 较少，而真正能够吸 合完成，完成主要 者直接进行系统 引并产生。因此内容 的商品展示。 抓取内容，方便 产生方面可能会存在 用户进行选择和 一定问题。 讨论。 用户构建的关系链可 后期达人（或卖家） 1 期 上 线 的 达 人 能会存在，才能避免 需要反的达人，处 均是，后期用户 纯粹广告的泛滥。 以相应的处罚。 需提交申请。
§ 几个好用的工具
10
交易流程说明
§ 名词定义
-
-
-
何为订单 § 交易人（用户&商家） 名词 § 交易实体（商品） 订单 § 交易过程（状态变化） 何为状态 § 随时间变化 订单状态 § 可枚举 何为订单系统 § 核心——订单的生命周期管理 § 范围——与其他系统的边界
26
合理利用USE CASE图
§ 通过分析Use Case图，产品经理可以找出不同的业务过程之间的关系
-
扩展、包含、派生、使用等关系
§ 通过这些关系可以降低系统的复杂度 § 可以帮助产品经理发现重复的过程
-
需求在细化过程中不断精细
27
需要说明的是
§ Use Case图并不是需求文档的必备部分 § Use Case分析是过程，不是结果 § Use Case可以是测试人员分析过程，也可以是产品人员分析过程 § Use case有可能是超越功能需求文档的
17
功能说明
§ 功能细分
- -
操作
角色
用户（粉丝） 用户（达人） 运营 √ √ √ √ √ √
需求总表
BD
商家
应包含功能组成图 作图常用的工具 § Visio § OmniGraffle 可配合原型展示 原型工具 § Axure RP § Balsamiq mockup
发布微博 转发微博 评论Leabharlann Baidu博
§ 每个Actor都通过不同的方式使用系统，除非他们是相同的Actor § Actor使用系统的每一种方式就是一个Use Case
副版主 普通用户
管理员 版主
22
斑竹
脚本Script
§ 脚本是一个角色与系统之间的一组交互作用 § 通常具有详细的真实数据及实际的期望输出值 § 一个应用系统可能具有成千上万个脚本 § 即使同一件事，所得到的脚本可能也会有细微的区别 § 脚本是描绘Use Case的重要的背景信息
4
首先，您需要把系统看成黑盒
一开始就深入细节的产品经理，忙乱而又没有绩效
- - -
往往陷入细节的泥坑，甚至是技术细节，甚至UI细节 被层出不穷的需求点和例外处理困扰 控制不住满脑袋乱冒的ideas
- - -
使用通过产品定位去约束自己 接受一个不完美的概念产品 系统总有一个从粗到细的过程
-
与外部系统交互的流程 需外部提供的接口及数据 接口描述方式 § 输入参数 § 输出参数
§ 接口
- -
15
产品详细设计要素
SQECS原则： § 精细（Specific） § 定量（Quantitative） § 执行（Executive） § 比较（Comparative） § 静态（Statical）
§ 场景描述
- 界面 - 操作（按钮、链接） - 结果展示
12
13
订单状态图示
§ 订单状态图
-
主状态图 子状态图 § 与子流程相关 § 考虑系统间的交互
-
14
流程说明文档的书写要点
§ 业务规则
-
流程中使用的业务规则
§ 输入 § 处理过程 § 输出 § 关联流程
3
需求获取的前提
§ 用户必须告诉你他想要什么 § 你必须完整地了解用户的业务 § 你必须知道与系统有关的任何人和任何东西 § 如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现 在是怎么工作的 § 需要了解人最普遍的心理活动 § 你是去了解要做什么而不是怎么做
Use Case与脚本
§ 一个Use Case代表一组潜在的脚本 § 通过研究一组相似的脚本，可以得到它们内在的逻辑 § 相似的脚本通常遵循相似的模式工作，并提供相似类型的结果 § 一个Use Case通常关注某一个目标
脚 本
用例
24
USE CASE
§ 描述系统提供的交互功能
20
什么是角色（Actor）
§ 与系统发生交互作用的、系统外的任何东西都是角色
- -
可以是人 也可以是机器
§ 角色不等同于使用者 § 角色存在于系统外部 § 角色不是活动的准确描述 § 使用者是行驶某个角色职责的系统的使用人员
-
21
我是角色Actor！
如小周是个组织者
角色的作用
§ 常用书写Use Case的工具：Visio，ROSE等
28
性能需求
§ 性能指标 § 易用性 § 安全性 § 兼容性 § 可扩展性 § 可维护性 § 可延展性 § 可移植性 § 可编程性 § 可靠性 § 可测试性
29
产品关注
技术关注
产品经理如何处理性能需求
- -
一个Use Case可以被其他的Use Case调用 Use Case可以组合完成某一项更大的功能
§ Use Case说明系统需要提供什么而不是怎么提供
-
用户并不关心你如何给他们提供所需要的功能
§ Use Case一般是用“动宾”短语命名 § 系统的每一个Use Case都必须列举，否则系统将会遗漏功能
5
再者，你要控制系统复杂性
系统内部无论多么复杂 - 他总是可以被“使用说明书”说清楚 - 用户没有耐心，需要直接了当
-
最后，有好的文字水平去控制
§ 需求分析是一个工业化的写作过程：80％的套路＋20％的创意 模式化的路子: § 定义好用户 § 定义好产品 § 先分析功能需求 § 再分析性能需求
8
产品概念设计要素
SQVID原则 § 简单（Simple） § 定性（Qualitative） § 愿景（Visional） § 个性（Individual） § 动态（Dynamic）
9
通过概念设计去表现产品
§ 产品概念是什么
- - -
怎么表现 包含哪些 与哪些有关联
§ 角色与操作
- -
描述 登录 注册流程 用QQ\新浪微博账号登陆 忘记密码流程
优先级 1 1 2 1
§ 需求优先级
18
设计工具
§ Axure RP的发音是』Ack-sure』，RP则是』Rapid Prototyping』快速 原型的缩写。RP是一个快速绘制Wireframe 和Prototyping的工具，主 要用来定义应用程序的需求与规格，以及设计使用者界面与功能，使用者 包括User Experience Designers、商业分析师、信息架构师、Usability Expert与产品经理等专业人士。 § 在Axure RP中建立Wireframe和Prototype可以帮助您快速且有效地分析 需求、验证设计并传达给所有参与者，以确保在有限的项目时间与资源下 ，开发出有用和可用的应用程序。 § Axure RP 结合了广受欢迎的简报与图标工具中简易操作的特性和其它必 要的功能。这样一来，商务专家就可以在不需要大量的文件制作下快速的 建立prototype，而项目成员与项目关系人也可以在不中断开发的情况下 轻松完成prototype。
31
高质量文档的标准
§ 概念、逻辑表述正确 § 可行性高 § 必要性 § 确定的优先级 § 需求清楚明确 § 需求可证实 § 完整性 § 一致性 § 可修改性 § 可追踪性
32
不同阶段的文档
§ 第一个阶段的文档是市场需求文档（产品经理提供） § 第二个阶段的文档是功能需求文档（产品经理提供） § 第三个阶段的文档是测试用例文档（测试人员编写） § 第四个阶段的文档是项目安排计划表（项目经理安排） § 下一个阶段的文档是详细设计说明书（技术架构组提供） § 再下一个阶段的文档是数据库设计及模块设计说明书（技术开发组提供）
7
以电子商务的交易系统为例
电子商务网站交易系统的目的和原则
目的： § 实现对订单的统一管理和跟踪 § 减少交互，提升交易管理性能 § 支持多渠道，实现复杂流程的调度 § 统一基础数据，可复用的订单模板 § 利用订单的信息进行经营性分析 设计原则： § 未来可同时承接多渠道订单 § 拆分主订单流程，减少分支流程 § 主订单状态简单，与其他系统耦合 § 订单数据的可扩展性高 § 订单积累可用于广泛的数据分析
定义 订单是消费者与出售者直接进行交易的契约，包括交易实 体、交易人和交易过程 状态是根据时间序列变化的标记，订单状态即订单在不同 流程时间点的枚举变量
11
交易流程图示
§ 流程简介
-
说明流程的使用场景，流程的总体说明 § 主流程图
- 普通流程图
§ 单向的 § 可变流
- 跨域的流程图
用例（USE CASE）的历史
§ 1967年Jacobson在爱立信工作的时候开始使用这种思想 § 这种想法最早应用于大型交换机系统的需求获取 § 1971年完成了这种方法的最初原型 § 1985年推出了改进版，并发布了面向对象的OOSE方法 § 大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去 § 它还被广泛的应用于工业领域
§ 产品经理应忘记自己懂技术、交互
§ 从用户、市场角度把需求提出来 § 弄清楚自己的专业发展方向，指标决定
§ 好消息是：大部分这种需求开发工程师和软件测试人员都帮你搞定了 § 你所做的就是找最好的测试人员帮你获取性能指标
30
为何需求高质量的文档
§ 没有高质量的需求文档，软件就像掉进泥沼的巨象，越挣扎陷得越 深入。——《人月神话》
33
=====
文档模版======
34
产品确认和项目安排（Microsoft project）
35
产品设计过程中的工具一览
基本工具 概念分析 原型设计
需求管理
37
汇集智慧，传播理念
产品经理系统分析方法与设计文档规范
王晟 2012年9月
Deeper Wider Farther
产品定位思考
定位思考的四个步骤： § 观看 § 验证 § 想象 § 展示
2
定位思考六要素
§ 谁？——与人有关的角色的相关作用； § 有多少？——涉及数量预估是多少； § 什么时候？——关于计划和安排的挑战； § 在那里？——有关方向和彼此配合的挑战？ § 结果怎样？——事情之间如何相互影响？ § 为什么？ ——展望全景的挑战？
25
USE CASE 是基础测试单元
§ Use Case清晰地描述了系统的功能界面 § 测试人员可以在开发初期制定测试计划 § 每一个Use Case都严格地说明了系统的某一项功能
- - -
它的输入 它的输出 期间的交互作用
§ Use Case是黑盒测试的基准（Benchmark）
16
功能说明与流程说明的区别
§ 流程说明
- - -
风险 1
风险级别 高
整体性 以流程为核心，重点描述流程的变化 下一个阶段的文档是功能说明文档 完整性 以功能为核心，重点描述系统的功能
§ 模块划分 § 功能描述 § 风险评估
2
较高
§ 功能说明
- -
3
较高
描述 监控策略 改善策略 S N S 社 区 引 导 购 物， 一期完成后，通过 引 导 购 物 放 在 2 消费的内容需要与纯 运营策略，监测用 期完成，一期主 粹自己发起打架的情 户在社区中的消费 要 LBS 的社区服 况。 倾向，再确定二期 务部分。 引导消费的内容。 线下消费产生内容比 上线前需要运营配 通过运营活动或 较少，而真正能够吸 合完成，完成主要 者直接进行系统 引并产生。因此内容 的商品展示。 抓取内容，方便 产生方面可能会存在 用户进行选择和 一定问题。 讨论。 用户构建的关系链可 后期达人（或卖家） 1 期 上 线 的 达 人 能会存在，才能避免 需要反的达人，处 均是，后期用户 纯粹广告的泛滥。 以相应的处罚。 需提交申请。
§ 几个好用的工具
10
交易流程说明
§ 名词定义
-
-
-
何为订单 § 交易人（用户&商家） 名词 § 交易实体（商品） 订单 § 交易过程（状态变化） 何为状态 § 随时间变化 订单状态 § 可枚举 何为订单系统 § 核心——订单的生命周期管理 § 范围——与其他系统的边界
26
合理利用USE CASE图
§ 通过分析Use Case图，产品经理可以找出不同的业务过程之间的关系
-
扩展、包含、派生、使用等关系
§ 通过这些关系可以降低系统的复杂度 § 可以帮助产品经理发现重复的过程
-
需求在细化过程中不断精细
27
需要说明的是
§ Use Case图并不是需求文档的必备部分 § Use Case分析是过程，不是结果 § Use Case可以是测试人员分析过程，也可以是产品人员分析过程 § Use case有可能是超越功能需求文档的
17
功能说明
§ 功能细分
- -
操作
角色
用户（粉丝） 用户（达人） 运营 √ √ √ √ √ √
需求总表
BD
商家
应包含功能组成图 作图常用的工具 § Visio § OmniGraffle 可配合原型展示 原型工具 § Axure RP § Balsamiq mockup
发布微博 转发微博 评论Leabharlann Baidu博
§ 每个Actor都通过不同的方式使用系统，除非他们是相同的Actor § Actor使用系统的每一种方式就是一个Use Case
副版主 普通用户
管理员 版主
22
斑竹
脚本Script
§ 脚本是一个角色与系统之间的一组交互作用 § 通常具有详细的真实数据及实际的期望输出值 § 一个应用系统可能具有成千上万个脚本 § 即使同一件事，所得到的脚本可能也会有细微的区别 § 脚本是描绘Use Case的重要的背景信息
4
首先，您需要把系统看成黑盒
一开始就深入细节的产品经理，忙乱而又没有绩效
- - -
往往陷入细节的泥坑，甚至是技术细节，甚至UI细节 被层出不穷的需求点和例外处理困扰 控制不住满脑袋乱冒的ideas
- - -
使用通过产品定位去约束自己 接受一个不完美的概念产品 系统总有一个从粗到细的过程
-
与外部系统交互的流程 需外部提供的接口及数据 接口描述方式 § 输入参数 § 输出参数
§ 接口
- -
15
产品详细设计要素
SQECS原则： § 精细（Specific） § 定量（Quantitative） § 执行（Executive） § 比较（Comparative） § 静态（Statical）