PRD（产品需求文档）与SRS（软件需求规格说明书）的区别

需求分析是软件开发过程中很重要的一个环节目前需求分析完成后输出的文档有2种体系一个是SRSSoftware Requirements Specification软件需求规格说明书一个是PRDProduct 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) BRDBusiness Requirements Document商业需求文档这是产品生命周期中最早的文档其内容涉及市场分析销售策略盈利预测等。BRD要讲明白用户价值为什么用你的产品、商业价值为什么要做这个产品市场分析、目标市场、竞争对手、时机、规模、趋势产品功能、原型、实施计划、愿景成本、ROI分析风险及应对措施。文档重点放在定义项目的商业需求。BRD要能说出客户碰到的一个或多个商业问题并且通过公司的产品能够解决这些问题。BRD就是战略需求文档呈现形式很多可以是商业可行性分析可以是建模方法论等等取决于这份文档的读者务必根据读者的特点进行撰写这样通过的概率会大大增加。MRDMarket Requirements Document市场需求文档BRD评审通过后就是写MRD文档说明产品的定位。具体来说要有更细致的市场与竞争对手分析通过哪些功能来实现商业目的功能/非功能需求分哪几块功能的优先级等等。MRD重点放在为一个被提议的新产品或者现有产品的改进定义市场需求MRD更深入提议解决方案的细节。它包括一些或者所有这些细节a. 解决商业问题所需要的特色b. 市场竞争分析c. 功能和非功能需求d. 特色/需求的优先级e. 用例PRDProduct Requirements Document产品需求文档MRD通过评审后就要编写PRD文档。PRD是在MRD的基础上详细的给出了UIUser Interface 用户界面和UEUser Experience 用户体验。PRD文档的核心是需求分析并根据需求开始落实产品原型输出产品的DEMO针对不同的阅读人群尝试重点的偏移比如技术读者注重流程图的逻辑和原型备注UI和测试注重原型和需求描述。PRD也就是传统意义上的需求分析要给出功能使用的具体描述每个UCuse 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 用户类别13.2.1.1 功能需求1.1...3.2.1.n 功能需求1.n3.2.2 用户类别2...3.2.m 用户类别m3.2.m. 功能需求m.1...3.2.m.n 功能需求m.n3.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 安全需求其它内容