讨论新系统时，人们很容易直接跳到功能：“要有统计，要能审批，最好再加一个大屏。”

这些要求可以记录，但还不足以让开发人员理解业务。

拿采购审批来说，“支持审批”只是一个结果。实际工作中，谁发起采购？金额不同是否走不同流程？负责人不在时由谁处理？申请退回后能否修改？这些细节才决定系统应该怎样设计。

准备需求时，可以从最近发生的一笔真实业务讲起。拿出相关表格或单据，按实际顺序说明每一步由谁完成、使用什么信息、下一步交给谁。

过程中不要只讲正常情况。那些需要打电话协调、临时找人签字的环节，往往更值得讨论。有些是系统需要支持的例外，有些则暴露了规则本身尚未明确。

也可以邀请实际操作人员参与。他们知道哪些字段经常填错，哪些步骤只是为了补齐手续，哪些信息虽然没有写进文档，却每天都在使用。

把现状讲清楚之后，再讨论哪些保留、哪些调整。这样形成的需求，比单纯列一张功能清单更接近实际使用。