什么是产品需求文档？
产品需求文档 (PRD) 是产品开发过程中用于向开发和测试团队传达产品发布中必须包含哪些功能的工件。本文档通常更多地用于产品定义、设计和交付按顺序发生的瀑布环境中，但也可以用于敏捷环境中。PRD 将包含发布中必须包含的所有内容才能被视为完整，作为发布过程中后续文档的指南。虽然 PRD 可能会暗示可能的实现来说明用例，但它们可能不会规定具体的实现。
另请参阅： 市场需求文件 (MRD)
PRD 和 MRD 有什么区别？
几十年来，产品需求文档 (PRD) 是产品经理创建的最重要的工件。它煞费苦心地列出了给定产品发布所需的一切，并作为整个发布所基于的记录文档。简而言之，如果它不包含在 PRD 中，它就不会包含在发行版中。PRD 可能跟在营销需求文档 (MRD) 之后——也由产品营销、市场营销或产品管理创建——描述客户需求、市场机会以及整体产品或特定产品发布的业务案例.
PRD 本身不涉及市场机会或收入，而是牢牢植根于用例和所需功能。每个特性或能力通常被描述为一个单独的项目，并且每个项目通常也包含一个用例。
产品需求文档应该包含哪些内容？
PRD 必须包括发布所需的每个显式功能。为了支持每个所需的功能，应该有一个伴随的用例来说明用户将如何使用此功能并告知测试计划。如果一个特性很复杂，可以使用子项为技术团队提供更多的细节和粒度。这些子项目中的每一个都应在相关时包括自己的用例。
除了特定的特性和功能外，PRD 还应包括发布的概述/目的。虽然这不应该试图复制 MRD 中的内容，但它应该详细说明产品团队试图通过此特定版本实现的目标（因为 MRD 可能用于同一产品/产品套件的多个版本）。
除功能要求外，PRD 还应阐明任何其他要求。其中包括任何系统或环境要求（即该产品应在 Windows 10 或更高版本上运行，或者应在 Firefox、Chrome 和 Safari 浏览器中运行），以及任何可用性要求（即移动应用程序的单手导航）。
PRD 的最后一批成分是假设、约束和依赖项。
- 假设是您期望到位的任何东西（但不能保证），例如假设所有用户都将具有 Internet 连接。
- 约束决定了最终实现不需要的东西，无论是预算约束还是技术约束。
- 依赖项是产品将依赖的任何已知条件或项目，例如依赖谷歌地图为遛狗应用程序添加方向。
基于 PRD，组织中的其他人将创建许多其他工件。工程将创建一个功能规范，描述 PRD 中的每个项目将如何实现，他们还可以创建（或更新）架构设计文档。UX 将根据需要创建线框和模型，质量保证将编写测试计划，确保 PRD 中的每个用例都能在测试期间成功执行。
什么是产品需求文档的示例？
以下是 PRD 中应包含的内容的基本概述。对此没有硬性规定，但通常会出现以下项目：- 目的/目标：解释你为什么要构建这个以及你希望完成什么。
- 功能：对于每个功能，您应该至少包括描述、目标和用例。根据功能的复杂性，例如超出范围的项目，其他详细信息可能会有所帮助或有必要。
- UX 流程和设计说明：大多数组织在 PRD 被审查和接受后完成功能的 UX 设计。但是，在此阶段可能需要一些通用指南以确保满足发布目标。这不是用于绘制每个可能场景的像素完美模型或线框的地方；相反，它可以用来描述整个用户工作流程。
- 系统和环境要求：将支持哪些最终用户环境（例如浏览器、操作系统、内存和处理能力等）。
- 假设、约束和依赖项：列出对用户的期望、要注意的实施限制以及最终解决方案发挥作用所需的任何外部元素。
创建RPD的步骤是什么？
假设 MRD 已经存在，产品管理应首先咨询产品营销，以确保充分理解 PRD 中描述的特定版本的业务驱动因素。从那里开始，应该利用已经使用的产品优先级排序方法来确定发布范围内的内容。然后是编写文档的时候了，利用为版本中包含的每个功能捕获的注释和用户反馈。如果可能，该文档应与产品团队中的其他人一起进行多轮审查，以确保尽可能多的潜在问题得到解答，并且文档尽可能详尽。
有了完全完整的 PRD，接下来应该在业务方利益相关者之间传阅，以确认他们与发布的目标以及为实现该目标而包含的功能保持一致。达成共识后，就该将PRD交给工程部门了。
在此阶段，技术团队将提出问题、澄清和挑战，应口头解决这些问题，并在必要时在 PRD 中进行更新。目标是让 PRD 足够彻底和全面，这样以后就不会出现意外。一旦就 PRD 达到该阶段达成一致，便会将其传递给其他团队进行 UX 设计、功能规范和测试计划定义。
通过将所有这些团队纳入 PRD 创建和审查过程，它让每个人都参与到发布的预期结果和内容中。关于将交付什么、它将如何使企业受益以及在流程结束时对用户的影响应该是毫无疑问的。
另请参阅：发布计划、发布说明、产品发布、最小可行产品