• 文档说明
• 产品说明
• 理解并掌握全局功能
• 理解并掌握详细功能说明
– 用例 （Use Case）
– 功能描述
——————————————————————————————————
• 全局功能说明
– 由于接下来我们要比较详细的表述每个类与每个子类的功能说明，所以这里就要把那些不能放到子类里面去
的全局性的东西清楚
• 尽管是全局功能，但也可以分类说明，例如：
– UI
– 交互
– 等等...
• 例如：
– 用户交互统一说明：
– 本客户端在用户触发操作后，应优先加载用户界面，同时在界面中加载数据的位置使用风火轮提
示用户数据中。
– 本客户端的时间显示，建议使用人性化提示，例如：20分钟前，一天前，三天前，超过7天，则
显示具体时间，如：3月30日17点55分，超过一年，则显示12年3月30日17点55分
• 详细功能需求描述
• 整体说明完成以后，我们就要开始对各个需求板块进行详细的需求说明
– 根据实际的需求，你可以按照你习惯的表述顺序来表述，常见的表述顺序有：
• 按照功能的逻辑来表述（更抽象，研发喜欢）
• 按照产品结构来表述（频道，页面，模块，元素的逻辑表述，相对比较适合产品经理，产品经理喜欢)
– 具体哪一个，看团队要求和默契度
• 例：按照产品的逻辑来表述需求
• UML > 用例文档 > 用例图与状态图
• UML登场（其实产品经理的PRD文档写作所涉及到的UML知识非常有限）
– 中文名称：统一建模语言
– 英文名称：Unified Modeling Language
– 定义：是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模
• UML 常见的说明图类型
– 用例图 - 表述
– 状态图
– 时序图
– 结构图
– 等....
♦ 什么是用例图？
• 用例
– 用例就是一种描述系统功能需求的方法
• 用例图
– 用例图表述的是系统的外部参与者与系统之间的关系，是由参与者与用例组成的示意图
– 用例图的组成要素
• 参与者（可以是人，也可以是另一个系统，也可以是其它的东西，是相对的）
• 用例
• 关联线
• 方框
例：
• 用例说明
界面元素说明
• 特别批注：你所看到的这个表格，只是一个基本格式，关于用例在业内并没有一个成为和固定的专门
供我们套用的东西，一切都以你团队的默认习惯和达到你的目的为依据来写用例
• 产品的整体用例图
• 功能板块1需求
– 功能板块1的止功能1
• 功能板块1的子功能1的元素1说明（用例描述）
• 功能模块1的子功能1的元素2说明（用例描述）
– 功能板块1的子功能2
• 功能板块1的子功能2的元素1说明（用例描述）
• 功能板块1的子功能2的元素2说明（用例描述）
• 功能板块2需求（用例文档）
– 功能板块2的子功能1
• 功能板块2的子功能1的元素1说明（用例描述）
• 功能模块2的子功能1的元素1说明（用例描述）
– 功能板块2的子功能1
• 功能板块2的子功能1的元素1说明（用例描述）
• 功能模块2的子功能1的元素1说明（用例描述）
• MECE 原则
– MECE，是Mutaually Exclusive Colletively Exhaustive, 中文意思是 “ 相互独立，完全
穷尽”。 也就是对于一个重大的议题，能够做到不重叠，不遗漏的分类，而且能够籍此有
效把握问题的核心，并解决问题的方法。
• MECE 只是一种思考方式，当PRD 文档撰写交付研发以后，其实多少还是会存在没有考虑到
位或者需求调整的情况，所以：
– 撰写PRD文档前一定要保证思考到位了，产品结构本身短期内不会有重大改动
– 需求分类与表述方式要参考NECE原则
– 这样即便是在交付后，出现调整或需要优化的地方，也不会出现重构的情况
• 重构需求，重新调整产品结构等，对已经处在开发过程中的团队来说是灾难性的
– 需求撰写，更多的是考验耐心，思路，经验，但产品架构的确定等更是考验一个产品经理
对产品的规划与把握能力
– 不要害怕，不要迷信
• 正确
– 确保文档中的表述与产品经理的思路是对应且正确的
• 无歧义
– 文档的表述方便阅读理解，不会产生歧义
• 完备
– MECE原则尽量保证对产品功能需求表述的系统完整
• 一致
– 文档中用词用语一致，对于同一事物的表述应该一样，避免混用同义词
• 具有优先级
– 产品的功能性需求是有先后主次的，对于一次性规划叫多功能的PRD ，应该注明功能性
需求的先后主次
• 可验证
– 对于功能的描述，是可以进行测试的，而不是不发测试，无法定性的东西。例如：效率高，
交互完美等词语，都是无法验证的
• 可修改
– PRD 文档利于后期的修改与升级
• 可追踪
– 每个功能性需求的来源应该是清楚明白的