在撰写需求文档时，要怎么确保需求文档的完善性，确保交付的需求文档是稳当的？这篇文章里，作者梳理了核心流程与相关步骤，一起来看看，或许会对屏幕前的你有所帮助。

一、核心逻辑

1）围绕主数据展开的系统建设。根据二八法则，我们最重要的是那20%的主数据，主数据也可以理解为我们最重要的业务对象，例如：客户、支付、订单、发货等。

这启发于《华为数字化转型之道》以及我平时常看的saas系统写的说明书，特别是旺店通ERP的说明书，让我受益匪浅。

2）用“强逻辑”去确保我们每一步都走得很踏实，来确保我们整份需求文档交出去的时候是稳当的。

二、梳理业务流程，得到核心逻辑

1）详细地将业务流程刻画下来，建议主要用图表来描述，例如：流程图。这一步主要是让我们加深对业务的理解。

2）开始总结出核心。用图表以及一些的文字言简意赅描绘出整个需求，让人一目了然。需要写出必要的固化后业务流程图、功能流程图、数据流程图等。这一步做完，你对需求已经非常理解，能够简要地表达给别人。

注意：这里尽量需要能够从数据底层理解需求。

三、抽象出主数据

主数据也可以理解为我们最重要的业务对象，例如：客户、产品、支付、订单、发货等。对于主数据的认识也依赖我们对于系统的理解深度、广度，全局观和前瞻性。

能够借鉴先进的系统，并立足于自己所在的公司业务，严谨地推敲，大胆建设。

四、分析主数据

按照生命周期去分析，得到相关的操作和字段。

我们梳理主数据的时候，通常是从主数据的生命周期去梳理，从一条数据产生到其被废弃不再使用。

我们以产品为例，简要地做个示范。事实上一个很完善的系统，将会记录下产品创建时的状态、上架时的状态、下架时的状态、修改后的状态。这里真的是很简单示范，事实上信息远不止这些。

从数据的角度来说，这样做才算真正将功能做完整，关键操作后该记录下来的东西都记录下来了。

这也是更接近于我们说的一个概念“数字孪生”，现实世界上的东西更多地记录在了系统上。

这也是风控的一种手段，随时能够排查出哪里出了问题。

我还记得某次业务问起谁改了产品信息，结果我们没有日志记录下这些信息就很尴尬，无法排查问题。我们大多数人做系统，特别是企业内部系统，都没有这种将关键操作记录下来的习惯，不信你看看你旁边的同事。

五、分析原型怎么画

直接开始画原型，一边画原型一边脑补应该有什么页面，页面上有什么？

这很容易让我们的思维是很发散的，一边需要兼顾原型的样式，一边需要想有什么操作，应该展示什么数据。可能你会在脑子里想，应不应该搞个批量操作呢，然后画了一下，然后又觉得还是不要了，初期版本没必要。就是这样的不集中的思考，会消耗你很多的时间，让你花了更多的时间去画原型。

本质上，应该是逻辑先行，先从逻辑上大概构建好你的原型。

这里讲的是大概，我特别指出，因为我曾经尝试过将原型的逻辑先构建得非常详细，发现这很花费时间，其实也没必要，因为有一些页面上的字段你在逻辑里概括一下（还有的业务会直接给你表单的字段，这个时候你更没必要重复在逻辑里写一遍字段），等到画原型时直接写在原型上也省一点事。

工作量与产出要达到一定的平衡，这样才会有高的ROI。

六、梳理出页面

根据业务流程图先梳理出页面，假设你要做的是一个简单的商城管理后台，从业务流程梳理我们可以得到下面的页面。

当页面足够多的时候，我们就需要形成一个菜单，也就是我们说的功能结构。

七、梳理页面上的字段与操作

参考我们上面梳理的核心逻辑与主数据信息，我们可以很快梳理出页面上有什么字段、操作。到这里的时候，我们已经将整个原型基本勾画出来了，接下来就是打开axure开始绘制，这一步自然难不到各位。

八、原型的逻辑怎么写

这个逻辑已经在我的上一篇文章里写过了，按照那样去写，大概率不会有什么问题，这是多年实践下来的。

大家一定还是想要一个武功秘籍一样的东西，那应该就是自检表。

以下是我总结的一套自检表。

九、最后

别忘了写完原型之后，自己按原型走一走核心流程以及各个操作看看有没有哪里有问题，这不比啥都强吗！