PRD编写规范
为何需要写PRD？
在PRD没有标准化、模板化、版本化前，大多数会存在的情况：
- PRD里关键需求描述不准确，研发过程中不断修改，导致项目延期；
- 产品总监、项目经理、研发、测试总是不断挑刺，信誉度降低，自信心受打击；
- 到新公司负责新项目，前任产品经理留下的文档晦涩难懂，不知所云。
如果遇到以上一个或多个问题，那么你可能需要反思，自己写PRD的思路是不是有问题？
写PRD是产品经理非常重要的基本功，写好PRD，可以提高团队效率，减少无效的沟通。
**产品需求文档是产品设计研发过程中的指导纲领；**是需求描述的工具，避免各部门在传达中出现遗漏、偏差等问题，减少沟通成本，也为产品质量提供保障；它有助于新成员快速熟悉项目；还有利于产品迭代管理中回溯、复盘。
由上表可见，每一个阶段、每个成员，都需要以产品需求文档为依归。
PRD文档的目的就是让每个项目成员知道需求为什么做、要做什么、怎么做。
PRD的书写原则：
有理有据：从项目成员知道为什么做
全面、清晰、准确：让大家知道做什么、怎么做。
易读性：让大家方便快捷的理解文档内容。
明确了原则，还有2个前提：「需求类型、需求大小」
需求类型有：功能需求、接口需求、性能需求、策略需求、埋点需求、统计需求等等。
需求大小：可以是从0-1的大项目，包含上边的所有需求类型，还有就是日常迭代版本的小需求。
什么是PRD？
PRD是Product Requirement Document的简称，其中文翻译为：产品需求文档。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最重要的一个文档。
PRD的主要使用对象有：研发、测试、交互设计师及其他业务人员。
- 研发可以根据PRD获知整个产品的逻辑，作为编码的依据；
- 测试可以根据PRD编写测试用例，为正式测试做准备；
- 交互设计师可以根据PRD设计交互细节；
- 业务人员可以通过PRD提前了解产品，为运营和推广做准备；
PRD是项目启动之前，必须经过评审达成共识的最重要文档。产品经理的PRD，就像建筑设计师的设计图纸，是设计和思考的文档化呈现。《用户体验要素》作者在书中有一句很经典的话：“文档不能解决问题，但定义可以”，PRD就是要定义需求。
写PRD前的思考？
**1.解决什么问题？**解决用户什么问题？发现问题比解决方案更重要。
**2.怎么衡量？**不同的干系人，通过什么指标去衡量问题是否已解决？有没有埋点？有没有业务数据？谁来运营？
**3.需要多少资源？**为了实现这个解决方案，需要多少资源、多少人？能大致评估吗?
**4.会不会太复杂？**这个解决方案会不会太复杂？复杂是产品的坟墓。有没有性价比更高的解决方案？会不会影响现有的业务？会不会影响历史数据？
**6.有创新吗？**有更创新的解决方案吗?竞品怎么做的，有没有调研3个以上的竞品方案。
**7.用户怎么说？**需求真的是提交人说的那样吗?有亲身体验过场景吗？有跟用户面对面交流吗？熟悉相关领域的基本知识吗？有看不懂的名词吗？动手写文档或做设计方案之前，一定要问问自己以上几个问题，想清楚了在动手，任何一个问题没想清楚，都不要进行下一步。
如何写产品需求文档？
需求文档的质量好坏直接影响到产品项目的开展，所以撰写需求文档是一个合格的产品经理的必备技能。
产品需求文档主要包含产品文档的使用场景、使用目的、前提条件、写作原则、常用工具、主要内容和画原型写文档的相关规则等。
Axure一体化需求文档：
使用Axure将全部需求文档，最终通过Axure打包提供出去。好处是方便查看，看原型的基础上又能看文档说明。但有一种不是很“严肃”的感觉。
Word版需求文档
通过Word进行需求描述，并统一提供。容易留存，也比较正规，在阅读上以文字为主。
PRD需求文档版本化
Axure一体化需求文档版本化：
Axure是一款常用的原型设计工具，它可以支持在同一个项目中实现多个版本的需求文档，并且可以进行版本化管理。以下是一些实现Axure一体化需求文档版本化的步骤：
- 创建版本库：使用版本控制软件（如Git、SVN等）创建一个版本库，用于存储需求文档的各个版本。
- 导出Axure文件：将Axure原型文件导出为HTML文件，并将HTML文件放置在版本库中。
- 版本化管理：使用版本控制软件进行版本化管理，例如在Git中使用分支（branch）来管理不同的版本，每个分支对应一个版本。
- 合并更新：当需要更新需求文档时，可以在对应的分支中进行修改和更新，然后将更新后的HTML文件上传到版本库中，并在版本控制软件中合并更新。
- 回滚版本：如果某个版本出现问题，可以在版本控制软件中回滚到之前的版本，以便进行修复和处理。
通过以上步骤，可以实现Axure一体化需求文档的版本化管理，方便团队成员进行协作和管理，同时也可以保证需求文档的稳定性和可靠性。
Word版需求文档版本化：
Word版需求文档的版本化管理可以使用版本控制软件来实现，例如Git、SVN等。以下是一些实现Word版需求文档版本化的步骤：
- 创建版本库：使用版本控制软件创建一个版本库，用于存储需求文档的各个版本。
- 复制文档：将需求文档复制到版本库中，并将其命名为初始版本（例如v1.0）。
- 版本化管理：使用版本控制软件进行版本化管理，例如在Git中使用分支（branch）来管理不同的版本，每个分支对应一个版本。
- 更新文档：当需要更新需求文档时，可以在对应的分支中进行修改和更新，然后将更新后的文档上传到版本库中，并在版本控制软件中合并更新。
- 回滚版本：如果某个版本出现问题，可以在版本控制软件中回滚到之前的版本，以便进行修复和处理。
- 版本号管理：在文档中添加版本号（例如v1.1、v1.2等），以便团队成员进行区分和识别。
通过以上步骤，可以实现Word版需求文档的版本化管理，方便团队成员进行协作和管理，同时也可以保证需求文档的稳定性和可靠性。需要注意的是，每次更新文档时，都需要在版本控制软件中进行提交和记录，以保证版本的完整性和可追溯性。
PRD需求文档模板标准化
搭框架、定流程、扣细节，这是从一名产品前辈那了解到的产品设计流程，写PRD，也可以按照这个思路。
1、文档修改记录
记录每次文档更新的时间、作者、修订内容，便于追溯历史变动；
一般通过表格展示出以下内容：
- 修改内容：说清楚修改的哪个模块，哪个页面、哪个功能点。当然也可以分成修改模块、修改页面多个列。
- 修改原因：就是为啥要修改，比如说逻辑缺失需要补充等等。
- 修改人：谁改的
- 修改日期：修改时间
2、全局说明
包括名词解释、统一异常处理、列表默认数据规则等。
- 名词解释：每个行业都有专业术语，可以提前将晦涩难懂的术语提前做好解释，便于达成共识，更好沟通；
- 统一异常处理：网络异常、后台服务异常的交互逻辑；
- 列表默认数据规则：默认列表的排序方式，默认显示条数，超过多少条翻页，缺省值展现方式；
- 所有涉及全局的描述，都可以罗列在这里。
- 重要说明/风险
3、项目背景
每个产品，都有一套价值模型。以信贷产品为例，针对用户的价值指标有放款额、审批时长、是否上征信等；针对后台业务人员，有审批时效、通过率、放款率、坏账率等指标；针对老板，有投资回报比、员工成本、净利润等价值指标，每一个需求，应该都是围绕某个价值指标展开。
参考格式如下：当前的现状是什么，有哪些问题/痛点，这些问题导致了什么结果，为了解决这个问题，我们需要采取什么动作，达到什么目的，能够获取哪些收益，产生什么价值。
背景从现状、方案、目标3方面描述:
- 现状：描述当前需求方遇到的问题，最好能跟价值模型关联；
- 方案：针对这个问题，所提供的解决方案概述；
- 目标：期望获得多少价值指标提升；
通过项目背景的描述，可以让项目参与者感受到自己的工作价值。
4、项目结构
项目范围对应搭框架部分，将功能结构图在此处罗列；
首先遍历出所有用户角色，再针对每个角色，提供相应的系统/功能，然后按照某种维度进行结构划分。产品由一个个功能组成，功能是逻辑结构，一个完整的功能具备输入、处理、输出三大特性。
从大到小的划分是：系统>功能模块>功能，用户+功能组成了用例，用例是PRD文档里描述占比70%以上的内容，所以合理的功能结构，是写好PRD的前提。
产品架构图
功能结构图
5、业务流程
业务流程对应定流程部分，将核心业务流程、子系统业务流程在此处罗列
每个产品都有一个核心业务流程，这个核心业务流程涉及多个角色，这个步骤就是把各个角色和功能联系起来。通过核心业务流程，阅读者可以了解产品全貌，对产品有个宏观的认识。
此外，每个系统也有各自的核心业务流程，全业务流程+子系统业务流程，可以概括产品的业务逻辑。
这个步骤输出产品核心业务流程图，子系统核心业务流程图，活动图，状态机图，与外部系统交互可能还有时序图。
流程图的类型有很多种，像业务流程图、页面流程图、泳道图、uml里的时序图、用例图等等；‘
基于不同流程图的特性去选择不同的类型，比如有多角色时，我们可以使用泳道图。对于UML，像用例图、序列图，在画的时候有一定的门槛，同样的一定会有团队成员看不懂。流程图的能够达到业务清楚，表明重点，项目成员能够快速理解的目的就行。
用例图
这个用例图表明了用户下单的整个流程，可以帮助团队成员更好地理解和掌握该功能的业务逻辑和流程。
整体产品业务流程图
为了将这个产品的功能业务串起来，可以不用画的太详细，画出大的概览图，从大而全的角度将这个项目表达出来。一般是在0-1的新项目中画，日常迭代的需求中不需要。
单个模块的流程图
当一个功能模块功能很多时，为了将模块内的功能串起来，说清楚单独模块的流程，这个就要画的细致一点。当涉及到新的模块时一定要画。
@startuml
title 商品管理功能模块流程
start
:进入商品管理页面;
:查看商品列表;
if (需要添加商品?) then (是)
:添加商品信息;
else (否)
endif
if (需要编辑商品?) then (是)
:编辑商品信息;
else (否)
endif
if (需要删除商品?) then (是)
:删除商品;
else (否)
endif
if (需要上架商品?) then (是)
:上架商品;
else (否)
endif
if (需要下架商品?) then (是)
:下架商品;
else (否)
endif
:保存商品信息;
:返回商品管理页面;
stop
@enduml单个功能的流程图
对于复杂的单个功能，涉及到的处理逻辑比较多时，我们也需要画出单独的流程图进行说明。
时序图
通过“UML 图”卡片可以绘制时序图来梳理业务调用时序。
6、功能需求说明(70%)
功能用例原型设计
每个功能设计主要是从输入处理输出三个方面去考虑，用户执行输入指令后，系统会进行逻辑处理，然后输出结果。此外，还要考虑功能涉及到哪些数据，表结构怎样设计，这些会涉及大量细节，PRD大部分内容，都是在描述这些细节。步骤1和步骤2没有严格的顺序，也可以先梳理业务流程，再根据流程中的具体场景梳理出实际功能或系统结构。
这个部分在PRD中占比最大，搭框架部分，已经将产品功能点全部梳理出来了，这部分就是对功能点进行逐一描述。功能是从系统的角度来看，我们还要考虑用户角度，所有我们采用用户+功能的方式来描述需求，这就是用例。
功能用例原型说明模板参考
完整用例名称一定是动宾结构，如添加文章、删除文章、修改文章、查看文章列表。那到底该如何专业的描述一个页面的需求呢？从三个方面：1. 页面说明；2. 逻辑处理；3. 异常处理。一个完整的用例模板：
- 描述&背景
- 前置条件
- 后置条件
- 界面交互
- 业务流程
- 异常和分支流程
- 数据字典
- 外部文档
完整用例详述：登录功能
**描述：**功能的简要描述。描述功能背景，为什么要做这个功能。
**前置条件：**要操作此功能，需要具备什么角色、权限或状态。
**后置条件：**执行完这个用例后，关联的数据会有什么变化，页面怎么跳转。
**界面交互：**每个界面都可以拆分成多个元素，如表单、文本、链接、图片等；
**业务流程：**当用户完成输入并提交时，后端应该做什么校验，不同输入该怎么处理，不同结果该返回什么值，最好通过业务流程图+文字来描述，确保逻辑完整。
异常和分支流程：
异常流程如网络错误、接口返回异常、服务器内部错误等；
以登录为例，分支流程包括找回密码、密码登录等，分支流程非必须，简单的分支流程可以直接通过主流程体现，
具体可以视情况按照一定颗粒度进行拆分。
数据字典：
这个用例涉及哪些数据，可以通过数据字典描述，这一步非必须，最终表结构也不一定就是这样，只是给开发一个参考。有技术背景的产品，也可以做得更细。以注册功能涉及的用户表为例：
外部文档：
外部接口说明文档、外部工具文档、外部人员支持等
功能用例原型说明布局参考
当采用Axure写需求文档的时候，常见的布局是：左图右文。左边展示原型图，右边展示需求说明(按照用例说明模板填充即可)。如录入处方用例：
先画出原型图，在原型中标注「序号」，然后在右侧按照相同的序号进行功能需求描述。
标注顺序：一般按照从左到右，从上到下的顺序。
标注哪些点：需要进行功能说明的功能点，但是并不意味着每一个点都要进行标注。一般按照从大到小，按照模块化的方式。
对于word版，常为：原型页面展示，单独写文档说明，(按照用例说明模板填充即可)。
7、非功能需求
**数据需求: **常见的就是数据埋点，产品经理需要梳理出埋点事件表，告知开发，让开发在编码过程中进行埋点。
监控需求: 需要监控某个接口或某些服务，当出现异常时，可以发送报警信息至相关人员。
**性能需求: **需要支撑多大的并发，运维人员可以提前准备部署方案。
**数据埋点需求：**帮助产品团队了解用户行为和使用数据，以便进行产品优化和改进。
……
顾名思义，非功能性需求其实是一个通用的模板，即与描述本次需求并没有太大关联，在其他需求文档中，都可以写入该非功能性需求，非功能性需求包括：性能、安全、备份和日志。即对软件的一些性能、安全等行为进行一定的约束。不要造成打开太慢，安全无保障等。
PRD（产品需求文档）中的非功能性需求是指产品在使用过程中需要满足的一些性能、安全、可用性、可靠性等方面的要求，与功能性需求相对应。以下是一个简单的PRD非功能性需求的举例：
| 非功能需求 | 描述 |
|---|---|
| 性能 | 响应时间：系统的响应时间应该在1秒内，以保证用户体验。 并发性能：系统应该支持同时处理1000个并发请求。 可扩展性：系统应该具备可扩展性，以应对未来的用户增长和业务变化。 |
| 安全 | 用户认证：系统应该支持用户注册和登录，并采用加密方式保护用户密码。 数据安全：系统应该采用数据加密和备份等措施，保护用户数据的安全性。 防止攻击：系统应该具备防止DDoS攻击、SQL注入等安全攻击的能力。 |
| 可用性 | 易用性：系统应该具有良好的用户体验和易用性，以降低用户使用门槛。 可访问性：系统应该支持多种访问方式，如PC端、移动端等。 可靠性：系统应该具有高可靠性，以保证用户使用的稳定性。 |
以上是一个简单的PRD非功能性需求的举例，可以根据实际情况进行调整和完善。这个表格涵盖了性能、安全和可用性三个方面的非功能需求，分别描述了产品在响应时间、并发性能、用户认证、数据安全、易用性、可访问性、可靠性等方面的要求。这些非功能需求可以帮助团队成员更好地了解和把握产品的性能和安全要求，为后续的产品设计和开发提供指导和依据。