接着上篇继续写，上篇请点击标准的产品需求文档在这里！(详细说明版)(1)

入口已经写完，读此文档的无论是研发人员还是测试都已经知晓此需求需要做的从哪里进入，接下来就是主菜了，进入以后该干嘛。

进入以后当然就是新的页面！或者是在旧页面基础上进行修改。

那到底该如何专业的描述一个页面的需求呢？

从三个方面：1. 页面说明；2. 逻辑处理；3. 异常处理。

首先要明白一个页面有多少种状态，因为一般来说页面都是有交互，比如浏览历史的页面，它可能有多个状态，比如下面为携程的浏览历史的页面，有多个状态，此处只选取3个供大家理解。

(点击查看大图)

所以一般情况下浏览历史有多种状态，分别是交通浏览历史、酒店浏览历史和全部浏览历史，都是通过头部点击下拉然后进行选择切换的，我们就需要对每种状态进行描述。

我们已经知道了前面我们写入口的时候是3.1.4.1，那么假设浏览历史有三种状态，我们这个时候就可以预想到应该有3.1.4.2到3.1.4.4这三个页面需要描述。

当然这只是举例子，若存在更多的状态还需要把所有状态都列出来，产品需求文档的专业体现在细致上，让开发人员和所有读文档的人都看的明明白白，再也不会找你聊天烦着你。

知道了布局之后，我们开始对剖析每一个页面。

首先从交通浏览历史开始来说。

先贴一张图。

先给3.1.4.2取一个标题，只要看的懂就行，然后贴一张次状态的图，再贴一张删除的弹窗提示图以及缺省图。把该状态下该页面可能出现的情况都得贴图出来，才能体现文档的完整性。

贴完之后，开始进入正题。从

1. 页面说明；2. 逻辑处理；3. 异常处理。

三方面说明。

先讲界面说明。

从上图也可以看到，界面说明分为导航栏和界面元素两部分来说明。

导航栏，说明导航栏左上角，中间和右上角的情况。

用项目序号a\b\c或者其他都可以。

界面元素，则是界面内部除了导航栏之外的所有细节。

注意此处只讲界面说明，不讲逻辑。即这个页面到底呈现了什么给我们，而对这个页面存在什么样的逻辑不说。UI设计师和前端工程师更侧重于看这一部分，在做UI图和前端页面的时候就不会有遗漏。

以下是界面说的文案，可以供大家看看怎么书写。

(一)界面说明：

1) 导航栏：

a. 返回按钮：返回上一个界面；

b. 标题：机票搜索浏览历史；

c. 清空：清空当前页面浏览信息；

2) 界面元素：

a. 机票预订浏览历史图标、机票兑换浏览历史图标及下方图标文字说明；

b. 机票搜索浏览历史记录信息

l 出发地与目的地；如：北京→广州 机票；

l 时间显示：如遇历史查询信息为单程，则显示×月×日出发；如为往返程记录信息，则显示×月×日至×月×日(此日期为用户查询去程的日期和返程的日期)；

l 单程或往返箭头图标；单程为单箭头与往返为双向箭头；

l 舱位：只有“机票兑换”的查询历史才显示，“机票预订”查询历史不显示，舱位分：经济舱、明珠经济舱、公务舱和头等舱；

l 日期分割线：以每天晚上12点为分割，分割方式如上图，分割显示文案如：12月30日；如果遇到当天则显示“今天”，昨天则显示“昨天”，其他时间显示日期；日期分割时间是触发查询的时间点而非飞机起飞时间；

l 成人儿童数量：如：1成人 0儿童；机票兑换栏目只显示成人数量；

l 底部说明：没有更多信息了；

对应的图片为，可上下对比查看，看看如何用文字描述页面中的界面。

(点击查看大图)

当然界面说明和逻辑说明之间并不是非常严格的界面，当有些在陈述界面说明的时候，可以稍微带一点逻辑说明，但不要过分讲逻辑，比如说在界面说明中，如果定义今天和昨天？是过了12点还是如何？这个在界面说明可以稍微提一下，并没有太大问题。还有什么情况下是双向箭头？这个可以稍微说明一下。

当然这只是例子，不同的页面当然描述的就不一样，但都是描述我们能看得见的东西。

初次撰写需求文档，尽可能的把自己能看见的界面和元素，都尽可能的描述清楚细节，这样不仅让你的文档更加的细致丰满专业，且可以锻炼你严谨的产品思维。

界面说明讲完，接下来讲最最重要的逻辑说明。

逻辑说明是一个页面的重中之重，讲好了这个，再加上前面的流程等图串起来，一切都变得非常丰满了。

还是继续以机票浏览历史为例，本页面一眼看过去，似乎看不出什么逻辑。但仔细一想，感觉还是有点复杂，比如浏览历史如何产生？产生浏览历史是用户触发了什么？准确的说是点击了哪些页面导致触发生成浏览历史？生成了浏览历史后，这些浏览历史该怎么排序？如果浏览历史很多一页摆不下该怎么办？用户还能不能通过点击浏览历史，直接按照浏览历史的查询条件继续查询信息，比如我曾经浏览过了12月1日到5日的往返北京到广州的机票，这么一想问题又来了，如果用户可以点击再查询12月1日到5日的机票，但12月1日已经过去了，系统该怎么给用户查？系统不能查已经过去的机票啊，直接提示不给用户查？不合理啊，但如果能给用户查，就得分情况讨论了，一种是开始结束时间都在过去了，一种开始时间过去了结束时间没过去，emmmmmm,这么一想好像有点逻辑在里面。

脑子开始有点转不动了，没关系，先慢慢理清楚。

先把简单的能想到的逻辑先写出来。

比如比较简单的一些看得见的点击事件，如点击右上角“清空”按钮会弹窗出现确认是否清空的提示这一类的说明，排列是按照时间顺序先后排列，最近查询的记录会排在最前面，还有只记录最近三十天的浏览历史，再多不展示了等。

这些细节的东西都是自己想的还是从哪里来的呢？其实这些大部分都是看竞品怎么做，像这些比较多APP都在做的功能，不需要自己去想，只需要看看大部分市面上比较知名的APP即可，把这些你能想到的逻辑尽可能的用文字描述出来即可，但你不能跟程序员和测试人员说，你就照抄哪个那个APP的这个功能就行，这要你产品经理来干嘛呢，再说产品经理存在的一部分价值就是去调研并梳理这些逻辑形成图文信息，才能节省开发人员和其他团队成员的时间，更快的开发出相应的且符合用户体验的功能。

通过摸索我们知道了一些页面的逻辑，但有一些确实有点复杂，不太好说明，比如我前面提到的问题——点击查询历史记录可根据历史记录的条件进行再次查询，那如果这个查询条件已不再适用，比如我曾经查询昨天的日期，我现在继续点击，我该怎么办？

这就需要用到高中数学分类讨论的思想。

把所有问题都列出来，分类讨论，每种情况该怎么做，这个时候，我比较喜欢列表格，这样就更容易清晰易懂，比如如下表格以及文字说明：

1) 存在点击浏览历史中查询记录，但该历史记录的机票飞行时间已过期的情况，如果是单程查询记录，遇到日期过期情况，则把查询日期改为当天的日期，如果是往返程的情况，则往返程历史查询日期过期情况处理说明如下：

关于逻辑说明这部分，我们都只是尽可能的把自己能摸索到的和想到的逻辑描述出来，分点作答，不可能答得完整的，只能说在经验的积累过程中不停地提升自己这一块的能力，你只需要尽你所能详细的分点列出这些逻辑，当逻辑复杂不方便用纯文字的方式表述是，可以采用表格，当表格都不方便表述时，可以采用画图的方式。写需求文档的最终目的就是让看文档的人快速明白需求，文字、图表，哪种方便理解则使用哪种。

需求文档都是越写越快的，刚开始不熟悉会觉得好多逻辑要写，等你写多了你会觉得很多逻辑都是你曾经碰到过，自然就越写越快了。

以下为该案例需求的逻辑说明描述部分，供大家参考：

(一)处理逻辑：

1) 触发说明：

l 在“首页”点击“搜索”，成功进行搜索则视为触发历史记录成功；

l 在“服务大厅”点击“机票预订”，成功进行搜索则视为触发历史记录成功；

l 在“首页”点击“机票兑换”，成功进行搜索则视为触发历史记录成功；

l 在“我”→“我的里程”→“机票兑换”，成功进行搜索则视为触发历史记录成功，由于e行用户暂无开通机票兑换，则无法打开从而无法记录，后期打开仍然需要进行记录；

2) 查询范围为保留30天以内的查询数据；即从当前天数倒推30天以前，以天数为单位进行计算；加载方式为一次性全部加载所有记录，无需分页加载；

3) 查询排序方式为以最新的查询记录放在第一位，以最旧的查询记录放在最后一位；

4) 当历史查询记录为单程查询，则显示单方向箭头，当查询历史记录为往返程查询，则显示双向箭头方向，可查看上方图片显示方式；

5) 查询列表中的查询记录要以日期分割线来划分，划分规则为：以每天凌晨零点为分割，分割方式如上图，分割显示文案为如：12月30日；如果遇到当天则显示“今天”，遇到是昨天则显示为“昨天”，其他时间显示日期；

6) 对同一天同一“机票预订”查询结果进行去重；须满足所有查询条件都相同的情况下才进行去重处理，查询条件为：“去程日期”、“返程日期”、“出发地”、“目的地”“成人与儿童数量”五者条件均重复的情况下才进行去重处理。

7) 对同一天同一“机票兑换”查询结果进行去重，须满足所有查询条件相同的情况在才进行去重处理，查询条件为：‘’出发日期”、“返回日期”、“出发城市”、“到达城市”、“舱位”、“成人数量”；六者条件均重复的情况下进行去重处理；不对“机票预订”和“机票兑换”的结果进行去重处理；

8) 后期存在多程查询“机票预订”的情况，则需要对多程查询记录拆分为单程记录，把多程查询结果分为单程记录进行记录即可，排序方式也按照单程排列顺序由最新查询时间到最旧查询时间排序；

9) 点击任何一条查询记录，则认为是对该记录进行再一次查询，查询条件须与该历史查询记录一致，但存在查询时间过期的情况，如今天查询了当天的飞行航班，第二天再次点击该查询历史记录进行查询，但不存在查询昨天航班的情况，以下为对该情况的处理说明；

10) 存在点击浏览历史中查询记录，但该历史记录的机票飞行时间已过期的情况，如果是单程查询记录，遇到日期过期情况，则把查询日期改为当天的日期，如果是往返程的情况，则往返程历史查询日期过期情况处理说明如下：

11) 点击清空按钮，弹窗提示：提示语文案中文：提示——确定要清空历史记录吗？——取消(左边)；确定(右边)。点击确定则清空当前页面历史查询记录，点击取消则返回当前页面。

异常处理

关于此部分，不一定进行书写，在许多我写的需求文档中，都比较少撰写这一块，这一块若没信息可以空着不写。所谓异常处理，就是当后台系统发生一些错误信息会影响该页面的展示或逻辑等。

比如关于这片需求文档的异常处理我是这么描述的：

1) 当存在某条浏览历史记录获取失败时，则不显示该条浏览历史信息，当所有浏览历史信息都无法获取则显示缺省页面；不弹出任何错误提示。

即数据可能存在获取失败的情况，这个时候不要出现乱码不友好提示等信息，可以显示空白页，但别显示一堆乱码让用户看不懂，想表达的是这个意思。

异常处理这一块可以认为是对前面两块界面说明和逻辑说明的最后补充，把一些特殊出现的情况在这里表述。

接着就可以继续循环其他状态的页面了，同理可得，直到页面的所有状态写完为止。

总结一下

描述需求我们通过“基本流”的方式进行表述，基本流就像流水，会从许多入口流入到许多页面，页面还分许多状态，把所有状态的页面的界面说明、逻辑处理和异常处理都表述出来，就能很好的描述需求。

当然需求文档还是可以灵活变通，不一定按照这个格式，比如说有些页面虽然存在多种状态，但状态之间的差异性很小，就可以不用分状态的表述。

当要做到一点就是，要把所有可能出现的页面都贴图展示出来，自己在前期没法获取图片则需要找UI设计师配合出图，争取尽量减少不必要的沟通成本。

大家可以尝试动手去寻找到你喜欢的APP中的某个功能，比如浏览历史，比如足迹这些比较小的功能，然后研究它的页面和逻辑，设想一下加入这个页面是新增的功能需求，然后你需要出一份关于这个需求的需求文档，尝试动手按照我的流程撰写一下，你一定会收获很多。

本节主要讲解重要的部分，最后面还有一点点收尾留到下一期再讲解，谢谢大家。

未完，待续......