之前有文章介绍了关于项目的解决方案，其中有关于功能点详细描述，以及设计确认的部分。
这些其实都是挖掘用户需求，分析需求之后获得的结果。
挖掘并分析出用户的核心诉求，才能真正算读懂用户，了解其真实意图，保障项目、产品方向不会跑偏，是保障产品成功的前提。
作为产品经理，要保障做正确的事，作为项目经理，要保障把事情做正确。
另外，作为产品负责人，以结果为导向，以创造价值为最终目标。
接下来，通过编写产品需求文档，分步为大家带来，关于需求调研、需求分析、需求管理等方面的内容。
通用产品需求文档模板如下，有些时候可能会加上其他内容，比如关于竞品方案等。
一、需求介绍
所属业务线、需求负责人、需求介绍（目的在于告知其他人。关于此份需求文档的基本情况。）
二、需求背景
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界面设计截图，一般会混合在需求详细说明中进行，然后，在最后附录完整的设计稿，供相关人员查阅、核对，是产品开发验收的依据之一。
