• 文档说明
• 产品说明
• 理解并掌握全局功能
• 理解并掌握详细功能说明
– 用例 (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 文档利于后期的修改与升级
• 可追踪
– 每个功能性需求的来源应该是清楚明白的