在九游的报表系统项目里，需求文档往往是业务方与开发团队之间最重要的“契约”。但现实中，很多需求文档写成了一句话：“我要一张能看每月销售情况的报表。”开发照着做出来，业务一看却说不是想要的。问题不在技术，而在需求表达。这篇指南从业务方视角，讲讲一份能落地的报表需求文档应该包含什么。

一、先把“看什么”说清楚：指标与维度分开写

报表需求最常见的模糊点，是把指标和维度混在一起描述。九游报表团队建议，需求文档里至少要把两件事分开列：一是指标，即要统计的数值，比如销售额、订单量、退货率；二是维度，即从哪些角度切分这些数值，比如按区域、按渠道、按产品线。

写法上可以做成两张小表。指标表里写清指标名称、业务含义、计算公式、数据来源系统；维度表里写清维度名称、取值枚举、是否需要层级下钻。比如“销售额”要说明是含税还是不含税、是否扣退款；“区域”要说明是按发货地还是按客户注册地。这些细节不写，开发只能猜，猜错就要返工。

  • 指标名称尽量用业务通用叫法，避免自造缩写。
  • 每个指标标注口径负责人，方便后续核对。
  • 维度取值超过二十个时，说明是否需要“其他”归并。

二、把“怎么算”落到文字：取数逻辑与时间规则

指标口径是报表争议的高发区。九游在多个报表项目中观察到，同一张报表上线后反复调整，多半是因为时间规则没提前约定。需求文档里要明确：统计周期是自然月还是滚动三十天；数据截止到当天几点；跨期订单归到下单日还是完成日；历史数据是否需要回溯重算。

除了时间，还要写清过滤条件。比如是否剔除测试订单、是否包含内部采购、异常值如何处理。这些规则写在文档里，开发实现时有据可依，业务验收时也有对照标准。九游建议业务方在文档中附上一到两个手工计算的小样例，用真实业务场景说明“这个数是怎么来的”，比纯文字描述更有效。

三、把“怎么用”提前想：展示形式与权限范围

报表最终是给人用的，所以展示形式也要写进需求。是表格还是图表、需不需要导出、要不要按角色看到不同数据范围，这些都属于需求的一部分。九游报表团队常遇到的情况是，业务方只说要“一张汇总表”，上线后才发现还需要按门店下钻、需要移动端查看、需要定时推送给区域负责人。

权限部分建议单独成段：哪些角色能看全量、哪些角色只能看本部门、是否需要字段级隐藏。把这些前置说清楚，能避免上线后临时加权限导致的排期挤压。最后，别忘了写验收标准——用哪几个已知数据做核对、偏差多少算通过。一份带验收标准的需求文档，能让业务和开发在交付时少扯皮，也让九游的报表交付节奏更可控。