编辑导语：产品经理有一个工作内容叫做需求分析（PRD），主要是看业务上有哪些不合适的地方，并且提出方案去完善。在这篇文章里，作者便通过分析一个实际例子中存在的问题，像我们分享了如何写好需求文档，需要注意什么，一起来看一下吧。

最近和一些初入刚入门的产品或者想要进入产品岗位的人交流。发现很多人都是在自学Axure、去练习软件的使用和交互的设计。

昨晚有个朋友把他的原型发给我，想让我帮忙看下问题。

其实这里第一个问题就是他不知道自己的问题在哪里，这本身就是一个比较致命的问题。

产品经理有一个工作内容叫做需求分析，去看业务上有哪些不合适的地方，并且提出方案去完善。

暂且抛开这些，我们今天先来看下PRD到底应该怎么写。

01

这是这位同学的需求文档，我简单截2张图：

乍一看挺像那么回事的，但其实不管是逻辑上、还是原型交互上，仔细看都会有问题。

以登录页面的需求描述为例：

1）图中1、2两部分的逻辑是有冲突的。1讲的是账号没有填写的时候，点击登录按钮会给予提示“账号不能为空”；而2讲的是登录按钮在账号密码未填写时是不可点击的。

那请问当账号和密码都没有填写的时候是可点击还是不可点击呢？

如果可以点击，那点击后的提示是提示账号不能为空还是密码不能为空呢？

2）图中3是指密码错误时候给予提示：密码错误请重新输入。看起来逻辑是正确的，但业务场景上是有问题的。

这样表述代表着你已经默认账号是正确的。

那是否会存在A用户的账号是ningshu，B用户的账户是ninshu。当A在账户上填写的是B用户的账户，那密码不可能正确。

因为错误其实不在密码上，而是在账户上。所以更准确的说法应该是：账号或密码可能有误，请重新输入。

3）图中4部分是指账号不存在的时候，输入框下方会进行提示：无此账号，请重新输入。

第一，没有触发条件，是需要研发监控输入框，每输入一个字符就去数据库查询是否有这个账户吗？显然不合适。

第二，哪怕你的触发条件是在光标离开输入框之后也不合适。因为判断账号信息应该在登录按钮时一起来判断，原本在一个操作上完整判断的事情不合适分开来处理。

4）图中5部分只讲了自动登录，那什么时候自动登录会被取消呢？

是保持7个自然日的自动登录，如果用户登录后会重新更新7自然日的token记录，超出7个自然日不登录会被取消自动登录？还是其他的一些条件？

5）整个文档从逻辑上就有问题，在讲某一个页面组件，比如“账号输入框”的时候会出现其他组件的逻辑判断（输入框提示账号不能为空）。

你在和研发沟通的时候，研发的思维是跳跃着来，并且本身是登录按钮的逻辑被打散拆到了账号输入框、密码输入框等不同地方，对于单个组件的逻辑是不连续的。

6）登录按钮在页面上讲过有很多错误提示的情况。那请问这些错误提示的优先级是什么？

就像我们上面刚刚提到过的，既有账号不能为空，也有密码不能为空。那当账号密码都为空的情况下应该给予什么样的错误提示呢？

……

其实这里面还有很多问题，就不一一详细来说了。

02

需求文档到底应该怎么写？

首先我们得理解原型是原型，需求文档（下面简称为PRD）是需求文档。像这种原型边上做标注的方式是可以的，但标注完也不是完整的PRD。

PRD是给谁看的？PRD评审其实根据不同业务或者重要程度参与的人每次都可能不一样。

参与者会是以下11个岗位的其中1个或多个。

当有这么多人参与进行PRD评审的时候，第一件事情不是讲具体的功能点事什么。

而是要和大家沟通为什么做这件事情，做这件事情对我们的业务有什么样的好处？也就是常说的需求目标是什么？

只有大家达成共识的时候，在接下来的PRD评审过程里，才能让研发和其他部门的人和你是在一个频道上思考的。

03

PRD文档是用于给研发进行开发所使用的，所以这里就有一个非常关键的原则——没有任何歧义的部分。

1就是1，2就是2，不能模凌两可，这样研发才能很好地把代码写出来，千万不能让研发去猜。

就像我们刚刚上面聊到的，登录按钮的错误提醒是有优先级的，你可以这样写：

当账户和密码两者有一个没有输入的情况下，点击登录按钮时，在下方提示：账号或密码不能为空。

当账户和密码输入后，点击登录按钮时，系统按以下顺序进行判断：

1.账户是否存在

存在：进行第2条规则判断

不存在：下方提示文案：“该账号不存在”

2.判断密码是否正确

不正确：下方提示文案：“账号或密码错误,请重新输入”

正确：toast提示：“登录成功”并跳转页面进入管理后台首页

把所有的情况都写出来，这样研发看起来是没有争议的。当然，更好的做法是写User Case，如下：

User Case 是拿来干嘛的？是用来描述什么角色通过某某系统能做什么事情的流程体现，User Case 的书写也是产品经理对用户需求深刻理解的体现。

04

需求文档的书写上还有很多需要写的，比如你需求中的完整业务流程图、分角色甬道图、详细需求清单等。

如果涉及到系统安全性部分还需要有安全性需求，比如接口的加密、账户的单点登录、单位时间内多次接口访问时需要进行人机交验、用户输入不能注入SQL、代码等。

如果涉及到一些法律上的部分，需要法务进行协助的需求。比如用户隐私、用户所输入的安全性交验，是否涉黄涉暴涉政等。

详细的内容一篇文章说不完，我们后面再慢慢详细说。

本文由 @宁叔爱思考 原创发布于人人都是产品经理。未经许可，禁止转载

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