需求分析要解决的问题是：把"我想看一些数据"转化成明确的业务决定、证据要求和可检查的交付范围。
业务说"想看促销效果"，如果立刻列字段、设计报表，很可能交付了数字，却仍然无法回答活动是否值得继续。需求分析需要先弄清用户怎样工作、为什么作决定，再检查数据能支持到什么程度。
本文依据《数据仓库工具箱》第3版第17章的业务需求定义和第18章的建模组织工作整理。下文的推导顺序是阅读归纳，不是作者命名的一套新步骤；短案例为教学设定。
一、先了解决定，再讨论报表
经营诉求通常以报表形式出现，例如"按商品增加一张活动销售表"。报表是用户想到的呈现方式，背后的工作任务才决定数据需要承担什么责任。
因此，先问用户怎样完成工作、需要作什么决定、根据哪些信息判断成功，以及当前最难的环节是什么。原书建议用开放问题理解工作和组织位置，再深入关键业务过程，而不只询问想要哪些字段。
例如，同样查看活动销售额，有人准备调整补货，有人准备停止优惠，有人需要核对结算。它们对日期、成本、退款和时效的要求不同。
这一环节应形成"谁在什么场景下，依据什么结果，准备采取什么行动"的说明。若连决定都不清楚，先澄清用途，不急着承诺计算结果。
二、把决定落到业务过程与证据
决定明确后，需要识别哪些实际活动能够留下证据。下单表达购买意愿，成功支付形成收款事实，退款成功改变保留金额；它们不是同一个事件。
这一步先画过程和时间关系，再列对象、状态及来源。业务部门可以帮助解释事件，系统人员帮助核查记录；单方解释都可能遗漏关键条件。
如果活动复盘需要了解退款后的交易结果，就不能仅取得订单创建金额。若要进一步判断经营贡献，还需要明确商品成本、费用及其归属依据。
检查标准是：每个预期判断都能对应证据；尚无证据的判断明确列为缺口，不靠字段名称猜测含义。
三、同时核查业务需求和数据实际
原书强调，需求收集还要配合以数据为中心的调查。已有来源怎样记录、哪些字段可靠、历史能否恢复，会影响方案是否成立。
例如，支付系统只保留订单号，退款系统只有订单总退款额。此时可以分析订单净额，却不能未经规则确认就声称已经获得每个商品的实际退款额。
应区分三种情况：来源直接提供的事实；经过明确规则推导的结果；当前无法支持的结论。分配得到的金额需要保留分配依据，不能伪装成来源明细。
业务需求不应被现有系统完全限制，但缺口需要有补采、构造教学输入或收缩范围的方案。这种双向检查，是后续建模的输入。
四、把解释转化为共同的验收依据
访谈结束不代表需求已经确定。不同人对"销售""客户"和"当天"的理解可能不同，需要将分歧放到可讨论的样例上。
教学例子：订单周一支付135元，周三退款45元。"周一支付额"是135元；"这批订单截至周三净支付额"是90元。两者回答不同问题，不能仅凭数值不同判定错误。
明确统计对象、事件、时间归属、观察截止、排除项、来源及负责人，再给出输入和预期答案。数据不足、截止后更正和延迟交付的处理方式，也应在需要时说明。
这样的需求说明能够被业务复核、被开发实现、被测试检查。若同一输入仍存在两个相互冲突的答案，应继续澄清或分别命名，而不是让SQL默认行为替业务作决定。
五、怎样知道需求分析已经够用
可以检查四项：业务决定说得清；关键过程和证据找得到；口径与样例能够共同复核；缺口、责任与交付边界有记录。
需求分析的成果不必是一份很厚的文档，但应足以支持模型设计，并允许后续发现问题时回溯修订。
它也不保证业务一定取得理想收益。证据显示当前无法判断，需要补充数据，本身可以是正确的需求结论。
快速复习
理解工作与决定 → 识别过程和证据 → 核查数据实际 → 用定义和样例形成共同依据。
关键反例：用户要一张销售报表，不能直接推定他要比较支付发生额，也不能推定他要评价促销增量。
原书入口与边界
《数据仓库工具箱》第3版17.2.2，书内290---293页、本地PDF312---315页；18.2---18.3，书内304---312页、PDF326---334页。本文直接核对了访谈规划、访谈过程及模型评审相关页。
原书提供需求访谈、数据调查与协作设计方法；本文的需求说明组织方式、135元样例和检查清单是应用归纳。原书介绍可参见Kimball Group官方书目。