网站建设心得感想,wordpress随机切换主页内容,wordpress po翻译,华为模板建站接着上篇继续写#xff0c;上篇请点击标准的产品需求文档在这里#xff01;(详细说明版)(1)入口已经写完#xff0c;读此文档的无论是研发人员还是测试都已经知晓此需求需要做的从哪里进入#xff0c;接下来就是主菜了#xff0c;进入以后该干嘛。进入以后当然就是新的页面… 接着上篇继续写上篇请点击标准的产品需求文档在这里(详细说明版)(1)入口已经写完读此文档的无论是研发人员还是测试都已经知晓此需求需要做的从哪里进入接下来就是主菜了进入以后该干嘛。进入以后当然就是新的页面或者是在旧页面基础上进行修改。那到底该如何专业的描述一个页面的需求呢从三个方面1. 页面说明2. 逻辑处理3. 异常处理。首先要明白一个页面有多少种状态因为一般来说页面都是有交互比如浏览历史的页面它可能有多个状态比如下面为携程的浏览历史的页面有多个状态此处只选取3个供大家理解。(点击查看大图)所以一般情况下浏览历史有多种状态分别是交通浏览历史、酒店浏览历史和全部浏览历史都是通过头部点击下拉然后进行选择切换的我们就需要对每种状态进行描述。我们已经知道了前面我们写入口的时候是3.1.4.1那么假设浏览历史有三种状态我们这个时候就可以预想到应该有3.1.4.2到3.1.4.4这三个页面需要描述。3.1.4.1入口3.1.4.2交通浏览历史3.1.4.3酒店浏览历史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中的某个功能比如浏览历史比如足迹这些比较小的功能然后研究它的页面和逻辑设想一下加入这个页面是新增的功能需求然后你需要出一份关于这个需求的需求文档尝试动手按照我的流程撰写一下你一定会收获很多。本节主要讲解重要的部分最后面还有一点点收尾留到下一期再讲解谢谢大家。未完待续......
