产品需求文档(PRD)写作方法(下)

13.2常见PRD文档包含内容

• 文档说明
• 产品说明
• 全局功能需求说明
• 详细功能需求说明

13.3全局功能说明

• 全局功能说明
  • 由于接下来我们要比较详细的表述每个类与每个子类的功能说明,所以这里就要把那些不能放到子类里面去的全局功能性的东西说清楚
    • 尽管是全局功能,但是我们也可以分类说明,例如:
      • UI
      • 交互
      • 等等...

13.3全局功能说明案例

13.4详细功能需求描述

• 整体说明完成以后,我们就要开始对各个需求模块进行详细的需求说明
  • 根据实际的需求,你可以按照你习惯的表述顺序来表述,产检的表述顺序有:
    • 按照功能的逻辑来表述(更抽象,研发喜欢)
    • 按照产品结构来表述(频道,页面,模块,元素的逻辑表述,相对比较适合产品经理的逻辑.产品经理喜欢)
      • 具体哪一个,看团队要求和默契程度

13.4详细功能需求描述-按照产品的逻辑来表述需求

13.5UML>用例文档>用例图与状态图

• UML登场了(其实产品经理的PRD温昂写作所涉及到的UML知识非常有限)
  • 中文名称:统一建模语言
  • 英文名称:Unified Modeling Language
  • 定义:是一种面向对象的建模语言,他是运用统一的,标准化的标记和定义实现对软件系统进行面向对象的描述和建模.
• UML常见的说明图类型
  • 用例图-表述
  • 状态图
  • 时序图
  • 结构图
  • 等..

13.6什么是用例图

• 用例
  • 用例就是一种描述系统功能需求的方法
• 用例图
  • 用例图表述的是系统的外部参与者与系统之间的关系,是由参与者与用例组成的示意图
  • 用例图的组成要素
    • 参与者(可以是人,也可以是另一个系统,也可以是其他的东西,是相对的)
    • 用例
    • 关联线

    • 方框

      
      

13.7用例说明

13.8用例说明特别批注

13.9详细功能需求描述的基本结构

• 产品的整体用例图

13.10详细需求说明的原则

• MECE原则
  • MECE,是Mutually Exclusive Collectively Exhaustive,中文意思是"相互独立,完全穷尽".也就是对于一个重大的议题,能够做到不重叠,不遗漏的分类,而且能够藉此有效把我问题的核心,并解决问题的方法
• MECE只是一种思考方式,当PRD文档撰写交付研发以后,其实多少还是会存在没有考虑到位或者需求调整的情况,所以:
  • 撰写PRD文档前一定要保证思考到位了,产品结构本身短期内不会有重大改动
  • 需求分类与表述方式要参考MECE原则
  • 这样即便是在交付后,出现调整或需要优化的地方,也不会出现重购的情况
    • 重构需求, 重新调整产品结构等,对已经处在开发过程中的团队来说是灾难性的
  • 需求撰写,更多的是考验耐心,思路,经验,但产品架构的确定等更是考验一个产品经理的规划与把握能力
  • 不要害怕,不要迷信

13.11优秀的PRD文档应该具备的特点

• 正确
  • 确保文档中的表述与产品经理的思路是对应且正确的
• 无歧义
  • 文档的表述方便阅读理解,不会产生歧义
• 完备
  • MECE原则尽量保证对产品功能需求表述的系统完整
• 一致
  • 文档中用词用语一致,对于同一事物的表述应该一样,避免混用同义词
• 具有优先级
  • 产品的功能性需求是又先后主次的,对于一次性规划叫多功能的PRD,应该注明功能性需求的先后主次
• 可验证
  • 对于功能性的描述,是可以进行测试的,而不是步伐测试,无法定性的东西,例如:效率高,交互完美等词语,都是无法验证的
• 可修改
  • PRD文档利于后期的修改与升级
• 可追踪
  • 每个功能性需求的来源应该是清楚明白的.