如何正确编写Excel格式的需求文档？

需求文档是以一种文档记录的方式，Excel需求文档的优势在于能够帮助更好地查阅信息。如何编写Excel格式的需求文档？作者根据自身经验，并结合案例分享了相关经验，希望对你有用。

之前参加枯叶讲师的公开课，提到了Excel需求文档的优势，刚好目前工作中也是通过Excel来编写需求文档，于是总结如下通过Excel来编写需求文档的经验和技巧。

2. 需求颗粒度细

我们经常会很纠结，需求到底要写到多细，常常以为写的很详细了，结果研发还是有很多疑问。通过Excel的需求文档，对每一个元素进行描述，这样细化之后的需求，可以防止遗漏，思考就更加清楚，方便检查，查漏补缺，从而提升需求文档的质量。

例如：后台系统都有导出某个页面上的数据的功能，比如导出用户列表的数据。有些产品经理在写这个导出需求时只有一句话的描述：点击『导出』按钮后，将表格中的数据导出为excel文档。

但是我们经过一步一步拆解到不能再细的程度，这样再来审视这句话，会发现有很多不明确的点：

导出的文件格式是什么？xlsx？xls？还是csv？（这三种格式都很常见）导出的表格是否区分sheet？sheet名称是什么？导出的表格包含哪些字段？如果还有图片（头像）等信息，怎么处理？导出列表数据的最大上限值是多少？导出的文件如何命名？

上述这些问题，如果在需求文档中不明确，在需求开发过程中通常会出现两种情况：要么是技术同学过来问产品经理如何定义（可能不止一次的沟通），要么是技术同学按自己的想法实现。前者增加了沟通成本，后续还是要花费时间完善文档或是再给测试同学讲需求，后者如果实现的方案在测试环节发现与产品或测试的想法不同，就需要返工再调整，两种情况无论怎样，都会浪费时间。

3. 迭代更新，沉淀需求库

需求传递到研发和测试人员之后，通过团队后续反馈，产品经理可以及时补充遗漏的地方，完善需求文档，并且总结遗漏的原因，避免后期再出现同样的问题，从而最终能够完成一个高质量的需求文档。

通过这样迭代，可以形成一个通用的需求库。其实在需求中，发现不同需求所用到的功能很多都是类似的，那么后面如果再碰到这样的需求，我们可以在这个基础上面进行复用，从积累的需求库中，提取出相应的功能即可。

4. 模板说明

需求文档的模板参考上图，需求文档的关键属性说明如下：

编号：编号就是功能的顺序号，主要是需求的唯一性标识。模块：把需求划分到系统的某个功能模块，一般只需要划分到系统的一级菜单。功能名称：系统化到系统的功能菜单，比如注册、个人中心、活动管理。功能点：这个功能菜单中具体的功能点，比如修改个人信息、查询订单。需求类型：需求类型一般包括：新增功能、功能改进、需求变更、界面优化、Bug修复、删除功能、接口需求等。功能详细描述：功能详情是描述这个功能点的页面展示、业务规则内容。是需求文档的核心内容。参数：对输入的参数信息描述。提示信息的描述。备注：其它任何信息，如：与哪个信息相关。

1. 搭建框架

在写需求文档前，需要先搭建框架，首先会把这个模块尽可能细化到功能点，其实就是先写目录。结合产品功能的操作，涉及到多个页面或多个系统的状态变化；另一个是大框架下的内容是不是有遗漏，有没有遗漏描述某一项功能逻辑。

2. 结构化描述

通常完成了目录框架，自己对整个需求就很清晰明朗了，一种一切尽在掌控的感觉，接下来就是挨个补齐具体的需求的功能描述。功能是有逻辑的。而不是只讲功能点罗列出来。通过结构化的梳理，也是自己对系统的进一步深入思考。

所以，产品交付给研发的，是详细的系统功能说明。研发是实现功能，按照功能清单来，此时产品提供的就是简明扼要的功能说明。

3. 抠细节

工作中我经常建议产品同学写完需求文档后自己再读一遍，自己读一遍就能发现很多问题和漏洞。更重要的是，要能代入看需求文档的人的角色中，以他们的视角来审阅需求。最简单的，我习惯于将文档中我认为重要的，担心他人阅读时会忽视的段落文字加下划线或背景色标识，或是特别注明（此处设计师请注意有多个状态）等。代入测试的角色，试想自己看着这份需求文档在写测试用例，通常会发现很多漏洞。

总结

需求文档不仅仅是为了交付给研发测试而编写的，是为了降低需求遗漏的风险，降低团队的矛盾，确保研发理解的功能与产品想要的功能一致，从而有效避免了团队甩锅。

通过编写需求文档，产品经理也可以再次梳理一遍需求。或者在研发过程中，根据沟通发现问题，继续查漏补缺需求文档。最终反哺于自己，发现自己的遗漏，提升需求质量。这样长期积累下面的需求文档，就是一个功能库，一方面可以引导我们把需求思考的更加清晰，一方面当做功能库，便于后期的需求复用，帮助我们更快的完成需求文档，提升效率。

本文由 @瓜子 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。