产品经理需求分析方法和文档书写规范

汇集智慧，传播理念

产品经理系统分析方法与设计文档规范

王晟 2012年9月

Deeper Wider Farther

产品定位思考

定位思考的四个步骤： §  观看 §  验证 §  想象 §  展示

2

定位思考六要素

§  谁？——与人有关的角色的相关作用； §  有多少？——涉及数量预估是多少； §  什么时候？——关于计划和安排的挑战； §  在那里？——有关方向和彼此配合的挑战？ §  结果怎样？——事情之间如何相互影响？ §  为什么？ ——展望全景的挑战？

3

需求获取的前提

§  用户必须告诉你他想要什么 §  你必须完整地了解用户的业务 §  你必须知道与系统有关的任何人和任何东西 §  如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现 在是怎么工作的 §  需要了解人最普遍的心理活动 §  你是去了解要做什么而不是怎么做

4

首先，您需要把系统看成黑盒

一开始就深入细节的产品经理，忙乱而又没有绩效

-  -  - 

往往陷入细节的泥坑，甚至是技术细节，甚至UI细节 被层出不穷的需求点和例外处理困扰 控制不住满脑袋乱冒的ideas

-  -  - 

使用通过产品定位去约束自己 接受一个不完美的概念产品 系统总有一个从粗到细的过程

5

再者，你要控制系统复杂性

系统内部无论多么复杂 -  他总是可以被“使用说明书”说清楚 -  用户没有耐心，需要直接了当

- 

最后，有好的文字水平去控制

§  需求分析是一个工业化的写作过程：80％的套路＋20％的创意 模式化的路子: §  定义好用户 §  定义好产品 §  先分析功能需求 §  再分析性能需求

7

以电子商务的交易系统为例

电子商务网站交易系统的目的和原则

目的： §  实现对订单的统一管理和跟踪 §  减少交互，提升交易管理性能 §  支持多渠道，实现复杂流程的调度 §  统一基础数据，可复用的订单模板 §  利用订单的信息进行经营性分析 设计原则： § 未来可同时承接多渠道订单 § 拆分主订单流程，减少分支流程 § 主订单状态简单，与其他系统耦合 § 订单数据的可扩展性高 § 订单积累可用于广泛的数据分析

8

产品概念设计要素

SQVID原则 §  简单（Simple） §  定性（Qualitative） §  愿景（Visional） §  个性（Individual） §  动态（Dynamic）

9

通过概念设计去表现产品

§  产品概念是什么

-  -  - 

怎么表现 包含哪些 与哪些有关联

§  几个好用的工具

10

交易流程说明

§  名词定义

- 

- 

- 

何为订单 §  交易人（用户&商家）

名词 §  交易实体（商品） 订单 §  交易过程（状态变化） 何为状态 §  随时间变化 订单状态 §  可枚举 何为订单系统 §  核心——订单的生命周期管理 §  范围——与其他系统的边界

定义 订单是消费者与出售者直接进行交易的契约，包括交易实 体、交易人和交易过程 状态是根据时间序列变化的标记，订单状态即订单在不同 流程时间点的枚举变量

11

交易流程图示

§  流程简介

- 

说明流程的使用场景，流程的总体说明 §  主流程图

-  普通流程图

§  单向的 §  可变流

-  跨域的流程图

§  域的划分 §  域间交互

§  场景描述

-  界面 -  操作（按钮、链接） -  结果展示

12

13

订单状态图示

§  订单状态图

- 

主状态图 子状态图 § 与子流程相关 § 考虑系统间的交互

- 

14

流程说明文档的书写要点

§  业务规则

- 

流程中使用的业务规则

§  输入 §  处理过程 §  输出 §  关联流程

- 

与外部系统交互的流程 需外部提供的接口及数据 接口描述方式 §  输入参数 §  输出参数

§  接口

-  - 

15

产品详细设计要素

SQECS原则： §  精细（Specific） §  定量（Quantitative） §  执行（Executive） §  比较（Comparative） §  静态（Statical）

16

功能说明与流程说明的区别

§  流程说明

-  -  - 

风险 1

风险级别 高

整体性 以流程为核心，重点描述流程的变化 下一个阶段的文档是功能说明文档 完整性 以功能为核心，重点描述系统的功能

§  模块划分 §  功能描述 §  风险评估

2

较高

§  功能说明

-  - 

3

较高

描述 监控策略 改善策略 S N S 社 区 引 导 购 物， 一期完成后，通过 引 导 购 物 放 在 2 消费的内容需要与纯 运营策略，监测用 期完成，一期主 粹自己发起打架的情 户在社区中的消费 要 LBS 的社区服 况。 倾向，再确定二期 务部分。 引导消费的内容。 线下消费产生内容比 上线前需要运营配 通过运营活动或 较少，而真正能够吸 合完成，完成主要 者直接进行系统 引并产生。因此内容 的商品展示。 抓取内容，方便 产生方面可能会存在 用户进行选择和 一定问题。 讨论。 用户构建的关系链可 后期达人（或卖家） 1 期 上 线 的 达 人 能会存在，才能避免 需要反的达人，处 均是，后期用户 纯粹广告的泛滥。 以相应的处罚。 需提交申请。

17

功能说明

§  功能细分

-  - 

操作

角色

用户（粉丝） 用户（达人） 运营 √ √ √ √ √ √

需求总表

BD

商家

应包含功能组成图 作图常用的工具 §  Visio

§  OmniGraffle 可配合原型展示 原型工具 §  Axure RP §  Balsamiq mockup

发布微博 转发微博 评论微博

§  角色与操作

-  - 

描述 登录 注册流程 用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。

用例（USE CASE）的历史

§  1967年Jacobson在爱立信工作的时候开始使用这种思想 §  这种想法最早应用于大型交换机系统的需求获取 §  1971年完成了这种方法的最初原型 §  1985年推出了改进版，并发布了面向对象的OOSE方法 §  大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去 §  它还被广泛的应用于工业领域

20

什么是角色（Actor）

§  与系统发生交互作用的、系统外的任何东西都是角色

-  - 

可以是人 也可以是机器

§  角色不等同于使用者 §  角色存在于系统外部 §  角色不是活动的准确描述 §  使用者是行驶某个角色职责的系统的使用人员

- 

21

我是角色Actor！

如小周是个组织者

角色的作用

§  每个Actor都通过不同的方式使用系统，除非他们是相同的Actor §  Actor使用系统的每一种方式就是一个Use Case

副版主 普通用户

管理员 版主

22

斑竹

脚本Script

§  脚本是一个角色与系统之间的一组交互作用 §  通常具有详细的真实数据及实际的期望输出值 §  一个应用系统可能具有成千上万个脚本 §  即使同一件事，所得到的脚本可能也会有细微的区别 §  脚本是描绘Use Case的重要的背景信息

Use Case与脚本

§  一个Use Case代表一组潜在的脚本 §  通过研究一组相似的脚本，可以得到它们内在的逻辑 §  相似的脚本通常遵循相似的模式工作，并提供相似类型的结果 §  一个Use Case通常关注某一个目标

脚 本

用例

24

USE CASE

§  描述系统提供的交互功能

-  - 

一个Use Case可以被其他的Use Case调用 Use Case可以组合完成某一项更大的功能

§  Use Case说明系统需要提供什么而不是怎么提供

- 

用户并不关心你如何给他们提供所需要的功能

§  Use Case一般是用“动宾”短语命名 §  系统的每一个Use Case都必须列举，否则系统将会遗漏功能

25

USE CASE 是基础测试单元

§  Use Case清晰地描述了系统的功能界面 §  测试人员可以在开发初期制定测试计划 §  每一个Use Case都严格地说明了系统的某一项功能

-  -  - 

它的输入 它的输出 期间的交互作用

§  Use Case是黑盒测试的基准（Benchmark）

26

合理利用USE CASE图

§  通过分析Use Case图，产品经理可以找出不同的业务过程之间的关系

- 

扩展、包含、派生、使用等关系

§  通过这些关系可以降低系统的复杂度 §  可以帮助产品经理发现重复的过程

- 

需求在细化过程中不断精细

27

需要说明的是

§  Use Case图并不是需求文档的必备部分 §  Use Case分析是过程，不是结果 §  Use Case可以是测试人员分析过程，也可以是产品人员分析过程 §  Use case有可能是超越功能需求文档的

§  常用书写Use Case的工具：Visio，ROSE等

28

性能需求

§  性能指标 §  易用性 §  安全性 §  兼容性 §  可扩展性 §  可维护性 §  可延展性 §  可移植性 §  可编程性 §  可靠性 §  可测试性

29

产品关注

技术关注

产品经理如何处理性能需求

§  产品经理应忘记自己懂技术、交互

§  从用户、市场角度把需求提出来 §  弄清楚自己的专业发展方向，指标决定

§  好消息是：大部分这种需求开发工程师和软件测试人员都帮你搞定了 §  你所做的就是找最好的测试人员帮你获取性能指标

30

为何需求高质量的文档

§  没有高质量的需求文档，软件就像掉进泥沼的巨象，越挣扎陷得越 深入。——《人月神话》

31

高质量文档的标准

§  概念、逻辑表述正确 §  可行性高 §  必要性 §  确定的优先级 §  需求清楚明确 §  需求可证实 §  完整性 §  一致性 §  可修改性 §  可追踪性

32

不同阶段的文档

§  第一个阶段的文档是市场需求文档（产品经理提供） §  第二个阶段的文档是功能需求文档（产品经理提供） §  第三个阶段的文档是测试用例文档（测试人员编写） §  第四个阶段的文档是项目安排计划表（项目经理安排） §  下一个阶段的文档是详细设计说明书（技术架构组提供） §  再

下一个阶段的文档是数据库设计及模块设计说明书（技术开发组提供）

33

=====

文档模版======

34

产品确认和项目安排（Microsoft project）

35

产品设计过程中的工具一览

基本工具 概念分析 原型设计

需求管理

37

汇集智慧，传播理念

产品经理系统分析方法与设计文档规范

王晟 2012年9月

Deeper Wider Farther

产品定位思考

定位思考的四个步骤： §  观看 §  验证 §  想象 §  展示

2

定位思考六要素

§  谁？——与人有关的角色的相关作用； §  有多少？——涉及数量预估是多少； §  什么时候？——关于计划和安排的挑战； §  在那里？——有关方向和彼此配合的挑战？ §  结果怎样？——事情之间如何相互影响？ §  为什么？ ——展望全景的挑战？

3

需求获取的前提

§  用户必须告诉你他想要什么 §  你必须完整地了解用户的业务 §  你必须知道与系统有关的任何人和任何东西 §  如果用户不能告诉你他们想要什么，你必须花费时间去观察和记录他们现 在是怎么工作的 §  需要了解人最普遍的心理活动 §  你是去了解要做什么而不是怎么做

4

首先，您需要把系统看成黑盒

一开始就深入细节的产品经理，忙乱而又没有绩效

-  -  - 

往往陷入细节的泥坑，甚至是技术细节，甚至UI细节 被层出不穷的需求点和例外处理困扰 控制不住满脑袋乱冒的ideas

-  -  - 

使用通过产品定位去约束自己 接受一个不完美的概念产品 系统总有一个从粗到细的过程

5

再者，你要控制系统复杂性

系统内部无论多么复杂 -  他总是可以被“使用说明书”说清楚 -  用户没有耐心，需要直接了当

- 

最后，有好的文字水平去控制

§  需求分析是一个工业化的写作过程：80％的套路＋20％的创意 模式化的路子: §  定义好用户 §  定义好产品 §  先分析功能需求 §  再分析性能需求

7

以电子商务的交易系统为例

电子商务网站交易系统的目的和原则

目的： §  实现对订单的统一管理和跟踪 §  减少交互，提升交易管理性能 §  支持多渠道，实现复杂流程的调度 §  统一基础数据，可复用的订单模板 §  利用订单的信息进行经营性分析 设计原则： § 未来可同时承接多渠道订单 § 拆分主订单流程，减少分支流程 § 主订单状态简单，与其他系统耦合 § 订单数据的可扩展性高 § 订单积累可用于广泛的数据分析

8

产品概念设计要素

SQVID原则 §  简单（Simple） §  定性（Qualitative） §  愿景（Visional） §  个性（Individual） §  动态（Dynamic）

9

通过概念设计去表现产品

§  产品概念是什么

-  -  - 

怎么表现 包含哪些 与哪些有关联

§  几个好用的工具

10

交易流程说明

§  名词定义

- 

- 

- 

何为订单 §  交易人（用户&商家）

名词 §  交易实体（商品） 订单 §  交易过程（状态变化） 何为状态 §  随时间变化 订单状态 §  可枚举 何为订单系统 §  核心——订单的生命周期管理 §  范围——与其他系统的边界

定义 订单是消费者与出售者直接进行交易的契约，包括交易实 体、交易人和交易过程 状态是根据时间序列变化的标记，订单状态即订单在不同 流程时间点的枚举变量

11

交易流程图示

§  流程简介

- 

说明流程的使用场景，流程的总体说明 §  主流程图

-  普通流程图

§  单向的 §  可变流

-  跨域的流程图

§  域的划分 §  域间交互

§  场景描述

-  界面 -  操作（按钮、链接） -  结果展示

12

13

订单状态图示

§  订单状态图

- 

主状态图 子状态图 § 与子流程相关 § 考虑系统间的交互

- 

14

流程说明文档的书写要点

§  业务规则

- 

流程中使用的业务规则

§  输入 §  处理过程 §  输出 §  关联流程

- 

与外部系统交互的流程 需外部提供的接口及数据 接口描述方式 §  输入参数 §  输出参数

§  接口

-  - 

15

产品详细设计要素

SQECS原则： §  精细（Specific） §  定量（Quantitative） §  执行（Executive） §  比较（Comparative） §  静态（Statical）

16

功能说明与流程说明的区别

§  流程说明

-  -  - 

风险 1

风险级别 高

整体性 以流程为核心，重点描述流程的变化 下一个阶段的文档是功能说明文档 完整性 以功能为核心，重点描述系统的功能

§  模块划分 §  功能描述 §  风险评估

2

较高

§  功能说明

-  - 

3

较高

描述 监控策略 改善策略 S N S 社 区 引 导 购 物， 一期完成后，通过 引 导 购 物 放 在 2 消费的内容需要与纯 运营策略，监测用 期完成，一期主 粹自己发起打架的情 户在社区中的消费 要 LBS 的社区服 况。 倾向，再确定二期 务部分。 引导消费的内容。 线下消费产生内容比 上线前需要运营配 通过运营活动或 较少，而真正能够吸 合完成，完成主要 者直接进行系统 引并产生。因此内容 的商品展示。 抓取内容，方便 产生方面可能会存在 用户进行选择和 一定问题。 讨论。 用户构建的关系链可 后期达人（或卖家） 1 期 上 线 的 达 人 能会存在，才能避免 需要反的达人，处 均是，后期用户 纯粹广告的泛滥。 以相应的处罚。 需提交申请。

17

功能说明

§  功能细分

-  - 

操作

角色

用户（粉丝） 用户（达人） 运营 √ √ √ √ √ √

需求总表

BD

商家

应包含功能组成图 作图常用的工具 §  Visio

§  OmniGraffle 可配合原型展示 原型工具 §  Axure RP §  Balsamiq mockup

发布微博 转发微博 评论微博

§  角色与操作

-  - 

描述 登录 注册流程 用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。

用例（USE CASE）的历史

§  1967年Jacobson在爱立信工作的时候开始使用这种思想 §  这种想法最早应用于大型交换机系统的需求获取 §  1971年完成了这种方法的最初原型 §  1985年推出了改进版，并发布了面向对象的OOSE方法 §  大部分面向对象技术都采用这种需求方法，UML建模语言也已将它包容进去 §  它还被广泛的应用于工业领域

20

什么是角色（Actor）

§  与系统发生交互作用的、系统外的任何东西都是角色

-  - 

可以是人 也可以是机器

§  角色不等同于使用者 §  角色存在于系统外部 §  角色不是活动的准确描述 §  使用者是行驶某个角色职责的系统的使用人员

- 

21

我是角色Actor！

如小周是个组织者

角色的作用

§  每个Actor都通过不同的方式使用系统，除非他们是相同的Actor §  Actor使用系统的每一种方式就是一个Use Case

副版主 普通用户

管理员 版主

22

斑竹

脚本Script

§  脚本是一个角色与系统之间的一组交互作用 §  通常具有详细的真实数据及实际的期望输出值 §  一个应用系统可能具有成千上万个脚本 §  即使同一件事，所得到的脚本可能也会有细微的区别 §  脚本是描绘Use Case的重要的背景信息

Use Case与脚本

§  一个Use Case代表一组潜在的脚本 §  通过研究一组相似的脚本，可以得到它们内在的逻辑 §  相似的脚本通常遵循相似的模式工作，并提供相似类型的结果 §  一个Use Case通常关注某一个目标

脚 本

用例

24

USE CASE

§  描述系统提供的交互功能

-  - 

一个Use Case可以被其他的Use Case调用 Use Case可以组合完成某一项更大的功能

§  Use Case说明系统需要提供什么而不是怎么提供

- 

用户并不关心你如何给他们提供所需要的功能

§  Use Case一般是用“动宾”短语命名 §  系统的每一个Use Case都必须列举，否则系统将会遗漏功能

25

USE CASE 是基础测试单元

§  Use Case清晰地描述了系统的功能界面 §  测试人员可以在开发初期制定测试计划 §  每一个Use Case都严格地说明了系统的某一项功能

-  -  - 

它的输入 它的输出 期间的交互作用

§  Use Case是黑盒测试的基准（Benchmark）

26

合理利用USE CASE图

§  通过分析Use Case图，产品经理可以找出不同的业务过程之间的关系

- 

扩展、包含、派生、使用等关系

§  通过这些关系可以降低系统的复杂度 §  可以帮助产品经理发现重复的过程

- 

需求在细化过程中不断精细

27

需要说明的是

§  Use Case图并不是需求文档的必备部分 §  Use Case分析是过程，不是结果 §  Use Case可以是测试人员分析过程，也可以是产品人员分析过程 §  Use case有可能是超越功能需求文档的

§  常用书写Use Case的工具：Visio，ROSE等

28

性能需求

§  性能指标 §  易用性 §  安全性 §  兼容性 §  可扩展性 §  可维护性 §  可延展性 §  可移植性 §  可编程性 §  可靠性 §  可测试性

29

产品关注

技术关注

产品经理如何处理性能需求

§  产品经理应忘记自己懂技术、交互

§  从用户、市场角度把需求提出来 §  弄清楚自己的专业发展方向，指标决定

§  好消息是：大部分这种需求开发工程师和软件测试人员都帮你搞定了 §  你所做的就是找最好的测试人员帮你获取性能指标

30

为何需求高质量的文档

§  没有高质量的需求文档，软件就像掉进泥沼的巨象，越挣扎陷得越 深入。——《人月神话》

31

高质量文档的标准

§  概念、逻辑表述正确 §  可行性高 §  必要性 §  确定的优先级 §  需求清楚明确 §  需求可证实 §  完整性 §  一致性 §  可修改性 §  可追踪性

32

不同阶段的文档

§  第一个阶段的文档是市场需求文档（产品经理提供） §  第二个阶段的文档是功能需求文档（产品经理提供） §  第三个阶段的文档是测试用例文档（测试人员编写） §  第四个阶段的文档是项目安排计划表（项目经理安排） §  下一个阶段的文档是详细设计说明书（技术架构组提供） §  再

下一个阶段的文档是数据库设计及模块设计说明书（技术开发组提供）

33

=====

文档模版======

34

产品确认和项目安排（Microsoft project）

35

产品设计过程中的工具一览

基本工具 概念分析 原型设计

需求管理

37