假设一个工厂的采购部每天需要一张采购订单报告。 报表按部件号排序，表中列出了需要重新订购的所有部件。 对于需要重新订购的每个部件，必须列出部件编号、部件名称、订货量、当前价格、主要供应商和副供应商的数据。 零部件入库或出库称为办公，通过仓库放置的CRT终端将办公报告给订货系统。 如果某个零件的库存数量小于库存极限值，就应该重新订货。
数据流图包含四个分量：
1、源点和终点
2、处理
3、数据存储
4、数据流
因此，第一步可以从问题说明中提取数据流图的四个分量。
首先考虑数据的来源点和端点。 从上面对系统进行说明，可以看到“采购部每天需要一张订单报表”、“通过仓库里的CRT终端向订单系统报告事务处理”。 因此，3358www.Sina.com/，http://ww.Sina.com/
接下来考虑处理，再次阅读问题的说明，“采购部需要报告书”。 很明显他们还没有这样的报告，所以需要处理生成报告。 事务的结果是改变零件的库存量，但改变数据的操作都是处理，所以加工事物是另一个处理。
最后，考虑数据流和数据存储。 因为系统会把订单发送给采购部，所以订单是数据流。 很明显，事务必须从仓库发送到系统，事务是另一个数据流。 生成报告和处理事务在时间上明显不匹配3354-1每次发生一个事务时都会立即处理，但订单报告每天只生成一次。 因此，用于制作订单的数据必须保管一段时间。 也就是说，应该保管数据
构成数据流图的要素可以从描述问题的信息中提取
来源/端点处理采购员
仓库管理员
生成报告
处理事务
数据流数据存储采购订单报表
零件编号
零件名称
订单数量
当前价格
主要供应商
子提供程序
事务
零件编号
事务处理类型
数量
订单信息
库存清单
零件编号
库存量
库存量阈值
一旦分离了数据流图的所有四个成分，就可以画数据流图了，你怎么开始画呢？
注：数据流图是系统的逻辑模型，但任何计算机系统实质上都是信息处理系统。 也就是说，计算机系统本质上是将输入数据转换为输出数据。 因此，任何系统的基本模型都由几个数据源点/终点和一个处理组成，这个处理体现了系统对数据加工转换的基本功能。
从非常高的层次绘制数据流图是一种很好的方法，如基本的系统模型。 这是一个很有价值的通讯工具，因为高层次的数据流图可以一目了然地看到是否列出了所有指定数据的终点/源点。
但是订货系统的基本系统模型图只是抽象的，从这个图中可以代表订货系统的信息非常有限。 下一步应该细化基本的系统模型，描绘系统的主要功能。 从信息表中可以看出，“生成报表”和“处理事务处理”是系统必须完成的两个主要功能，它们代替了采购订单系统基本系统模型图的采购订单系统。 另外，细分的数据流图中添加了两个数据存储器。 处理交易需要“库存清单”的数据。 生成报告和处理事务处理是在不同的时间进行的，因此必须保存订单信息。 除了订单系统基本系统模型图中列出的两个数据流之外，还有两个数据流与数据存储相同。 这是因为从数据存储中检索和放入的数据通常与原始数据相同。 换句话说，数据流和数据流只是同一数据的两种不同格式。
采购员是数据终点
现在考虑通过仓库管理员是数据源点。系统的逻辑数据流。 在发送事务处理时，必须首先接收它。然后，如果根据事务处理内部修改库存列表的最后更新的库存量小于库存量阈值，则应该处理重新订购，即采购订单信息。 因此，将"事务处理"功能分解为以下内容
述3个步骤，这在逻辑上是合理的：“接受事务”,"更新库存清单","处理事务"。为什么不进一步分解“产生报表”这个功能呢？订货报表中需要的数据在存储的订货信息中全部都有，产生报表只不过是按一定顺序排列这些信息，再按一定格式打印出来。然而这些考虑纯属具体实现的细节，不应该在数据流图中表现。同样道理。对“接收事务”或“更新库存清单”等功能也没有必要进一步细化。总之，当进一步分解将涉及如何具体实现一个功能时就不应该再分解了。
当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同。
此外还要注意图中处理编号的方法。处理1.1，1.2和1.3是更高层次的数据流图中处理1的组成元素。如果处理2被进一步分解，它的组成元素的编号将是2.1，2.2，……；如果把处理1.1进一步分解，则将得到编号为1.1.1，1.1.2，……的处理。