在撰写需求文档时，要怎么确保需求文档的完善性，确保交付的需求文档是稳当的？这篇文章里，作者梳理了核心流程与相关步骤，一块儿来看看，或许会对屏幕前的你有所帮助。
在撰写需求文档时，要怎么确保需求文档的完善性，确保交付的需求文档是稳当的？这篇文章里，作者梳理了核心流程与相关步骤，一块儿来看看，或许会对屏幕前的你有所帮助。
1）围绕主数据展开的系统建设。根据二八法则，我们最重要的是那20%的主数据，主数据也能够理解为我们最重要的业务对象，例如：客户、支付、订单、发货等。
这启发于《华为数字化转型之道》以及我平时常看的saas系统写的说明书，特别是旺店通ERP的说明书，让我受益匪浅。
2）用“强逻辑”去确保我们每一步都走得很踏实，来确保我们整份需求文档交出去的时候是稳当的。
1）详细地将业务流程刻画下来，建议主要用图表来描述，例如：流程图。这一步主要是让我们加深对业务的理解。
2）开始总结出核心。用图表以及一些的文字言简意赅描绘出整个需求，让人一目了然。需要写出必要的固化后业务流程图、功能流程图、数据流程图等。这一步做完，你对需求已经很理解，能够简要地表达给别人。
主数据也能够理解为我们最重要的业务对象，例如：客户、产品、支付、订单、发货等。对于主数据的认识也依赖我们对于系统的理解深度、广度，全局观和前瞻性。
我们梳理主数据的时候，通常是从主数据的生命周期去梳理，从一条数据产生到其被废弃不再使用。
我们以产品为例，简要地做个示范。事实上一个很完善的系统，将会记录下产品创建时的状态、上架时的状态、下架时的状态、修改后的状态。这里真的是很简单示范，事实上信息远不止这些。
从数据的角度来说，这样做才算真正将功能做完整，关键操作后该记录下来的东西都记录下来了。
这也是更接近于我们说的一个概念“数字孪生”，现实世界上的东西更多地记录在了系统上。
我还记得某次业务问起谁改了产品信息，结果我们没日志记录下这一些信息就很尴尬，无法排查问题。我们大多数人做系统，特别是企业内部系统，都没有这种将关键操作记录下来的习惯，不信你看看你旁边的同事。
这很容易让我们的思维是很发散的，一边需要兼顾原型的样式，一边需要想有什么操作，应该展示什么数据。可能你会在脑子里想，应不应该搞个批量操作呢，然后画了一下，然后又觉得还是不要了，初期版本没必要。就是这样的不集中的思考，会消耗你很多的时间，让你花了更多的时间去画原型。
这里讲的是大概，我特别指出，因为我曾经尝试过将原型的逻辑先构建得非常详细，发现这很花费时间，其实也没必要，因为有一些页面上的字段你在逻辑里概括一下（还有的业务会直接给你表单的字段，这样一个时间段你更没必要重复在逻辑里写一遍字段），等到画原型时直接写在原型上也省一点事。
根据业务流程图先梳理出页面，假设你要做的是一个简单的商城管理后台，从业务流程梳理我们大家可以得到下面的页面。
参考我们上面梳理的核心逻辑与主数据信息，我们大家可以很快梳理出页面上有什么字段、操作。到这里的时候，我们已将整个原型基本勾画出来了，接下来就是打开axure开始绘制，这一步自然难不到各位。
这个逻辑已经在我的上一篇文章里写过了，按照那样去写，大概率不会有什么样的问题，这是多年实践下来的。
别忘了写完原型之后，自己按原型走一走核心流程以及各个操作看看有没有哪里有问题，这不比啥都强吗！