系统需求分析模板(系列（三）：需求文档)

国产第七代

2022-04-27 04:50:02

编者指南：需求文档伴随着产品经理的整个职业生涯。编写需求文档是最能反映产品基本技能的地方。如何编写需求文档？本文将从三个方面进行分析，希望对大家有所帮助。

一家大工厂的首席执行官曾经说过“如果你把基本技能练得好，你可以赢得99%，而编写需求文件是最能反映产品基本技能的地方。许多产品/运营商的童鞋抱怨研发缺乏合作，态度不好，喜欢挑毛病。如果你在日常工作中遇到这些问题有时，姐姐强烈推荐阅读这篇文章，并首先考虑你的要求文件是否合格。

此外，尽管需求文件很少用于报告和促销辩护，但这位学生姐姐听说，许多大型互联网制造商的高管会阅读需求文件，以了解产品细节，并检查一线童鞋的基本技能是否扎实。在这个时候，如果文件没有写到位，那会很尴尬~

大型工厂产品专家教你手拉手系列（一）：写一份好简历的三个步骤

大型工厂产品专家教你手拉手系列（二）：行业研究与规划

1、写作前分类

在编写需求文档之前，我们必须首先对这次编写的文档进行正确分类。毕竟，半年和半天的要求会有所不同。这与我们将在需求分析阶段首先进行用户分层的原因是一样的（用户分层的学生姐妹多次强调了这一点，我们不知道的童鞋可以在本文中被戳到）。一般来说，需求可分为以下三类：

1.重大项目

有超过3个功能点能够实现的需求是一个比较完整的项目，一般需要2个月以上的研发。

例如，学生姐姐之前在订单上做了一个收取1元服务费的功能。虽然这听起来像是一种损失（一句话，它需要启动~），但它将涉及整个交易过程的转变。C终端将涉及交易清单、商品详情页面、订单清单、订单详情、退款详情等，B终端将涉及商户通知、交易清单报表等；除业务方研发外，还需参与折扣中心、订单中心、结算中心等大中型平台的研发。此外，无法在线拆分每个功能点。

此类文件的模板是最完整的，将在第2章中介绍。

2.功能点

指可以单独启动的功能点。

比如微信公众号不过，新添加的文章中有一半可以从“草稿箱”中保存公众号从作者的角度来看，这是一个相对较大的修订，因为它涉及公众号背景的核心功能是写文章。但是，该实现只增加了这三个功能点：

撰写文章时，可以保存草稿或查看草稿
公众号“最近的草稿”模块添加到后台主页上
公众号在后台主页左侧的工具栏中添加“草稿框”。单击此处查看所有草稿

后两者可在功能1启动后单独启动。这样的需求可以根据“功能点”编写。这三个功能点可以写在一起，也可以单独写，具体取决于产品的进度要求。

3.小优化

这些需求可能是一些小的用户体验改进、大的修复、视觉优化等，比如更改页面上的按钮。很多童鞋在写这样的文件时往往是“一句话的要求”，但事实上，这样的文件也会关注“麻雀虽小，但五脏俱全”。

2、三阶段写入PRD

在理解了三类需求之后，我们可以使用不同的模板。学生妹妹将按照三个阶段的公式详细介绍PRD的每个部分：背景->；内容->；计划（小优化不需要）。

1.需求背景

这是一个常见的扣减点。如果背景写得不好或写得不好，就相当于问一个女孩，当她赶上她时，她体重有多重（你可以问研发小弟弟/妹妹的心理阴影区域）。本部分针对每种类型的需求编写，永远不要忽略。需求背景分为以下两部分：

1）为什么

首先，我们需要弄清楚为什么我们需要这样做。在这里，姐姐提供了一个经典的句型，即先发展的欲望和先抑制的欲望。我们可以先谈谈当前的问题，比如列出用户的痛点，匹配一些数据，最后提出我们的解决方案，以便更顺利地讲述故事。举两个简单的例子，让我们感受一下：

目前行业参差不齐，信息不公开透明，消费者权益根据行业报告，如果没有保护，投诉率是多少？因此，我们需要建立一个真实可靠的消费者评价体系
结算页面是用户完成交易所必需的页面。目前，其转化率低于50%，竞争产品/行业标准为60%。因此，需要对其进行优化

这篇文章的优点是，它会让其他部门的同事也有同感。毕竟，其他人不像你那样了解这个行业的用户和产品。这可以产生移情。

2）你想要实现什么

估计项目能实现什么核心指标，最好写下评估的过程。一方面，“直接谈论金钱”可以增强其他同事的成就感，使他们更愿意积极参与；另一方面，这也是为了锻炼你对数据作为产品/操作的敏感性。例如，因为你估计得太多，每次的数量级基本上非常准确，越来越接近真实数据。

例如，本阶段公司的核心指标是交易量。我们想在订单完成页面上添加一个推荐模块。此类推荐模块其他业务线的购买访问率一般为2%，我们交叉推荐行业的客户单价一般在100元左右。那么我们只需要在订单详情页面上取日均UV*2%*100元*计算每日新增交易量。如果在评估时没有数据可供参考，而且你是新工作或新业务人员，你也可以与周围的一些高级同事交谈，询问他们的想法，然后取一个中间值。

2.需求内容

在写完背景后，你可以输入文本，这也是一个三阶段（我要买娃娃）：需求概述->；需求详细信息->；数据管理。

1）需求概述

事实上，这一部分是为了澄清这一要求的范围。首先，它给你一个更直观的印象，不同类型的需求将有自己的编写方法。

对于大型项目，一定要写出功能列表，因为项目中通常有许多功能点。如果你直接谈论功能点，很容易把别人搞糊涂。首先，给我们一个整体的画面。以表格形式写出每个功能点对应的页面、平台等。如果涉及跨部门，最好写下相应的（研发）接口人（或需求评审后补充）↓

功能点，您可以先简要描述每个功能点。如果将多个功能点组合并写入一个文档中，还可以清楚地标记优先级↓

对于小型优化，需求本身并不复杂，可以通过几十行代码来解决。正因为如此，研发可能是随机进行的，忽略了一些小细节，比如它在哪一端，在哪一页上。此时，我们应该尽可能凭直觉行事。如果需求非常简单，你甚至可以在这个表格中把详细的需求写在一起

2）详细要求

本部分详细介绍了这些要求。不同的项目和功能点之间有很大的差异（小优化相对简单，所以不会进行）。说可以使用同一个模板来设置它有点不负责任。因此，学生姐妹提取了两个共同的维度来细分函数。不同类型的需求对应不同的写作方法。她也会教你映射步骤

a）新vs优化

添加是从0到1构建函数，优化是从1到100。

对于新的，我们需要“新概念”定义明确。例如，添加了一些新页面/状态，它们定义了它们是什么。例如，此页面将显示“草稿框”功能公众号在作者的所有草稿都被明确定义之后，在撰写文件时应该使用统一的措辞，以确保每个人都能用一张脸交流。例如，没有草稿详细信息页面，但在原始文章详细信息页面中添加了一个名为“草稿状态”的中间状态。点击“保存草稿”后，在发布文章之前就是这种状态。这样，大家和研发之间的沟通在对齐后会更加顺畅，不容易被误解。

对于优化，我们要强调的是优化后和优化前的差异。例如，对于页面优化，我们可以直接将对比图放在需求文档上，圈出调整后的部分并粘贴到需求文档上，清楚地标记数字，然后用文字描述相应的优化，这样研发人员就不必对新手稿“找茬”。

b）关注前端页面与后端逻辑

许多人喜欢将其分为b端和C端，对应不同的写作方法。然而，姐姐认为，在编写文档时，最好看看需求是集中在“首页”还是“后端逻辑”，因为这是开发的逻辑。B或C实际上是产品需求分析的逻辑。

例如，刚才提到的“新增1元服务费”是一个端到端的需求（B和C）。它在逻辑上并不复杂，但由于事务处理的缘故，会有更多的页面，因此它主要关注前端页面。对于这样的需求，我们可以与设计对话，点缀着图片和文字，在描述需求时，尝试粘贴更多图表。例如，您还可以在流程图上粘贴一些页面，甚至可以直接使用交互式/可视化草稿进行查看。

另一个例子是出租车业务，它在乘客侧的订单详细信息页面上显示并优化。虽然这听起来像是页面调整，但订单页面有很多状态，包括十多种状态：在收到订单之前、收到订单之后、出发之前、出发之后、未到达目的地、到达目的地、乘客上车之后、乘客到达目的地时未支付、已支付等，在每种状态下显示的页面是相似的，但显示的元素（如按钮）会略有不同，这是一个非常强调逻辑的要求。此时，如果只粘贴设计草图，很难解释问题。你仍然需要灵活使用各种图表。

所以问题是，除了表格和流程图，如何制作适当的图表来表达产品逻辑？

搜索互联网，你会发现各种图表，如泳道图、序列图、状态机、架构图拓扑图等待说实话，这位学生姐姐认为，只要这幅画能清楚地表达逻辑，没有人会在意你的画是否足够标准（指互联网行业，非软件）。在一家大工厂里工作了这么多年，她做过各种各样的生意，经历过很多次战斗。她从来没有受到过研发的挑战，她甚至没有在一家大工厂里听到任何人提到这一点。”统一建模语言”这个词（当然，如果你愿意仔细学习UML，它也很棒）。

事实上，绘画的原理是相似的。姐姐抽象出了绘画的五个步骤。读完后，童鞋们应该会觉得画画很容易。

3.清除图纸中的5个步骤

1）绘画元素

每个人都应该知道图中的元素吗？它是具有不同形状和文本的框，例如脑图流程图（图1）中的每个主题，例如开始、结束、步骤、选择等，例如序列中的对象和激活周期（图2）

*prossesson截图

如果你想画得更标准，你还可以进一步了解不同形状框架的含义。

2）安置位置

元素的角色可以直接标记在框中，但如果该对象和角色中有许多细分逻辑，则应该通过元素的位置来表示。就像刚才一样序列图在中，同一列表示同一对象车道图在（图1）中也是如此。同一列表示角色。在系统架构图（图2）中，每个水平行代表同一级别的系统功能

*processon的屏幕截图

3）再三看

把它放在适当的位置，我们可以开始一次又一次地观察它，也就是说，建立元素之间的关系。有三个共同点，从属关系、序列和数据传输，前者通过一条线连接，后两条线带有箭头。例如，流程图和顺序图中的单个箭头表示顺序；架构图中的双箭头表示数据传输↓

*processon的屏幕截图

奥克尔中的连接线表示依赖关系，从大O（目标）到小O，从小O到Kr（路径）↓

*processon的屏幕截图

4）查找包含

通过前三个步骤，我们实际上可以解决大多数图表，但我们仍然需要看看是否包含元素。由于包含关系，我们经常看到架构图中有一些大盒子和小盒子（也称为玩偶）的样式。举个简单的例子，美团该平台的骑手评估和上诉流程（简化版）非常清晰。可以看出，平台的第一次过滤主要包括四种情况，第二次过滤将包括三种情况。这样，我相信骑手也能看得很清楚↓

*来自美团公众号

需求分析模板

如果前一部分包括后一部分，我们只需要稍微叠加这两个元素，比如经典的PMF方法。然而，这种图很少用于详细的需求中，通常是在需求的背景中

5）添加辅助项

为了让你看得更清楚，制作完地图后，我们可以适当添加一些辅助，比如背景色、辅助线等，帮助你更容易地看到地图。例如，下面的架构图和泳道图将比黑白图更清晰↓

processon的屏幕截图

4.数据管理

在这里，文档的大部分内容都已经编写好了，数据管理是文档中一个容易被忽略的部分。通常情况下，数据管理文档会在以后进行补充，这很容易导致上线后缺少管理。

学生姐姐建议你可以先写下最核心的管理，然后在需求被审查并确定需求细节后再写下详细的管理，这样就不会花费太多时间，也不会因为一些管理没有经过评估而增加工作量（如果你不知道如何管理，你可以看学生姐姐的文章）。

5.项目计划

如果这次的需求是一个大型项目或一个重要的功能点，则必须编写项目计划。虽然在编写文档时没有评估研发工作量，但许多重要项目都有时间节点。与其等待每个人在评估后发表评论，不如在一开始就直接向你展示你内心的节奏，这样研发部门就可以推断出项目的启动时间和资源。

当然，如果这不是一个有时间节点的高优先级项目，你可以把表格留空，在审核后填写。

3、审核后更新

经过三个阶段的审查后，我们需要更新文件中的以下内容↓

1.风险点

这一部分也需要更新。除了资源、合规性、预算等，大多数需求的风险点也容易被忽略，这是不同部门研发之间的依赖关系。例如，研发B需要研发C的接口，研发a需要研发B提供的接口。即使C按时提供接口，a和B的研发已经完成，并用虚假数据进行了测试，但很可能a和B都因为C的缺陷无法成功协调，整个项目很容易被delay发现。

因此，如果在研发审查期间提出了一些依赖性，我们必须在文件中明确使用黄底标，这可以在珠江三角洲项目计划的第三部分中进行标记。