手把手教你写产品需求文档

之前有文章介绍了关于项目的解决方案，其中有关于功能点详细描述，以及设计确认的部分。

这些其实都是挖掘用户需求，分析需求之后获得的结果。

挖掘并分析出用户的核心诉求，才能真正算读懂用户，了解其真实意图，保障项目、产品方向不会跑偏，是保障产品成功的前提。

作为产品经理，要保障做正确的事，作为项目经理，要保障把事情做正确。

另外，作为产品负责人，以结果为导向，以创造价值为最终目标。

接下来，通过编写产品需求文档，分步为大家带来，关于需求调研、需求分析、需求管理等方面的内容。

通用产品需求文档模板如下，有些时候可能会加上其他内容，比如关于竞品方案等。

一、需求介绍

所属业务线、需求负责人、需求介绍（目的在于告知其他人。关于此份需求文档的基本情况。）

二、需求背景

2.1 需求价值

目的在于说明，此需求用于指导产品开发、测试用例编写、质量评审、技术可行性分析、以及详细设计的依据，同时也是产品验收的标准。

2.2 目标用户

找到该产品、项目所涉及的干系人（利益相关方），比如一线操作员、QA、QC、项目经理、高层领导等。

只有找准、找全了目标用户，后续需求调研才能进行排序，合理制定开发计划，同时，可避免功能点遗漏。

比如，实验室原始数据记录，最核心的用户是做实验的那帮人，也就是实验员、科学家，另外，还需要满足合规要求，QA，药监局核查，物料、设备管理员以及项目经理。

2.3 典型使用场景

使用用户访谈、焦点小组、调研问卷等定性、定量方式，搞清楚用户主要业务流程、应用场景。明细这些典型使用场景中的关键点、注意事项，为后续产品设计打下基础。

比如，实验室送样检测流程，制剂、分析、合成实验场景，物料出入库，物料报废，设备预约，实验记录复核审批等等应用场景。

三、需求目标

3.1 需求目标

需求目标，即制定此需求，需要达到的效果，以此来告知相关人员，我们需要做到什么程度，并为之努力。

目标1 : ......

目标2 : ......

目标3 : ......

可以从多个维度，比如，前后端开发、UI设计、测试等，功能开发完成度、BUG调试完成率、用户体验设计完成度、软件稳定性以及可靠性、并发数等。

3.2 衡量指标

制定衡量指标，即对成果的评判标准。有了标准，才好评判成果好坏，人员绩效，也可作为后续产品迭代优化的依据。

指标	计算方式	目标值
用户满意度	下发满意度问卷	3.5 分
并发数	N个并发 延迟时间	2秒...

四、需求范围

明确需求范围，即表明做哪些，只有界定清楚需求范围，才能在后续开发过程中，不断插入新需求，同时避免项目验收时带来麻烦。

制定需求范围后，对于产品迭代开发计划，产品路径也会有很大帮助。

五、需求详情

5.1 操作流程

核心业务的操作流程描述，可以帮助UED、测试、产品、开发、甚至实施人员快速了解业务。

可通过visio等工具绘制流程图、业务逻辑，UML工具设计功能模块，展示清晰的操作路径。

5.2 需求描述

需求描述是很重要的一环，通过需求点说明，示意图，优先级，重要程度，需求类型，以及限制条件等，告知相关人员，该产品的主要内容，注意事项等。

需求点	说明	示意图

需求收集可以通过定性、定量的方法来实现，比如用户访谈、调查问卷。

这里需要对需求进行仔细分析，判断哪些是管理需求、哪些才是真正的功能需求，避免被客户牵着鼻子走。

5.3 已有功能兼容

此部分需要对需求进行分析后，根据自己的产品实际情况，区分出那些已经实现，或可以替代使用的部分，对市场、项目实施、开发人员有指引作用。

场景	处理方式

此部分多可引导客户，利用现有产品功能，来实现客户的需求，这样能最大可能实现双赢。

六、数据埋点

数据埋点是产品数据分析的基础,一般用于对用户行为的监控和分析。

通过分析过程数据，能更好地了解用户对页面的浏览和功能的使用情况，进而找出容易出现用户流失的环节，为产品的优化和迭代提供重要的决策依据。

触发条件	埋点事件	埋点参数	涉及终端

七、设计稿

包含原型设计、UI界面设计截图，一般会混合在需求详细说明中进行，然后，在最后附录完整的设计稿，供相关人员查阅、核对，是产品开发验收的依据之一。