Repository navigation
SRS
| 项目 | 内容 |
|---|---|
| 文档名称 | 在线购物系统（最小可行产品）需求规格说明书（SRS） |
| 版本 | V1.5 |
| 日期 | 2026-10-18 |
| 编写依据 | ① 基线需求原文（全文见附录 A）；② 需求方对全部澄清问题的最终答复（全文见附录 B）；③ 《需求分析文档 V2.2》 |
| 文档说明 | 本文档为需求基线，取代此前 V1.0 / V1.1 / V1.2 版需求规格说明书。全部条款均为已确认结论，可逐条验证。本文档自包含：全部需求来源原文收录于附录，脱离任何外部文件亦可核对与评审。 |
修订记录
- V1.0：初版（"提交意向即冻结"模型）。
- V1.1：更正为"提交意向仅登记排队、进入交易才冻结"模型。
- V1.2：依据需求方全部最终答复重写——商品五态状态机、先到先得硬约束、失败自动递补、口令码机制、意向五种结局；格式升级为规范 SRS（每条需求可验证，含验收标准）。
- V1.3：文档改为自包含——新增附录 A（基线需求原文）、附录 B（需求方答复原文 B-1 ~ B-19）、附录 C（答复与业务规则对照表）；参考资料不再指向外部文件。
- V1.4：随 Java 重构更新——§2.3 运行环境改为 Java 17 + Spring Boot + SQLite；新增"输入字段前端预校验"要求（FR-S-02、FR-S-09、FR-B-02、6.2 节）：各输入字段约束应先在浏览器端校验并即时反馈，后端校验仍为最终权威（依据课程评审意见与 DEF-001 迭代结论）。
- V1.5：依据阶段性评审意见收紧价格约束——原规则"价格 > 0、两位小数"无上限，导致数千位的超长数值（评审中实测 5000 位）只能通过后端判定，违背"不合格输入不应到达后端"的分层校验原则。新增价格上限 999,999.99 元（整数部分不超过 6 位），浏览器端可用 HTML 约束属性（
max/maxlength/pattern）直接拦截此类输入（同步更新 FR-S-02、BR-17、§4.1 数据字典）。补齐其余无界输入约束（与 V1.5 同一评审意见延伸）——商品名称 ≤ 128 字符、商品描述 ≤ 2000 字符（与实现数据库varchar(128)/varchar(2000)对齐，消除"需求无界、实现有界"的不一致）；新密码 8~64 位（原规则仅有下限）。同步更新 FR-S-02、FR-S-09、BR-17、BR-18、§4.1、§4.3、6.2 节。
本说明书规定"在线购物系统（MVP）"必须满足的全部功能与非功能需求，作为系统设计、实现、测试与验收的依据。每条需求均以可验证的方式陈述。
本系统为软件需求工程实践课程作业：一个只销售单一商品的极简在线购物系统。一名卖家发布商品，不特定访客免注册登记购买意向并排队，卖家按先来后到与买家进行线下交易（一手交钱一手交货），售出一件后再发布下一件。
| 术语 | 定义 |
|---|---|
| 在售 | 商品对外展示、可接受购买意向的状态。 |
| 意向购买人 / 意向队列 | 提交购买意向者进入该商品的意向名单，按提交时间先后排队。 |
| 交易中 | 卖家与队首买家开始走线下交易流程时，该意向所处的状态；同一商品同一时刻至多一条。 |
| 冻结 | 商品暂停接受新意向的状态。进入方式：开始交易时自动冻结、后台手动冻结；二者为同一状态。 |
| 交易失败（状态） | 卖家标记"交易失败"后商品进入的过渡状态：先处置当前买家意向，再按队列情况分流，不停留。 |
| 恢复在售 | 交易失败处置完毕且队列已空后商品重新可售的状态；行为与"在售"完全等价。 |
| 下架 | 交易成功后商品进入的终态，永久撤下、进入历史，不可撤销。 |
| 递补 | 交易失败后队列非空时，下一位自动进入交易，商品随之重新冻结。 |
| 口令码 | 提交意向成功时系统生成并当场展示的唯一凭证，是买家查询、修改、撤销意向的唯一凭据。 |
| 作废 / 重新排队 | 交易失败时卖家对当前买家意向的两种处置：直接终结；或结案后排至队尾（旧口令码失效、另发新码）。 |
| 未成交 | 商品被更早排队者买走后，队列中其余意向的结局。 |
| 历史商品 | 已下架的商品，连同其完整意向名单一并保留。 |
- 基线需求原文——见附录 A（本文档自包含）。
- 需求方对全部澄清问题的最终答复原文——见附录 B（B-1 ~ B-19）。
- 《在线购物系统（MVP）需求分析文档 V2.2》（过程稿，记录需求澄清过程）。
- 附录 C：附录 B 条目与本文档业务规则（BR-01 ~ BR-19）的对照表。
系统提供买家侧（浏览商品、提交意向、凭口令码查/改/撤）与卖家后台（发布商品、管理交易、查看队列与历史、修改密码）两类功能。系统不涉及在线支付、物流、库存数量与用户注册。
| 角色 | 说明 |
|---|---|
| 访客（买家） | 无需注册登录。浏览在售商品、提交购买意向，凭口令码管理自己的意向。 |
| 卖家 | 系统唯一管理用户，凭预置账号密码登录后台，完成全部管理操作。 |
- 服务端：可运行 Java 17 的主机（Spring Boot 3.4，内嵌 SQLite 数据库，本地文件系统可写）。
- 客户端：现代浏览器（Chrome / Edge / Firefox 近期版本）。
- 系统中任意时刻至多存在一件未售出商品。
- 数据须持久保存于服务端，重启、关机不丢失。
- 本版本不实现：用户注册、退出登录、修改已发布商品、撤销交易成功、超时自动处理、意向去重合并、意向操作流水、落选通知、手动下架（详见第 7 章）。
- 系统预置且仅预置一个卖家账号，初始凭据随部署交付。
- 交易的钱货交割在线下进行，系统只记录意向与状态，不处理钱款。
flowchart TD
S1[卖家登录后台] --> S2[发布商品<br>（名称/描述/图片/价格）]
S2 --> P1[商品：在售]
P1 -->|买家浏览商品| B1[买家填写姓名、电话<br>提交购买意向]
B1 --> B2[系统生成独立意向记录<br>置于队尾，发出口令码]
B2 -->|商品保持「在售」| P1
B3[买家凭口令码<br>查询位次/修改信息/撤销意向] -.可选操作.-> B2
P1 -->|卖家开始交易<br>（强制取队首）| P2[商品：冻结<br>队首意向转「交易中」]
P1 -->|卖家手动冻结| P2
P2 -->|标记交易成功| P3[商品：下架（终态）<br>该买家结局=成功<br>其余意向=未成交，口令码全部失效]
P2 -->|标记交易失败| D1{卖家处置当前买家意向}
D1 -->|作废| D2[该意向结局=作废<br>口令码失效]
D1 -->|重新排队| D3[旧记录结案<br>生成新意向排至队尾<br>向卖家展示新口令码]
D2 --> Q1{队列是否为空?}
D3 --> Q1
Q1 -->|非空| P2
Q1 -->|已空| P4[商品：恢复在售]
P4 -.等价于「在售」.-> P1
说明：图中商品状态（在售/冻结/下架/恢复在售）与意向结局（成功/作废/重新排队/撤销/未成交）的完整规范见 3.3、3.4 节；线下交易、钱款交割不在系统流程内。
FR-B-01 浏览在售商品
- 系统应展示当前未售出商品的名称、描述、图片、价格。
- 商品处于冻结状态时，仍应正常展示，并以显著标识表明"已被预定/暂停接受意向"。
- 无未售出商品时，应提示"暂无在售商品"。
- 验收：三种情形（在售/冻结/无商品）分别访问，展示与标识符合上述要求。
FR-B-02 提交购买意向
- 前置条件：商品处于"在售"或"恢复在售"状态；否则系统应拒绝并提示。
- 买家应且只应填写：姓名、联系电话，两项均必填，缺一不得提交；姓名不超过 64 字符、电话不超过 32 字符，超限应在浏览器端即被阻止输入/提交。
- 提交成功后，系统应：生成一条独立的意向记录并置于队尾；当场生成并展示唯一口令码，提示买家保存。
- 系统不得因联系方式相同而合并、覆盖已有意向记录。
- 验收：连续以同一联系方式提交两次，队列中出现两条独立记录，各持不同口令码；冻结状态下提交被拒绝。
FR-B-03 查询意向（凭口令码）
- 买家输入有效口令码后，系统应显示对应意向的排队位次及是否已进入交易。
- 口令码无效或已失效时，系统应拒绝查询，且不区分"无效"与"已失效"的具体原因。
- 验收：队列第 2 位买家查询显示"第 2 位"；其进入交易后查询显示"交易中"；商品售出后任一买家查询均被拒绝。
FR-B-04 修改意向信息（凭口令码）
- 凭有效口令码，买家应可修改本人的姓名、联系电话，且仅限这两项。
- 修改不得改变排队位次、不得触发重新排队。
- 意向已终结或商品已下架时，系统应拒绝修改。
- 验收：第 2 位买家修改电话后仍居第 2 位；已撤销意向的口令码修改被拒。
FR-B-05 撤销意向（凭口令码）
- 凭有效口令码，买家应可撤销本人的意向；撤销后该意向从队列移除，结局记为"撤销"，后续买家位次依次前移。
- 撤销不得改变商品状态；即使撤销的是交易中的买家，商品仍应保持冻结，等待卖家处理。
- 验收：撤销后队列位次前移正确；商品状态不变；该口令码此后查询/修改/撤销均被拒。
FR-S-01 卖家登录
- 卖家应凭"用户名 + 密码"登录后台；未登录访问后台任何功能应被拒绝。
- 登录失败提示不得区分"用户名错误"与"密码错误"。
- 本版本不要求提供退出登录功能。
- 验收：未登录直接访问后台接口/页面被拦截；错误凭据登录得到统一提示。
FR-S-02 发布商品
- 前置条件：系统内无未售出商品；否则应拒绝发布。
- 卖家应填写：商品名称、商品描述、商品图片、商品价格，四项均必填；商品名称不超过 128 字符、商品描述不超过 2000 字符，超限应在浏览器端即被阻止输入/提交。
- 图片约束：最多一张主图，仅 JPG/PNG 格式，单张不超过 5MB；价格约束：大于 0、保留两位小数、不超过 999,999.99 元（整数部分最多 6 位）、单位为人民币元。
- 输入校验分层：上述图片格式/大小、价格取值约束应先在浏览器端校验（HTML 约束属性 + 提交前脚本检查），不满足时即时提示且不发起请求；服务端校验仍为最终权威，两条防线缺一不可（见 6.2 节）。
- 发布成功后商品进入"在售"状态，系统记录发布时间。
- 商品一经发布，其名称、描述、图片、价格在任何状态下均不得修改。
- 验收：缺图/超 5MB/非 JPG·PNG/名称超 128 字符/描述超 2000 字符/价格为 0、负数或超过 999,999.99 元均被拒绝（超长输入应在浏览器端即被拦截，不产生请求）；存在未售出商品时发布被拒；全系统无修改商品入口。
FR-S-03 查看意向队列
- 后台应展示当前商品的意向名单，按提交时间排序，含：位次、姓名、联系电话、提交时间、当前状态（排队中/交易中）。
- 交易中买家已自行撤销的，名单中应有可见标记。
- 意向购买人信息仅卖家可见。
- 验收：名单顺序与提交时间一致；买家侧任何页面无法获取他人意向信息。
FR-S-04 开始交易
- 卖家发起交易时，系统应强制取队列最前者（最早提交且仍在排队的意向）作为交易对象，不提供选择其他买家的入口。
- 开始后：商品自动进入"冻结"，该意向转为"交易中"。
- 队列为空时操作应被拒绝。
- 验收：队列有 3 人时发起交易，绑定的一定是第 1 位；卖家无法指定第 2、3 位。
FR-S-05 手动冻结 / 解冻
- 卖家应可将"在售/恢复在售"的商品手动冻结；冻结后停止接受新意向。
- 卖家应可将冻结中的商品手动解冻回"在售"；解冻只改变商品状态，不得改变任何意向的状态。
- 手动冻结与开始交易产生的自动冻结为同一"已冻结"状态。
- 验收：手动解冻后，原队列全部意向（含位次）保持不变。
FR-S-06 标记交易成功
- 仅当存在"交易中"意向时可操作。
- 标记后：商品进入"下架"（终态），系统不提供任何撤销手段；该买家意向结局记"成功"；队列中其余未结束意向结局记"未成交"；全部口令码即时失效。
- 系统应记录交易结果与交易时间；操作前界面应要求卖家二次确认。
- 验收：标记成功后商品不可再售、不可恢复；落选买家口令码查询被拒；历史中出现该商品及完整意向名单。
FR-S-07 标记交易失败
- 仅当存在"交易中"意向时可操作。
- 卖家应同时确认对当前买家意向的处置，二选一：
- 作废：该意向终结，结局记"作废"，口令码失效；
- 重新排队：该意向以结局"重新排队"结案、口令码即时失效；系统生成新意向记录（新口令码、排至队尾），并向卖家展示新口令码以便线下告知买家。
- 处置完成后系统应立即分流：队列非空 → 新队首自动转为"交易中"，商品保持/重新"冻结"；队列已空 → 商品进入"恢复在售"。
- 系统应记录结果标记时间。
- 验收：选"重新排队"后旧口令码失效、新记录位于队尾；队列非空时递补自动发生、无需卖家再次操作；队空时商品恢复可接受意向。
FR-S-08 查看历史商品
- 后台应可查看全部历史商品：名称、描述、图片、价格、发布时间、交易结果、交易时间。
- 每个历史商品应附完整意向购买人名单：姓名、联系电话、提交时间、对应结局（成功/作废/重新排队/撤销/未成交）。
- 历史记录不得删除，成交后亦完整保留。
- 验收：完成一轮完整交易后，历史中商品信息与意向名单（含五种结局的准确标注）完整可见。
FR-S-09 修改密码
- 修改前应先验证原密码，原密码错误应拒绝。
- 新密码应满足：8~64 位，且同时包含字母和数字；不满足应拒绝，超长输入应在浏览器端即被阻止（
maxlength）。 - 输入校验分层：新密码强度约束应先在浏览器端校验（HTML 约束属性 + 提交前脚本检查），不满足时即时提示且不发起请求；服务端校验仍为最终权威（见 6.2 节）。
- 密码应以加密（哈希）形式存储，任何存储位置不得出现明文。
- 系统应记录改密时间。
- 验收：弱密码（如纯数字 6 位）或超 64 位密码均被拒；改密后旧密码无法登录、新密码可登录；数据文件中密码为密文。
商品应在以下五个状态间切换，且仅允许下列转移：
| 当前状态 | 事件 | 下一状态 | 约束 |
|---|---|---|---|
| 在售 | 买家提交意向 | 在售（不变） | 仅登记排队，不冻结 |
| 在售 / 恢复在售 | 开始交易（系统取队首） | 冻结 | 自动冻结，队首意向转"交易中" |
| 在售 / 恢复在售 | 手动冻结 | 冻结 | 与自动冻结同一状态 |
| 冻结 | 手动解冻 | 在售 | 不影响任何意向 |
| 冻结 | 标记交易失败 | 交易失败（过渡） | 先处置当前买家意向（作废/重新排队） |
| 交易失败 | 意向处置完毕且队列非空 | 冻结 | 下一位自动递补进入交易 |
| 交易失败 | 意向处置完毕且队列已空 | 恢复在售 | 商品重新可售 |
| 冻结 | 标记交易成功 | 下架（终态） | 不可撤销；其余意向记"未成交"；口令码全部失效 |
- "交易失败"为过渡状态，处置完毕应立即分流，不得停留。
- "恢复在售"与"在售"行为完全等价。
- 任意时刻至多一件未售出商品、至多一条"交易中"意向。
- 冻结期间不得接受新的购买意向；已排队意向保留。
每条意向的结局应记为以下五种之一，且历史记录中应能区分：成功、作废、重新排队、撤销、未成交。
- "重新排队"以旧记录结案 + 新记录入队尾的方式实现。
- 历史只保留每条意向最终的姓名、电话、提交时间与结局；修改、撤销的操作流水不予保留。
| 编号 | 规则 | 依据 |
|---|---|---|
| BR-01 | 提交意向只登记排队，不冻结商品；商品继续在售并接受意向。 | B-3 |
| BR-02 | 开始交易时商品自动冻结；后台亦可手动冻结；二者为同一"已冻结"状态。 | B-3、B-9 |
| BR-03 | 冻结期间不得接受新意向。 | B-3 |
| BR-04 | 交易对象严格先来后到，系统不得允许卖家跳选；失败后按顺序递补。 | B-3 |
| BR-05 | 交易失败且队列非空时，下一位自动递补进入交易并重新冻结；队列已空时恢复在售。 | B-11 |
| BR-06 | 手动解冻只改变商品状态，不触碰任何意向。 | B-12 |
| BR-07 | 交易失败时卖家二选一：作废 / 重新排队（队尾 + 旧口令码失效、另发新码）。 | B-15 |
| BR-08 | 交易成功后商品下架且不可撤销；其余意向记"未成交"；全部口令码失效。 | B-13、B-14 |
| BR-09 | 买家撤销仅退出排队、位次前移；商品状态不因此改变。 | B-1、B-18 |
| BR-10 | 每次提交生成独立意向记录，不按联系方式合并/覆盖。 | B-17 |
| BR-11 | 意向信息字段仅姓名 + 联系电话，均必填。 | B-2 |
| BR-12 | 凭口令码修改仅限姓名、电话，不改变位次。 | B-18 |
| BR-13 | 口令码于意向终结或商品下架时失效；重新排队时旧码即时失效。 | B-7、B-15、B-18 |
| BR-14 | 商品发布后任何状态下信息不得修改。 | B-8、B-9 |
| BR-15 | 历史商品附完整意向名单（姓名/电话/提交时间/结局），成交后不删。 | B-4、B-16 |
| BR-16 | 历史只留意向最终内容，不留修改/撤销流水。 | B-19 |
| BR-17 | 商品图片最多 1 张、JPG/PNG、≤ 5MB；价格 > 0 且 ≤ 999,999.99 元（整数部分 ≤ 6 位）、两位小数、人民币；名称 ≤ 128 字符、描述 ≤ 2000 字符。 | B-10、评审意见 |
| BR-18 | 密码加密存储；改密验原密码；新密码 8~64 位且含字母和数字。 | B-9、B-10、评审意见 |
| BR-19 | 发布、冻结、标记交易结果、修改密码应记录时间戳；意向修改/撤销不记时间戳；全部数据持久保存。 | B-10、B-19 |
"依据"列说明：
B-n指附录 B 的第 n 条（需求方答复原文），本文档附录内即可逐条核对，无需外部文件。全部业务规则均有来源，不存在无依据的自增规则。
| 字段 | 类型 | 必填 | 约束 |
|---|---|---|---|
| 商品名称 | 字符串 | 是 | ≤ 128 字符；发布后不可改 |
| 商品描述 | 字符串 | 是 | ≤ 2000 字符；发布后不可改 |
| 商品图片 | 文件 | 是 | 1 张，JPG/PNG，≤ 5MB；发布后不可改 |
| 商品价格 | 数值 | 是 | 0 < 价格 ≤ 999,999.99 元（整数部分 ≤ 6 位），两位小数，人民币；发布后不可改 |
| 状态 | 枚举 | 是 | 在售 / 冻结 / 恢复在售 / 下架（"交易失败"为不停留的过渡态） |
| 发布时间 | 时间 | 系统记录 | — |
| 冻结时间 | 时间 | 系统记录 | 关键操作时间戳 |
| 交易结果 / 交易时间 | 枚举 / 时间 | 售出后记录 | — |
| 字段 | 类型 | 必填 | 约束 |
|---|---|---|---|
| 关联商品 | 引用 | 是 | — |
| 姓名 | 字符串 | 是 | ≤ 64 字符；可凭口令码修改 |
| 联系电话 | 字符串 | 是 | ≤ 32 字符；可凭口令码修改 |
| 提交时间 | 时间 | 系统记录 | 决定排队位次，不可变 |
| 口令码 | 字符串 | 系统生成 | 唯一，8 位随机字母数字 |
| 阶段 / 结局 | 枚举 | 是 | 排队中 / 交易中；终结后记结局：成功 / 作废 / 重新排队 / 撤销 / 未成交 |
| 字段 | 类型 | 必填 | 约束 |
|---|---|---|---|
| 用户名 | 字符串 | 是 | 系统预置，唯一 |
| 密码 | 哈希 | 是 | 加密存储；改密验原密码；新密码 8~64 位且含字母和数字 |
- 用户界面：浏览器访问。买家侧：商品展示页（含意向提交与口令码管理）；卖家侧：后台管理页（登录后使用）。界面应极简，买家无需任何说明即可完成操作。
- 软件接口：无外部系统接口；不接入支付、短信、邮件等任何第三方服务。
- 通信接口：浏览器与服务端之间使用 HTTP；买家侧数据交互无需鉴权，后台数据交互须凭登录会话。
- 系统按"单卖家、单商品、低并发"规模设计；在意向队列不超过 200 条的规模下，常规页面加载与操作响应应不超过 2 秒。
- 系统无多商品、多卖家、高并发要求。
- 密码加密存储；登录失败提示不区分账号/密码错误。
- 后台全部功能须登录后访问；会话凭证不得暴露于页面脚本（HttpOnly）。
- 意向购买人姓名、电话仅卖家可见；买家侧按口令码仅返回本人的位次与阶段。
- 口令码应唯一且不可顺序枚举（8 位随机字母数字）。
- 上传图片应校验格式（JPG/PNG）与大小（≤ 5MB）。
- 输入字段前端预校验：发布商品（名称/描述长度、价格、图片）、修改密码（新密码强度与长度）、提交/修改意向（姓名、电话长度）等输入约束，应先在浏览器端校验并即时反馈，不合格的请求不得发出；服务端对同一约束保留完整校验，作为最终权威防线（防止绕过前端直连接口）。
- 口令码输入框应限制长度（8 位）并在提交前做规范化处理（去除首尾空白、统一大写）。
- 全部数据持久保存，关机、重启不丢失。
- 关键写操作（发布、冻结、标记结果、改密、提交意向）完成后数据应立即落盘。
- 状态切换应保证一致性：不得出现两人同时买下同一商品、不得出现一件商品同时有两条"交易中"意向（NFR-01）。
- 买家免注册完成"浏览 → 提交 → 保存口令码 → 查/改/撤"全流程。
- 口令码在提交成功页显著展示并提示保存。
| 编号 | 不实现的功能 |
|---|---|
| EX-01 | 用户注册（买家侧） |
| EX-02 | 退出登录 |
| EX-03 | 修改已发布商品（任何状态下） |
| EX-04 | 撤销"交易成功"标记 |
| EX-05 | 冻结/交易超时自动处理 |
| EX-06 | 按联系方式对意向去重、合并、覆盖 |
| EX-07 | 意向修改/撤销的操作流水与时间戳 |
| EX-08 | 在线支付、物流、库存数量 |
| EX-09 | 落选买家通知 |
| EX-10 | 手动下架（不经交易直接撤下商品） |
- 第 3 章全部功能需求逐条通过验收（各条已附验收要点）。
- 第 3.5 节业务规则通过场景测试验证；第 6 章非功能需求通过测试与审查验证。
- 第 7 章范围外功能出现即视为缺陷（防止自行扩需求）。
| 需求类别 | 验证方式 |
|---|---|
| FR-B-01 ~ FR-B-05 | 功能测试（买家场景脚本） |
| FR-S-01 ~ FR-S-09 | 功能测试（后台场景脚本） |
| 3.3 状态机 | 状态遍历测试（覆盖全部 8 条合法转移 + 非法转移拒绝） |
| 3.4 意向结局 | 五种结局各构造一例核查历史记录 |
| BR-01 ~ BR-19 | 融入上述场景测试逐条断言 |
| 6.1 性能 | 200 条意向规模下抽样测量响应时间 |
| 6.2 安全 | 数据文件审查（密码密文）、越权访问测试、口令码枚举抽查 |
| 6.3 可靠性 | 重启后数据核对；并发/重复提交一致性测试 |
以下为课程题目给出的原始需求（基线），本文档全部条款均在其范围内展开，未自行扩大范围。
基线需求——最简单而又可用的在线购物系统（MVP），具备功能如下：
- 只卖一个商品，卖掉一个，再制作一个，再卖。
- 只有一个卖家。
- 没有用户注册，当查看后想要购买时，再填入用户信息。
- 线下交易，一手交钱一手交货。
- 在实施线下交易前，商品暂且冻结，直到交易成功，把商品撤下，或者交易失败，商品恢复上线。
- 卖家有一个后台，用于发布一个商品、查看历史商品、查看意向购买人信息、冻结商品等功能。
- 卖家可修改密码。
- 其中商品信息包括：商品名称、商品描述、商品图片、商品价格。
题目附加说明：本系统为软件需求工程实践作业，要求"根据基线需求完善成正常正确的需求，不自行多加需求"。
本附录为需求方（卖家）对全部澄清问题的最终答复原文，按答复先后顺序编号 B-1 ~ B-19。第 3.5 节业务规则表"依据"列即指向此处。
B-1 · 买家撤销的后果
买家撤销只是他退出排队，后面的人位次往前挪一下。商品本身不会因为买家点个「撤销」就自动变回可卖——商品什么时候恢复在售，还是得我在后台操作（标记交易失败，或者手动解冻），不是买家那边一点就能直接放出来的。
B-2 · 意向信息字段
就两个：姓名和联系电话，都得填。买家看中了想买的时候，填这俩就行，我好线下联系他完成交易。
B-3 · 冻结触发时机与先来后到
买家登记意向之后，不会立刻冻结商品。他登记完只是进了我的「意向购买人」名单，算是在排队——这时候商品还在正常在售，别人也还能继续登记意向。 冻结是等真正进入交易时才发生的：我跟某个买家开始走交易流程（商品变成「交易中」）时，商品会自动冻结；我也可以在后台手动冻结。冻结之后才停止收新的意向。 而且交易对象也不是我随便挑的，是按先来后到——最早提交意向的先跟我交易；前面这单要是没谈成，再按提交顺序递补下一个。
B-4 · 历史保留意向名单
会保留的，成交了也不删。我后台看历史商品的时候，每个商品下面都带着它的意向购买人名单——姓名、电话、什么时候提交的意向、最后是成了还是没成，都留着，方便我以后翻记录。
B-5 · 线下交易的确认方
线下交易谁说了算——由我（卖家）在后台标记。买卖双方当场「一手交钱一手交货」谈妥之后，我自己在后台把这一单标成「交易成功」或「交易失败」，系统就按我标的这个结果去改商品状态。
B-6 · 无超时机制
这个版本没有超时机制。商品冻结之后会一直保持冻结状态，直到交易有个结果为止——不存在「冻结多久自动算超时、系统自动处理」这一说。结果是我在线下交易完成后自己在后台标记的：标记成功就下架，标记失败就恢复在售、重新上线。系统本身不会去算冻结了多久，也不会自动超时。
B-7 · 口令码机制
买家虽然不登录，但每次提交购买意向后，系统会当场生成一个唯一的口令码，直接显示在提交成功的页面上，让他自己保存好。 之后他就凭这个口令码来查自己的意向——现在排到第几位、有没有进入交易，都能查到；还能凭它改自己留的姓名、电话，或者撤销意向。 不过这个口令码只在交易结束（成功或失败）或商品下架后失效，之后就不能再用来查了。
B-8 · 不提供修改已发布商品
不能。这个版本没有「修改已发布商品信息」的功能——商品发布后，名称、描述、图片、价格这些信息就固定下来了。卖家后台对商品能做的只有发布、冻结/解冻、标记交易成功或失败，没有编辑入口。
B-9 · 卖家后台功能清单
登录：必做。后台得用「用户名 + 密码」登录，不登录进不去。 退出：这个我没提过，这版本不要求做退出登录。 修改密码：必做。改的时候得先验原密码，新密码有长度和强度要求。 发布商品：必做。填名称、描述、图片、价格。 修改商品：没有这个功能。商品发布之后——不管在售、冻结还是已售出——都不能改。 手动冻结：必做（冻结和解冻都在后台手动操作，跟自动冻结是同一个「已冻结」状态）。 查看购买意向：必做。后台能看到意向购买人名单和联系方式。 确认交易结果：必做。线下交易完了，我在后台标记「交易成功」或「交易失败」。 查看历史商品：必做。后台能翻历史记录。 商品冻结或售出后还能改吗：不能。这版本压根没做「修改商品」，发布了就定死了，冻结、售出之后更动不了。
B-10 · 商品状态、图片与价格规则、历史内容、数据持久与密码
商品得有状态来回切：在售、冻结、下架、交易失败恢复在售，这一套得定清楚，别让一件商品被两个人同时买走。 图片：一件商品最多传一张主图，就认 JPG/PNG，单张别超过 5MB。 价格：得是大于 0 的数，保留两位小数，人民币。 历史记录要存啥：商品名、描述、图片、价格、发布时间、交易结果、交易时间；意向购买人名单里得有姓名、电话、提交时间、结果。 数据不能一关机就没；发布、冻结、标记结果、改密码这些关键操作得记时间戳。 密码得加密存，不能明文；改密要验原密码。
B-11 · 交易失败后自动递补
我标记「交易失败」→ 商品先恢复「在售」→ 只要后面还有人排队，下一位就自动递补进入交易，商品随之重新冻上；要是队已经排空了，商品就真正回到「在售」挂着。
B-12 · 手动解冻与标记交易失败的区别
手动解冻不会自动把那位买家的意向判成失败。手动解冻只是把商品从「冻结」放回「在售」，就动了商品这一个状态，不碰买家的意向。 标记交易失败：这才是正式结束跟某位买家的交易——那时候我会确认这位买家的意向是作废还是重新排队，商品同时恢复在售。 所以真在跟人谈着的时候想结束，走「标记交易失败」；手动解冻主要是我自己冻了商品（没人在谈）之后想解开用的。
B-13 · 交易成功后其余意向的处置
商品交易成功、一下架，其余排队的人就算没轮上、没成交了，他们的意向到此结束——商品已经卖给先到的那个人了。口令码：失效了。商品一下架，所有口令码就作废，他们不能再凭码查到任何结果（包括"没成交"这个结果）。 不过：他们填的姓名、电话这些，还留在我的后台历史记录里——每个商品的意向购买人名单都存着，含提交时间和对应结果，只是买家自己查不到了，我后台能翻到。
B-14 · 不可撤销交易成功
没有，这个版本没有「撤销交易成功」的功能。我在后台标记了「交易成功」之后，商品就直接永久下架、进历史记录了，点错了也撤不回来。所以标记前得先确认清楚。
B-15 · 交易失败时对买家的两种处置
交易失败之后，我可以选把这个买家的意向直接「作废」，也可以让他「重新排队」，这两个由我在后台确认。不过「重新排队」是排到队尾，口令码立刻失效重新生成。
B-16 · 意向四种结局均须记录
历史要能还原整个商品的完整过程，所以每个意向从提交到最后结局，都得留个状态。我倾向这样记——成功、作废、重新排队、撤销，这四种结局都各自记清楚，而不是只留「成功/作废」两档。因为重新排队和撤销都是真实发生过的事，卖家回头查历史，应该能看出「这个人排队又退出了」「那单失败后又重新排了」。
B-17 · 每次提交独立记录
我现在的想法就是：每次提交都是一条独立的意向记录，一条就是一条，不会因为联系方式相同就自动合并覆盖。真要改自己的信息，有专门的通道（凭提交时拿到的凭证），不是靠「重复提交同名联系方式」去覆盖。
B-18 · 口令码全流程与边界
买家要改意向，核心靠的是提交成功时系统给的那个「口令码」——买家没注册，口令码就是他认领自己这条意向的唯一凭证，所以第一步是：提交时把口令码保存好。 完整流程大概这样：提交意向时，系统生成一个唯一口令码，在提交成功页面直接展示，提示买家保存；买家想查自己的意向，就凭口令码查询——能看到自己的排队位次、有没有进入交易；想改信息，凭口令码修改——姓名、联系电话这两个都可以改；不想要了，凭口令码撤销——撤销后这条意向从队列里移除，排在后面的人位次依次往前移。 限制和边界：改内容只限姓名、联系电话，别的不动；修改不改变排队位次、不重新排队，原来排第几还是第几；口令码会失效：交易结束（成功或失败）或商品下架后，口令码就作废了，不能再用来查、改、撤。 所以概括起来就是：一口令码贯穿全程，能查、能改名和电话、能撤销；改信息不插队，交易完了码就失效。
B-19 · 历史只留最终内容
只保存最新内容，不留完整过程。历史记录里的「意向购买人」列表，存的是每个买家最终的那份：姓名、联系电话、意向提交时间、对应的交易结果。买家中途改过几次、撤销没撤销，这些操作流水不会保留，系统里留的就是最后定下来的那一条。 而且我这边对关键操作记时间戳的清单里（发布、冻结、标记交易结果、改密码），也没有「意向修改/撤销」这一项——所以改动的过程本身是不留痕的。
| 附录 B 条目 | 主题 | 对应业务规则 |
|---|---|---|
| B-1 | 买家撤销的后果 | BR-09 |
| B-2 | 意向信息字段 | BR-11 |
| B-3 | 冻结触发时机、先来后到 | BR-01 ~ BR-04 |
| B-4 | 历史保留意向名单 | BR-15 |
| B-5 | 线下交易确认方 | 3.3 状态机（交易结果确定方） |
| B-6 | 无超时机制 | 第 7 章 EX-05 |
| B-7 | 口令码机制 | BR-13 |
| B-8 | 不可修改商品 | BR-14、EX-03 |
| B-9 | 后台功能清单、密码要求 | BR-02、BR-14、BR-18、EX-02、EX-10 |
| B-10 | 状态/图片/价格/历史/持久化/密码 | BR-17 ~ BR-19 |
| B-11 | 交易失败自动递补 | BR-05 |
| B-12 | 手动解冻与标记失败的区别 | BR-06 |
| B-13 | 交易成功后其余意向处置 | BR-08、BR-13、EX-09 |
| B-14 | 不可撤销交易成功 | BR-08、EX-03 |
| B-15 | 失败时作废/重新排队 | BR-07、BR-13 |
| B-16 | 四种结局均须记录 | BR-15 |
| B-17 | 每次提交独立记录 | BR-10、EX-06 |
| B-18 | 口令码全流程与边界 | BR-09、BR-12、BR-13 |
| B-19 | 历史只留最终内容 | BR-16、BR-19、EX-07 |
说明：EX-xx 为第 7 章"范围外需求"编号，用于证明"不作某功能"同样有需求方依据，而非遗漏。