PRDFITLIFE小程序产品需求文档用户端Word文件下载.docx

1、二、产品结构1. 信息结构图2. 功能结构图由于完整结构图展开占很大的篇幅并且看不清楚，为了阅读体验，对结构图部分收缩。完整版结构图可在AXURE中查看。三、业务流程图建议将流程图统一整理至表格中，做成链接跳转形式，实现快速查阅。为了顺畅的需求阅读体验，将各自的流程图放在之后的需求描述部分中展示。四、全局说明1. 名词术语说明2. 权限弹窗3. 时间距离规范3.1 时间规范3.2 距离规范4. 异常情况4.1 网络异常手机网络连接异常，小程序弹窗提示如下：4.2 用户状态说明五、功能性需求说明良好的需求阅读体验需要保证阅读过程是顺畅的。在这部分，首先列出【需求清单】，总览这次需求涉及的模块及简

2、要信息。紧接着，按照【需求模块】-【流程图】-【原型页面流转】-【原型需求拆解】的叙述逻辑去完成各个模块的需求说明。1. 需求池&需求清单1.1 需求管理池需求来源：产品、运营、BOSS等等需求类型：新增需求、需求调整、功能优化、BUG修复、UI优化系统：涉及到的系统及模块需求说明：简述需求优先级判断：重要紧急、重要但不紧急、紧急但不重要、既不紧急也不重要（ps：我们要经常关注重要但不紧急的任务进度，避免重要紧急任务扎堆出现。）1.2 需求清单对需求管理池评估筛选后，将需求模块、对应功能、需求优先级、完成情况统一整理到表格中。同样的，这里将模块名称做成链接格式，快速查阅对应的需求模块。优先级规

3、范：p1、p2数字越小代表优先级越高。2. 新用户&首页模块2.1 新用户登录流程图2.2新用户登录原型（点击查看大图）2.3 首页3. 预约团课模块3.1 团课预约流程图3.2团课预约页面流转课程列表页3.3课程详情页3.4预约课程页4. 预约私教模块4.1 私教预约流程图4.2 私教预约页面流转4.3 私教列表页4.4 私教详情页4.5 私教预约页5 购卡模块5.1 购卡流程图5.2 购卡页面流程5.3 购买储值卡页面6. 我的模块（个人中心）6.1 个人页面6.2 修改资料6.3 我的卡包6.4 我的课程包6.5 我的优惠券6.6 富文本页面六、非功能性需求非功能性需求，是比较容易忽视的

4、部分，往往和性能、安全挂钩，影响着产品的稳定性与安全性。以下仅仅是例子，具体方案需要根据业务情况和产品特性与相关人员深入沟通。1. 性能需求响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。并发用户数：同时承载正常使用系统功能的用户数量。与性能相关的数据指标还有QPS（每秒响应请求数）、TPS（每秒处理的事务数）等。性能需求这部分仅仅是举个例子，具体情况和数据方案，需要和相关人员深入沟通。2. 可用性需求避免用户高频点击无反馈的情况。为用户提供反馈渠道。保持文案与组件的一致性。3. 数据统计需求产品初期需要一定基础的数据提供支持，

5、因此，除了小程序官方数据统计平台，再接入第三方统计平台，统计以下事件的数据及路径转化率。七、思考总结1. 内容细节流程图和页面流转图要整齐统一，实在太多信息，建议用子流程模块和多页面分述解决。见过很多像“蜘蛛网”一样的图，阅读体验比较糟糕。尽量让用户不用点开大图就能看清内容，本篇部分页面流转图和页面需求也难免遇到这类问题。异常逻辑和toast弹窗等细节需要加强把控，本篇这部分还是有所欠缺。2. 高保真or低保真？低保真线框图：重点在于功能、结构、流程的梳理，利用简单的框架和元素，省时省力；但细节相对高保真没这么完善，可能会有一定的沟通成本。高保真：针对于高层领导及投资人等，进行产品概念演示，视

6、觉效果好，细节相对完善；相当于是一个产品的demo，但修改成本较高。原型交互做的很酷炫，证明你对工具非常熟练。但如果为了做交互花费了大量的时间，就得考虑时间成本值不值得。如果能够用简单的注释和跳转，清晰表达交互逻辑，会不会省时省力一些？具体情况具体分析，比如，你做了很多交互，开发做漏了会说：“没写清楚啊，我怎么知道哪里可以点击呢？”因此，我的习惯是做简单的“交互逻辑+交互注释”，尽量避免复杂且耗时耗力的交互。当然，重要核心的交互逻辑，绘制出来比文字说明更容易理解。这时候，如果有现成的组件就套用，如果没有，就采用“图+文字+口述”的方式表达清楚。3. WORD？AXURE？需求文档用什么工具写比

7、较好？这是我见过比较多的产品话题讨论之一有用WORD的，有用AXURE的，还有用墨刀、石墨文档等等我曾经请教过两位分别使用WORD和AXURE撰写需求文档的朋友，他们是这样的看法：WORD选手：用word写，形式更规范。结构大纲清晰，细节到位。洋洋洒洒几十页，满足感杠杠滴。AXURE选手：用AXURE写，图+标注+交互，更直观地表达产品需求，阅读更顺畅。预览方便，支持上传云端同步。WORD写了也没人有耐心看，这个世界很浮躁啊。我的看法：需求文档是帮助传达及沟通需求的工具，讲究的是“可读性”。所以，在选择采用什么方式之前，需要和团队沟通达成共识，即什么样的方式能给到他们更好的阅读体验。我在实际工作中，采用的是AXURE，整理需求与线框图后与团队沟通，实现需求快速流转更新。但我会选择再用WORD梳理一遍，利用文字梳理大纲结构，整理产品逻辑和需求，能够发现某些疏漏的环节，完善产品细节。因此，用WORD写，是一个良好的查漏补缺的手段，是检视自身逻辑的过程。