104 lines
3.0 KiB
Markdown
104 lines
3.0 KiB
Markdown
## PRD 要素
|
||
- 命名编码
|
||
- 版本历史
|
||
- 引言
|
||
- 需求概述
|
||
- 功能性说明
|
||
- 非功能性说明
|
||
|
||
---
|
||
### 文档标识
|
||
|
||
- 文档命名形式和编码
|
||
XX 产品V1.0PRD_V1
|
||
V1.0 是产品编号， PRD_V1 的V1 是PRD版本号
|
||
- 版本历史
|
||
- 版本号： V1
|
||
- 文档编号：V1.0
|
||
- 文档密级：
|
||
- 产品名：
|
||
- 编写人：
|
||
- 编写日期
|
||
- 修订记录
|
||
- 版本号：
|
||
- 修订人
|
||
- 修订日期
|
||
- 修订描述
|
||
- 目录 -- 使用软件生成
|
||
---
|
||
### 引言
|
||
- 引言
|
||
- 产品背景
|
||
- 说明该产品的研发的背景、市场趋势、发展前景(搜集并陈述事实，解释信息和活动、预测功能)
|
||
- 说明该铲平研发的目的、意义、里程碑式的建设(说明研发的优势)
|
||
- 预期读者
|
||
- 该文档的阅读对象: 开发、测试、UI、产品
|
||
- 产品规划
|
||
- 说明该产品每一阶段的迭代目标, 开发及UI初期要达到的效果
|
||
- 名词解释
|
||
- 对文档中会出现的比较新的名称进行解释
|
||
- 该文档的参考资料
|
||
|
||
---
|
||
### 实现PRD文档的几种工具
|
||
|
||
- word
|
||
- 原型工具
|
||
- xiaopiu
|
||
- Axure
|
||
- 墨刀
|
||
- figma
|
||
- 慕客
|
||
|
||
---
|
||
### 需求描述
|
||
|
||
- 业务流程
|
||
- 组织架构图 -- 包含的模块、和子功能
|
||
- 流程图 -- 泳道图（着重关注有判断逻辑和复杂业务逻辑的程序）
|
||
- 用户角色
|
||
- 用户角色
|
||
- 用户描述
|
||
- 功能清单
|
||
- 功能模块
|
||
- 主要功能点
|
||
- 优先级 决定开发的顺序
|
||
- 运行环境
|
||
- 软件运行环境 （浏览器、 操作系统）
|
||
- 产品规划
|
||
- 对PRD中要开发的内容，给出关键里程碑，例如：需求评审通过的时间、开发完成的时间、上线时间
|
||
- 描述产品可能存在的风险、比如性能瓶颈、没有解决的问题，用户不当使用的风险等等
|
||
|
||
|
||
---
|
||
|
||
### 功能性需求说明
|
||
- 简要说明：介绍此功能的用途，包括其来源或背景，能解决哪些问题
|
||
- 场景描述，产品 在哪种情况下会被用户使用，就是用户场景模拟
|
||
- 用户场景
|
||
- 用户描述
|
||
- 业务规则：
|
||
- 产品在开发时都有相应的业务规则，需要将跪着清晰的描述出来，让开发、测试人员明白，避免产生歧义
|
||
- 业务规则必须是完整的、准确的，易懂的。
|
||
- 原型图 （涉及到页面交互的部分）
|
||
- 前置条件：该需求实现依赖的前提条件。比如上传照片是，需要存有图像文件
|
||
- 后置条件：操作引发的后续处理
|
||
|
||
---
|
||
|
||
### 非功能性需求
|
||
|
||
- 性能需求
|
||
- 产品使用的并发性能、响应性能、安全性能、预期效果描述
|
||
- 需求变更的计划
|
||
- 运营需求
|
||
- 产品上线后如何运营、目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等。以及与运营人员的协作方式
|
||
- 风险分析： 针对可能出现的问题进行预判和预设解决方案
|
||
|
||
---
|
||
|
||
### 铲平设计原则
|
||
- 不做高保真
|
||
- 不写废话
|
||
- 不重复
|
||
- 把时间花在产品得核心驱动力上，减少对无用功的投入，降低单调重复的操作频次，才能保证高效产出有价值的牵引力 |