需求确认不只是清单
电商项目启动时，团队往往急于梳理功能列表，却忽略了功能背后的使用场景。需求确认的本质，是让开发方理解业务逻辑，而不只是记录页面数量。
很多项目后期返工，都源于前期对细节的模糊描述。明确“谁在用、怎么用、为什么用”，比单纯罗列功能更重要。
五个容易被忽略的确认细节
1. 商品规格与库存逻辑
多规格商品（如颜色、尺寸）的组合库存如何计算？是否支持不同规格不同价格？这些规则直接影响后台设计，建议在需求文档中单独列出。
2. 订单状态流转节点
从下单到收货，中间包含付款、发货、售后等多个状态。每个状态由谁触发、是否发送通知、用户能否取消，都需要明确。
3. 营销工具的叠加规则
优惠券、满减、会员折扣同时使用时，优先级如何计算？叠加顺序不同，最终成交价差异很大，建议提前用表格模拟几种组合。
4. 未登录用户的购物车
用户未登录时加入购物车的商品，登录后能否保留？跨设备访问时购物车数据是否同步？这关系到用户体验和数据库设计。
5. 后台权限的细粒度划分
运营、客服、财务人员需要看到的数据范围不同。如果所有账号权限一致，后续数据安全和管理效率都会出问题。
核心要点
- 需求确认要聚焦使用场景，而非功能数量
- 库存、订单、营销规则需用具体案例验证
- 权限设计需提前规划，避免后期重构
- 购物车逻辑影响用户转化，需明确数据同步策略
- 所有规则确认后，应形成书面文档并签字确认
常见问题
问题：需求确认阶段需要开发方参与吗？
需要。开发人员能从技术实现角度提出潜在风险，比如第三方接口限制、数据量预估等。提前沟通可以避免方案无法落地的情况。
问题：需求文档做到什么程度算合格？
至少包含角色说明、操作流程、异常处理、页面字段说明。每个功能点都要有明确的输入、处理和输出描述。
总结
电商项目上线前的需求确认，决定后续开发效率与运营成本。建议预留充足时间讨论上述细节，并用书面文档固定结论。
项目启动后，任何需求变更都会产生连锁成本。前期多花一天确认细节，后期可能节省一周的返工时间。