又到了需求评审会，业务方把一叠写满功能描述的文档拍在桌上："需求都在这了，照着做就行。"我翻了翻，光是"订单"这一个词就被叫出了七种名字：订单、客户订单、销售单、单据、记录……功能描述里全是"支持""可以""方便"这类希望动词。这个场景我再熟悉不过，它几乎就是项目返工的前兆。真正需要的不是立刻打开代码编辑器，而是先做一轮结构化分析。
结构化分析这套方法论，核心产物就是三大模型：数据流图描述"功能"，实体-联系图描述"数据"，状态转换图描述"行为"。我最早被老同事逼着用这套方法时，心里很不服气，觉得画图是浪费时间。直到我在几个项目里靠这三张图提前拦下大量需求矛盾和返工，才彻底改观。这篇文章我不讲教科书上的定义，只讲实际用法、画图边界和踩过的坑，适合刚开始做需求分析的同学，也想给团队建立需求评审底线的技术负责人。
1. 三大模型的分工：功能、数据、行为各管哪一段
1.1 三张图画的是同一个系统的三个侧面
先纠正一个常见误解：三大模型不是三种画图套路，而是三个观察角度。你盯着一套订单系统看，从"它要做什么"切入，得到数据流图；从"它要长期记住什么"切入，得到实体-联系图；从"它在什么事件下从什么状态切到什么状态"切入，得到状态转换图。
我经常用生活类比来解释这件事：描述一个人一天的情况，日程表回答"他做了哪些事"，通讯录回答"他认识谁、彼此什么关系"，心情波动曲线回答"他在什么刺激下从平静变成烦躁"。三份材料内容完全不同，但描述的是同一个人。三大模型也是这个逻辑：功能、数据、行为三个投影合在一起，才构成一套可以评审、可以开发、可以校验的完整需求。只画其中一张，或者把三张硬揉成一张，后面都会出问题。
1.2 建模顺序：先功能还是先数据？
这个问题几乎每次培训都有人问。我的回答是：先看项目类型。数据模型强、业务规则稳定的系统，比如财务结算、订单库存、会员积分，可以先做实体-联系图，把核心实体和关系定死，再去推功能；业务流程主导、规则经常演变的系统，比如审批流、工单流转、客服排班，我建议先画数据流图，把系统边界、数据流向摸清楚，再回头提炼实体。
我的真实经验是，大约八成管理信息系统按"先DFD、后ER图、再STD"的顺序推进最顺。原因很朴素：数据流图能逼你先把系统边界画出来，边界一旦清楚，哪些数据必须落库、哪些状态会发生迁移，自然就有迹可循。反过来，如果你一上来就陷入某个实体有多少字段，很容易钻进细节出不来。当然，实时控制系统是例外，那类项目状态本身就是核心，建议从状态转换图起步。
1.3 为什么"一张图走天下"走不通
经常有人问：我见过有人把功能、数据、流程全画在一张大图上，不是也挺直观？确实，三五个人的小工具这么画没问题，但一旦系统成型，一张图就会变成信息垃圾场。假设系统有两百个加工点，全部平铺在一张图上，别说业务方看得头晕，连画图的人自己也找不到一条完整路径。
把模型拆开，不是搞教条，而是为了让每张图保持单一职责，也方便不同角色评审：业务人员盯数据流图看流程通不通，数据库同事盯实体-联系图看表结构合不合理，开发盯状态转换图看对象生命周期完不完整。各看各的图，评审判定标准更清晰，需求遗漏也更容易暴露。
2. 数据流图（DFD）：把"做什么"变成一层层可追问的网
2.1 四个基本元素和三个容易标错的位置
数据流图的基本元素只有四个：外部实体、加工、数据存储、数据流。不同流派画法符号有差异，但含义完全一致。外部实体是系统边界之外的人和系统，比如"客户""支付渠道"；加工是系统内部对数据做转换的动作，比如"校验订单""计算运费"；数据存储是系统要保留的数据集合，比如"订单表""商品目录"；数据流则是带着名字的箭头，表示数据的移动方向和内容。
我评审过的DFD里，最常见的问题有三个。第一，把控制流画了进去。"开始""结束""如果成立则"这类词一旦出现在DFD上，说明画图人还没分清数据流和控制流——DFD只管数据从哪里来、经过什么处理、到哪里去，判断逻辑属于判定表或状态图。第二，外部实体画进了系统内部，或者两个加工之间直接连数据流而跳过了存储，这会掩盖"数据是否被持久化"的关键问题。第三，数据流没有命名，或者名字太笼统，比如一条流就叫"数据"，评审的人完全不知道里面传的是什么。
2.2 分层画法与父子图平衡
数据流图最核心的技巧是分层。顶层图只有一个加工，名字就是系统本身，周围是外部实体；0层图把系统拆成三到七个主要加工，画出它们之间的数据流；每个主要加工再单独抽一层子图，继续向下分解。这个粒度控制很重要：画到每个加工都对应一个规模适中的功能模块时就可以停了，继续拆只会让图变琐碎，反而失去评审价值。
分层之后，最容易被评审抓的就是父子图平衡。规则很简单：父图中某个加工的输入输出数据流，必须与它的子图边界上的输入输出完全一致，不能多，不能少，不能改名。我见过很多项目子图里突然多出一个"催单信息"流，而父图完全没有，这就是典型的平衡破坏。这条规则是DFD的合规底线，它保证你分层拆分时没有偷偷往系统里塞需求，也没有凭空丢掉功能。
2.3 一个工单系统的分层实战
拿一个模拟项目X来演示。假设我们要做一个工单处理系统，外部实体是"客户"和"客服主管"。顶层图就是客户把"问题描述"发给系统，系统最终把"处理结果"返回给客户。
0层图可以拆成四个加工：接收工单、校验工单、派单处理、归档反馈。数据流大致是：客户的问题描述流入接收工单，再到校验工单；校验通过后进入派单处理；处理完成进入归档反馈；归档反馈把处理结果传给客户。此时数据存储已经能浮现出来："工单记录""处理日志"。到了第1层，比如"派单处理"可以继续细化成"分派客服""处理中""升级审核"子流程，它的输入仍然是"已校验工单"，输出仍是"处理完成通知"，保证和父图一致。
这层实践的价值在于：画完0层图，你的系统边界、主要功能模块、需要落库的数据集合全都清楚了。还没写一行代码，架构已经在你脑子里成型。
3. 实体-联系图（ER图）：数据建模里三处容易翻车的细节
3.1 实体和属性的边界怎么划
实体-联系图负责回答"系统要记住哪些东西"以及"这些东西之间什么关系"。线上练手平台经常出ER图画图题，很多人分数线画得漂亮，实体和属性却分不清楚。我见过最典型的情况：把"客户地址"直接做成客户实体的一个属性，但业务上客户可能有多个收货地址，地址还需要单独维护、单独验证，这时地址就应该升格为独立实体。
判断实体与属性边界，我有两个硬标准：第一，这个信息是否需要拥有自己的属性？如果"地址"需要记录联系人、电话、是否默认，它就不再是属性而是实体；第二，这个信息是否会被其他多个实体同时引用？比如"商品分类"既被商品实体引用，又需要维护分类图片、排序号，那它就必须从商品属性中拆出来。先列候选实体，再定义属性，而不是一上来就抠字段，能少走很多弯路。
3.2 基数、"多对多"和三元联系的表达
基数关系是ER图里最重要的内容，一对一、一对多、多对多，画错一个，表结构全盘皆错。特别要强调多对多关系，比如"学生"和"课程"就是一个经典多对多，它们之间必须拆出一个联系实体，比如"选课记录"，让选课记录同时关联学生和课程，并且可以挂上"选课时间""成绩"这些属性。如果不拆，最后建表时一定会出现冗余或者笛卡尔积，这是SQL设计的大雷。
三元联系我建议谨慎使用。理论上三个实体之间可以直接画一个联系，但在实际落地上，几乎所有的三元联系都可以改写成"两个二元联系加上一个联系实体"，这样更容易对应到物理表。曾经有个项目把"仓库、商品、供应商"画成一个三元联系，到了建表阶段三个人吵了一下午也没落地，后来改成"供应关系"实体加两个一对多，十分钟就收敛了。ER图的第一使命是能被数据库设计直接使用，而不是追求学术上的表达简洁。
3.3 弱实体、编码字段与ER图的"落地感"
弱实体是指没有独立标识、必须依赖父实体存在的实体，最典型的就是订单和订单明细：明细离开了所属订单就没有意义，也无法单独被识别。建模时很多人不画弱实体的双框符号，导致后期表设计时主键到底用独立单列还是复合主键发生争执。你至少在图上要把这种依赖关系表达清楚，后面建表才有依据。
还有一个细节：主键编号到底算属性还是算约束。比如"订单编号"在业务上是一个自然存在的编号，在ER图上它可以作为标识属性；但如果编号是数据库自动生成、本身不承载业务含义，在ER图阶段就不必把它标成核心属性，等物理设计时再补。ER图不是字段清单，太早陷入字段细节，反而会忽略实体间关系这个更重要的东西。
4. 状态转换图（STD）：行为模型不只属于实时系统
4.1 状态、事件、动作：先分清这三件事
状态转换图是三大模型里最容易被忽视的一个。很多教材把它放到实时系统章节讲，导致普通项目团队压根不画。我现在的观点很明确：只要你的系统里有"单据""任务""订单"这类会随业务推进改变形态的对象，就应该为它画状态图。
画图之前先分清三个概念。状态是对象在等待某事发生时处于的稳定局面，比如"待支付"就是一个稳定状态；事件是触发状态迁移的外部信号，比如"收到支付成功回调"；动作是迁移过程中要做的事，比如"扣减库存""发送通知"。初学者最容易把动作当状态，写出"正在发送邮件"这种"状态"——它没有持续等待的含义，实际是迁移过程中的瞬时动作，不应该成为状态圈的成员。
4.2 普通业务系统里的状态图实例：订单全生命周期
拿最常练手的订单对象举例。它的常见状态可以定义成：已创建、已支付、已发货、已完成，同时要有已取消、退款中、已退款这些异常分支。迁移事件要写清楚：已创建在"支付成功"事件下迁移到已支付；已支付在"超时未发货"或"用户申请退款"事件下可能进入退款流程；已发货在"确认收货"后进入已完成。
这张图的价值在开发阶段才会真正体现。没有状态图，后端同事一定会在订单表里放一个order_status字段，然后凭个人喜好定义0、1、2的含义，前端同事再按自己的理解渲染按钮。有了状态图，状态是所有模块的共同常量，按钮什么时候可点击、接口在什么状态下才允许调用，全部可核对。状态图让"订单流转"从口头讨论变成白纸黑字。
4.3 状态图最容易漏画的两个点
我检查过的状态图，十张里有八张漏画两个点。第一是初始状态和终止状态，很多人从"已创建"开始画，却没说清订单对象从哪个事件诞生、最后是终结在"已完成"还是"已关闭"，这导致代码里switch分支永远少一个default。第二是异常分支，支付超时、库存扣减失败、审核驳回、物流异常，这些不正常路径如果不画出来，开发人员就自己脑补一套逻辑，每个开发脑补的还不一样。
有一次在项目评审里，我们对"下单后超时未支付"的行为完全靠口头约定，结果上线第二周就出现了用户订单被自动占用库存的投诉。画状态图时把这个分支画上，讨论的是"超时定时器应该滚多久""是否发提醒消息"这些真正的问题，而不是等线上出bug再倒推需求。状态图的检查项很简单：每个状态是不是都有进入和离开路径？每个非终态是否都有事件出口？异常迁移是否都覆盖到了？
5. 三大模型如何互相校验：从三张图到一套完整需求
5.1 模型间的三组对应关系
三张图各自画完，只是工作的前半段，更关键的是让它们互相校验。模型之间有天然的对账关系：数据流图中的每个数据存储名称，应该在实体-联系图中能找到对应实体或实体集；数据流图中每个加工，应该对应状态转换图中由事件触发的动作或功能分解；状态转换图中的每个触发事件，在数据流图中应该能找到对应的数据流或控制输入。
我曾经带过一个小型进销存项目，需求文档写了几十页，三张图也画了，但图各画各的。对账时发现数据流图里有"调拨仓库"加工，状态图中却没有"调拨单"的状态，实体-联系图里也没有"调拨记录"这个实体。这意味着开发时必然有人临时造表、临时写状态逻辑，质量完全不可控。这三个对应关系，就是需求的"数据血缘"，对不上就是有漏洞。
5.2 用交叉检查找出需求矛盾
交叉检查不是理论游戏，它真的能提前抓住需求矛盾。举一个常见例子：数据流图里画了"订单审核"这个加工，更新了名为"订单"的数据存储，但实体-联系图里订单实体根本没有"审核状态"和"审核人"字段。这说明要么漏了字段，要么订单审核压根不存在，两条路线必有一假。
另一个我经常分享的反例：状态图里画了"已支付"到"已退款"的迁移，说明系统必须处理退款；接着检查数据流图，如果没有"退款处理"加工，没有"退款渠道"外部实体，再检查实体-联系图，没有"退款记录"实体，那么这次退款流程就没有数据落点，做完支付接口就等于背上一笔坏账。三张图交叉验证，本质是把需求从"业务方说要做退款"这种模糊表达，强制翻译成"谁触发、做什么、记什么、存哪里"的精确描述。
5.3 一套可落地的建模流程
基于这些经验，我整理出一套适合中小型团队的建模顺序。第一步，先用顶层数据流图把系统边界画清楚，确认外部交互方；第二步，做0层数据流图，拆出主要加工；第三步，顺着数据流找存储，把初步实体-联系图画出来，这一步也是实体-联系图练手最常见的场景；第四步，为订单、工单、审批单这类核心对象绘制状态转换图；第五步，做三图交叉对账，凡是图上对不上的地方，一个都不放过；第六步，组织评审，按图修改需求规格说明书。
这套流程在小规模系统上一般一周内就能走完，不需要等需求文档定稿，边画边聊的效果反而更好。图不是一次画完的，评审后必然会改，改图比改已经写出来的代码成本低得多，这也是结构化分析最大的红利。
6. 我踩过的坑和检查清单
6.1 "画完图就扔"等于没画
我职业生涯早期犯过一个很典型的错误：花大力气画完DFD，交差似的贴进文档，然后写代码的时候图是图、代码是代码，完全脱节。结果是图上标着"库存扣减"应该在支付成功之后，实际代码却在创建订单时就扣了库存，测试阶段才发现差了一步。
从那以后我给自己立了一条规矩：代码评审之前先过图，任何一张数据流图、实体-联系图、状态转换图对不上的实现，都不允许进入评审。图不是项目启动时的一次性产出，而是贯穿需求、设计、测试的对照基准。测试用例也可以从图里直接派生：数据流图生成主流程用例，状态图生成状态迁移用例。把图用起来，它的价值才会兑现。
6.2 画图工具选型：从白板到文本化绘图
工具选择也踩过不少坑。早期头脑风暴阶段，白板和纸笔效率最高，不要一上来就开软件，至于感不美观完全不重要。到了需要多人协作评审的阶段，用在线协作白板或者市面常见的绘图类SaaS工具都很顺手，它们的好处是多人实时编辑、评论留痕。
我自己现在偏向用文本化图表工具，比如PlantUML这类用文本描述生成图表的开源方案。原因很实际：第一，版本管理友好，图和代码一起进仓库，改动有diff可看；第二，批量修改效率高，比如全局把"工单记录"改成"工单主表"，文本文件全局替换就好，鼠标拖拽的图反而改起来痛苦。缺点是样式控制弱一些，但结构化分析图的审美要求远没有架构图那么高，能看清、能评审就足够了。
6.3 交付前自查清单
最后送一份我自己每次评审前都会过一遍的检查清单。数据流图部分：是否有未命名的数据流？是否混入了控制流？子图和父图是否平衡？外部实体是否都在边界之外？实体-联系图部分：多对多关系是否都拆成了联系实体？属性里是否藏了本应独立成实体的对象？弱实体的依赖关系是否画清楚？状态转换图部分：每个状态是否有进入和离开路径？异常和超时分支是否缺失？动作是不是被误当成了状态？
最后再做一次三图对账：存储与实体对得上吗？加工与状态迁移对得上吗？事件与数据流对得上吗？这轮自查做完，再开评审会，你会发现业务方提的"新需求"里，相当一部分要么是已经画在图上只是没宣贯到位，要么是图上确实存在待补的缺口。结构化分析的价值，就在这种"对不上"和"补缺口"的过程里一点一点体现出来。
我自己现在遇到复杂需求，已经形成肌肉记忆，先动手切三张图。它不能替代和业务方的频繁沟通，但它能把沟通成果固化成不依赖个人口才的资产。这是我在这个方法论里得到的最大的甜头，希望在读这篇文章的你也能体会到。
