PRD（产品需求文档）与SRS（软件需求规格说明书）的区别
需求分析是软件开发过程中很重要的一个环节，目前需求分析完成后输出的文档有2种体系，一个是SRS（Software Requirements Specification，软件需求规格说明书），一个是PRD（Product Requirements Document，产品需求文档）。它们都用于需求分析，但是什么场合下使用SRS、什么场景适用PRD，很难给出明确的答案，它们之间的相似与区别可以从以下几个方面借鉴一下：出处、使用用户、编写要点、编写内容。
一、出处
1. SRS的出处
SRS 出自《GB/T 11457-2006 信息技术 软件工程术语》、《GB/T 8567-2006 计算机软件文档编制规范》，并且在《GB/T 9385-2008-软件需求规格说明书规范》中进行了标准化。
《GBT9385-2008-软件需求规格说明书规范》描述了软件需求规格说明的编制方法。它基于以下设想，即软件需求规格说明确定过程的结果是一份明确和完备的规格说明文档。本标准将有助于：
- 软件的顾客准确地描述其希望得到什么；
- 软件的供方正确地理解顾客想要什么；
- 对于实现以下目标的有关单位和人员：
● 为其所在的组织编制一份标准的软件需求规格说明（SRS）提纲；
● 定义其具体软件需求规格说明的格式和内容；
● 编制其他的本地支持资料，如，SRS质量检查清单、或SRS编写者手册。
2. PRD的出处
历史上第一份PRD据推测应该是诞生于宝洁这家公司，因为据史料记载，宝洁在二十世纪二三十年代第一次提出了产品经理的概念，并诞生了第一位产品经理。产品经理大约从2015年开始发展，有自己的一套成熟理论体系，成为大型软件服务公司的标配。 BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）三种文档已经成为产品经理的标配。（参见：产品经理系列1——起源发展篇 | 人人都是产品经理 (woshipm.com) ）
BRD（Business Requirements Document，商业需求文档）
这是产品生命周期中最早的文档，其内容涉及市场分析，销售策略，盈利预测等。BRD要讲明白：用户价值（为什么用你的产品）、商业价值（为什么要做这个产品），市场分析、目标市场、竞争对手、时机、规模、趋势，产品功能、原型、实施计划、愿景，成本、ROI分析，风险及应对措施。文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。
BRD，就是战略需求文档，呈现形式很多，可以是商业可行性分析，可以是建模方法论等等，取决于这份文档的读者，务必根据读者的特点进行撰写，这样通过的概率会大大增加。
MRD（Market Requirements Document，市场需求文档）
BRD评审通过后就是写MRD文档，说明产品的定位。具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。
MRD重点放在为一个被提议的新产品或者现有产品的改进定义市场需求，MRD更深入提议解决方案的细节。它包括一些或者所有这些细节：
a. 解决商业问题所需要的特色
b. 市场竞争分析
c. 功能和非功能需求
d. 特色/需求的优先级
e. 用例
PRD（Product Requirements Document，产品需求文档）
MRD通过评审后就要编写PRD文档。PRD是在MRD的基础上，详细的给出了UI（User Interface 用户界面）和UE（User Experience 用户体验）。PRD文档的核心，是需求分析并根据需求开始落实产品原型，输出产品的DEMO，针对不同的阅读人群尝试重点的偏移，比如技术读者注重流程图的逻辑和原型备注，UI和测试注重原型和需求描述。PRD也就是传统意义上的需求分析，要给出功能使用的具体描述（每个UC（use case）一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程等几大块）。
二、使用用户
1. SRS的用户
SRS可由来自供方、顾客或双方的一个或者多个人员编写，推荐由来自供方和顾客双方的人员联合编写。
《GB/T 8567-2006 计算机软件文档编制规范》中明确SRS的使用人员包括：开发人员和维护人员。
《GB/T 9385-2008-软件需求规格说明书规范》中明确：SRS可以为顾客和供方之间的协议建立基础、作为开发合同的一部分、为估计成本和进度提供基础。
2. PRD的用户
PRD由产品经理撰写，使用用户包括：
1.产品同事
2.运营
3.设计师
4.开发工程师
5.其他需求方(相关业务部门等)
三、编写要点
1. SRS的编写要点
SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。SRS 编写人员应关注以下基本点：
ａ） 功能———软件将执行什么功能？
ｂ） 外部接口———软件如何与人、系统的硬件及其他硬件和其他软件进行交互？
ｃ） 性能———各种软件功能的速度、响应时间、恢复时间等是多少？
ｄ） 属性———软件的可用性、可靠性、可移植性、正确性、可维护性、安全性如何？
ｅ） 影响产品实现的设计约束———是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？
编写适当的 SRS 限定了正确设计的范围，但不规定任何具体的设计：
ａ）宜正确地定义所有软件需求。由于将要处理的任务的性质或项目的具体特性，则软件需求是存在的。
ｂ）不宜描述任何设计或实现的细节。这些内容应当在项目的设计阶段进行描述。
ｃ）不宜对软件设置附加的限制条件。这些内容可在其他文件中规定，如，软件质量保证计划。
好的SRS具备以下特征：
ａ）正确；
ｂ）无歧义；
ｃ）完备；
ｄ）一致；
ｅ）重要性和／或稳定性分级；
ｆ）可验证；
ｇ）可修改；
ｈ）可追踪。
2. PRD的编写要点
根据PRD使用的不同对象，PRD包含的内容也会有差别。为了能够使得PRD的目标用户更好的去获取到他想要的信息，一份PRD至少就应该包含以下内容：业务流程图、功能结构图、功能细节描述、界面原型等。
三、编写内容
1. SRS的编写内容
SRS文档包含以下内容：
- 引言
1.1 目的
1.2 范围
1.3 定义、简写和缩略语
1.4 引用文件
1.5 综述- 总体描述
2.1 产品描述
2.2 产品功能
2.3 用户特点
2.4 约束
2.5 假设和依赖关系
2.6 需求分配- 具体需求（按照运行模式、用户类别、对象、系统特征、激励、功能层次分类，具体需求描述方式不同，下面只给出按照用户类别的描述内容）
3.1 外部接口需求
3.1.1 用户界面
3.1.2 硬件接口
3.1.3 软件接口
3.1.4 通信接口
3.2 功能需求
3.2.1 用户类别1
3.2.1.1 功能需求1.1
...
3.2.1.n 功能需求1.n
3.2.2 用户类别2
...
3.2.m 用户类别m
3.2.m.１ 功能需求m.1
...
3.2.m.n 功能需求m.n
3.3 性能需求
3.4 设计约束
3.5 软件系统属性
3.6 其他需求
附录
索引
2. PRD的编写内容
文档目录
修订记录
- 产品概述
1.1 产品背景
1.2 目标用户
1.3 产品目标- 需求列表
列出需求模块、子模块、需求简述和优先级- 功能结构
- 需求明细
4.1 功能性需求
4.1.1 用户场景
4.1.2 优先级
4.1.3 前置条件
4.1.4 需求描述
4.1.4.1 用户界面
4.1.4.2 界面描述
4.1.4.3 基本流程
4.1.4.4 异常流程
4.1.5 后置条件
4.1.6 流程图
4.2 非功能性需求
4.2.1 性能需求
4.2.2 统计需求
4.2.3 安全需求- 其它内容
