close
Boardmix博思白板 logo boardmix 白板
产品
AI工具
企业服务

DFD · 系统分析与需求沟通

在线数据流图

梳理数据来源、处理与去向

用外部实体、处理、数据存储和数据流,画清系统中的信息关系。在 Boardmix 从系统边界开始,逐层拆分处理,与团队一起核对输入输出。

  • 在线编辑
  • 图形与连线
  • 团队协作评审
Boardmix 数据流图编辑画布,展示图形、连接线与协作工具栏

认识 DFD 的四类元素

让数据的来去一目了然

谁提供数据、怎样处理、存在哪里、交给谁——用四类图形表达清楚,并在同一张图中保持符号一致。

外部实体:读者矩形表示系统边界以外的数据提供者或接收者。 读者

外部实体

系统边界外的数据来源或接收者,如读者、客户或其他系统,常用矩形表示。

处理:整理查询圆角矩形表示将输入数据转换为输出数据的处理。 1.0 整理查询

处理

对输入数据进行校验、计算或转换,命名宜用“整理查询”“检索馆藏”等动宾短语。

数据存储:馆藏记录右侧开口的矩形表示供处理读取的数据集合,D1 为标识。 D1 馆藏记录

数据存储

需要保留并供处理读取或写入的数据集合,如馆藏记录、订单档案,不等同于某一种数据库。

数据流:查询条件带箭头的线表示数据移动方向,查询条件是所传递的数据名称。 查询条件

数据流

箭头表示数据流向,标签写具体的数据名称;它不是操作步骤,也不是“是/否”控制分支。

处理也可用圆形、数据存储也可用两条平行线表示。选择一种符号体系后,避免在同一张图里混用含义。

同一个案例,逐层看清

先看系统边界,再展开处理

以馆藏查询为例:先确认读者与系统交换的数据,再展开内部处理,保持边界输入与输出对应。

01

上下文图:界定范围

馆藏查询服务的上下文数据流图 读者向查询服务提供查询条件,查询服务向读者返回查询结果。整个服务暂作为一个处理,不展开内部存储。 读者 查询服务 查询条件 查询结果
只展示系统与外部实体之间的数据交换。这里的输入是“查询条件”,输出是“查询结果”。
02

首层分解:说明内部处理

馆藏查询服务的首层分解数据流图 读者将查询条件交给1.0整理查询;整理查询输出检索条件给2.0检索馆藏;D1馆藏记录提供馆藏数据给检索馆藏;检索馆藏将查询结果返回读者。与上下文图相比,读者输入输出保持不变。 读者 1.0 整理查询 2.0 检索馆藏 D1 馆藏记录 查询条件 检索条件 馆藏数据 查询结果
把系统展开为处理与数据存储。内部增加了“检索条件”和“馆藏数据”,但边界仍是同一组输入、输出。

分层前后,检查这三件事

  • 外部实体与边界数据是否对应,不能拆分后凭空增加或丢失数据。
  • 每个处理是否有能解释其输出的输入,避免只有输入、没有输出,或凭空产出数据。
  • 数据流是否通过处理连接实体与存储;处理编号用于辨识,不表示执行先后。

以上为简化概念示例,聚焦查询,不展开馆藏维护。层级编号在不同方法中可能不同,本页用“上下文图”和“首层分解图”说明两种观察范围。

从个人绘图到团队共识

把图与问题放在同一张画布

数据流图需要业务、产品与开发共同确认。用 Boardmix 整理图形、连接线和补充说明,让讨论围绕具体的数据来源、处理规则与交付结果展开。

  • 并排放置各层图:先保留系统全貌,再在旁边展开处理细节,便于对照边界数据。
  • 在问题附近补充说明:例如“订单状态由谁更新”“报表数据取自哪里”,减少脱离图形的来回解释。
  • 按需设置分享权限:邀请成员共同编辑,分享前确认接收人的访问范围。
Boardmix 画布中的链接分享设置与多人协作界面
在画布内分享和讨论,具体权限以当前账号设置为准。
业务分析

找出缺失的数据来源

顺着每条输出追问:需要哪些输入、由哪个处理生成、最终交给谁。

需求评审

对齐系统责任边界

区分外部系统、内部处理和数据存储,确认哪些信息需要跨边界交换。

方案交接

留下可继续维护的说明

把字段含义、业务规则和待确认事项附在图旁,让后续修改有据可查。

按业务场景开始

数据流图模板与案例

从社区案例理解系统的数据关系,再按自己的业务边界调整实体、处理和数据名称。

模板用于启发建模,使用时仍需核对符号、缺失的数据流和上下层平衡。模板使用条件以对应详情页为准。

先有边界,再补细节

数据流图怎么画?

先明确要回答的问题,再选择符号和层级,避免一开始就把所有细节挤进同一张图。

  1. 界定系统边界

    列出与系统交换数据的外部实体,写清输入与输出。先将整个系统视为一个处理,画出上下文图。

  2. 拆分主要处理

    按数据的转换关系拆分处理,使用“核验订单”“生成报表”等动宾短语命名,补上处理需要读取或写入的数据存储。

  3. 标注数据与连接

    在箭头旁写“订单明细”“查询条件”等数据名称。两个外部实体之间不直接连线;实体与存储、存储与存储之间的数据交换应经过处理。

  4. 核对平衡后分享

    逐项对照父图与子图的边界输入输出,检查每个处理的输出是否有足够输入支持,再邀请团队评审并记录修改结论。

交付前,用三个问题检查

有没有只接收却不产生输出的处理?有没有缺少来源却产生输出的处理?内部拆分后,原有的边界数据是否仍能一一对应?

数据流图常见问题

数据流图和流程图有什么区别?

数据流图(DFD)表达数据从哪里来、经过什么处理、存放在哪里,以及流向谁;箭头表示数据传递。流程图表达操作的先后顺序和判断分支。要说明审批是否通过或任务下一步做什么,可使用在线流程图;要分析系统中的信息流转,则使用数据流图。

数据流图有哪些基本符号?

常见四要素是外部实体、处理、数据存储和数据流。外部实体通常用矩形,处理可用圆形或圆角矩形,存储可用两条平行线或开口矩形,数据流用带名称的有向箭头。不同表示法的外形有所差异,一张图中应保持同一种约定。

上下文图、0层和1层数据流图怎么区分?

上下文图把整个系统视为一个处理,只展示它与外部实体交换的数据;首层分解展开主要处理与内部存储,再按需要细化子图。资料对“0层”的编号存在不同约定,有的指上下文图,有的指第一次内部拆分。团队应先统一命名,并始终核对父图与子图的边界输入输出。

数据流图能代替 ER 图或 UML 图吗?

不能完全代替。数据流图侧重数据的流动与处理;ER图侧重实体、属性与关系;UML图可分别表达系统结构、交互或行为。可以围绕同一个业务分别绘制,通过统一的数据名称把它们联系起来。

可以免费开始画数据流图吗?

可以注册账号,按当前免费权益开始创建与编辑。可编辑文件、导出、协作及 AI 等能力的额度以账号和价格页为准;社区模板可能有独立的使用条件。选择前先确认自己需要的功能与额度。

AI 可以帮助整理数据流图吗?

可以把业务描述交给 AI 辅助整理外部实体、处理和数据清单,再据此绘图。无论初稿来自 AI 还是模板,都要由熟悉业务的人检查系统边界、数据名称、连接关系与分层平衡,不能直接把初稿当作已经验证的系统设计。

让系统中的数据关系更清楚

从一张数据流图开始,
对齐团队对系统的理解

先画系统边界,再补处理与存储,把未确认的问题放到图上一起讨论。

开始绘制数据流图