| ||||||||||||||||||||||||||||||||||||
一、先固定「公司唯一标准」 统一一份需求文档模板（必须固定目录、格式、字体、标题样式） 统一业务术语（用户、会员、商品、订单、优惠券、支付、退款等） 统一字段命名（order_sn、user_id、pay_status、goods_id） 统一状态枚举（订单状态、支付状态、物流状态、售后状态） 统一核心业务规则（超时关闭、库存扣减、优惠券叠加、退款逻辑） 这 5 项统一 = 规范的基础。
二、需求文档必须包含的强制内容（缺一不可） 任何 B2C商城系统需求，必须有： 版本历史与变更记录 功能范围（做 / 不做） 业务流程图（正常 + 异常） 页面原型 字段 / 状态 / 枚举说明 业务规则（明确、量化） 对原有功能的影响 验收标准 少一项，就不符合规范。
三、写作必须遵守 3 条铁律 不使用模糊词 禁止：大概、可能、自动、应该、相应、合适。 所有规则必须量化 例：30 分钟未支付关闭，不是 “一段时间后关闭”。 所有交互必须明确 点击→跳转→提示→失败处理，全部写清楚。
四、建立「准入检查清单」 提交评审前必须勾选，不通过不允许进入评审： 使用公司模板 术语统一 字段 / 状态统一 有流程图 有原型 有业务规则 有验收标准 无歧义 有影响范围说明 有版本记录
五、三级审核机制（保证 100% 合规） 作者自检 产品负责人审核（规范 + 逻辑） 技术负责人审核（可行性 + 影响） 任何一级发现不符合规范，直接打回重写。 六、需求变更必须走规范流程 提交变更申请 评估影响（页面、逻辑、数据、兼容性） 审批通过 更新需求文档 + 提质版本 同步所有相关人员 禁止口头改需求、禁止私下改文档。
七、最终保障：写进制度 明确两点： 不符合公司规范的需求文档，研发有权拒绝研发。 未通过审核的需求，不能进入研发、测试、上线环节。 一句话终极总结 确保 B2C商城系统需求文档符合公司规范，就做 4 件事： 统一模板 + 统一术语规则 + 强制检查清单 + 三级审核 做到这 4 点，所有需求文档格式统一、内容完整、无歧义、100% 合规。 | ||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
|
