指南编辑：要求文档和要求规范指南都与产品相关，但适用的方案不同。产品经理可以使用需求规则手册进行系统验证或评估，以便更好地为实际方案提供服务。在这篇文章中，作者详细说明了他理解的需求规格说明书，请一起看一下。

一个，前言

以需求工作经验(ToB方面)，两年小白，在没有大手的情况下摸索着扭动着，事实上有点关门了，希望大家能多指点一下。怎样才能更好地完成需求工作？

另一方面，希望能记录自己的胡思乱想，避免变成真正的胡思乱想。

第二，制定规定的目的是什么？

为什么要把写规定的目的放在第一位？

作为生产岗位，挖掘用户需求是我们的最终目标。对于这种思维结构，那么为了探讨如何写好需求规定，我们需要知道需求规则存在的意义是什么。为了什么而存在？我们可以继续通过用户场景进行分析。我们在什么情况下使用需求规定？

方案A:需求负责人在需求传递过程中，通过需求向开发团队成员说明系统功能A、功能B、功能C等。情景B:开发同事发现了业务A，有两种理解方法，不知道该用哪种。案例C:当专案进入需求验证阶段时，需要需求同事检查系统是否通过。情景D:测试同事提出了bug，但开发同事认为这不是bug，需求是这样的。对于上述四种情况，我们可以感觉到，目前开发的系统是否正确，需要指导、验证和判断。场景中分析的合规效果可以理解为一个解决方案。

我们进一步思考，需求的根本目的是否可以认为“开发的系统是顾客想要的系统”。

三、要求文件和要求规范之间有什么区别？

一样又不一样。

说他俩一样。因为他使用的主要对象是开发、测试、项目经理。需要说明核心业务、具体使用案例说明、功能内容说明等。

说他俩不一样。因为需求文件是从产品的角度叙述的。需求是从系统的角度谈的。

两者都有交集，但没有必要区分。面对矛盾时，我们要理解矛盾点在哪里。

一般来说，矛盾大部分是由利益矛盾引起的。那么这是谁的利益矛盾呢？

只不过是读者和作者的矛盾。读者想快速简洁地获得自己想要的信息，因为懒！毕竟，阅读冗长的文件对读者来说是精神和肉体的双重折磨。作者们总是想对事物说得足够详细。不要产生两重性，否则要懒。

因此，需求文档更侧重于产品说明、产品定位、大象市长/市场、大象用户和竞争产品。需求更侧重于系统的描述、逻辑、约束条件、输入输出条件等。

第四，从发生的问题中反思。

合规性的目的是“确保开发的系统是客户想要的系统”(首先假定戴尔的法规内容与客户的想法一致)。我们首先分析可能存在的场景中，规定上应该有哪些内容。

1. 一定要有业务场景描述

实际上是对商业场景的说明，我想让文档读者更快地导入系统。由于公司资源的调整，项目的很多同事都交换了，直接参考文件，给同事们一张容易说的懵脸。因此，为了使团队成员易于理解和集成，对业务场景的说明也很重要。

我们在描述场景时，最好说明为完成“谁”(参与者)、“什么场景下”、“什么目的”而做了“什么工作”。

通过这几个因素，个人认为很容易解释需求背景。

2. 尽量用用例的方式去划分功能点

《1000读者1000哈姆雷特》，对需求结构的理解必然因人而异。个人认为，要保持中心思想进行需求。用户可以通过系统做什么。

作为系统的使用案例，可以通过多种方式整理系统的使用案例，从而更直观地了解系统的功能。

例如，在“方案A”的情况下，要指导开发团队开发功能，必须尽可能清楚地说明每个功能，并确保功能没有缺少任何内容。

那么，什么逻辑能完美地描述功能呢？我认为，在计划项目时，应该明确划分模块范围，确定每个模块的定义、目的和复盖范围，然后根据模块计划使用案例。这样可以保持完全涵盖开发内容的功能。读者看的时候也能直观地看到，原来我们的系统能够完成上述功能。

3. 复杂逻辑功能的流程图很重要

为什么要单独提出功能的概念？总结场景B、C、D可以发现我们对功能的理解是不同的。

文字说明总有缺点。短文、说明顺序、说明逻辑都是主观的。所以我们可以画流程图来辅助对文字的说明。

还必须确定流程图的范围、业务流程或使用案例的说明。因为遇到了将业务场景与用例一起绘制的工作。这样很容易误导读者，造成读者的迷惑。

那么为什么要只指向复杂的逻辑功能呢？事实上，我们

本文由 @小钟也会胡思乱想 原创发布于人人都是产品经理，未经作者许可，禁止转载。

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