软件项目-产品需求文档(PRD)
简述
- PRD是英文“Product Requirement Document”的缩写,翻译为中文就是“产品需求文档”
- 主要用于完整描述产品需求,向研发部门明确产品的功能和性能以及作为产品文档归档
- 其中包含对项目的介绍,如项目概述、项目价值、项目背景、词汇表、运营计划等
- 整份文档的主体部分,有对产品需求的详细描述,包括功能需求和非功能需求等
文档的使用者
- 产品经理
- 通过产品功能描述自查清单来系统的梳理产品功能点和描述,可以更加透明和完整的梳理产品
- 通过PRD可以更方便的与其他人员进行沟通
- 交互设计师
- 通过功能点及其描述来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等
- 开发工程师
- 检查自己的代码是否符合PRD中的相关要求
- 测试工程师
- PRD中的功能描述和用例转化为测试用例的一部分,进行产品可用性测试
文档的头部
产品名称
- 所有给别人看的文档都是得有名称的,不然大家根本无法直观知道自己看的是什么。
- 要注意的是最好这里直接占满页居中(别问为啥,因为美观)
版本历史
- 写上版本历史的主要用途也就是为了大家在修改或迭代的时候避免出现一些细节性错误,并且可以让研发直观的看出你所修改的地方
文档目录
- 可以让研发快速定位自己负责的板块,所以目录也是必不可少的
文档的主要内容
项目介绍
项目背景
- 讲述项目/需求产生原因,以及是如何贴合当前公司业务进行的项目
项目的意义和价值
- 讲述项目在当前市场中存在的价值,潜移默化的告诉大家产品的可实施性,让大家更好的实现产品
项目的目标
- 讲述项目日后的最终发展目标,让大家以最终目标为方向去推动产品进行
需求方案描述
简述
- 这里主要是体现出产品需求的核心流程功能点
- 其中包含项目的实体关系图、业务流程图用来告诉开发测试人员项目的实现流程(绘制流程图的形式)
流程图
- 实体关系图(E-R图)
- 业务流程图
- 数据流向图
- 界面交互图
功能模块总览
项目风险
- 如果项目存在较高的风险值时,可以起到告诉业务中其他人该项目需要注意的地方,以防项目推广后出现致命性的问题
功能需求
简述
- 也可以理解为功能清单,需要你将所有功能点罗列出来
- 并告诉研发人员每个功能的功能描述、优先级、需求逻辑描述、相关细节性描述、相互作用描述、交互说明
- 需求包括用户界面和功能描述两个部分
- 用户界面,主要是以产品原型作为载体,用直观图像的形式展现产品的功能
- 功能描述,在用户界面的基础上,以文字的形式诠释产品功能的细节,使开发人员更清晰的明白产品功能性能的要求
需求列表参考表
- 序号
- 功能
- 需求描述
- 优先级
需求明细(用例)参考
- 功能描述
- 优先级
- 需求逻辑描述
- 相关细分描述
- 相互作用说明
产品功能单元拆分方式
- 按功能在系统中的位置
- 按业务流程
- 按功能主次
- 按功能所处界面位置
产品用例
简述
- 是指在不展现系统或子系统内部结构的情况下,对系统或子系统的某个连贯功能单元的定义和描述
- 可以将产品功能需求与产品设计彻底分离,不用考虑具体的系统设计与技术细节
- 包含了用例图和用例表
用例表参考表
- 编号
- 名称
- 角色
- 描述
- 基本流程
- 备选流程
- 异常流程
- 后置条件
- 备注
非功能需求
- 性能需求
- 响应时间、吞吐率、容量、精确度、资源利用率等
- 安全需求
- 数据加密、防泄漏、防攻击、身份验证、权限控制、日志和审计等
- 可靠性需求
- 可用性、容错性、可恢复、故障/缺陷率低等
- 易用性需求
- 易学习、易理解、易操作、页面布局合理美观、防错机制等
- 可维护性和可拓展性需求
- 可复用性、组件和模块化、易分析、修改和测试等
- 其它需求
- 软硬件环境、端口要求、语言要求等等
上线要求
- 告诉研发与测试人员本次项目的最终效果,好让研发人员以此为目标开发,测试人员以此为目标进行测试
运营计划
- 与运营协助撰写出功能的后期运营计划,并告知研发人员,便于让研发人员了解产品逻辑
- 在这里也可以写明项目的阶段说明(如:某个功能我们分三波进行研发上线,在这一期我们之做第一阶段的XXX功能,其余板块需预留好接口)
文档的基本要求
- 完整
- 必要内容无遗漏
- 功能描述完整 。如页面、输入框、浮动层、弹出框
- 准确
- 表述没有歧义
- 同一内容前后表述一致
- 清晰
- 做好版本管理
- 文档结构要清晰
- 使用技术化语言
- 表示不能过于含糊
- 简洁
- 多用图标
- 语言简练
- 稳定
- 开发前对内容进行充分确认