先写明“谁需要拿到什么”
假设运营人员每天要找出交期已过但尚未发完的订单，按负责人分组检查。本期目标可以写成：“读取现有订单导出表，按指定核对日期生成逾期未发完订单清单，显示剩余数量，并列出无法判断的记录。”
这句话已经限定了主要工作：输入来自现有导出，结果是一份清单。它没有承诺自动安排发货，也没有默认向客户发送催办消息。这些动作若需要，应分别定义授权与流程。
一页需求可以这样填写
| 项目 | 本期约定 |
|---|---|
| 使用者与频次 | 运营人员按工作需要运行，核对日期由使用者指定 |
| 输入字段 | 订单编号、承诺日期、订购数量、已发数量、订单状态、负责人 |
| 筛选规则 | 承诺日期早于核对日期；剩余数量大于零；排除已取消订单 |
| 计算规则 | 剩余数量 = 订购数量 − 已发数量；同一行数量使用相同单位 |
| 输出 | 按负责人分组的订单清单、异常清单、读取记录数与筛选结果数 |
| 一期范围 | 处理约定导出格式，生成文件；不改订单、不自动发送通知 |
“早于”要写清楚：如果核对日期是 6 月 12 日，承诺日期恰好是 6 月 12 日的订单，本规则不算逾期。若业务希望当日未发也列入，应改成另一条明确规则，不能让开发者自行猜测。
四条样本能暴露很多误解
| 订单与承诺日期 | 订购 / 已发 | 预期结果 |
|---|---|---|
| SO101，6 月 10 日 | 10 / 6 | 进入清单，剩余 4 |
| SO102，6 月 11 日 | 5 / 5 | 已发完，不进入清单 |
| SO103，6 月 14 日 | 8 / 0 | 尚未逾期，不进入清单 |
| SO104，日期缺失 | 7 / 0 | 进入异常清单，不猜测日期 |
再补充数量非数字、已发数量大于订购数量、负责人为空和订单重复的情况。对于重复订单，应先确定文件是一单一行还是一单多行；如果一个订单有多种商品，唯一标识可能需要订单编号与行号组合。这个问题不解决，剩余数量就可能被重复计算。
把模糊要求改成可观察行为
- “系统要智能提醒”改为“运行后列出承诺日期早于核对日期、剩余数量大于零的订单”。
- “错误数据自动处理”改为“日期缺失、数量非数字、已发大于订购的记录进入异常清单，并显示原因”。
- “导出要方便”改为“结果包含约定字段，文件名包含核对日期，使用者能够选择保存目录”。
这些表达没有要求业务人员理解程序实现，却足以让双方讨论完成标准。对尚未决定的规则直接标注“待业务确认”，并指定确认人，不把它隐藏在“按实际情况处理”里。
验收从同一份样本和口径开始
验收时固定样本文件与核对日期，检查 SO101 是否得到剩余 4、SO104 是否进入异常清单，并抽查其他排除原因。随后由实际使用者独立运行一次，确认文件能选、结果能找、异常能看懂。
需求文档完成的标志，是双方能够指出一项要求通过或未通过。如果还只能说“感觉差不多”，就补充一个样本或一条可观察结果；通常不需要再增加一整页抽象描述。