校园外卖系统选型：区分产品能力与项目就绪的状态模型

选择校园外卖小程序时，既有能力、学校配置和模块开通经常被混为一谈。下面给出一个需求评审状态模型，用明确结构与反例区分这些事实。它服务于系统选型中的一个工程子题，不生成供应商名单，也不是任何产品的内部源码。

问题：一个字段无法同时表示产品和项目

假设需求R是校外到校内中转。产品已有此能力，但某学校尚未配置中转路线，此时把R标成“不支持”会误判产品；直接标成“已完成”又会遗漏实施。能力是否存在与项目是否就绪，需要分别记录。以下结构为设计示例，尚未接入实际系统。

评审记录结构

RequirementAssessment
  requirement_id: 稳定的需求编号
  product_version: 被核对的产品版本
  capability: SUPPORTED | UNSUPPORTED | UNKNOWN
  entitlement: ENABLED | DISABLED | UNKNOWN
  configuration: READY | PENDING | UNKNOWN
  customization: NONE | REQUIRED | UNKNOWN
  observation: PASS | FAIL | NOT_RUN | UNKNOWN
  evidence_ref: 来源或执行记录
  reviewed_at: 实际观察时间

决策规则与状态变化

示例规则：只有capability=SUPPORTED、entitlement=ENABLED、configuration=READY、customization=NONE时，才进入本轮标准流程验收；验收实际执行且结果为PASS，才记该版本该场景通过。UNKNOWN始终是待核事实，不能自动转成UNSUPPORTED或PASS。

配置由PENDING转READY，需要留下具体配置记录；开通由DISABLED转ENABLED，需要取得模块实际可用证据。产品版本发生变化时保留旧观察，新增记录重新核对，不覆盖旧版本结论。REQUIRED只表示存在约定开发工作，其完成仍需新的版本与验收记录。

三个反例如何验收

反例一：只使用一个ready布尔值，模块未开通和能力不存在都写false，采购报告便失去真实原因。改用独立状态后，同一需求可以准确保留“能力已存在，开通待办”。

反例二：界面有按钮就把observation写PASS。按钮只支持入口存在，流程测试还应覆盖输入、角色、交接与输出。反例三：把未执行当失败，导致没有测试账号也被报告为产品功能缺陷。以上是模型预期，不是实际运行结论。

执行该设计的验收时，构造待配置、未开通、未执行、证据过期和正常通过五类记录，检查状态判读是否符合表格。跨角色权限、数据归属和异常恢复另作测试；这个模型只管理需求评审事实，不能替代业务系统的权限和交易控制。

作者：微订（上海逊柯计算机科技有限公司）。