产品需求文档（PRD）怎么写？
2023-08-31 10:08:19 43 举报AI智能生成
产品需求文档（PRD）是一份详细描述产品功能、特性和用户需求的文档。它通常包括以下几个部分：1. 介绍，包括产品的目标、背景和范围；2. 用户需求，包括用户画像、使用场景和需求列表；3. 功能需求，包括功能列表、用例和原型图；4. 非功能需求，包括性能、安全和可用性要求；5. 项目计划，包括时间表、里程碑和资源分配；6. 风险评估，包括可能的风险和应对措施；7. 附录，包括参考文献、术语表和附加信息。编写PRD时，应确保内容清晰、简洁、具体，并与相关团队成员进行充分沟通和确认。
作者其他创作
大纲/内容
产品需求文档使用场景
1.产品需求评审的时候看
2.研发技术方案设计、敲代码的时候看
3.UI进行界面设计的时候看
4.测试写测试用例、执行用例的时候看
写产品需求文档的目的
让每个项目成员知道需求为什么做、要做什么、怎么做
写产品需求文档的前提
需求类型
需求类型分类
功能需求
接口需求
性能需求
策略需求
埋点需求
统计需求
需求大小
从0-1的大项目，包括以上所有需求分类
日常迭代版本的小需求
产品需求文档的写作原则
1.有理有据
让项目成员知道为什么做
2.全面、清晰、准确
让大家知道做什么、怎么做
3.易读性
让大家方便快捷的理解文档内容
产品需求文档常用工具
Axure一体化需求文档
设计到画原型，用这个
Word
偏后端需求，逻辑相关需求，可以使用这个
产品需求文档包含哪些内容
文档修改记录
修改内容
说清楚修改的哪个模块，哪个页面，哪个功能点。也可以分成修改模块、修改页面多个列。
修改原因
就是为什么要修改，比如逻辑缺失需要补充等
修改人
谁修改的
修改日期
修改时间
项目背景/需求背景
参考格式
当前的现状是什么
有哪些问题/痛点
这些问题导致了什么结果
为了解决这个问题，我们需要采取什么动作
达到了什么目的
能够获取哪些收益，产生什么价值
名词解释
在进行名词解释时，尽量加上示例说明，方便大家快速理解
如果有专业名字，一定要写上名词解释。
流程图
整体流程图
单个模块功能的流程图
单个功能的流程图
需求说明
产品架构图
通过数据层、服务层、应用层、展现层等抽象层面表现出产品的整体架构
功能架构图/信息架构图
功能架构图
展示出功能层级关系，体现出菜单-功能的层级逻辑
信息架构图
展示出每个功能页面内的展示字段内容，主要用于研发设计表结构与表字段
画原型写文档
先根据要做的需求范围进行分类
功能需求说明
性能需求说明
算法需求说明
接口需求说明
全局说明
业务流程图
需求文档的表现方式
Axture
左图右文：左边展示原型图，右边展示需求说明
ProcessOn
左图右文：左边展示原型图，右边展示需求说明
Word
原型图页面展示，单独写文档说明
提取公共逻辑，放入全局说明
将相同的功能逻辑、需求内容放在一个单独的全局说明中，在全局说明中进行单独说明
功能点序号标注
标注顺序
一般按照从左到右，从上到下的顺序
标注哪些点
需要进行功能说明的功能点，但是并不意味着每一个点都要进行标注。
需求详细书写
标题
功能点名称
角色权限
如当前登录用户角色为管理员时，则显示此按钮
规则逻辑
主要有校验逻辑、前置条件、触发时机等，当涉及到的校验逻辑太多时，可以采用分行分段、添加序号、使用表格等范式，将每个逻辑有条理的全部说明清楚
极值说明
如输入框输入字符的长度，数字输入的范围值
交互说明
如点击调整至XX页面
其他
文字描述言简意赅，避免口语化
添加示例
被误解是表达者的宿命，文字说明都会有一定片面行。对于复杂内容，可以添加示例说明
为了便于阅读，建议采用多分段、多分行、加序号的方式
使用标点符号，将内容说清楚
结合Axure的特性，添加文字链接
便于阅读者快速跳转查看，不用自己找。
对于变量值，使用特殊符号标记
重要内容进行标记
涉及到逻辑时，可以使用公式进行说明
写完后自己再检查一遍
对外提供时，对于Axure，可以打包出html提供；Word版本，可以提供PDF版
收藏
0 条评论
下一页
