需求澄清结论 第5组 - xiaochu-dev/online-shopping-group5 GitHub Wiki

第 5 组 · 需求澄清访谈结论(MVP)

项目:在线购物系统(挑战升级)|版本:MVP 基线
访谈对象:课程助教(需求方)|主问:周到(PM)
记录日期:2026-10-04 | 来源:访谈逐条回答
性质:这是本组开发与验收的依据文档,与课程 Wiki「需求澄清记录」页内容一致


一、商品与上架规则

  • 同一时间在售商品只有一件。卖完、或卖家手动下架之后,才能发布下一件。
  • 下一件不自动上架。系统没有自动补位逻辑,必须由卖家手动进后台重新发布。
  • 基线里"卖掉一个再制作一个"的含义:卖家自己做一件挂上去,卖掉后再手动发下一件;"制作/发布"全程是卖家手动动作。
  • 系统只负责状态流转(冻结、撤下等),不负责补货。

二、商品字段与边界

商品字段共 4 项:名称、描述、图片、价格。

字段 必填 限制
名称 ✅ 必填 不卡字数
描述 ❌ 选填 不卡字数,可留空
图片 ❌ 选填 缺省放占位图;最多 1 张主图;JPG / PNG;单张 ≤ 5MB,超出给提示
价格 ✅ 必填 必须 > 0(不能标 0 元);人民币;保留两位小数(如 9.90)
  • 名称、描述不设字数上限。
  • 描述留空、图片不传都允许。

三、卖家账号

  • 只有一个卖家账号,是系统里唯一的,不是买家那种临时注册出来的。
  • 形式:用户名 + 密码。
  • 账号初始化方式由实现方自定(助教不约束统一给还是自己建),唯一要求:有一个卖家账号、能凭用户名密码登录。
  • 必须登录才能进后台。发布、冻结、查看意向购买人等操作都需先登录。
  • 改密码:需先验证原密码;新密码至少 8 位。
  • 「退出登录」本版本不做。

四、买家信息

  • 仅 2 项:姓名、联系电话,都必填。
  • 不做格式校验(填什么系统都收)。
  • 同一号码可反复购买:不注册、不建账号,每次提交都是独立意向,各有各的口令码,系统不按号码去重/拦截。

五、意向、排队与撤销

  • 规则:严格先到先得,按意向提交时间排序。
  • 只有有效意向才进队列。
  • 队列可挂多人(不是只能一个)。
  • 同一时间真正进入交易(线下谈)的只有排最前面的那一个(因为只有一件商品)。
  • 前面那个交易失败后,后面的人依次递补上来。
  • 买家可撤销自己的意向:凭提交时系统给的口令码操作。
  • 撤销后该买家从队列移出,后面的人位次自动往前顶。

六、商品冻结与恢复

冻结有两条路径,走的是同一个状态:

路径 触发方式
自动冻结 商品一进入交易(卖家选定跟某人线下谈时)系统自动把「在售」→「已冻结」
手动冻结 卖家在后台手动冻结
  • 手动冻结与自动冻结是同一个"已冻结"状态,不区分。
  • 冻结期间:
    • 不再接受新的购买意向,买家点「我要买」看到「商品交易中」提示;
    • 商品买家仍可见,但买不了、也提不了意向。
  • 恢复上线:
    • 交易成败由卖家线下谈完后到后台手动标记「成功」/「失败」;
    • 标记「失败」→ 商品恢复在售、重新上线;若队列还有排队的人,按顺序递补进来。
    • 系统不自行判定交易结果。
  • 交易进行中卖家也可手动解冻:后台有冻结/解冻开关。

七、交易结果与历史记录

  • 成交/失败只能由卖家在后台标记,买家侧无此入口。
  • 没有超时自动判失败的机制。成败由卖家线下谈完后自行判断、自行标记(一手交钱一手交货)。
  • 系统不参与判定,也不会自动超时判定。
  • 成交后商品撤下,但历史记录保留。

历史记录至少保留:

层级 保留字段
商品级 商品名称、描述、图片、价格、发布时间、最终交易结果(成功/失败)、交易时间
意向人级 每个商品可点进去看意向购买人列表:姓名、联系电话、意向提交时间、每人对应的交易结果
  • 历史记录按时间倒序排列,支持翻页。

八、范围与验收

  • 终端范围:仅 Web 网页端。Android / iOS / 微信小程序不在本版本范围内。
  • 评价功能:不做。
  • 「必做/选做如何划分、验收标准谁定」——助教答复:超出需求讨论范围,需求方只负责聊产品需求。
    → 因此这两项由课程文档(系统验收标准.md)与本组自行定义,不在本澄清结论内。

九、待办与影响

# 事项 说明
1 核对课程 Wiki 去「需求澄清记录」页确认第5组条目已记上、且与本文件一致
2 回填需求规格说明书 本文件结论 → 正式需求条目
3 回填 Product Backlog 每条需求配验收标准
4 验收标准自行定义 助教不提供,需本组对照 系统验收标准.md 自拟
5 口令码机制待细化 「提交时生成口令码、凭码撤销」的生成与校验规则需在设计阶段定
6 递补逻辑需覆盖 撤销、交易失败两种触发都要能正确重排队列

本文件由产品经理(周到)整理,作为本组需求基线。后续变更在此追加「变更记录」。