需求文档是产品需求的表达方式，而其中需要描述什么内容取决于产品经理想要描述什么，即产品经理的需求。如果产品经理的需求是明确的，而且产品经理脑中有物，那么需求文档自然而然就出来了。最可怕的是产品经理自己都不知道自己要描述的是什么内容，这个时候即使有模板，写出来的东西也是一团糟。
互联网产品以用户为中心，所以prd也应该站在用户的角度来描述，如果不知道自己要写什么，在写文档之前产品经理可以先问问自己以下4个问题：
用户需求是什么？
通过产品，用户能得到什么？
如何满足不同用户的使用场景？
产品应该做什么？
这四个问题凝聚了End2End思想的核心，站在用户的角度给需求，在Jesse James Garrett的《用户体验要素》一书中，被分别称为范围层（问题1，2），结构层（问题3），框架层（问题4）的用户体验。
>>>>用户的需求是什么
按照需求出生的先后排序，需求分别是：
用户需求
功能需求
即先有用户需求，才有功能需求。此文开头已经提过，笔者曾受功能需求模板误导，所以下文中仅描述用户需求。举个例子，用户希望买到物美廉价的商品，那么对于用户而言，用户需求其实就是以下几点：
如果是B2C平台，还得考虑到B端用户的需求，那么用户需求列表就是：
>>>>用户可以得到什么
这个问题，其实也是思考产品的有用性，即产品这么做对用户能产生的价值。
在上面这个B2C电子商务平台的例子中，B端用户通过在系统中发布商品，供C端用户购买，可以给B端用户带来收益，加入了优惠券之后，B端用户在系统中发放优惠券，系统通过优惠券可以刺激C端用户消费，此时B端用户给C端用户提供了折扣，拉动消费后C端用户会给B端用户带来更多的收益，图形化后的表达为：
此图可称为用户价值链
>>>>如何满足不同用户的使用场景
满足不同用户的使用场景，又称作用户场景分析。
接着上面的例子，在用户的两个需求中又包含了不同的场景，其中商品需求的场景包括浏览、下单和付款，优惠券需求的场景包含了获取和使用，于是用户场景（use case）主要表现为：
发布商品是对B端用户而言
在浏览商品这个场景中，不同的用户有不同的使用场景。一部分用户是有目的的，他们知道自己想要的东西叫什么名字，可能只是想知道在这个产品中该商品的价格，所以产品需要提供搜索功能来应对这种用户场景。然而大部分用户都是无目的浏览，为了满足这种用户的需求，只需将商品罗列出来就好。电商平台常见的分类展现、价格范围等等功能都是为了满足介于有目的和无目的之间的用户场景，分析方法类似，此处不再展开描述。
浏览商品之后是下单，有的用户习惯把看起来觉得还不错的商品全部放在一起，先比较比较，再决定是不是要购买，有的用户属于冲动消费或者消费目的明确，这些用户通常看到一个商品觉得还不错，就直接下单了。所以下单这个场景，又有两个用户场景，一个是添加到购物车再下单，一个是直接下单。
最后是付款，付款的方式有多种，有的用户喜欢用支付宝，有的喜欢用微信，有的喜欢用银联等等。这些场景都是现实存在的，但是产品经理需要过滤哪些场景是频繁的场景，哪些是不频繁的。比如，如果这个B2C平台是建立在微信上的，那么用户用支付宝和银联付款的场景就显得很弱，如果是淘宝或者天猫，毋庸置疑，支付宝一定是频繁场景，如果是独立的电商平台，那么可能以上几种场景都需考虑在内，甚至还需要再多加入几个支付场景。
优惠券为大家所知，获取的途径通常有两种，一种是系统发放，一种是主动领取。
通过以上描述，不难得出以下用户场景分析图：
>>>>产品应该做什么
描述产品应该做什么的过程，是prd最核心的部分，也是研发人员最关心的部分。因为只有研发人员看了到产品应该做什么，他们才知道自己应该怎么做。
互联网产品重交互，所以用户与系统之间的互动是最好的描述方式。在测试中有一种方法被称为黑盒测试，用在这里，再合适不过。简单地说，就是用户输入什么，系统输出什么，即：
左边一列描述用户的动作，一行仅与用户的一个动作关联，右边一列描述对于用户的这个动作，系统做出什么样的反应，包括达到什么页面，展示什么信息或者跳转到哪个页面。
结合我们的例子，由于这个例子中有“两个”用户，我们的C端用户和B端用户，所以表格需要做一点小改造：
以其中B端用户发布商品和C端用户搜索商品为例，展开描述，可得到如下用户事件流（user story）：
将其他场景拓展开之后，prd文档基本完成。在此基础上，不管系统应对的用户多么的复杂，都可以自如地化繁为简。
来源：人人都是产品经理
