简介一份完整的APP产品需求说明书文档覆盖移动电商APP的功能定义、界面说明、使用流程与业务规则面向产品总监、设计人员、技术总监、项目经理、开发测试等相关角色可用于指导产品设计、开发排期与测试验收。文档以docx格式提供共1个文件大小2.08MB内容详细描述了系统架构手机客户端、PC端、服务器端以及前台首页、交易大厅、专场、业务中心等核心模块包含图片轮播、业务提醒、会员登录、新闻公告、竞买公告等具体功能设计同时明确了买卖双方会员在业务中心的处理流程并注明支付、合同异议功能需在PC端完成。目前已有476人学习下载适合需要编写规范化APP需求文档的产品经理、项目负责人及需求分析人员可参考其清晰的章节组织、功能描述方法和业务规则梳理方式直接套用于同类项目提升文档的专业性与可落地性。1. 从需求说明书到可执行方案这个APP的核心约束在哪里我拿到这份APP产品需求说明书.docx时第一反应是“怎么全是页面描述”。但读完几页后有一个强烈的判断这份需求文档的价值不在于描述首页长什么样而在于它划出了一条业务边界——手机端不支持支付、不支持订单合同异议所有交易闭环都落在PC端。换句话说这个移动商城APP是一个“信息浏览业务处理入口”不是完整电商终端。这个定位决定了整个技术方案的分工手机端负责公告、挂牌、询价、下单触发PC端负责支付、合同、异议服务器端负责数据与状态。读者如果是产品、开发或测试建议先记住这条边界再去看那些“点击按钮跳转”的描述。后面所有的导航结构、字段约束、购买流程都是在这条边界内展开的。说白了这份docx是给三方评审用的不是给前端照着画页面的。2. 拆解首页与交易大厅功能树、导航状态与定向挂牌可见性这一章把需求文档里的“页面描述”翻译成功能树和规则。首页和交易大厅是整个APP的流量入口也是信息架构最密集的部分。开发团队如果直接按顺序开发页面很容易漏掉“后台维护轮播图”“搜索历史数量上限”“定向挂牌不可见”这类细粒度规则。2.1 五个导航模块背后的角色与状态文档中提到底部浮动导航有五个模块首页、交易大厅、专场、业务中心、更多。其中业务中心需要登录其余模块允许未登录用户浏览。这个“未登录可浏览、登录后可操作”的模型是移动端资讯类APP的标准结构。整理成一张表方便开发排期也能帮助测试写用例。模块允许角色核心行为特殊状态首页未登录、企业会员浏览公告、轮播图、查看最近4条新闻登录后业务中心显示红点交易大厅未登录、企业会员查看挂牌列表、搜索、高级搜索、排序定向挂牌对非定向会员不可见专场未登录、企业会员查看推荐专场、供应商专场供应商信息中可进入专场业务中心仅登录会员验货、验票、评价、生成二维码有代办时导航角标红点更多所有角色扩展入口无特殊状态这个表直接映射到路由和权限中间件。注意导航模块在未登录时点击“业务中心”会先跳登录页而不是弹窗拒绝这是文档里明确写的事件流。如果测试人员只看界面可能会漏掉这个跳转逻辑。2.2 搜索与高级搜索的输入约束文档对搜索框的描述很具体只可搜索品名模糊匹配下拉搜索框为半透明显示最近8次搜索历史下方有清空历史选项高级搜索包含品名、供应商、存货地、价格区间、出价方式。这里没有提到对“规格”“材质”的搜索说明这个版本的商品搜索是按品名维度做的后端索引只需要覆盖品名字段。搜索历史在客户端本地保留一般可以像下面这样用一个有序数组来维持8条。const history []; function pushSearchHistory(keyword) { if (!keyword.trim()) return; const idx history.indexOf(keyword); if (idx ! -1) history.splice(idx, 1); history.unshift(keyword); if (history.length 8) history.pop(); }逻辑说明先判断空串再查重重复的提到最前超过8条从尾部移除。这样既能满足“最近8次”的要求也避免用户在搜索历史里看到重复项。注意搜索历史不需要同步到服务端但如果要做多端同步就要改成服务端存储并补充一个用户行为表另外还要处理“清空历史”这个操作客户端删除本地记录即可。高级搜索里的“存货地”是级联选择点击弹层收回。后端请求参数可以直接拼成GET参数例如GET /api/listed-goods?keyword螺纹钢supplierxxxlocation上海minPrice3000maxPrice4000priceMode1这里的priceMode可以用枚举0一口价1可洽谈。注意“出价方式”在文档中属于高级搜索条件但在挂牌列表字段里也展示所以查询参数和返回字段要做明确对应避免前端传了priceMode但后端没使用导致筛选失效。2.3 挂牌列表排序与定向挂牌可见性文档中有两个排序维度一是系统默认按发布时间逆序排列二是用户可点击时间、价格、信用三个标签按钮再次点击切换升降序。这里要注意“信用”排序指的是供应商信用等级不是商品库存。后端排序字段需要映射成枚举避免前端传字符串直接拼SQL比如只允许传sorttime|price|credit和orderasc|desc。更关键的是定向挂牌的可见性规则“定向挂牌的信息只有定向会员才能查看未登录用户或非定向会员不显示。”这意味着列表查询必须拿到当前登录会员的ID和定向关系表。如果只是前端隐藏抓包就能看到数据相当于泄露了定向挂牌信息。所以后端必须做过滤。常用的SQL写法是SELECT g.id, g.name, g.price, g.supplier, g.credit_level FROM listed_goods g WHERE g.target_flag 0 OR (g.target_flag 1 AND EXISTS ( SELECT 1 FROM target_member t WHERE t.goods_id g.id AND t.member_id #{currentMemberId} )) ORDER BY g.publish_time DESC;说明target_flag0是非定向target_flag1是定向。定向商品必须通过EXISTS子查询判断当前会员是否在定向名单里。未登录用户的memberId传nullEXISTS条件自然为false因此定向商品不会出现在结果集中。这条SQL看起来简单但实际优化时要注意索引target_member表建议建复合索引(goods_id, member_id)否则列表页数据量一大就会慢。这个逻辑容易漏在测试点里。建议测试时至少覆盖四类账号未登录、普通会员、定向会员、非定向会员。定向会员应该看到该商品非定向会员不应看到且直接请求详情接口也应返回无权限。还有一类情况是会员已登录但没有交易权限他可能看得到挂牌信息但购买时会被拦截这部分放在第3章讲。3. 挂牌详情与购买流程字段建模、浮动操作栏与比例计算这一章进入交易环节。挂牌详情页是用户做决策的核心页面字段多、交互复杂也是开发最容易产生歧义的地方。文档里还把“浮动购买栏”单独做了说明明确滑动详情页时该栏不动。这是典型的下拉刷新与悬停交互的组合前端需要用悬浮容器实现而不能放在列表滚动区域内。3.1 详情页四标签页的信息分组逻辑文档要求详情页最上方显示品名和价格价格要醒目。下面是四个标签页商品信息、商品描述、交收信息、供应商信息页面可以左右滑动。这个结构等价于一个PagerAdapter加四个Fragment业务字段要按组拆开不能全塞一个JSON里不然前端拿到数据也难切分。整理字段列表标签页字段商品信息品种、品名、规格、材质、挂牌重量、起订量、可购买量、存货地、厂家、生产日期、批号、质量标准商品描述详细描述内容交收信息交收方式、配送方式、结算方式、验货后付款比例、验票后付款比例、保证金方式、支付保证金比例或额度、保证金截止日、付款截止日、发货截止日、验货截止日、验票截止日、存货地供应商信息供应商、联系人、联系电话、联系地址这个清单可以直接作为详情接口的DTO字段。注意同一个“存货地”在商品信息和交收信息里都出现但含义不同一个是库存所在地一个是交收起止地。开发时字段名要区分比如stockLocation和deliveryLocation避免混淆。另外验货截止日和验票截止日要明确是时间戳还是日期字符串建议统一成时间戳避免时区问题。3.2 交收信息里的下拉框与自动计算规则文档特别提到交收方式、配送方式、结算方式是下拉框形式选择后收回。保证金方式决定保证金比例或额度的单位和显示比如百分比显示“%”固定金额显示“元/次”。这里的“支付保证金比例或额度”要跟着保证金方式联动如果选择比例方式输入框单位显示“%”最大100如果选择固定额度单位显示“元/次”无上限。最关键的规则是“填写验货后付款比例自动生成验票后付款比例两者相加为1。”这句话在开发时容易被误读为两个输入框需要用户自己填实际上只需要填一个另一个自动生成。前端应该监听验货后付款比例的输入事件实时计算验票比例。function confirmInspectRatio(el) { let ratio parseFloat(el.value); if (isNaN(ratio)) return; if (ratio 0 || ratio 1) { showToast(比例必须在0到1之间); el.value ; return; } const checkRatio 1 - ratio; document.getElementById(checkRatio).value checkRatio.toFixed(2); }参数说明el是验货后付款比例的输入框ratio取浮点数后先做边界校验如果不合法直接清空并提示checkRatio是验票后付款比例保留两位小数。后端在保存时也必须校验两个比例之和为1不能只依赖前端。因为接口可以被直接调用绕过前端输入的伪造数据很容易。我见过一个项目忽略了后端校验用户提交0.7和0.4的数据导致付款比例加起来超过1结算时对不上账。另外还要注意文档要求“填写验货后付款比例自动生成验票后付款比例”说明验票比例是只读的前端要给输入框加上readonly属性。但UI上不能让它看起来像一个死字段要做到用户刚输入完旁边立刻更新体验才自然。3.3 一口价购买与洽谈的条件判断文档列出三个购买相关的事件未登录点击一口价跳转登录已登录非交易会员弹窗提示购买成功跳转“全部订单”页。洽谈按钮只在非一口价商品下出现。这说明购买操作需要后端做两类判断鉴权条件和定价条件。我建议在后端直接把条件判断写成一个函数function canPurchase(member, goods) { if (!member) return { code: 401, action: redirect, target: /login }; if (!member.tradePermission) return { code: 403, action: toast, message: 您还不是交易会员不能进行现货交易请登录网站了解详情 }; if (goods.priceMode ! fixed) return { code: 400, action: toast, message: 该商品不支持一口价 }; return { code: 200, action: continue }; }这里重点是action字段前端拿到401做路由跳转拿到403只弹toast避免把每个错误都写成跳转或者都在前端判断。文档里没有写具体HTTP状态码但按RESTful习惯可以这样约定。另外洽谈按钮的显示条件是商品出价方式是“可洽谈”所以清单接口必须把priceMode字段返回给前端前端根据这个值决定是否渲染洽谈按钮。还有一个隐藏的规则购买量字段在浮动栏中用户先输入购买量再点按钮。后端要校验购买量是否在可购买量范围内且不能小于起订量。需求文档没有明确写但基于通用逻辑是必须的。我一般会在下单接口让前端同时传quantity和goodsId后端校验库存避免并发超卖。4. 业务中心与PC端分工支付、异议为什么被砍掉看过需求的人都会注意到文档反复强调手机端不支持支付、不支持订单合同异议需要去PC端处理。这个“砍掉”不是设计倒退而是业务风险控制。支付涉及资金安全异议涉及法律纠纷移动端仅作为入口这两块功能如果强行搬到手机端要投入的合规成本和前端复杂度会成倍增加。4.1 手机端与PC端的功能边界功能手机端PC端说明支付不支持支持避免移动端支付合规风险和数据篡改订单/合同异议不支持支持异议流程需要上传证据PC端操作更完整验货/验票支持支持手机端可扫码确认PC端可批量操作评价支持支持两端同一套评价体系生成二维码支持支持用于线下提货或交收这个分界意味着手机端的业务中心只是一个“事务受理”界面真正完成资金流转和争议仲裁靠PC端。开发团队在设计接口时手机端只需要调用订单状态查询和提交操作的API而PC端需要调用支付渠道接口、合同生成、异议工单维护等。两端共用一套订单状态字段最好比如持有订单状态枚举待付款、待发货、待验货、待验票、已完成、异议中。这样手机端展示状态和PC端处理状态是一份数据不会出现两端状态不同步的扯皮问题。4.2 业务中心的操作边界与二维码文档写明买方在业务中心可以验货、验票、评价、将提单生成二维码卖方可以发货、评价、将提单生成二维码。这里的“提单”是交易标的二维码应该是扫码后能看到提单号和状态用于线下物流交接。我一般会这样设计二维码不直接在二维码里嵌入完整提单数据只存一个临时token服务端扫码后返回提单详情。这样二维码可设失效时间避免长期有效导致的信息泄露。接口大致是POST /api/bill/qrcode Authorization: Bearer token { billId: 12345, expireMinutes: 30 }说明billId是提单IDexpireMinutes设置二维码有效期。生成的二维码内容是一个URL或加密字符串扫码端解析后请求服务端校验。这个设计的好处是二维码不包含业务数据抓包也只能拿到一串无效token。如果二维码直接包含提单号别人捡到手机拍个照就能伪造收货。还有一个细节验货和验票是买方操作发货是卖方操作。这些操作都需要在服务端记录操作人和操作时间。文档里“评价”没有细化星级和内容但至少要有评价状态比如未评价、已评价、追评否则订单完成后无法判断评价是否遗漏。4.3 前后端状态通知与待办红点首页的业务提醒规则是会员登录后如果业务中心有待办事项导航模块右上角显示小红点。这里有两个实现点一是待办事项的列表来源二是红点的触发时机。待办事项可以在服务端保存一个待办表业务中心有单据状态变化时插入一条待办。推荐做法是提供聚合接口一次性返回待办数量和摘要GET /api/todo/count响应示例{ code: 0, data: { count: 5, items: [ { type: verify, billId: 1024, message: 您有1笔提单待验货 } ] } }前端在APP启动、登录成功、从后台切回前台时请求这个接口拿到count大于0就点亮红点。红点的清除时机要和服务端已读标记联动不能只看本地操作否则用户换了设备红点状态是错的。文档里“业务中心”导航处显示红点正确的后端语义是“存在至少一条未读待办”所以需要给待办表加已读标记字段比如read_flag当业务中心列表页被打开且用户浏览过后把该会员的待办批量置为已读。5. 把需求说明书变成可评审的技术方案字段级核对与状态流校验三步法每次产品丢来一份类似docx的需求我一般不会先看界面设计而是直接用三步把文档翻译成技术方案。这个章节分享这个做法。第一步是字段级核对。把文档中出现过的所有字段列成一张表加上“列表展示”“详情展示”“搜索条件”“提交参数”四个维度逐行打勾。比如品名在列表、详情、搜索里都出现供应商在列表、高级搜索、供应商信息里都有生产日期只出现在商品信息里。这个表做出来后前后端接口字段基本不会漏测试用例也能按字段分组。第二步是事件流补全。需求文档的事件流写的是“正常路径”比如点击购买跳转订单。但开发要处理异常分支像未登录、非交易会员、库存不足、黑白名单等。可以做一个简单状态机未登录购买 - 登录页已登录无权限 - 弹窗有权限库存不足 - 提示修改数量成功 - 跳转全部订单。这个状态机不是空想而是把文档里的“备选流”扩展成可测试的用例。具体到写代码时每个节点都能对应一个if-else或switch分支。第三步是权限矩阵检查。把角色和操作对应起来例如未登录用户只能看公告和挂牌列表不能点购买企业会员有交易权限才能购买定向挂牌对非定向会员不可见。把这张矩阵放到合同评审会上产品、开发、测试三方一起逐格签字能减少大量上线后的权限Bug。我见过一个APP因为权限矩阵没核对导致普通会员通过修改请求参数直接看到了定向挂牌的价格问题持续了两周才发现。这三步执行完之后我会把清单分别命名成field_checklist.md、state_machine.md、permission_matrix.md随需求文档一并归档后续任何人变更功能都先改这三份文件再改代码。本文还有配套的精品资源点击获取