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

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

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

一、需求文档的常见问题

产品经理的日常工作中，编写需求文档是一项必备的技能。

需求文档的重要性是不言而喻的，对团队的研发和测试人员，他们需要产品经理提供详情的需求文档，以便以此为依据，开展开发和系统测试的工作。

但是往往由于时间紧迫、产品经验不足等原因，提供的需求文档，常常出现需求描述不清楚、逻辑不通、需求遗漏等问题，这些问题很容易在研发和测试工作中发现，例如：

研发抱怨需求文档中没有描述清楚：比如：文档中写到：点击新增按钮，打开新增页面。前端就**跑过来疑问：这里新增页面是新开页面，还是当前页面打开。

研发在开发过程中，发现需求逻辑不通，找产品经理反馈，产品经理发现确实如此，赶紧补救。从而导致在研发过程中产生需求变更，引起众怒，还是引起研发人员质疑产品经理的能力。

需求有遗漏，不完整。产品在验收的时候，发现某个功能的排序规则不对，然后让研发修改。结果研发抱怨你的需求文档中，没有定义这个列表的排序规则，从而**产生团队矛盾。

那么，我们如何才能把需求说明清楚，尽量减少需求不清、需求遗漏、需求质量问题呢？

二、Excel需求文档

需求文档是以一种文档记录的方式，进行信息的沟通和传递。以便有迹可循，有理可依。

前面出现的：需求不清、需求遗漏、需求质量问题，我们可以通过编写Excel形式的需求文档，逐渐减少此类情况的发生，从而提升需求文档质量。

需求文档也是一个迭代的过程中，通过多次的迭代过程，一方面我们可以形成思考的方式，然后查漏补缺，进而逐渐可以完成出完整的需求文档。另一方面我们可以积累出需求文档库，便于后期的复用。

1. 历史迭代可追溯

首先Excel的需求文档，可以很清楚每个版本迭代的功能有哪些。产品不断的迭代更新，或是人员的交接，经常需要回溯之前的线上逻辑，需求文档的缺失或不完善，**导致线上逻辑不明确，甚至后续的产品需求设计的逻辑与线上矛盾或冲突，为项目的开发带来麻烦。

Excel需求文档中，可以通过sheet保留每一个迭代版本的需求内容。方便进行信息的查阅！

2. 需求颗粒度细

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

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

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

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

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

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

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

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

三、Excel需求文档的模板介绍

下面来介绍Excel形式的需求文档的模板，定义好模板结构之后，可以快速编写。

1. 文档命名规范

文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。

文件命名的方法一般是通过版本号定义，比如简单的方法是：XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。

2. 文档基本信息介绍

需求文档的封面基本信息，需要注明产品名称、需求文档的状态、当前版本、编写需求文档的人员和完成的时间。

3. 文档修改记录

产品是分多个版本迭代的，关于需求文档修改的记录页需要记录下面，包括：版本号、修订日期、模块、修订说明、修订人、备注。文档版本号显示的当前修改的内容属于文档的第几个版本(当前系统的版本XX产品V1.0+修改的版本V1)，模板是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。

4. 模板说明

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

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

示例：如何以正确的姿势编写需求？

在编写需求文档的过程中，往往因进度紧而来不接写的完整，这就需要技巧性的简化文档，不妨先出一个系统框架，然后再补充每个栏目中的内容，最后再来扣细节，这样在检查的时候，能够及时发现需要是否有遗漏。没有任何文档是一次能写好的，所以在初期版本不要一上来就追求完美，有瑕疵是很正常的，在考虑到不影响开发设计工作的前提下，将后期迭代的思考加入其中就好了。

• 搭建需求框架，细化了每个功能点上。
• 针对每个功能点，结构化描述详情功能。
• 最后整体检查，补充遗漏、抠细节，完善需求文档。

例如：一个活动管理页面如下，那我们要如何编写活动管理模板的功能说明。

1. 搭建框架

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

2. 结构化描述

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

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

3. 抠细节

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

总结

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

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

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

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