范围、优先级与验收

核心概念

范围同时说明“做什么”和“不做什么”。用目标用户、任务、资料范围、允许动作和依赖界定一期能力；将未知依赖列为待确认。优先级结合价值、证据、实现成本与风险，不只看需求提出者的紧迫程度。

验收需要输入、预期行为和可检查证据。它不是“用户觉得好用”这一句话。建单成功要看到 mock API 返回的记录及状态；缺字段要追问，未授权动作要停止。阈值由任务要求与风险共同决定，不能借用别的项目数字。

情境拆解

虚构企业同时要求制度问答、建单、审批与自动退款。一期可以先覆盖授权制度问答及确认后的建单，把审批与退款列为范围外。原因要写清：后两者涉及更高影响的权限和责任，当前没有相应授权与接口证据。

新增要求应进入变更记录，标明它对资料、测试、周期和验收的影响，再由指定负责人决定，不暗中扩展工具权限。

常见误区

只写成功样例会漏掉资料不足、接口超时和越权请求。把“暂不做”藏在口头讨论里，则会让客户将演示能力当成正式承诺。

把愿望写成可以验收的范围

模拟需求包含制度问答、建单、查询状态、审批、退款和删除记录。一期只选择授权制度问答与确认后的模拟建单，其余写进不做清单。

“支持自动建单”仍不够具体。可验收的表述是：“字段齐全且获准执行，用户确认当前摘要后，模拟接口返回可核验编号；缺字段、未确认和无权限时不写入。”

动手：做一页范围与验收表

1. 给六项需求排序，选两项一期任务。说明取舍和依赖，不用虚构市场规模或客户承诺。
2. 为一期任务写输入、允许动作、输出和完成证据。
3. 编写八个验收例子：三个成功、三个失败或信息不足、两个禁止执行。
4. 为范围变更写明提出者、影响检查和确认者。还没有接口许可时，执行目标仍是模拟服务。

任务 / 一期是否包含 / 理由：
输入及前提：
允许动作：
完成证据：
异常或禁止情境：
预期状态与用户回复：
依赖、待确认者：

检查产物

每项范围都能被测试请求检验。“按用户要求处理”不能代替动作边界。审批、退款和删除等未授权需求，即使业务方口头感兴趣，也不应自动加入执行路径。