系统数据流程图分析与设计

系统分析是信息系统开发过程中重要的一步，也是关键性的一步。只有通过系统分析才能把对系统功能和性能的总体概念描述为具体的系统需求说明，从而奠定整个系统开发的基础。实践表明，系统分析工作的好坏，在很大程度上决定了信息系统的成败。

在系统分析阶段，要使用系统的观点和方法，把复杂的对象分解为简单的组成部分，并确定这些组成部分的基本属性和彼此之间的关系。

系统分析是一个不断加深认识和逐步细化的过程。在这个过程中使用了结构化系统分析方法、数据流程图、数据字典等方法和工具。

该阶段产生的系统分析说明书，既是后续阶段开发工作的依据，也是将来信息系统进行验收的依据。

本节将从系统初步调查与可行性分析、系统详细调查、业务流程分析、数据流程分析、数据字典、处理逻辑描述和系统分析说明书七个方面对管理信息系统的分析进行详细论述。

一、系统分析概述

1. 系统分析的任务

系统分析阶段的基本任务是系统分析员和用户一起在充分了解用户的要求的基础上，把双方对目标系统的理解表达为系统分析说明书。

系统分析说明书通过评审之后，将成为目标系统设计的依据和验收的依据。

(1) 目标系统的来源。

目标系统并不是无源之水，由系统开发人员凭空想象出来的，目标系统的逻辑设计必须从现行系统入手，建立在现行系统的基础之上，经过对现行系统的优化，目标系统功能更强，效率更高，使用更方便，要“优于现行系统”。因此，系统分析员要在系统规划工作的基础上，与用户密切配合，用系统的思想和方法，对企业的业务活动进行全面的调查分析，收集报表、账单等业务资料，详细掌握现行系统的工作流程，分析其局限性和不足之处，找出制约现行系统的关键问题，列出几种可行的解决方案，并综合分析、比较这些方案的优劣，最终确定目标系统的逻辑功能。

概括地说，目标系统建立在现行系统的基础之上，且优于现行系统。

(2) 系统分析阶段的困难。

系统分析是系统开发中最重要的阶段，也是困难最多的阶段。最主要的困难来自于系统分析人员和用户对问题的不同理解。

一般情况下，系统分析员往往是计算机信息处理的行家，但缺乏足够的关于目标系统的业务知识，在系统调查中系统分析员往往面临关于业务流程的困惑。一个稍具规模的系统，其业务数据数量是相当大的，有反映各种业务情况的报表、账簿、业务数据，有业务人员手中的各种正规的或非正规的手册、技术资料、规章制度等。各种业务之间的关系复杂，不熟悉业务情况的系统分析员往往被淹没在各种信息流程中，难以理出头绪，更难以分析出制约现行系统的“瓶颈”问题。

具体来说，用户精通业务，但往往缺乏足够的计算机方面的知识，对计算机“能够做什么”和“不能够做什么”比较模糊。而且，用户虽然精通自己的业务，但不善于把业务过程明确地表达出来，不知道该给系统分析员介绍些什么。对一些具体业务，用户认为理所当然就该这样做或那样做。特别是对某些决策问题，往往根据的是个人的经验和直觉。

由于以上原因，使得系统分析员和用户的交流比较困难，对同一问题的描述容易出现误解和遗漏，而这些误解和遗漏往往成为系统开发的隐患。例如，系统分析说明书是这一阶段的工作成果，它可以认为是用户与开发人员之间的技术合同。系统分析说明书应当严谨准确，无二义性，才能作为设计基础和验收依据。否则，如果开发人员和用户对系统分析说明书中的同一个问题有不同的理解，即使这样的系统开发出来了，在验收时也会引起双方的纠缠。

(3) 问题的解决。

为了克服这些困难，做好系统分析工作，为信息系统的成功开发奠定基础，需要系统分析员与用户团结起来，精诚合作。系统分析人员应当树立“用户第一”的思想，虚心地向用户学习业务知识，并向用户介绍有关的计算机知识，加强双方的沟通。除此之外，还要借助一定的技术和工具，特别是直观的图表可以帮助系统分析员与用户沟通。20世纪70年代以来，出现了很多这样的工具，如业务流程图、数据流程图、数据字典等。

2. 系统分析的目标

管理信息系统的开发就是要实现目标系统的物理模型，即建立一个物理系统。物理模型是由系统的逻辑模型经过实例化得来的。系统的逻辑模型只描述系统要完成的功能和要处理的信息，与物理模型相比，逻辑模型忽略了实现的方法与细节。物理模型用来描述系统“怎么做”的问题，逻辑模型则用来描述系统“做什么”的问题。需求分析的目标就是要借助于当前系统的逻辑模型，导出目标系统的逻辑模型，解决目标系统“做什么”的问题。

图8－1所示的是目标系统逻辑模型建立的过程

图8－1 目标系统逻辑模型的建立

(1) 获取现行系统的物理模型。

现行系统可能是已经存在的计算机数据处理系统，也可能是手工的数据处理过程。系统分析员通过现场调查研究，了解现行系统的运行情况，掌握现行系统的组织机构、资源利用、日常业务数据处理过程以及数据的输入和输出等，并借助一个具体的模型来反映自己对现行系统的理解。这一模型就是现行系统的物理模型，它客观地反映出现行系统的实际情况。

(2) 抽象出其逻辑模型。

在物理模型中有许多关于物理系统实现的细节问题，去掉这些非本质的细节性问题，从物理模型当中抽取那些关于“做什么”的本质性问题，从而得到反映系统本质的逻辑模型。

(3) 建立目标系统的逻辑模型。

目标系统的逻辑模型建立在现行系统的逻辑模型基础之上。分析目标系统与现行系统逻辑上的差别，明确目标系统要“做什么”，对现行系统的逻辑模型进行调整，从而导出目标系统的逻辑模型。

(4) 优化目标系统的逻辑模型。

对目标系统的逻辑模型，还要根据实际情况做一些优化。例如，目标系统的用户界面优化、系统功能的优化、输入输出的优化等。它客观地反映出现行系统的实际情况。

3. 系统分析的内容

系统分析按其内容可以分为目标分析、需求分析和功能分析。

(1) 目标分析。

目标分析包括对现行系统的组织目标分析和目标系统的组织目标分析。任何一个企业或组织都有自己的目标，这是组织开展各项工作的指南。信息系统是帮助企业实现其总体目标的，因此，在开发信息系统时，首先应该弄清楚企业的组织目标。组织目标分析包括以下内容。

①根据系统调查的结果，分析、归纳、确定现行系统中的关键问题，列出问题表。

②根据问题表，画出现行系统目标树。

③分析、确定各个分目标以及它们之间的关系，如果目标之间有冲突，便要确定解决冲突的方法。

④根据各分目标在系统中所起作用的轻重程度，重新排列问题表。这是确立新系统目标的基础。

目标系统的组织目标分析是指在现行系统组织目标分析的基础上，确定目标系统应该在哪些方面发挥作用以及如何发挥作用。一般来讲，目标系统在以下两个方面功能得到了加强。

①辅助管理功能。

新的计算机信息管理系统可以帮助人们从大量烦琐、重复的日常工作中解放出来。例如，生产经营情况的统计，财务记账，填制各类报表等。

②辅助决策功能。

新的计算机信息管理系统可以充分发挥信息存储、检索、传递的能力和迅速、准确的计算能力，人—机结合解决问题的能力，帮助企业决策者制订各种计划，实现辅助决策功能。

(2) 需求分析。

在系统分析阶段，系统分析员要对企业各有关部门的业务流程进行详细的调查。除此之外，还要向各级领导和业务人员就系统处理事务的能力和决策功能的需求做出分析:

①按照企业的管理目标并结合业务流程图，分析系统事务处理能力需求的合理性，既要对不合理的业务流程进行调整，还要对系统事物处理能力需求进行调整。

②按照企业的管理目标，分析决策辅助功能需求的合理性。

③根据信息系统的投资规模，综合分析、平衡各项需求，找出关键的、主要的需求，并制订出满足这些需求的初步计划，为功能分析打下基础。

需求分析的结果还要反馈给业务人员，以征求意见进行修改。

(3) 功能分析。

这里所说的功能指的是目标系统应该具备的功能。

功能具有层次性的特点，各层次功能之间存在着信息交换。因此，系统的功能分析主要包括功能层次结构分析和信息关联分析两个方面。关于功能分析的方法有很多，例如，下面涉及的结构化系统分析和设计方法。它是一种功能和数据分析、分解相结合的技术。

4. 系统分析的方法

随着计算机技术的不断提高和信息系统的普遍应用，人们不断尝试、总结进行系统分析的方法。在信息系统开发的实践中，常用的系统分析的方法有: 结构化分析方法、面向数据结构的Jackson系统开发方法、原型化方法等。这里，我们简要介绍结构化分析方法。

结构化分析方法 (Structured Analysis，SA) 是面向数据流进行分析的方法。它利用图形作为表达工具，非常清晰、简明，易于学习和掌握。具体地说，它按照自顶向下、逐层分解的原则，将系统功能逐层分解为多个子功能，对应于多个子系统，并在功能分解的同时进行相应的数据分析和分解，借助于数据流程图来表示。

二、系统初步调查与可行性研究

系统初步调查和可行性分析，是系统分析的第一步，其中系统初步调查是系统可行性分析的前提，可行性分析是在系统初步调查的基础上进行的。

1. 系统初步调查

系统初步调查的基本内容包括以下几点。

(1) 系统的基本情况。

(2) 系统信息处理情况。

(3) 系统资源情况。

(4) 态度。

2. 可行性研究

可行性是指在组织内外当前的具体条件下，进行某项目的必要性和可能性的研究。

可行性分析就是对项目开发的可能性和必要性进行分析，避免盲目投资。主要是必要性分析和效益分析，以决定是否建立MIS，同时还要进一步进行技术可行性分析、投资/效益分析、组织管理可行性分析，确定是否存在否定项目的可能性。

(1) 经济可行性。

估算新系统开发所需要的投资费用和未来的运行维护费用，预测新系统的效益，进行投资/效益分析，评估投资风险。

(2) 技术可行性。

采用的开发方法、开发环境和开发技术是否先进、可行，能否达到所需要的技术力量和设备。

(3) 管理可行性。

企业的领导是否重视、领导的信息意识和企业的管理水平如何。

(4) 环境方面的可行性。

人员变动、运行环境、方式是否可行。

3. 可行性分析报告

可行性分析报告是可行性分析最终形成的文档，其核心内容包括系统简述、系统的目标介绍、系统可行性的结论等。具体如下:

(1) 概述: 包括编写目的、背景、定义和参考资料。

(2) 系统目标: 包括近期目标和长远目标。

(3) 对现行系统的分析，包括以下三个方面。

①组织机构、职能、地理分布、概况和功能要求。

②运行情况、资源情况和开发条件。

③存在问题和薄弱环节。

(4) 建立的新系统，包括以下四个方面。

①新系统的战略目标、规模和总体结构。

②系统的信息结构、功能要求、技术指标和性能要求。

③新系统可能产生的影响和变革，包括对现行管理制度的影响、对人员的变动及要求等。

④可选择的其他系统方案。

(5) 投资与效益分析，可行性研究。

三、系统详细调查

1. 详细调查的目的和原则

实事求是地、全面地对现行系统进行调查是分析与设计工作的基础，现行系统包括手工信息处理系统和某些已经采用了计算机进行处理的系统。详细调查的目的在于完整地掌握现行系统的现状，发现系统的薄弱环节和存在的问题，收集有关的数据和资料，为下一步系统化分析工作和建立目标系统的逻辑模型做好准备。

详细调查应该按照自顶向下的系统化观点全面展开。首先从组织管理的最顶层开始，然后再调查第二层的组织管理，依此类推，直到调查清楚组织的全部管理工作。这样做可以使调查者按照一定的顺序进行调查工作，不会因为调查工作量太大而手忙脚乱、顾此失彼。

详细调查还应该遵循用户参与的原则。调查应该有业务部门的主管人员、业务人员和系统分析人员共同进行。业务人员熟悉业务本身，但不一定了解计算机，而系统分析人员虽然掌握计算机技术，但对业务部门的业务不够清楚。两者结合，就能长短互补，能更深入地发现系统存在的问题，并共同寻找解决问题的方案。

2. 详细系统调查的主要内容

详细调查的内容可以归纳为以下几类。

(1) 现行系统的环境和运行状况。

现行系统的环境和运行状况包括现行系统的发展历史、规模、经营状况、发展战略、业务范围、与外界的联系等。这些信息有助于确定系统的边界、外部环境及其接口、目前的管理水平等。

(2) 组织结构和人员分工。

现行系统的组织机构、领导关系、人员分工的信息有助于了解企业组织的构成、业务分工以及人力资源的开发利用情况。

(3) 业务流程。

不同的系统具有不同的业务处理过程，系统分析员要全面、细致地了解企业各有关部门的业务内容、物流和信息流的流通情况。除此之外还要对有关业务的各种输入、输出、处理过程、处理速度、数据量等进行了解。

(4) 各种计划、报表的处理。

各种计划和报表都是信息的载体。在详细调查中，凡是与业务有关的所有计算机和手工保存及传递的信息载体都要全面搜集，了解其产生和使用的部门、发生周期、用途、所包含的数据项及各数据项的类型、长度、含义等，为信息的分析和统计所用。

(5) 资源情况。

系统资源包括人力、物力、资金、设备、建筑资源以及各种资源的分布。如果已经配置了计算机还要详细调查计算机的型号、功能、容量、配置、操作系统、数据库、目前使用的情况以及存在的问题等。

(6) 约束条件。

约束条件包括现行系统在人员、资金、设备、业务处理方式、时间、地点、国家的有关政策、信息系统建设的有关政策等方面的规定和限制条件。

(7) 薄弱环节。

在调查中要特别注意收集用户的各种意见和要求，找出现行系统中存在的问题，并分析其产生的原因。现行系统的各个薄弱环节正是目标系统中要解决和改进的主要问题，也是其目标的重要组成部分。

3. 详细调查的方法与工具

(1) 详细调查的方法。

详细调查的方法很多，常用的有座谈调查、表格调查、实地调查和抽样调查。

①座谈调查。

座谈调查就是调查人员与被调查人员面对面地坐在一起，通过有目的的谈话获取所需信息的一种调查方法。调查者既可以事先拟好访谈提纲，在调查时按照提纲有序地发问，让被调查者回答预定问题; 也可以不预拟提纲，在座谈时与被调查者自由交谈，从中获取所需信息。采用座谈调查法，调查人员可以当场评定所了解信息，根据自己的判断进行深入而灵活的讨论，但这种方法费时、费力，谈话前要做好准备工作，谈话过程中还要具有一定的方法和艺术，以引导被调查人员积极、主动、乐观、明确地谈出所要了解的内容。

②表格调查。

表格调查就是事先准备好有关表格，通过让被调查对象填写表格来获取有关信息。表格调查适用于那些结构性较强、指标含义明确而具体的内容。例如，对计算机资源的调查，可设计计算机资源调查表，表格内容包括: 目前所用计算机系统的类型、容量、分布、软硬件配置、所采用的操作系统、应用软件、处理数据的格式等。

③实地调查。

实地调查就是调查人员深入现场对调查对象的情况进行观察和记录，取得第一手资料。调查人员往往对调查对象的业务不甚了解，如果能亲自到业务现场进行观察，甚至亲自动手操作，会有非常鲜明的印象。通过实地调查可以获取一些无法通过别的方法获得的信息，也有助于证实座谈调查法和表格调查法所发现的问题。但是，实地调查要求调查人员要具有敏锐的洞察力、良好的记忆力以及综合分析能力。

④抽样调查。

抽样调查是根据概率统计的随机原则，从全体被调查对象中选取出部分对象进行详细调查，并将统计分析得出的调查结果推广到全体对象。该方法适用于那些需要全面资料而又不可能进行全面调查，或者进行全面调查在实现中有困难，或者没有必要进行全面调查的情况。例如，在办公活动中有大量的信息是随机的，一天接、打电话的次数，每一次通话的时间等，对这样的信息进行抽样调查是比较有效的方法。

(2) 详细调查的工具。

在详细调查过程中使用了大量的、直观的、形象的图表工具。这些工具包括: 用于描述管理业务状况的业务流程图，用于描述和分析数据、数据流程以及各项功能的数据流程图，用于将所有的数据元素进行描述说明的数据字典，用于说明用户对数据存储提出的查询要求的数据立即存取图，以及用于描述处理功能和决策模型的判定树和判定表等。有关这些图表工具将在下面进行详细说明。

四、业务流程分析

对现行系统的详细调查中，通常会收集到大量的报表、单据、文件等资料。需要按照业务功能将业务处理过程中的每一个步骤用一个完整的图形表达出来。并在绘制业务流程图的过程中发现系统中存在的问题，分析并改正问题，对业务处理过程进行优化。

1. 业务流程分析的目的与任务

在对现行系统的组织结构和功能进行分析时，需要将详细调查中有关某项业务流程的资料从业务流程的角度串起来以便做进一步的分析。业务流程分析可以帮助系统分析人员了解该业务的具体处理过程，发现系统调查中的错误和疏漏，修改现行系统的不合理部分，优化业务处理流程，为目标系统的开发打下基础。

业务流程图 (Transaction Flow Diagram，TFD) 是业务流程分析所使用的图形工具，它是用一些规定的符号和连线来表达某个具体业务处理过程。可以认为，业务流程图是在业务功能的基础上将其细化，利用系统调查的资料，用一个完整的图形将业务处理过程中的所有处理步骤串联起来。绘制业务流程图是业务流程分析的重要步骤。

图8－2 业务流程图的基本图形符号

2. 业务流程图的基本符号

业务流程图的画法目前尚未统一。我们使用图8－2所示的图形符号为例。图8－2所示的基本图形符号共有5个，这5个基本图形符号所代表的内容与业务系统最基本的功能一一对应。圆圈表示业务处理发生的单位; 矩形框表示对业务处理的描述; 左右两端为弧形的框图表示数据存储; 带箭头的线段表示物流或信息流，即信息的传递; 平行四边形框表示产生的数据表单。

3. 业务流程图的绘制

业务流程图基本上是按照业务的实际处理步骤和过程来绘制的。图8－3表示的是某图书馆采编室的业务流程图。该采编室有两个工作组，订书组承担图书订购任务，登记组负责新书的登记和验收。系统分析员在承担了计算机信息管理系统的任务之后，对该采编室的业务进行了详细的调查研究，在此基础之上绘制出了采编室现行系统业务流程图。

图8－3 某图书馆采编室的业务流程图

从图8－3中可以看到，业务流程图表示了各个组织机构的业务处理过程和它们之间的业务分工和联系，表示出了连接各机构的信息流、物流的流通情况和传递关系，反映出了现行系统的界限、环境、输入、输出、数据存储和处理。业务流程图是系统分析的重要依据。

五、数据流程分析

数据是信息的载体，也是系统要处理的主要对象。因此，必须对现行系统调查中所收集到的数据以及处理数据的过程进行分析和整理。数据流程分析是今后建立数据库系统和设计功能模块处理过程的基础。

1. 数据流程分析的内容

管理业务调查过程中所绘制的业务流程图虽然形象地表达了管理中信息的流动和存储过程，但仍然没有完全脱离物质要素，例如图书、货物、产品等。为了用计算机进行信息管理，必须进一步舍去物质要素，收集有关数据资料，绘制出数据流程图，为下一步分析做好准备。

数据流程分析是把数据在组织内部的流动情况抽象地独立出来，舍去了具体组织机构、信息载体、物质、材料等，单从数据流动过程来考查实际业务的数据处理模式。数据流程分析的目的就是要发现和解决数据流通中的问题，这些问题包括数据流程不畅、前后数据不匹配、数据处理过程不合理等。这些问题，有些是属于数据处理流程的问题，有些是属于原系统管理混乱的问题。一个通畅的数据流程是目标系统实现业务处理过程的基础。

具体来说，数据流程分析的内容包括以下4点。

(1) 收集现行系统全部输入单据和报表、输出单据和报表以及数据存储介质 (账本、清单等) 的典型格式。

(2) 明确各个处理过程的处理方法和计算方法。

(3) 调查、确定上述各种单据、报表、账本、清单的制作单位、报送单位、存储单位、发生频率、发生的高峰时间和高峰量等。

(4) 注明各项数据的类型、长度、取值范围等。

数据流程图 (Data Flow Diagram，DFD) 是数据流程分析所使用的主要工具之一。数据流程图用少量几种符号综合地反映出信息在系统中的流动、处理和存储情况。数据流程图具有抽象性和概括性的特点。数据流程图的抽象性是指它完全舍去了具体的物质，只保留了数据的流动、加工、处理和存储; 数据流程图的概括性是指它可以把信息中的各种不同业务处理过程联系起来，形成一个整体。无论是手工信息处理还是计算机信息处理，都可以用数据流程图表达出来。

2. 数据流程图的基本符号

数据流程图由四个基本符号组成。这里，我们采用图8－4所示图形符号来表示。这四个基本符号分别代表了外部实体、数据处理、数据流和数据存储。

(1) 外部实体。

外部实体是系统之外的、又与系统有联系的人或事物，外部实体也可以是另外一个信息系统。外部实体是系统数据的来源和去处，它们和本系统都有着信息传递关系。

(2) 数据处理。

数据处理是对数据的逻辑处理，也就是数据的变换。输入数据在此进行变换产生输出数据。

图8－4 数据流程图的基本符号

(3) 数据流。

数据流表示流动着的数据，是处理功能的输入和输出。数据流可以是一项数据，也可以是一组数据 (如订货单)，可以用来表示对数据文件的存储操作。

(4) 数据存储。

数据存储指通过数据文件、文件夹等存储数据。这里指的是数据存储的逻辑描述，与保存数据的物理地点和物理介质无关。

在数据流程图中，指向数据存储的箭头，表示从送数据到数据存储的过程，即对数据存储的改写、存放等; 离开数据存储的箭头，表示从数据存储中读取数据。

3. 数据流程图的画法

数据流程分析的根本目的是分析出合理的信息流动、处理、存储的过程。无论是采用HIPO (Hierarchical Input Process Output) 法还是采用结构化分析方法，其基本思想是一样的。

(1) 先把系统看成一个整体，作为一个大的功能，明确系统的输入和输出。

(2) 系统为了实现这个整体功能，内部必然有信息的处理、传递、存储功能。

(3) 这些处理又可以分别看作成一个小的功能，其内部又有数据的处理、传递、存储的过程。

(4) 如此下去，自顶向下，逐层分解，一级一级地剖析，直到所有的处理步骤都具体到可以实现为止。

本书以某高等院校的学籍管理系统为例说明数据流程图的画法。

第一步，画数据流程图的顶层图，初步确定系统的输入、输出和外部实体。

整个系统看成一个功能。招生办等外部实体是系统的数据来源，教育部、用人单位等是系统数据的去向。

顶层图高度抽象，在实际中无法使用。如图8－5只概括描述了系统的轮廓、范围，标出了最主要的外部实体和数据流，需要进行进一步细化。

图8－5 学籍管理系统的顶层数据流程图

第二步，分解顶层图，进行第一级细化。

根据学籍管理系统的处理功能，学籍管理可以进一步分解为: 学生成绩管理、学生奖惩管理、学生学籍变动管理三个子功能，得到第一级细化的数据流程图如图8－6所示。

图8－6 学籍管理系统的第一层数据流程图

注意: 在进行功能分解的同时，数据也进行了分解，得到了相应的、更具体的数据流和数据存储。

第三步，逐步分解、扩充、调整，进行第二级细化。

我们以P2“成绩管理”为例来详细地说明逐层分解的思想。

任课教师在期末时将成绩单交到院系里进行成绩分析，相应的情况记录在学籍表里面，这是学生奖惩的依据。对重修课成绩也要进行重修成绩分析，相应的情况也记录在学籍表里。对学生的成绩还要进行统计，相应的统计结果上交有关领导。这样，P2“成绩管理”分解成了三个更小的功能: P2.1“分析期末成绩”、P2.2“分析重修成绩”、P2.3“统计成绩”。可以得到P2“成绩管理”框的展开图，如图8－7所示。

“成绩管理”框中的一些处理，还需要进一步展开。例如，“分析成绩”包括以下几个处理:

把每个学生的各科成绩登记在所在班的“学习成绩一览表”中;

根据“学习成绩一览表”，将每个学生的成绩登记在学籍表中;

根据“学习成绩一览表”，填写成绩通知单，发给学生;

根据“学习成绩一览表”，统计符合获奖条件的成绩，交系里领导;

根据“学习成绩一览表”和学籍表中记载的历史情况，决定留级或退学名单。

这样，“分析期末成绩”处理展开如图8－8所示。

图8－7 P2“成绩管理”框的展开

图8－8 P2.1“分析期末成绩”框的展开

4. 绘制数据流程图的注意事项

数据流程图具有图形符号少、通俗易懂、直观等特点，是系统分析员与用户交流思想的工具。在数据流程图的绘制中，要随时与业务人员进行讨论、分析，对所绘制的数据流程图进行补充和纠正，直到得到用户较为满意的数据流程图。

在绘制数据流程图中还要注意以下事项。

(1) 划分层次，逐层分解。

为了表达数据处理过程中的数据加工情况，只用一个数据流程图是不够的。稍微复杂的实际问题，出现在数据流程图中的加工常常有十几个甚至几十个。把这些加工处理放在一张数据流程图中看起来很不清楚，杂乱无序。解决的办法是采用分层的数据流程图。

顶层数据流程图: 采用“自顶向下，逐步求精”的方法，即先把整个系统当做一个处理功能看待，画出最粗略的数据流程图，然后逐层向下分析，分解为详细的低层次数据流程图。

(2) 数据流程图的正确性检查。

数据流程图是系统分析阶段最主要的表达工具之一，其正确与否直接关系到整个管理信息系统开发的质量。因此，保证数据流程图的正确性十分必要。

通常我们从以下几个方面去检查数据流程图的正确性。

①任何一个处理至少有一个输入数据流和一个输出数据流。

②任何一个数据存储，都必定有流入的数据流和流出的数据流。

③任何一个数据流至少有一端是处理框。

④图中某一处理框的输入数据流、输出数据流必须出现在相应的子图中，否则，就会出现父图与子图的数据不平衡。

⑤其他注意事项。

数据流程图上出现的所有的图形符号只限于上面四种基本图形符号;

数据流程图的主图通常应包含上述四种基本符号;

在初画时可以忽略细节问题，集中精力于主要数据流。例如，处理框中的出错信息可以不画在数据流程图中，对异常状态的处理留在系统设计阶段来完成;

数据流程图中不要夹带控制流。因为数据流程图是实际业务流程的客观映像，说明系统“做什么”的问题，而不是表明系统“怎么做”的问题，数据流程图不关心系统的执行顺序。

5. 数据流程图的其他表示方法

由于不同的国家和组织都有自己的系统开发标准和图表工具，因此，数据流程图的表示方法也有许多。我们在上面介绍的图示方法没有画曲线、斜线和圆圈的困难，便于在计算机上实现和管理。

除此之外，数据流程图还有泡泡图等表示方法，学籍管理系统的第一层数据流程图的泡泡图表示方式如图8－9所示。

图8－9 学籍管理系统的第一层数据流程图 (泡泡图)

六、数据字典

1. 数据字典的作用

数据流程图对于数据的详细内容却无法在数据流程图中反映。例如，在我们前面所介绍的例子里，数据存储“学籍表”包括哪些内容，在数据流程图中就无法具体、准确地描述。又如“判定留级或退学”的具体处理逻辑，在流程图上也无法表示。而只有当数据流程图中所出现的每一个成分都给出了明确的定义之后，才能完整、准确地描述一个系统。因此，还需要其他的工具对数据流程图进行补充说明。

数据字典 (Data Dictionary，DD) 就是在系统数据流程图的基础上，进一步定义和描述所有的数据项、数据结构、数据存储、处理过程和外部实体的详细逻辑内容与特征的工具。数据流程图和数据字典等工具相互配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

数据字典的作用是对于数据流程图中出现的所有命名元素都在数据字典中作为一个条目加以定义，使得每个图形元素的名字都有一个确切的解释。因此，建立数据字典的工作量很大，相当烦琐，但这是一项必不可少的工作。数据字典在系统开发中具有十分重要的意义，不仅在系统分析阶段要使用它，在系统的整个研制过程中以及系统运行中都要使用它来提供帮助。

2. 数据字典的条目

数据字典中共有六类条目，即数据项、数据结构、数据流、数据存储、处理逻辑和外部实体。

(1) 数据项。

数据项又被称为数据元素，是数据的最小组成单位，如学号、姓名等。

数据项的描述，应该包括以下属性: 数据项名称、数据项编号、别名、数据项类型、数据项长度、数据项取值范围和取值的含义。

数据字典中数据项条目的表示方式如图8－10所示。

图8－10 数据项条目

(2) 数据结构。

数据结构用于描述某些数据项之间的关系。一个数据结构可以是由若干个数据项组成的; 也可以是由若干个数据结构组成的; 还可以是由若干个数据项和数据结构组成的。数据结构是个递归概念。

数据字典中对数据结构的描述应该包括以下属性: 数据结构的名称; 数据结构的编号;数据结构的简要说明; 数据结构的组成等。

数据字典中数据结构条目的表示方式如图8－11所示。

图8－11 数据结构条目

数据结构描述的重点是数据结构的组成。数据结构可以包括若干个数据项和数据结构。这些数据之间的组合关系有三种特殊情况:

①任选项。

任选项是指那些可以出现，也可以省略的项，在数据字典中用 “［］”表示。如学生登记卡中的［曾用名］，可以有，也可以没有。

②必选项。

必选项是指那些在两个或者多个数据项中，必须选择其中一个的项。在数据字典中，是用 “{ }”将多个候选的数据项括起来表示必选项。例如，在高校中所开设的课程，或者是必修课，或者是选修课，两者必居其一，就用 {必修课，选修课} 表示。

③重复项。

重复项是指那些可以多次出现的数据项。在数据字典中，是“项目名称* ”来表示重复项。例如，某个学生的成绩单包括了多门课程的成绩，就用“成绩* ”来表示。

(3) 数据流。

数据流由一个或一组固定的数据项组成。在数据字典中关于数据流的描述除了数据流名称、数据流编号、简要说明之外，还应该包括以下属性。

①数据流的来源。

数据流可以来自某个外部实体、数据存储或某个处理。

②数据流的去向。

如果数据流的去向不止一个，则要分别说明。

③数据流的组成。

数据流的组成是指数据流所包含的数据结构。

④数据流的流通量。

数据流的流通量是指单位时间里的数据传输次数。流通量可以是平均传输数据量，也可以是最高流通量或最低流通量。

数据字典中数据流条目的表示方式如图8－12所示。

图8－12 数据流条目

(4) 数据存储。

在数据字典中关于数据流的描述除了数据流名称、数据流编号、简要说明之外，还应该包括数据存储的组成等属性。

数据字典中数据存储条目的表示方式如图8－13所示。

图8－13 数据存储

(5) 处理逻辑。

数据字典中的处理逻辑条目，仅是对数据流程图中最底层的处理逻辑加以说明。除了处理逻辑的名称、编号、简要说明之外，还要说明处理逻辑的输入数据流和输出数据流。对处理过程的描述，目的在于使读者有一个比较明确的概念，了解这一处理框的主要功能。详细的处理逻辑则要借助其他的工具进一步描述。

数据字典中处理逻辑条目的表示方式如图8－14所示。

图8－14 处理逻辑条目

(6) 外部实体。

外部实体是信息系统数据的来源和去向。在数据字典中对外部实体的描述应该包括: 外部实体名称、编号、简要说明以及外部实体产生的数据流和系统传送给该外部实体的数据流。外部实体的数量对于系统的业务量有参考作用，也应该在条目中加以说明。

数据字典中外部实体条目的表示方式如图8－15所示。

图8－15 外部实体

3. 数据字典的使用与管理

数据字典的建立有两种方式，既可以由手工方式生成，也可以由计算机自动生成。手工方式是将各类条目按上面所介绍的格式写在卡片上或写在纸上，并分类建立一览表。计算机方式是在手工方式的基础上，整理、存储在计算机中，由软件进行管理。一些大、中型计算机有专门的自动化数据字典软件对数据进行管理，查询和修改都十分方便。而对于规模较小的系统，采用手工方式是比较合适的选择。

数据字典实际上是“关于系统数据的数据库”。在整个系统开发阶段以及系统运行维护阶段，数据字典是必不可少的工具。在系统分析的过程中，使用数据字典，可以很方便地通过名称去查询数据的定义; 同时也可以按照各种要求，随时列出各种表，以满足分析员的需求。使用数据字典，也可以反过来，由描述内容去查询数据的名称。

数据字典可以确保数据在系统中的完整性和一致性。例如，通过检查各类条目的规定格式，可以发现以下问题: 是否存在没有指明来源和去向的数据流; 是否存在没有指明所属数据存储或所属数据流的数据项; 处理逻辑与输入的数据项是否匹配; 是否存在没有输入或者没有输出的数据存储。

数据字典必须有专人进行管理。数据管理员的职责就是维护和管理数据字典，保证数据字典内容的完整性和一致性。任何人，包括系统分析员、系统设计员、程序员，若要修改数据字典的内容，都必须通过数据管理员。数据管理员还要负责把数据字典的最新版本及时通知有关人员。

七、处理逻辑描述

在数据流程图中，每个处理框只是简单地标上了处理的名字，不能表达处理逻辑的全部内容。在数据字典中，包括了对各个处理功能的一般描述，但这种描述是高度概括的，也不可能描述各个处理逻辑的全部细节。因此，需要其他的工具来详细描述处理逻辑。

用于处理逻辑描述的工具主要有结构化英语、判定表和判定树。

1. 结构化英语

结构化英语又称程序设计语言 (Program Design Language，PDL)，是一种介于自然语言和形式化语言之间的半形式化语言。

结构化英语的词汇表包括英语命令动词、数据字典中定义的名字、有限的自定义词和逻辑关系词IFTHENELSE、WHILEDO、REPEATUNTIL、CASEOF等。

结构化英语只允许使用三种基本控制结构，处理逻辑的操作运用自然语言短语来表示。这三种基本控制结构是:

(1) 简单陈述句，力求简练，不应太长，避免使用复合语句。

(2) 判定结构，IFTHENELSE或CASEOF结构。

(3) 循环结构，WHILEDO或REPEATUNTIL结构。

例1: 某商店业务“检查发货单”有这样的处理: 对于超过5000元以上的大额发货单，如果客户信誉良好，欠款不超期，则发批准书及发货单; 否则，在欠款未偿还之前不予批准。对于5000元以下的小额发货单，如果客户信誉良好，欠款不超期，直接发批准书及发货单。否则，向客户发出赊欠报告，并发批准书及发货单。

该处理逻辑用结构化英语描述如下。

IF 发货单金额超过5000元 THEN

IF 欠款超过60天 THEN

在欠款还清之前不发批准书

ELSE (欠款不超过60天)

发批准书，发发货单

ENDIF

ELSE (发货单金额未超过5000元)

IF 欠款超过60天 THEN

发批准书、发发货单、发赊欠报告

ELSE (欠款不超过60天)

发批准书、发发货单

ENDIF

ENDIF

2. 判定树

在某些处理逻辑中，处理动作需要依赖于多个逻辑条件的取值，这时，处理逻辑的描述就比较复杂。如果用上面介绍的结构化英语来表达，就需要有多重嵌套，可读性下降。在这种情况下，可以采用判定树来描述。

与其他描述工具相比，判定树适用于条件组合多、层次不是很多的情况。

例2: 处理逻辑用判定树描述如图8－16所示。

图8－16 判定树

3. 判定表

对一些条件比较多、在每种条件下取值也比较多的情况，可采用判定表的形式。这时，需要描述的处理是由一组动作组成的，而这些动作是否执行又取决于一组条件的取值。使用判定表可以把所有的条件和动作都加以说明，不易发生错误和遗漏。

运用判定表来描述决策逻辑，通常包括以下几个步骤。

(1) 首先分析、确定决策逻辑涉及的条件，列在判定表的左上方。

(2) 分析、确定每个条件的取值情况。

(3) 列出条件的所有组合情况，标在判定表的右上方。

(4) 分析、确定决策逻辑涉及的动作，列在判定表的左下方。

(5) 决定各种条件组合下所采取的行动，画在判定表的右下方。

(6) 应用合并规则，化简判定表。

例3: 处理逻辑用判定表描述如表8－1所示。

表8－1 “检查发货单”的判定表

可以看出，判定表由四个部分组成，左上方是条件说明，列出了所有可能的条件; 左下方是动作说明，列出了所有可能采取的动作; 右上方是条件组合，是针对各种条件给出的多种条件取值的组合; 右下方是动作组合，指出了在某种条件取值的组合情况下所采取的动作，如表8－2所示:

表8－2 判定表的划分

我们可以归纳出合并的原则: 对于采取相同动作的N条规则，如果有某个条件在这N列中的取值正好是该条件取值的全部情况，而其他条件的取值都相同，那么这N条规则可以合并，合并以后该条件栏目用“/”表示，说明该条件的取值与所采取的动作无关。

例3: 化简后的判定表如表8－3所示:

表8－3 化简后的判定表

八、系统分析说明书

1. 系统分析说明书的内容

系统分析说明书是系统分析阶段的技术文档，也是系统分析阶段的工作成果。

系统分析说明书一般要包括以下几个部分。

(1) 概况介绍。

说明所开发信息系统的项目名称、背景资料、系统目标、系统主要工作内容、本文档所用的专门术语等。

(2) 现行系统的调查情况。

在系统分析说明书中概括阐明现行系统的目标、主要功能、主要业务、组织机构存在的问题和薄弱环节以及用户提出开发新系统请求的主要原因。

数据流程图是描述现行系统的主要工具。

(3) 目标系统的逻辑模型。

通过对现行系统的综合分析，找出影响现行系统的主要矛盾，进行必要的改动，就可以得到目标系统的逻辑模型。

通过系统分析的多方面工作，目标系统的目标已经逐步明确，对目标系统的目标应该尽量给出数量和指标。新的目标也是将来验收目标系统的标准。

具体内容包括以下几点。

①数据流程图的进一步说明。

说明目标系统与现行系统在处理功能、数据流和数据存储等方面有哪些主要变化，重点在于计算机信息系统的处理和数据存储的部分。

②数据存储的要求。

目标系统中要建立哪些数据文件，它们的用途、组织方式以及数据共享的方式等。

③与其他子系统的关系。

一般来说，业务信息系统是整个组织的一个子系统，它的开发和建立将影响与其他子系统之间的关系，系统之间的接口和信息流通方式等都将发生变化。

目标系统的逻辑模型也是通过相应的数据流程图来加以说明的。数据字典、判定树、判定表等往往篇幅较大，可作为系统分析说明书的附件。但是，由它们得到的主要结论，例如，主要的业务量、总的数据存储量等，应该列在系统分析说明书的正文当中。

(4) 实施计划。

①工作任务的分解。

对系统开发中的各项工作，按照子系统或系统功能进行划分，各部分内容由专人分工负责。

②工作进度安排。

安排各项工作的预定开始日期和结束日期，规定系统开发的进度和各项任务完成的先后次序。

③开发费用预算。

估算本项目所需要的劳务以及经费，包括各项工作所需的人力、办公费和差旅费等。

2. 系统分析说明书的审议

系统分析说明书在整个系统开发中占有非常重要的地位。对系统分析说明书的审议应该由开发人员、企业领导、业务人员和系统分析专家共同进行。

如果在评审中，有关人员发现开发人员对系统的了解存在比较大的差错、遗漏，或者是对系统分析说明书中所提出的方案不满意，则需要返工，重新进行系统调查和分析，直到系统分析说明书被通过为止。

系统分析说明书一旦通过审议，则将成为目标系统开发中的权威性文件，是下一阶段系统设计的主要依据。同时，系统分析说明书也成了用户与开发人员之间的技术合同，是将来对系统进行验收的标准之一。