在软件工程的需求分析阶段，“分析系统的数据要求”就是把“信息”从业务里抠出来、拆干净、画清楚、对得上。业界常把完整做法拆成 6 步 3 类产物，可归纳为“三开三验四图一典一规”：
一、6 步闭环流程（怎么做）
采集——“数据在哪”
手段：现场观察、访谈、问卷、用例/场景、原型反推、遗留系统逆向。
交付：访谈纪要、场景清单、原始表单/报表/接口样本。分类——“数据是谁的”
把采集到的“名词”按业务域做一级分类：实体类（长期存，如 Customer、Product）
事务类（一次性事件，如 Order、Payment）
资源类（外部引用，如 ISO 代码、汇率表）
规则类（派生/计算，如 DiscountRule）
拆解——“数据长什么样”
对每一类继续拆到“原子字段”级，同时给出：业务含义（一句话）
数据类型/长度/精度
值域/代码集
生命期（谁创建、谁维护、谁销毁）
保密/合规等级（GDPR、等保）
关联——“数据怎么勾搭”
用“四图”把静态结构+动态流向画出来：
① 实体-关系图（ER）——“表与表”
② 类图（UML）——“对象与对象”
③ 数据流图（DFD）——“从哪来到哪去”
④ 状态图——“同一实体生命周期”
目标：把“1 对多、多对多、强/弱实体、组合/聚合”全部对齐。定义——“数据正式立法”
把 3、4 步结果写进《数据字典》+《数据标准规范》：数据字典：字段级“法典”
数据标准：代码值、命名规则、度量单位、质量维度（唯一性、完整性、及时性、准确性、一致性、可追溯性）
验证——“数据对得上”
① 一致性验证：用例+DFD+ER 三张图跑同一场景，输入/输出能对上。
② 完整性验证：把报表/界面字段反向映射到字典，100 % 可回溯。
③ 质量验证：抽样真实数据跑“空值率、重复率、格式合规率”指标。
④ 评审验证：业务、开发、测试、运维四方签字，才能锁 baseline。
二、3 类核心产物（做什么）
数据字典（Data Dictionary）
最小颗粒度“字段”级，模板示例：字段ID 中文名称 英文名称 类型/长度 主键/外键 值域 NULL% 敏感级 来源 去向 备注 F015 订单编号 order_id varchar(24) PK 全局UUID 0 低 用户提交 DB·order 业务可见 F016 会员生日 member_birth date – 1900-01-01~今天 <1% 高 注册接口 营销系统 GDPR·需加密 数据模型图（ER/UML）
概念模型（CDM）——只含业务实体、业务关系，无技术细节。
逻辑模型（LDM）——加主键、外键、范式。
物理模型（PDM）——加索引、分区、引擎、字段类型对准具体 DB。
数据流图/状态图
DFD-0、DFD-1、DFD-2 至少画到第三层，把“外部实体→过程→数据存储→输出报表”全连上。
对关键实体（订单、支付、库存）画状态图，列清触发事件与约束。
三、图形化辅助技巧（画什么）
ER 图 → PowerDesigner、draw.io、MySQL Workbench
UML 类图 → Enterprise Architect、StarUML
DFD → Visio、Lucidchart（推荐 Gane-Sarson 符号）
状态图 → PlantUML、Visual Paradigm
数据血缘 → Apache Atlas、Alibaba DataWorks 血缘图（自动解析 SQL）
四、常见坑与对策
坑1 业务拍脑袋——“大概就这样”
对策：用“报表反推法”，把管理层最关注的 3 张报表先列字段，再追问“数从哪来”。
坑2 字典没人维护——“写完就过时”
对策：字典入库（Git 或 Wiki），字段变更必须发 MR，测试用例同步更新。
坑3 状态图缺失——“订单怎么糊里糊涂就关闭了”
对策：把“状态+事件+前置条件+后置动作”写成表格，再转图，开发直接照抄成代码枚举。
坑4 敏感字段未分级——“上线后 GDPR 罚款”
对策：在字典里加“敏感级”列，高/较高字段强制走加密/脱敏/审计三道闸。
五、可落地的交付清单（Checklist）
✅ 《数据来源清单》—— Excel，列出所有原始单据/接口/旧库
✅ 《实体-关系图》—— 概念+逻辑两层，评审签字
✅ 《数据字典》—— 字段级，含业务含义、技术格式、质量规则
✅ 《数据流图》—— 至少到第三层，与用例图一一映射
✅ 《数据标准规范》—— 命名、代码、度量、质量指标、密级
✅ 《数据验证报告》—— 抽样真实数据跑质量指标，截图留档
把这 6 件 artifacts 扔进配置库，需求评审会上就能自信地回答：
“信息从哪来、怎么变、存哪去、长啥样、对不上怎么办、将来怎么扩”——
这就是“分析系统的数据要求”具体要做、也要交付的全部内容。