数仓方法论（一）：需求分析——把经营诉求转化为可验证的数据需求-开发者社区

需求分析的作用，是把经营诉求转化成明确的业务问题、证据要求和交付边界，让业务、开发与使用者能够共同判断结果是否有用、是否正确。

例如，业务提出“做一张促销销售表”。如果目的是调整优惠，需要了解成交与让利；如果目的是核对结算，则需要了解收款、退款和到账。表面上都是查看销售，实际要支持的决定不同。

因此，需求分析需要先理解用途，再推导需要哪些证据，核查来源能否提供，最后形成可共同复核的定义与样例。以下顺序是依据Kimball需求方法整理的实践推导，不是原书命名的固定四步法。

报表是用户想到的呈现方式，决定才是选择数据的依据。若不知道用户准备做什么，就无法判断增加一个字段、缩短一次刷新或补充一段历史是否值得。

因此，先了解用户怎样完成工作、在哪个环节作决定、现在依据什么，以及哪些困难使判断无法继续。原书建议通过开放访谈理解工作和关键业务过程，再深入分析需要。

判断问题是否已经明确，可以沿“结果→行动”反推：看到不同结果后，用户是否会采取不同动作？如果数字变化不影响任何判断，就需要继续澄清用途，而不是直接扩大取数范围。

这一步应形成“谁在何时，针对什么对象，需要判断什么，并准备采取什么行动”的说明。有了这个用途，才能决定证据范围。

一个判断需要被什么事实支持，取决于它在判断什么。要观察购买意愿，需要下单等记录；要观察收款，需要成功支付；要观察交易后保留金额，还需要相关退款。

因此，先识别业务过程中的事件与状态，再说明事件涉及哪些对象、何时发生，以及彼此怎样关联。这样能够发现，多个部门说的同一个词，实际可能指向不同活动。

检查证据是否充分，应逐项反问：缺少这条记录，会使哪个判断无法成立？仅有这些记录，又能支持到哪一步？这有助于同时避免少取必要证据和无目的地收集全部数据。

当判断需要跨过程证据时，还要明确关联条件。无法确定退款属于哪个原订单，就不能直接从一批订单金额中扣除所有退款。

证据要求提出后，需要回到来源核实。字段名称只能提供线索，不能证明它记录了所需事实。

应追查记录在什么业务动作后产生，状态怎样变化，金额针对什么对象，时间记录什么，以及历史会被覆盖还是保留。再抽取少量记录，与业务过程和系统解释对照。

这样可以区分三种结果：来源直接提供的事实；需要经过明确规则推导的信息；当前无法可靠获得的信息。三者会影响结果的可信程度，也决定后续需要补采、分配还是限制结论。

如果业务要求商品级退款，来源却只有订单总退款额，问题是证据细度不足。可以补充明细或制定分配规则，但分配结果必须保留其推导身份。

用途与数据条件明确后，还需要消除双方对“正确答案”的不同理解。仅写“按日统计销售额”，仍可能在状态、日期和退款规则上存在分歧。

因此，将对象范围、计入事件、时间归属、观察截止和排除规则写清，再选一组能够触发分歧的输入，独立推算预期结果。若同一输入仍产生不同答案，应先定位规则差异。

真正服务不同用途的定义，可以分别命名；来源不足的部分，应明确限制。负责人、更新要求和异常处理边界也需要与实际交付相匹配。

这一步形成的需求说明，应能指导建模、支持实现并作为验证依据。它可以随着新发现修订，但不能让未经说明的实现默认值替代业务定义。

运营希望知道活动订单退款后还保留多少成交，以决定下一轮是否调整商品。我们只回答交易净额，不延伸为完整利润或促销增量评价。

教学输入：活动中的订单O001周一成功支付135元，周三成功退款45元。业务希望在周三结束时复盘这批订单。

先明确对象是活动关联且已支付的订单，再沿原订单关系取得截至观察日的成功退款。由此得到：原订单支付135元，截止前退款45元，净支付额90元。

如果来源没有可靠的原订单关联，90元就不是已经得到的可信结果。应先补足关系或限制交付范围。这说明需求分析也会产生“当前证据不足”的结论。

方法主线：理解工作与决定→推导事件和证据→核查来源能力→明确规则并形成预期。

原书入口：《数据仓库工具箱》第3版17.2.2，书内290—293页、本地PDF312—315页；18.2—18.3，PDF326—334页。

访谈、数据调查及协作设计依据原书；上述推导顺序、样例和验收说明是实践归纳。需求明确后，指标设计继续将问题落实为共同衡量规则。

返回系列总览：从业务问题到可信数据交付。