需求文档是每个产品经理都必备的一大技能之一，本着实用性的原则，作者所以了一版可以应用于B端的产品需求文档模板，并经过了实践的检验，分享给大家，希望对你有所帮助。

对于产品经理而言，书写需求文档是最为常见的工作。互联网上有着各种各样的需求文档模板，每个公司的也都有着自己的需求文档规范。

在刚做产品经理的时候，总是觉得所用的需求文档模板不是太简单，就是太过复杂。本着实用性的原则，我所以了一版可以应用于B端的产品需求文档模板。

这个模板我用了好多年，也曾作为文档规范在所在的团队中使用，可以说是经过了实践的检验。

在这里所以分享给大家，希望能够对大家有所帮助，也欢迎大神们能够多提宝贵建议。

一、版本记录

新增和变更需求时，须添加一条版本记录。

版本号：新增新的迭代的需求时需要在版本号整数位累加版本号，有需求变更时则在原版本的小数位累加版本号。通常在研发评审后，新增或修改评审过的版本的需求时，都需要走需求变更的流程。

内容提要：新增需求版本时，建议在“内容提要”中，以“XX版本：”开头；需求变更时，则建议以“需求变更：”开头。内容简短说明重点即可。

二、业务介绍

1. 业务场景

此项为必需项，需要描述实际业务场景及此需求产生的用户价值。

通常在此项会预设“业务活动者”和“业务场景及用户价值”两个二级标题。

有的模板会要求“业务场景”和“用户价值”分开描述，但我的经验是这两者在一起描述更加顺畅。在描述业务场景的过程中，用户价值也就自然而然的一起说明了。

2. 专业词汇

列出需要进行说明的业务专业词汇及其含义。此项可略。

e.g. 临床路径变异：指患者在进入临床路径接受诊疗服务的过程中，出现偏离临床路径程序或诊疗计划的情况。

变异率=变异人数/入径人数。

3. 业务流程

描述需求所对应的业务流程，推荐使用泳道图或业务流程图。

对于十分简单业务，此项可略。

需要上下游产品协同或研发认为需要说明，则必须进行业务流程描述。

4. 评级标准

新产品设计时，此项内容为必需。对于B端产品，能够达到所处行业相关的评级标准，往往是客户决定付费购买的前提条件。

拿医疗信息行业举例，一些产品既要对标医疗信息相关的《电子病历系统应用水平分级评价标准》、《医院信息互联互通标准化成熟度 》等评级标准，又要满足等级医院评审标准、公立医院绩效考核等医疗机构评价标准的要求。

三、需求说明

1. 功能概述

必需，简要描述相关功能之间的使用逻辑，复杂功能可用Xmind说明。

e.g. 药品常用方法维护：门诊及住院药品开立选择药品之后，自动带入维护的常用方法。同时有多个方法时，需要用户进行选择。可以设定全院、科室、个人级别的常用。

2. 功能详情

必需，在此项详细的描述产品的功能需求。以下规范性要求可供参考，可根据团队的实际需要进行增减。

（1）需写明是否需要提示框、二次确认框

如果需要，需写明判断触发条件和提示语内容，提示语需要注明阻塞条件。

e.g.【XXXX药品】超过一次量上限，请调整！

（2）涉及特殊的状态变更的操作，需写明状态变更逻辑及不同状态对应可执行的操作

e.g. 保存：保存完之后为草稿状态。

发布：点击发布之后，即变为“发布”状态。

各状态下操作：草稿：可以编辑、发布、删除；发布：可以编辑、停用。

（3）原型的数据是真实内容，便于交互和研发同学理解。

（4）每个页面需写明是否分页。

（5）列表功能需写明默认排序规则。

（6）需确认是否需要导出功能。

（7）新版本需求添加至上一版本内容下方，以分割线区分，开头注明版本号。如：

3. 界面及交互说明

必需。一般在交互评审之后，在此粘贴交互稿的链接即可。

4. 可用性需求

从业务视角提出的各项可用性需求。

4.1 性能需求

如对性能要特殊需求，请详细描述，如：响应时间、最大并发数等。

4.2 监控需求

如需要特殊的监控和统计埋点需求，请详细描述。

四、相关文档

产品其他相关的文档，可直接上传至文档中。如：业务手册、需求调研报告、竞品分析文档等。

五、产品评审纪要

产品评审后，详细记录评审过程中提出的问题（包含提出人）及问题回复。

六、研发评审纪要

研发评审后，详细记录评审过程中提出的问题（包含提出人）及问题回复。

第五、第六点是我最近才加进来的。现在大多数公司都采用了统一的在线文档工具，可以比较方便存储和共享文档。所以也就将产品评审和研发评审的纪要，特别是关键问题和回复内容直接添加到了需求文档中。方便日后回溯相关评审会的决议内容