经验分享：如何写好一份需求文档？从这几个方面下手

内容导航：

经验分享：如何写好一份需求文档？从这几个方面下手

怎么写项目需求文档

如何写出好的PRD

如何写产品文档，产品文档有哪些流程

一、经验分享：如何写好一份需求文档？从这几个方面下手

无论是互联网产品还是IT项目，所有这一切的开端都始于需求分析，一份好的需求文档往往是项目成功的先决条件，对一个IT产品经理或项目经理来说就显得尤为重要。如何才能写出一份让客户，开发人员都能读懂且满意的文档？

掌握需求分析的方法

需求分析的方法，是写好一份需求文档的内功；毛主席曾教导我们说“没有调查就没有发言权”，那么一份凭空臆想出来的需求文档，最后的结果也可想而知。需求分析也有各种方法，但终究起目的都是解决下面4个问题。

谁提出的想法？要解决什么问题？需要哪些业务来处理这个想法？这些业务是由什么信息支撑的？这些业务的支撑需要什么样的环境？

接下来，我会以“XXX校园安全平台的需求”为例，其原始的信息源如下，通过需求分析的方法来回答上面的问题。

XXX学校，希望对学生的出勤率，归寝情况进行统计；并希望使用信息化的手段，对学生的请假进行管理；而且学校了解到，现在的AI摄像机能进行人脸识别，希望能运用到新系统中，成为他们学校安全的一个亮点。

方法1：梳理出需求涉及的人员、组织机构及他们的诉求和职责

在围绕校园安全的需求中，大多数人都能分析出如下角色及职责：

但是这里他们犯了一个错误，混淆了客户与用户的概念。以上分析只是站在使用系统人的及（最终用户）角度来进行的，但是要知道最终付钱的（客户）还有想法的，所以上面的角色及职责应该还可以扩展成如下的表格才较完整。

上面只是通过原始信息源分析得到的，在通过不断需求访谈或挖掘中，你会发现的人员角色还在不断的扩展，这种就是通过人员与人员之间关联来的到的。所以最终的角色表大致如下：

组织机构图如下：

由上可见我们要避免如下错误：

不要混淆了用户和客户的概念，优先考虑客户，因为钱是他付的，想法是他提的；用户角色的梳理中，需要考虑到关联的人员是否也有可能在系统中；例如学生—家长，学生—保安

有了上面的角色，业务及业务流程就有了来源，我们就可以开始来回答第二个问题了。

方法2：找到支撑这些诉求及职责的业务或业务流程

什么是业务了？我的理解一般就是大家平常说的做事的流程或者做事的步骤。一般情况下我们可以根据用户的诉求就梳理出大致的业务及流程，再通过一对一的访谈就能达到你想要的业务。

根据上述的用户角色及诉求，我梳理了如下的业务。这里只做部分列举，不做详细说明。

学生出勤业务：学生上学通过AI摄像机进行到校，离校签到，系统记录相关数据。学生归寝业务：学生上学通过AI摄像机进行归寝，离寝签到，系统记录相关数据。学生请销假业务：学生在系统进行请假申请，提交到班主任处；学生凭借假条出入学校。

注意事项：由于信息化系统的引入，很多原有的业务流程需要再造。

例如在学生请销假业务由于AI摄像机和平板的引入其流程就会再造，再造后的流程如下：

学生在系统进行请假申请，提交到班主任处；或由班主任直接创建请假申请；通过后学生在非上下学时间离开时，AI摄像头识别到该学生后，会在门卫的PAD上显示该学生的请假信息，核实后允许其离校，离校时会将信息推送给家长。

考虑业务流程中的异常业务

大家分析业务时，都是正常流程很容易，但是一定要考虑其异常流程的处理，因为谁都没有一直顺的时候，例如下面这个异常业务。

学生归校异常业务：学生请假时间已过或未经请假就出校后归校，这个对于正常的请销假业务而言是个异常业务了。学生未按时归寝业务，这个也是归寝业务的异常业务。

复杂业务使用流程图更直观：有些业务比较复杂，这个时候使用业务流程图可以很清晰的表达出该业务，与客户沟通时可以取得事倍功半的效果。

找到支撑业务的数据信息

任何业务离开了数据信息，都是瞎说，所以发现业务背后的数据很重要，那么数据从何而来了？

收集客户日常流程使用到的单据：

角色日常工作我们经常会看到各种单据，具体到本文中，我们至少可以发现下面两种单据，学生的假条，访客进校的登记表，宿管查寝的登记表等。

跟踪客户的日常工作，找到他们用到的非正式表格

注意事项：原始表单并不能直接放入到需求中，需要加工成数据字典。

例如请假条：

我们要把他们转换成对应的数据字典或表格如下图所示：

梳理要实现以上业务的环境

按理说，完成了以上的业务梳理后我们对需求有了很深入的了解了，能写出较好的需求文档了。但是我们还要考虑实现这些的业务的软硬件环境，外部接口。就本例而言需要考虑如下的环境。

政策环境：

公安局对校园安装摄像头的要求教育局是否有对校园安全的政策文件等

系统运行的环境例如：

服务器是物理服务器还是云服务器；操作系统使用的是Linux还是，Windows的某个版本数据库需要使用Mysql Oracle Sqlserver的哪个版本物理服务器是否需要硬件防火墙，是否需要牵专线

外部接口：

罪犯的人脸头像库如何提供学籍信息，教师信息，年级班级信息如何提供

通过需求分析，其实我们已经掌握了很多的业务，流程，角色信息等，我们或多或少也使用了一些文档，例如需求访谈表，文档最终的目的是减少沟通的成本，确保能清晰的解释需求。

如果说需求分析方法是写好需求文档的内功，那么规范专业的文档目录及内容，则是写好需求文档的外功。再好的内功，只有使用恰当的外功才能发挥其效果。

需求文档

这里主要介绍三种需求文档的模版及其作用：

原始需求访谈表—记录用户最原始的需求文档；需求规格说明书—对现有业务整理或流程改造后的系统需求文档；需求清单及功能结构脑图—用于时间人力等资源进行估算成本计划。

1. 原始需求访谈表记录表

我们在与用户沟通交流时，每次都有必要做好需求的沟通记录。有了该文档，我们每次的需求访谈的效率和质量才会更高，而避免不必要的瞎扯，浪费大家时间。

需求的访谈记录的格式可包含如下要素：

2. 需求规格说明书

需求规格说明书是对原始需求进行加工后，可供开发使用的文档，所以需求规格说明书的需求是高于原始需求的，对原始需求中的某些内容进行了增删，确保按照新系统的方式进行的业务能满足用户的需求。

好的一份需求规格说明书会节省开发系统设计的大部分时间。需求规格说明书应包含如下结构：

3. 需求清单

需求清单是根据需求规格文档，按子系统，模块，功能进行分解后的功能清单；可以通过脑图进行分解展示，也可以通过Excle文档进行分类确定。

使用脑图便于分析和讲解：

使用Excle文档，方便统计和时间估计：

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

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

一、怎么写项目需求文档

1 项目概述
1.1 建设背景
1.2 建设需求
1.3 建设目标
1.4 建设依据
2 网络及硬件方案
2.1 网络方案
2.2 硬件方案
2.3 系统软件方案
3 平台软件建设方案

4 终端管理方案

5 接口
6 项目组织
6.1 项目组织
6.2 项目管理
6.3 问题管理过程
6.4 项目实施步骤
6.5 项目沟通与交流
6.6 项目风险分析
6.7 风险规避
7 实施计划
----------------------------------
只能给你提供一个简单的目录结构，这样估计你也知道该从哪里下手了~
不需要的可以更改，有自己的想法可以加进去~
做项目需求调研,最需要的是自己动脑去想~

二、如何写出好的PRD

首先，先了解清楚PRD的阅读对象，使用者。
　　PRD的模版中一般有如下信息：
　　PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。
　　其次，一个完整的PRD还应该具备的要素有
　　1、文档的命名和编号
　　文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。
　　2、文档的版本历史
　　包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。
　　3、目录
　　不需要自己新建，文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的
　　4、引言
　　这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明
　　产品概述：解释说明该产品研发的背景以及核心功能。
　　预期读者：文档的使用对象
　　成功的定义和判断标准：旨在说明产品的目标
　　参考资料：PRD的参考资料
　　名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。
　　5、需求概述
　　需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等
　　需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。
　　用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。
　　运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。
　　设计和实现上的限制：比如控件的开发环境、接口的调用方式等等
　　项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等
　　产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。
　　6.功能需求
　　功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：
　　简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
　　场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件
　　使用者说明：对产品使用者做出说明，可融入简要说明中。
　　前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
　　后置条件：操作后引发的后续处理。
　　主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。
　　推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。
　　7、可选方案
　　列出所有可以选择的达到该产品目标的方案要点(主要思路)，给各方案适当的评价，并推荐最优方案(在功能需求中描述的)。你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。所以可以写出几个可选方案，或许是你下期产品改版一个方向。记住，多思考方案是永不为过的
　　8、效益成本分析
　　通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。
　　9、整合需求
　　产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求，比如系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的一大重要表现。
　　10、BETA测试需求
　　很多产品在正式上线前都有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部份内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。
　　11、非功能性需求
　　一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。
　　12、运营计划
　　产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以非常建议运营计划的制定上有产品设计人员的参与。

三、如何写产品文档，产品文档有哪些流程

在线撰写产品文档越来越成为未来的趋势，使用摹客iDoc，轻松实现产品文档的在线协作、审阅，与原型、线框、高保真的紧密融合。

第一步：创建产品文档

在摹客iDoc 中可以免费创建在线的产品文档，摹客iDoc网址：

第二步：在线撰写产品文档

摹客iDoc 提供强大的产品文档撰写功能，可轻松引用设计稿，并在设计稿更新后自动同步到文档中，修改设计稿不必再次修改文档中引用的设计稿。

第三步：在线审阅产品文档

摹客iDoc 还提供在线评论、审阅产品文档的功能，审阅更及时，也可上传本地文档，支持doc、docx、pdf等格式的文档，工作更高效