• 报告期次：第1次 ｜ 报告日期：2026-10-08 ｜ 项目组号：第5组 ｜ 项目名称：在线购物系统（挑战升级）

• 已完成工作：组织需求澄清访谈（访谈对象：课程助教），整理澄清结论 9 节并形成需求基线

• 成果物：第 5 组 · 需求澄清访谈结论（MVP）

• 已完成工作：编写《需求规格说明书》v1.0（8 项 FR、6 条 NFR、14 条验收清单、需求追溯矩阵）

• 成果物：在线购物系统 需求规格说明书

• 已完成工作：编制 Product Backlog（27 条特性/71 故事点，v1.1 修正汇总口径）

• 成果物：在线购物系统 产品订单（Product Backlog）

• 已完成工作：口令码、队列与冻结模块开发（FR-04/06）：口令码生成与撤销、正序排队、失败自动递补、冻结/解冻，及口令码规则文档

• 成果物：口令码与队列规则说明

• 已完成工作：交叉测试：以 14 条验收清单对胡成溯后台模块执行交叉测试（零缺陷），产出测试记录

• 成果物：第1次测试记录（交叉测试）

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

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

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

• 名称、描述不设字数上限。
• 描述留空、图片不传都允许。

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

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

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

冻结有两条路径，走的是同一个状态：

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

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

历史记录至少保留：

• 历史记录按时间倒序排列，支持翻页。

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

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

文档说明：本文件描述 MVP 版本的功能需求，作为本组开发、测试与验收的依据。 需求条目中的规则均来自 2026-10-04 的需求澄清访谈结论，未经澄清的假设一律标注为「待确认」。

明确 MVP 版本的功能范围、业务规则与验收依据，供开发、测试、评审三方使用。

本课程项目采用「挑战升级」组织方式：所有项目组在统一基线需求之上，于 7 次迭代中逐步增加功能。本次为第 1 次迭代，目标是交付可运行的基线 MVP 原型。

• 《课程导论》——项目主题与基线需求来源
• 课程 Wiki《系统验收标准》——五方面验收要求
• 课程 Wiki《阶段性评审 (I)》——报告与提交规范
• 《需求澄清结论-第5组》——本组需求澄清访谈结果（2026-10-04）

⚠️ 本版本无买家账号体系，买家身份不具备持久性，每次提交意向都是独立记录。

① 卖家登录后台
      ↓
② 卖家发布商品（名称·描述·图片·价格）
      ↓
③ 商品进入「在售」状态，买家可见
      ↓
④ 买家浏览商品 → 填写姓名、电话 → 提交购买意向
      ↓
⑤ 系统生成口令码并显示给买家；意向按提交时间进入队列
      ↓
⑥ 卖家查看意向购买人列表，选定一位进行线下交易
      ↓
⑦ 商品自动转为「已冻结」；队列后位者仍排队但不可进入交易
      ↓
⑧ 卖家线下谈完后回后台标记结果
      ↓
   ┌────────────┴────────────┐
 标记「成功」               标记「失败」
   ↓                          ↓
商品撤下，进入历史         商品恢复「在售」，重新上线
（保留完整记录）                 ↓
                          队列后一位自动递补进入交易

买家凭口令码发起撤销
      ↓
该意向从队列中移出
      ↓
队列中后于它的意向位次自动前移（顺位递补）
      ↓
商品状态不变（仍为「在售」或「已冻结」，取决于撤销发生在何时）

商品状态值共 3 个，语义状态显式列为 4 个——「已恢复在售」为语义标签，库中复用 on_sale 状态值：

状态流转图：

              卖家发布
                 ↓
              ┌──────┐
              │ 在售 │ ←────────────┐
              └──────┘              │
                 │ ↑                │ 标记「失败」
    进入交易（系统自动）              │ 或手动解冻
      或卖家手动冻结                  │
                 ↓ │                │
              ┌──────┐              │
              │已冻结│──────────────┘
              └──────┘
                 │
                 │ 标记「成功」
                 │ 或卖家手动下架
                 ↓
              ┌──────┐
              │已下架│（终态）
              └──────┘

关键规则：自动冻结（进入交易时）与手动冻结是同一个状态，不做区分。 恢复路径显式化：流转图中「标记失败 / 手动解冻 → 在售」的回路即**「已恢复在售」**语义态——库中复用 on_sale，仅语义上区分「经历过冻结的商品重新在售」。

描述：系统内仅有一个卖家账号，卖家须登录后才能进入后台执行任何操作。

优先级：高（阻塞后续全部后台功能）

描述：卖家在后台发布商品，填写 4 项商品信息。

商品字段规格：

优先级：高

⚠️ 待确认：FR-02-8「发布后不可修改」是基于澄清结论「未提及修改」的推断，建议在第 2 次评审前与助教复核。

描述：买家浏览在售商品，填写信息提交购买意向。

优先级：高

描述：多名买家同时有意向时，按队列规则管理。

优先级：高（逻辑复杂度最高，需重点测试）

✅ 已于 v1.1 定义：口令码的生成算法、存储方式、校验规则与失效规则见 FR-04-8 ~ FR-04-10，设计细节见 Wiki《口令码与队列规则说明》（设计定义与代码实现一一对应）。

描述：卖家登录后可查看当前商品的意向购买人列表。

优先级：高

描述：商品进入交易或卖家主动操作时冻结，冻结期间不接收新意向。

优先级：高

描述：线下交易完成后，卖家回后台标记结果。

优先级：高

描述：商品成交或下架后，保留可查询的历史记录。

优先级：中（不影响主流程，但属于基线要求）

⚠️ 待确认：FR-08-2「按时间倒序」中的"时间"指发布时间还是交易时间，澄清未明确。默认采用交易时间，如需调整请确认。

对照课程《系统验收标准》五方面：

MVP 功能验收清单（逐条核对）：

本文件为第 5 组 MVP 版本需求基线，后续迭代在此文件基础上增补需求章节。

文档说明：产品订单（Product Backlog）是项目的概要文档，包含所有特性的粗略描述与估算。
本文件覆盖 MVP 迭代的完整需求池；后续迭代的新增特性在此表末尾追加，不删除历史条目。

故事点估算：采用斐波那契数列（1 / 2 / 3 / 5 / 8），表示相对工作量，非工时。

说明：A-2 为 P1——不影响主流程演示，但属于基线明确要求，应完成。本版本不做退出登录。

⚠️ 设计前置：D-2~D-5 依赖口令码机制与队列位次算法，须先出设计说明再编码。此项为本迭代技术风险最高的模块。

⚠️ PM 的故事点偏高（31/71 ≈ 44%）。原因：认领的队列与冻结是逻辑最复杂的两个模块，本身故事点虚高，且属首次实现。
建议：编码阶段若进度吃紧，优先保 D-1/D-3/D-4（队列基础能力），D-5（失败递补）可与 G-2 合并调试。
若仍需平衡，可将 B-3（图片校验）或 H-3（历史意向人）从黄程宇处划转给组长。

三人组、两周迭代（10/4 – 10/8 为首次交付窗口，之后每两周一次）。

本次交付窗口的冲刺订单（Sprint Backlog）应只圈 P0 条目：

决策建议：以「主流程能完整演示一遍」为交付底线。即：卖家登录 → 发布商品 → 买家提交意向 → 查看意向人 → 进入交易冻结 → 标记成功/失败 → 历史记录。这条链路上的 P0 条目一条都不能缺。

迭代目标：交付在线购物系统 MVP 基线版本，实现「单商品售卖」的完整业务闭环。

具体到功能需求点，本次迭代需达成以下 8 项：

1. 卖家可凭账号密码登录后台（FR-01）
2. 卖家可发布商品，同一时间仅一件在售（FR-02）
3. 买家无需注册即可浏览商品并提交意向，获得口令码（FR-03）
4. 意向按提交时间先到先得排队，仅队首可进入交易（FR-04）
5. 卖家可查看意向购买人列表并选定交易对象（FR-05）
6. 商品进入交易自动冻结，冻结期不收新意向（FR-06）
7. 卖家可标记交易成功/失败，失败后商品恢复并递补（FR-07）
8. 历史商品记录完整保留并可翻页查询（FR-08）

可度量的验收依据：见《需求规格说明书-第5组》第 6 章「MVP 功能验收清单」14 条。

以下为基线之外、留待后续迭代排入的候选特性（本次不做）：

本文件由产品负责人周到维护（Product Backlog、需求规格说明书、验收标准均由其负责）。每次迭代评审后，在此表追加新增特性并重新排序优先级，不删除历史条目。

文档说明：本文档是 FR-04 需求条目中标注「待细化」内容的正式设计定义， 与 services_state.py 现有实现一一对应，供评审老师对照代码查验。

以上规则的自动化验证见 卖家后台/test_d_module.py（D-1D-5、F-1F-5 共 10 项边界用例）， 运行方式：python test_d_module.py，期望输出 周到模块自测：10 通过 / 0 失败。

闭环互测规则：周到测胡成溯。此前 test_smoke 30/30、test_b_module 18/18、test_d_module 10/10 均已通过； 本次交叉测试为独立视角，按 14 条验收清单重新逐条对照，不重复已有测试。

汇总：14 通过 / 0 失败（共 14 项）。

测试说明：本次交叉测试按 14 条验收清单逐条独立设计场景（含撤销顺位前移、递补两分支、6 条历史翻页、改密回滚等此前用例未覆盖的组合路径），被测代码 main.py / auth.py 未做任何修改，全部一次通过。

本次交叉测试（周到 → 胡成溯，卖家后台 FR-01/05/07/08）全部 14 条验收项一次通过，未发现缺陷。被测模块的登录鉴权、意向人管理、交易结果标记（含递补两分支）、历史记录（含分页与两级字段）均符合《需求规格说明书》第 6 章验收标准。测试后回归运行 test_smoke.py，结果 30/30 无回归。

1. FR-06-6 与实现口径不一致（建议需求侧确认）：SRS FR-06-6 字面为「卖家在交易进行中亦可手动解冻」，而实现约定交易进行中禁止解冻（services_state.py 的 unfreeze_product 主动拦截，代码中有设计说明：防止破坏「仅队首进入交易」的队列语义），本次交叉测试按实现口径验证通过。该行为更稳妥，但属于对需求条目字面的偏离，建议在第 2 次评审前与助教确认，并在 SRS 中补一条修订记录。
2. 历史记录「倒序」时间字段：当前按交易时间（traded_at）倒序，与 SRS 第 8 章「待确认事项 #3」的暂定方案一致，待需求方正式确认。
3. 建议下轮迭代补齐交易中禁止解冻这一约束在后台界面上的前置提示（当前为操作后报错提示，体验上可提前 disabled 置灰——后台已有 disabled 处理，属锦上添花项）。

尾注：测试脚本 test_cross_review.py 已入库（卖家后台目录），执行 python test_cross_review.py 可复跑复现；测试库写入系统临时目录，不污染交付数据；改密用例测完自动改回 admin12345。

（评审后填写）