第3章〓系统分析
需求分析是必要且十分重要的环节。实践证明，软件分析工作的好坏，在很大程度上决定了软件的成败。本章将从实际案例出发，对结构化方法的可行性分析和需求分析过程进行全面的剖析。在软件开发实践中，诸多成功和失败的教训使人们认识到，为了使开发出来的目标系统能满足实际需要，在着手编程之前，首先必须要用一定的时间来认真考虑以下问题：
(1) 需求要解决的问题是什么？
(2) 为解决该问题，系统应该做些什么？
(3) 系统应该怎么去做？
软件分析的任务是： 通过计划和需求分析，最终完成系统的逻辑方案。逻辑方案不同于物理方案，前者解决“是什么”的问题，是软件分析的任务； 后者解决“如何做”的问题，是软件设计的任务。系统分析过程如图3.1所示。
图3.1系统分析过程流程图
3.1问题的定义
问题定义阶段的主要任务是回答“要解决的问题是什么”这一问题。问题定义的内容包括明确问题的背景、开发系统的现状、开发的理由和条件、开发系统的问题要求、总体要求、问题的性质、类型范围、要实现的目标、功能规模、实现目标的方案、开发的条件、环境要求等，然后写出问题定义报告，以供可行性分析阶段使用。
1. 调研
系统的开发一般都是从用户提出要求开始的。而对于这种开发要求是否具有可行性，以及原有系统是否真到了必须推倒重来的地步等，都需要在软件开发之前认真考虑。在没有做这些考虑之前提前进入后续任何一项工作都是不明智的。
为了使软件开发工作更加有效地展开，有经验的开发者往往将系统调查分为两步，第一步是初步调查，即先投入少量的人力对系统进行大致的了解，然后再看有无开发的可行性； 第二步是详细系统调查，即在软件开发具有可行性并已正式立项后，再投入大量人力展开大规模、全面的系统调查。初步调查的重点如下：
(1) 了解用户与现有系统的总的情况，包括现有系统的规模、目标、发展历史、组织结构、人员分工、技术条件、技术水平等；
(2) 了解现有系统与外部环境的联系，包括现有系统和外部环境有哪些联系，哪些外部条件制约系统的发展等；
(3) 了解现有系统的现有资源，包括现有系统有哪些资源及系统的状况等；
(4) 了解用户的需求，包括功能需求、性能需求、资源和环境要求及资金和开发进度等。
通过调查研究，分析人员应根据软件工作范围，充分理解用户提出的每项功能与要求，同时从软件系统特征、软件开发的全过程以及可行性分析报告中给出的资源和时间约束来确定软件开发的总策略。只有用户才知道自己需要什么，但是他们并不知道怎样利用软件来实现自己的需要，用户必须把他们对软件的需求尽量准确、具体地描述出来； 分析人员知道怎样用软件实现用户的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户的沟通了解用户对软件的需求。
2. 问题定义
在问题定义阶段，分析人员要深入现场，阅读用户书写的书面报告，听取用户对开发系统的要求，调查开发系统的背景理由； 要与用户负责人反复讨论，以澄清模糊的地方，改正不正确的地方； 最后写出双方都满意的问题定义报告，并确定双方是否可进行深入系统可行性研究的意向。
系统分析过程的第一步涉及对问题的确认。分析人员会见客户，客户可能是外面公司、分析人员所在公司的市场部门或技术部门的代表，其意图是了解软件开发的目的，并定义满足这一目的所需的具体目标。
问题定义报告的主要内容包括项目名称、背景、目标、范围、开发条件、环境要求和初步设想等。一旦确定了全部目标，分析人员即可转向可行性评估： 构造系统的技术是否存在？需要什么特殊的开发和制造资源？对成本和进度有什么限制？通过对上述问题的回答来确定目标系统的可执行性。下面，本书以库存管理系统为例介绍和描述问题的定义。
【案例31】库存管理系统
库存管理系统的问题定义如下。
某公司是小型生产企业，随着改革的深入和经济的发展，该公司的生产任务日益繁重，从而对库存管理的要求也更加严格。在传统的手工管理时期，一种物品由进货到发货，要经过若干环节，且由于物品的规格型号繁多，加之业务人员素质较低等因素，造成物品供应效率低下，严重影响了企业的正常生产。同时，由于库房与管理部门之间的信息交流困难，造成库存严重积压，极大地影响了企业的资金周转速度，也使得物资管理、数据汇总成为一大难题。
当今企业的竞争压力越来越大，企业要想生存，就必须在各个方面加强管理，并要求企业有更高的信息化集成，能够对企业的整体资源进行集成管理。现代企业都意识到，企业的竞争是综合实力的竞争，要求企业有更强的资金实力，更快的市场响应速度。这就要求企业各部门之间统一计划，协调生产步骤，汇总信息，调配集团内部资源，实现既要独立又要统一的资源共享管理。随着信息技术的发展，该厂为了提高库存周转率，加快资金周转速度，决定开发库存管理系统。图3.2所示为库存管理系统的问题定义报告。
1. 项目
库存管理系统。
2. 背景
由于人工系统业务流程复杂、业务人员素质低，造成工作效率低下； 信息交流不畅，造成库存严重积压，极大地影响了企业的资金周转速度； 物资管理、数据汇总困难。
3. 项目目标
建立一个高效、准确、操作方便，具有查询、更新及统计功能的信息系统，以满足管理人员的查询及更新要求，从而更加方便地管理库存物品。
4. 项目范围
硬件可利用现有设备，软件开发费用为2万元。
5. 开发条件
系统结构： B/S结构。
服务器端技术： ASP.NET。
开发语言： C#。
数据库技术： SQL Server 2000。
6. 环境要求
服务器端： Windows 2003+IIS5.1+Visual Studio 2003+SQL Server 2000。
客户端： IE 6.0。
网络： 服务器和客户端应有网络连通，配置TCP/IP。
7. 初步设想
增加库存查询、库存提示、库存统计等功能。
8. 可行性研究
建议进行一周，费用为1000元。
图3.2库存管理系统的问题定义报告
3.2可行性分析
可行性分析又称为可行性研究，其任务是以最小的代价、在尽可能短的时间内确定问题是否能够解决，也就是判断原定的目标和规模是否现实。如果在定义阶段较早地识别出构思错误的系统，就可以避免时间和财物的无谓损失。一般地，在软件项目策划阶段进行的可行性研究应包括经济可行性分析、技术可行性分析、社会可行性分析、方案的选择、编写可行性研究报告五个方面的内容，如图3.3所示。
1. 项目背景
1.1 问题描述
1.2 实现环境
1.3 限制条件
2. 管理概要和建议
2.1 重要的研究结果
2.2 说明
2.3 建议
2.4 影响
3. 候选方案
3.1 候选系统的配置
3.2 最终方案的选择标准
4. 系统描述
4.1 系统工作范围的简要说明
4.2 被分配系统元素的可行性
5. 经济可行性(成本效益)分析
5.1 经费概算
5.2 预期的经济效益
6. 技术可行性(技术风险评价)分析
6.1 技术实力
6.2 已有工作基础
6.3 设备条件
7. 社会可行性分析
7.1 系统开发可能导致的侵权、违法和责任
7.2 政策方面的影响
8. 可用性分析
8.1 用户单位的行政管理和工作制度
8.2 使用人员的素质
9. 其他与项目有关的问题
9.1 其他方案介绍
9.2 未来可能的变化
图3.3可行性分析报告的主要内容
1. 经济可行性分析
经济可行性分析主要是指进行成本效益分析，从经济角度判断系统开发是否“合算”，从组织的人力、财力、物力三方面来考查软件开发的可行性。包含在经济可行性研究中最重要的信息之一是成本效益分析(即对基于计算机系统项目的经济回报的评估)。成本效益分析用于描绘项目开发的成本，并将其和系统的实际和无形效益相比较。
所谓成本，包括以下四方面的内容：
(1) 购置并安装软、硬件及有关设备的费用；
(2) 系统开发费用；
(3) 系统安装、运行及维护的费用；
(4) 人员培训费用。
效益包括以下两方面的内容：
(1) 系统为用户增加的收入或为用户节省的开支，这是有形的效益；
(2) 给潜在用户心理上造成的影响。这是无形的效益，它可以转化为有形的效益。
成本效益分析标准随着将被开发的系统的特征、项目的相对规模以及投资期望回报的变化而发生变化。此外，很多效益是无形的，直接的数量比较可能难于实现。
2. 技术可行性分析
技术可行性分析主要是指进行技术风险评价，从开发者的技术实力、以往工作基础、问题的复杂性等出发，判断系统开发在时间、费用等限制条件下成功的可能性。分析人员需要根据系统的功能、性能需求建立系统模型，然后对此模型进行一系列的试验、评审和修改，最后由项目管理人员做出是否进行系统开发的决定。如果开发技术风险很大，或者模型演示表明当前采用的技术和方法不能实现系统预期的功能和性能，或者系统的实现不支持各子系统的集成，则项目管理人员可以做出停止系统开发的决定。
技术可行性分析包括如下几个方面：
(1) 对现有技术进行估价，包括对国内外相关技术的发展水平及国家相关技术政策，对目前可利用的技术进行评估(该技术必须是已经普遍应用，有现成产品，而不是待研究或正在研究的)；
(2) 评估使用现有技术进行软件开发的可行性；
(3) 对技术发展可能产生的影响进行预测；
(4) 对关键技术人员的数量和水平进行评估；
(5) 评估计算机硬件的可行性，包括对各种外围设备、通信设备、计算机设备的性能是否能满足软件开发的要求，以及这些设备的使用、维护及其充分发挥效益的可行性进行评估；
(6) 评估计算机软件的可行性，包括对各种软件的功能能否满足软件开发的要求，软件系统是否安全可靠，本单位对使用、掌握这些软件技术的可行性进行评估。
3. 社会可行性分析
社会可行性分析主要是指评估一些社会因素对系统的影响。例如，新系统开发是否会引起侵权或其他法律责任问题，新系统开发是否符合政府法规或行业正常要求，外部环境的可能变化对新系统的开发影响如何等。
4. 方案的选择
方案的选择是指评价系统或产品开发的几个可能的候选方案，最后给出结论意见。分析人员在考虑问题解决的方案时，一般采用将一个大而复杂的系统分解为若干子系统的办法来降低解决方案的复杂性。如何进行系统分解以及如何定义各子系统的功能、性能和界面，实现方案可能有多种。可以采用折中的方法，反复比较各个方案的成本效益，选择可行的方案。
5. 编写可行性研究报告
可行性研究的结果要用可行性研究报告的形式编写出来。
可行性研究的结论应明确指出：
(1) 系统具备立即开发的可行性，可进入软件工程的下一个阶段；
(2) 可行性分析结果完全不可行，软件开发工作必须放弃；
(3) 某些条件不具备，但可以创造条件，如增加资源或改变系统的目标后，再重新进行可行性论证。
可行性研究报告首先由项目负责人审查(审查内容是否可靠)，再上报给上级主管审阅(估价项目的地位)。
3.3需求分析
3.1节和3.2节通过问题定义和可行性研究，回答了上面的第一个问题，即“需求要解决的问题是什么”而第二个问题的解决，即“为解决该问题，软件系统应该做些什么”就是需求分析的任务了。
软件需求分析是软件生命周期中重要的一步，是软件定义阶段的最后一个阶段，是关系到软件开发成败的关键步骤。软件需求分析过程就是对可行性研究确定的系统功能进一步具体化，并通过分析人员与用户之间的广泛交流，最终形成一个完整、清晰、一致的软件需求规格说明书的过程。通过需求分析，能把软件功能和性能的总体概念描述为具体的软件，从而奠定软件开发的基础。总的来说，软件需求分析过程实际上是一个调查研究、分析综合的过程，它准确回答了“系统该做什么”的问题。
软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。
要解决“系统应该做些什么”的问题，分析人员必须与用户密切协商，这是软件分析工作的特点之一。根据现有系统的特点，认真调查和分析用户需求，弄清哪些工作应交由计算机完成，哪些工作仍由人工完成，以及计算机可以提供哪些新功能。这样就可以在逻辑上规定目标系统的功能，而不涉及具体的物理实现，也就解决了“系统应做些什么”的问题。
3.3.1需求分析的原则
一般来说，现有系统是杂乱无章的，并且用户群体中的各个用户会从不同角度提出对原始问题的理解及对用计算机要实现管理的软件系统的需求，但并非所有的用户提出的要求都是合理的，所以必须全面理解用户的各项要求，不可能接受所有的要求，因此要经过一个认清问题、分析资料、建立分析模型的过程。
需求分析的方法很多，但是总的来说任何分析方法都是为了把软件系统要做的事情描述清楚，所以有其共同的、可适用的基本原则。
1. 必须能够清楚地表达和理解问题的功能域和数据域
软件的定义以及开发工作基本上都是要解决数据处理问题，即从一种形式转换为另一种形式。转换过程大致都要经历数据的输入、数据的加工和对结果数据的输出等几个步骤。
对于软件中的数据，所谓的“数据域”应包含数据流、数据内容和数据结构。
数据流指的是数据通过一个系统时的变化方式。对数据进行转换是软件常见的功能。而功能与功能之间的数据传递就确定了功能之间的接口。
数据内容指的就是数据项。
数据结构指的是各种数据项的逻辑组织方式，如顺序表、各种树状的链表、二维表等等。
2. 以层次化的方式对问题进行分解和不断细化
通常软件要处理的问题，作为一个整体来看规模庞大、过于复杂，很难理解。但如果把问题以某种方式分解为几个较易理解的部分，并确定各部分之间的接口，就可以比较容易地实现整体的功能了。
在需求分析阶段，软件的功能域和信息域都能被进一步地分解。这种分解可以是同一个层次的，称为横向分解； 也可以是多层次的，称为纵向分解。
3. 给出系统的逻辑视图和物理视图
需求分析的方法各有不同，但是无论用什么方法，必须给出系统的概念模型和物理模型，这对于满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件是必不可少的。
软件需求的概念模型给出软件要达到的功能和需要处理数据之间的关系，而不是实现的细节。软件需求中的概念模型是软件设计的基础。
软件需求的物理模型给出处理功能和数据结构的实际表现形式，这往往与设备相关，分析人员必须清楚各种相关元素对软件的限制，来正确地进行功能和信息结构的物理表示。
3.3.2需求分析的过程
1. 软件需求的四个过程
在软件需求分析中，必须采用合理的步骤，才能准确地获取软件的需求，产生符合要求的软件需求规格说明书。软件需求可以分为问题识别与需求获取、分析综合与软件建模、编写软件需求规格说明书、评审与需求验证。
（1) 问题识别与需求获取。
首先系统分析人员要确定对目标系统的综合要求，即软件的需求，并提出这些需求实现条件以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。如针对某种开发模式，应确定质量控制标准，里程碑，评审、验收标准，各种质量要求的优先级等以及可维护性方面的需求。
需求获取通常从分析现有系统包含的数据开始。首先分析现实世界，进行现场调查研究； 通过与用户的交流，了解现有系统的运行方式、机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型反映分析员对现有系统理解。这就是现有系统物理模型的建立过程。这一模型应客观地反映现实世界的实际情况。
此外，要建立分析所需要的环境，以保证能顺利地对问题进行分析。分析所需的环境如图3.4所示。
图3.4软件需求分析的通信途径
（2） 分析综合与软件建模。
分析综合与软件建模是需求分析第二方面的工作。分析人员必须从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，判断是否存在因片面性或短期行为而导致的不合理的用户要求，是否有用户尚未提出的真正有价值的潜在要求； 剔除其不合理的部分，增加其需要部分； 最终综合成系统的解决方案，给出目标系统的详细概念模型。
分析建模的过程就是从现有系统的物理模型中抽象出现有系统的概念模型，再利用现有系统的概念模型，除去那些非本质的东西，抽象出目标系统的概念模型的过程，即对目标系统的综合要求及数据要求的分析综合的过程，是需求分析过程中关键的一步。
首先，在理解现有系统“怎么做”的基础上，抽取其“做什么”的本质，从而从物理模型中抽象出现有系统的概念模型。在物理模型中有许多物理的因素，随着分析工作的深入，需要对物理模型进行分析，区分出本质的和非本质的因素，去掉那些非本质的因素，得出反映系统本质的概念模型。
其次，分析目标系统与现有系统在逻辑上的差别，从现有系统的概念模型中导出目标系统的概念模型。从分析现有系统与目标系统变化范围的不同，决定目标系统与现有系统在逻辑上的差别； 将变化的部分看作是新的处理步骤，并对数据流进行调整； 由外向里对变化的部分进行分析，推断其结构，获取目标系统的概念模型。
最后，补充目标系统的概念模型。为了使已经得出的模型能够对目标系统作完整的描述，还需要从目标系统的人机界面、尚未详细考虑的细节以及其他诸如系统能够满足的性能和限制等方面加以补充。
（3） 编写软件需求规格说明。
软件需求规格说明又称软件规格说明书，是分析人员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。它的作用主要是： 作为软件人员与用户之间事实上的技术合同说明； 作为软件人员下一步进行设计和编码的基础； 作为测试和验收的依据。软件需求规格说明必须用统一格式的文档进行描述。为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。软件需求说明书主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。
软件需求规格说明是沟通用户与分析人员的媒介，双方要用它来表达对于需要计算机解决的问题的理解。书写时应当易于理解和无二义性，尤其是在描述的过程中最好不要使用用户不易理解的专业术语。
为了便于用户尤其是不熟悉计算机的用户理解，软件需求规格说明应该直观、易读和易于修改，所以应尽量以图文结合的方式，采用自然语言，标准的图形、表格和简单的符号来表示。
（4） 评审与需求验证。
由分析人员提供的软件需求规格说明的初稿看起来是正确的，但在实现的过程中却会出现各种各样的问题，如需求不一致问题、二义性问题等。这些都必须通过需求分析的验证、复审来发现，确保软件需求规格说明可作为软件设计和最终系统验收的依据。作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性以及其他需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析人员之外，用户/需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。验证的结果可能会引起修改，必要时要修改软件计划来反映环境的变化。需求验证是软件需求分析任务完成的标志。
2. 验证需求的正确性
软件需求分析阶段的结果是软件开发项目的重要根据。大量统计数字表明，软件系统中约15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，对目标系统提出一组要求后，必须严格验证需求的正确性。这个环节的参与者有用户，管理部门，软件设计、编码和测试人员。一般说来，应该从下述几个方面进行验证。
（1) 一致性。
所有的软件需求都必须是统一的，任何一条需求都不能和其他需求矛盾。用自然语言书写的软件需求规格说明是难以验证的，特别是目标规模大、软件需求说明书较长的时候，人工复审没有更好的方法进行测试。一些没有保证的、冗余的、遗漏和不一致的问题可能不容易被发现而被保留下来，为以后的软件设计留下后患。为了克服这困难，可使用形式化的语言书写软件需求规格说明，以便用软件工具验证需求的一致性。
（2) 现实性。
指定的需求应该是用现有的硬件技术和软件技术能够基本实现的。如果超出了现有的技术基础，就会增加软件实现的难度，提高软件开发成本，甚至导致软件开发的失败。因此验证现实性时，应该参照以往开发系统的经验，分析现有的软、硬件实现目标系统的可行性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求说明书的现实性。
（3) 完整性与有效性。
需求必须是完整的，软件需求说明书中必须包括用户需要的每个功能或性能； 需求必须是正确有效的，确实能解决用户的实际问题。只有用户才真正知道软件需求说明书是否完整、准确地描述了他们的需求。检验需求的完整性与有效性必须在用户的合作下才能完成。但大多用户并不能清楚地说明自己的需求，也不能根据软件需求说明书确认是否满足了自己的实际需求。使用快速原型方法是比较现实的解决方案。让用户试用一段时间的原型系统，让他们能够认识到他们真正需要什么，以便对比现有的需求分析，提出更符合实际的要求。同时，软件设计、编码及测试人员的参与可更进一步加深与用户的沟通，理解用户的真实需求，有益于软件开发各个环节的联系，保证目标系统的完整性与有效性。
3.3.3获取需求的方法
获取需求是软件开发工作中最重要的环节之一，其工作质量的好坏对整个软件系统开发建设的成败具有决定性影响。获取需求工作量大，所涉及的过程、人员、数据、信息非常多，因此要想获得真实、全面的需求必须要有正确的方法。获取需求技术包括两方面的工作:
(1) 建立获取用户需求方法的框架；
(2) 支持和监控需求获取过程的机制。
获取用户需求的主要方法是调查研究。
1. 了解系统的需求
软件开发常常是系统开发的一部分。仔细分析研究系统的需求说明，对软件的需求获取是很有必要的。在进行该项工作时，可将用户日常业务中所用的计划、原始凭据、单据和报表等的格式或样本统统收集起来，以便进行分类研究。
2. 市场调查
市场调查是指了解市场和用户对待开发软件有什么样的要求，了解市场上有无与待开发软件类似的系统。如果有，在功能上、性能上、价格上情况如何。也可以采用书面调查的方法，根据系统特点设计调查表，用调查表向有关单位和个人征求意见和收集数据，如表3.1所示。还可通过Internet 网和局域网发电子邮件进行调查，或利用打电话和召开电视会议进行调查。但只能作为补充手段，因为许多资料需要亲自收集和整理，不过仍可大大节省时间、人力、物力和成本。
在做调查研究时，可以采取如下的调查方式：
(1) 拟定调查提纲，向不同层次的用户发调查表；
(2) 按用户的不同层次分别召开调查会，了解用户对待开发系统的想法和建议；
(3) 向关键岗位上的工作人员个别咨询；
(4) 实地考察，跟踪现场业务流程；
(5) 查阅与待开发系统有关的资料；
(6) 使用各种调查工具，如数据流图、任务分解图、网络图等。
表3.1问卷调查表
序号问题回答
1你的工作岗位是什么？
2你的工作性质是什么？
3你的工作任务是什么？(收集或绘制业务功能图)
4你每天的工作时间安排？(绘制工作安排表)
5你的工作同前/后续工作如何联系？(绘制工作流程)
6如何建立计算机系统，你愿意学习操作吗？
×××先生/女士：
您好！请您抽空准备一下，我们将于×日与您会面。谢谢！
×××课题组
3. 访问用户和用户领域的专家
开调查会有助于大家的见解互相补充，以便形成较为完整的印象。但是由于时间限制等其他因素，并不能完全反映出每个与会者的意见，因此往往在会后根据具体需要再进行个别访问，把从用户那里得到的信息作为重要的原始资料进行分析。访问用户领域的专家所得到的信息将有助于对用户需求的理解。
4. 考察现场
如果条件允许，亲自参加业务实践是了解现有系统的最好方法。通过实践可加深开发人员和用户的思想交流和友谊，通过了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识，这将有利于下一步的系统开发工作。
为了能够有效地获取和理清用户需求，应当打破用户(需方)和开发者(供方)的界限，共同组成一个联合小组，发挥各自的长处，协同工作。
3.3.4通过现有系统建立目标系统的过程
通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于现有系统的概念模型导出目标系统的概念模型，解决目标系统 “做什么”的问题，其实现步骤如图3.5所示。
图3.5参考现有系统建立目标系统模型
一个好的设计过程通常总是从现有系统的物理模型出发，导出现有系统的概念模型，经过对现有系统的分析，找出问题和不足之处，设想目标系统的概念模型，最后根据目标系统的概念模型设计出新系统的物理模型。下面通过库存管理系统需求分析的过程进行介绍。
1. 了解现有系统的物理模型
现有的系统是信息的主要来源。显然，如果目前有一个正在使用的系统，那么这个系统一定能完成某些有用的工作，因此，新的目标系统必须也要完成这些基本的工作； 另一方面，现有的系统必然存在某些问题或不足，才导致了新系统问题的提出。新的系统必须能够解决现有系统存在的这些问题或不足。此外，运行和使用现有系统所需要的费用是一个重要的经济指标。如果新系统不能增加收入或减少使用费用，那么从经济角度看新系统就不如当前的系统，甚至要考虑新系统开发的必要性。
了解现有系统能做些什么（而不必清楚是怎样做到的）以及了解和记录现有系统和其他系统的接口情况，这是设计新系统时的重要约束条件。根据上述的了解画出现有系统的物理模型图。
库存管理系统现有系统的描述。
各车间向物品供应部门提出对某种物品的需求计划，仓库将相应的商品发放给各车间，一般要经过计划、库房管理等过程。系统的物理模型图如图3.6所示。
图3.6现有系统的物理模型图
2. 抽象出现有系统的概念模型
应该仔细阅读和分析现有系统的有关文档和所有资料并实地考察现有系统，了解现有系统都做了什么，能做什么，为什么这样做，使用现有系统所付出的代价。为了了解上述这些问题，必须访问相关的人员。这就是了解现有系统的过程。
在理解物理模型的基础上，抽取其做什么的本质，从而从现有系统的物理模型抽象出现有系统的概念模型。该概念模型应能描述出现有系统对相关业务的处理过程。要注意的是千万不要花费太多的精力去分析和描述现有系统的实现细节。
与用户座谈、沟通，开展调研，了解现有系统存在哪些问题和不足之处。例如经过对当前运行的“库存管理系统”的调研，发现库存管理系统存在以下问题和不足： 由于采用的是手工管理，账目繁多，加之几个仓库之间距离较远，库管员、计划员和有关领导相互之间的信息交流困难，使得物资供应效率低下，影响生产； 每月的月末报表会耗费大量的人力，且手工处理容易造成失误，从而影响了数据的效率和准确率，造成了不必要的损失。因此，该厂必须建立相应的库存管理系统，使其能根据市场情况，及时合理地采购所需商品； 同时又能科学地对商品进行管理，统筹安排人力、物力、财力，有效地改善当前管理的混乱状况。
根据对该厂的库存管理情况所做的调查和参考有关资料，发现目前该厂在库存管理方面存在着如下问题。
(1) 不能及时获得库存信息。
在企业运作过程中，管理人员必须获知各种商品当前的库存量，在库存数量小于商品最低库存限度的时候，应及时向供应商进行订货； 在库存数量大于商品最高库存限度的时候，即商品积压的时候，应该停止商品的进货活动。但在实际操作中，由于商品的种类多、数量大，需要进行仔细地核算，这不仅费时，而且易出错，从而影响企业快速有效地运转。
(2) 库存信息不够准确。
仓库管理员根据各种入库单、需求计划单和领料单进行商品的入库、出库操作后，要随时修改商品的库存信息和出库、入库信息，以便反映库存状况。该工作中的主要问题是： 由于商品种类多、数量大、出库/入库操作频繁等原因，造成库存记录和实际库存量通常达不到严格一致，因而需要通过盘点来纠正差错，这既耽误时间，又增加了工作量。
(3) 无法及时了解车间对库存商品的需求情况。
在需求计划单下达后，由于库存商品与车间的关系复杂，根据送料员的个人经验给各车间分配车间所需商品时，常缺少入库、出库信息和相关信息，经常在车间缺少该商品的时候才知道该产品的需要情况，此时如果库存量不足，将会导致车间的停产。无法及时了解车间对库存商品的需求情况会使企业的生产和销售环节发生混乱，使企业无法正常运作。
(4) 市场需求日益多样化和个性化。
产品更新换代的周期越来越短，这就要求企业必须改变库存管理现状，以适应时代的要求。
3. 建立目标系统的概念模型
通过前面对现有系统的了解，分析人员就清楚了新系统应该具有哪些基本功能，应该增加哪些功能及其所受的约束和限制条件，据此描绘出目标系统业务处理的过程，从而表达出对目标系统的设想。目标系统的系统流程图实际上是对目标系统的一个高度抽象的模型，对具体功能、性能、数据以及各种约束和限制条件的描述还有待于在需求分析与设计的过程中通过软件建模来实现。在本书的案例41“库存管理系统”中，对目标系统新增加的功能描述如下（也可以通过目标系统的系统流程图进行说明）。
4. 对目标系统的概念模型进行补充，以求完整地描述
库存管理系统新增加的功能。
因为传统企业库存管理存在以上问题，难以适应现代库存管理的要求，所以现代企业库存管理系统要具有以下特点。
(1) 科学的库存管理流程。
存货的种类不同，所涉及的业务环节及它们所组成的业务流程也各有差异。一般而言，库存业务包括入库处理、货物保管和出库处理三个主要部分。通畅的业务流程是保障高效库存管理的基础，应具备优化、无冗余、并行作业的基本属性。科学的企业库存管理系统可对企业的业务流程进行流程再造，使其更加通畅，提高企业在同行业中的竞争力。
(2) 商品代码化管理。
代码问题严格说是一个科学管理的问题，设计出一个好的代码方案对于系统的开发工作是一件极为有利的事情。代码设计得好，可以使很多机器处理变得十分方便，还可以把一些现阶段计算机很难处理的工作变成很简单的工作。
(3) 商品编码化管理。
由于库存商品种类繁多，在库存管理过程中极易发生混乱的问题。IT技术与层次编码技术的结合为商品的高效管理提供了可能。这种编码技术对所有库存商品按照层次和类别赋予唯一的编码。它是区分不同商品的最主要的标准，具有易读和易记的特点，使得管理者只需知道商品的编码，就可以了解该商品的有关信息。
(4) 库存异常报警。
当库存数量小于商品最低库存限度的时候，系统发出警报，提醒管理人员应该向供应商进行订货； 在库存数量大于商品最高库存限度的时候，即商品积压的时候，系统也会发出警报，提醒管理人员应该停止商品的进货活动。也就是说，企业库存管理系统应既能防止商品供应滞后于车间对它们的需求，也能防止商品过早地生产和进货，以免积压库存。
软件需求分析阶段研究的对象是软件项目的用户要求。如何准确表达用户的要求，怎样与用户共同明确将要开发的是一个什么样的系统，是需求分析要解决的主要问题。一方面，必须全面理解用户的各项要求，但又不能全盘接受所有的要求； 另一方面，要准确地表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。也就是说，需求阶段的任务并不是确定系统怎样完成工作，而仅仅是确定系统必须完成哪些工作，即对目标系统提出完整、准确、清晰、具体的要求。需求分析阶段所要完成的任务是在可行性研究成果的基础上，针对目标模型，通过分析综合建立软件系统的分析模型，编制出软件需求说明书。
在需求分析阶段，分析员要对收集到的大量资料和数据进行分析综合，透过现象看本质，看到事物的内在联系及矛盾所在； 同时，对于那些非本质的东西，找出解决矛盾的办法； 最后，通过“抽象”建立起描述软件需求的一组模型，即分析模型。分析模型应该包含以下系统需求内容：
(1) 功能要求；
(2) 性能要求，如对响应时间、吞吐量、处理时间、对内外存的限制等的要求；
(3) 接口要求；
(4) 约束与限制条件要求(安全性、保密性、可靠性)；
(5) 运行要求，如对硬件、支撑软件、数据通信接口等的要求；
(6) 异常处理等对系统的综合要求，以及对于系统信息处理中数据元素的组成、数据的逻辑关系、数据字典和数据模型等系统的数据要求。
这些是形成软件需求说明书、进行软件设计与实现的基础。需求说明书是软件分析阶段的最后结果，它通过一组图表和文字说明描述了目标系统的概念模型。设计概念模型是软件分析工作的另一个特点。概念模型包括数据流图、数据字典、基本加工说明等。它们不仅在逻辑上表明了目标系统所具备的各种功能，而且还包括输入、输出、数据存储、数据流程和系统环境等。概念模型只告诉人们目标系统要“做什么”，而暂不考虑系统怎样来实现的问题。
对需求说明书的复审是由软件开发者和客户一起进行的，因为需求说明书构成了设计和以后软件工程活动的基础，在进行复审时必须给予特别的重视。
简单说来，需求分析阶段是将新系统的目标具体化为用户需求，再将用户需求转换为新系统的概念模型，系统的概念模型是用户需求明确、详细的表示。
3.4结构化需求分析方法
为了更好地理解获取需求过程中用户描述的问题，可以采用创建模型的方式来实现，这就是分析建模的过程。所谓模型，就是为了理解事物所做出的一种抽象，是对事物无歧义的书面描述。模型由一组图形符号和组成这些符号的规则组成。
软件的分析模型通常由一组模型组成，其中包括数据模型、功能模型和行为模型。目前建立分析模型的方法主要有两种： 一种是结构化方法的需求分析模型，这是传统的建模方法，将在本节进行介绍； 另一种方法是面向对象分析模型，将在后面的章节中详细介绍。
结构化方法的需求分析模型的组成结构如图3.7所示，可以看出模型的核心是数据字典(Data Dictionary，DD)，这是系统所涉及的各种数据对象的总和。
图3.7结构化方法的需求分析模型的组成结构
从数据字典出发，主要通过以下三种图来构建该模型的三种模型，即通过ER图进行数据建模、通过数据流图进行功能建模、通过状态迁移图进行行为建模。
(1) 实体联系图(ER图)。实体联系图用于描述数据对象间的关系、构建软件的数据模型，在ER图中出现的每个数据对象的属性均可用数据对象进行说明描述。
(2) 数据流图(DFD)。数据流图的主要作用是指明系统中数据是如何流动和变换的，以及描述数据流是如何进行变换的。在DFD图中出现的每个功能都会写在(Process Specification，PSPEC)中，它们构成系统的功能模型。
(3) 状态迁移图(STD)。状态迁移图用于指明系统在外部事件的作用下将如何动作，表明系统的各种状态及各种状态间的迁移。所有软件控制方面的附加信息都包含在控制说明(CSPEC)中，它们构成系统的行为模型。
早期的结构化方法的需求分析模型只包括DD、DFD和PSPEC，主要描述软件的数据模型与功能模型。后来，一方面随着软件开发技术的不断发展，特别是数据库技术的发展，软件系统要去满足用户更多、更复杂的数据信息要求。在数据建模时，人们就将用于数据库设计方面的ER 图用于结构化方法的需求分析，用来描述包含较复杂数据对象和信息模型。另一方面，随着计算机实时系统应用的不断拓展，在分析建模过程中，由实时发生的事件来触发控制的数据加工无法用传统的DFD 来表示。因此在功能模型之外扩充了行为模型，用控制流程图(CFD)、CSPEC和STD等工具来描述。
3.4.1数据建模（ER图）
为了把用户的数据要求清楚、准确地描述出来，分析人员通常要建立一个概念模型。概念模型是面向问题的数据模型，是按照用户的观点对数据建立模型。在需求分析模型建立过程中，使用ER图来建立数据模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而与在软件系统中的实现方法无关。在ER模型中，数据模型包括三种互相关联的信息，即数据对象、描述对象的属性、描述对象间相互连接的关系。
ER图中通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体的属性，并用直线把实体与其属性连接起来。
人们通常就是用实体、关系和属性这三个概念来理解现实问题的，因此，ER图比较接近人们的思维方式。此外，ER图使用简单的图形符号表达系统分析人员对问题域的理解，不熟悉计算机技术的用户也能理解它。因此，ER图可以作为用户与分析人员之间一种有效的交流工具。
1. 数据对象
数据对象(实体型)是需要被目标系统所理解的复合信息的表示。所谓复合信息，是具有若干不同特征或属性的信息。
数据对象可以是外部实体(如显示器)、事物(如报表或显示)、角色(如教师或学生)、行为(如一个电话呼叫)或事件(如单击鼠标左键)、组织单位(如研究生院)、地点(如注册室)或结构(如文件)。
数据对象只封装了数据，没有包含作用于这些数据上的操作。这与面向对象范型中的类和对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象，其中的某个对象叫作该数据对象的一个实例。例如商品实体可用图3.8表示。
图3.8商品实体的表示方法
2. 属性
属性定义了数据对象的特征，它可用来：
(1) 为数据对象的实例命名；
(2) 描述这个实例；
(3) 建立对另一个数据对象的另一个实例的引用。
例如商品实体有商品编号、商品名称、规格、类型等属性。为了唯一地标识数据对象的某个实例，定义数据对象中的一个属性或几个属性为关键码(key)，书写为_id。例如在“商品”数据对象中用“商品编号”作为关键码，它可以唯一地标识一个“商品”数据对象中的实例。
属性是实体的说明。用椭圆形表示实体的属性，并用无向边把实体与其属性连接起来，则其ER图如图3.9所示。
图3.9商品实体及其属性
3. 关系
数据对象及其关系可用ER图表示，各个数据对象的实例之间有关联。如学生“张鹏”选修了“软件工程”与“计算机网络”两门课程，则学生与课程的实例可通过“选修”关联起来。
实例的关联有三种：
(1) 一对一(1∶1)。例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的关系就是一对一的。
(2) 一对多(1∶m)。例如，某校教师与课程之间存在一对多的关系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师任课。
(3) 多对多(n∶m)。例如，商品与供应商之间的关系是多对多的，即一种商品可以有多个供应商，每个供应商也可以有多种商品，如图3.8 所示。
4. 实体关系图
实体间的联系是两个或两个以上实体类型之间的有名称的关联。实体间的联系用菱形表示，菱形内要有联系名，并用无向边把菱形分别与有关实体相连接，在无向边旁标上联系的类型。例如可以用ER图来表示商品和供应商关系的概念模型，如图3.10所示。
图3.10实体、实体属性及实体联系模型图
如果概念模型中涉及的实体带有较多的属性，造成实体联系图非常不清晰，可以将实体联系图分成两部分，一部分是实体及其属性图，另一部分是实体及其联系图。
5. 数据的规范化
信息域分析需要确定数据的内容，每个数据项要用表格列出，最后组织成文件的逻辑结构，即面向应用而不是面向存储的结构。为了便于数据库的设计，常常要对这种结构做一些简化，其中最常见的一种方法就是规范化技术。
规范化技术将数据的逻辑结构归结为满足下列条件的二维表(关系)。
(1) 表中每个信息项必须是一个不可分割的数据项，不可以是组项。
(2) 表格中每一列中的所有信息项必须是同一类型，各列的名字(属性名)互异，列的次序可以任意。
(3) 表格中各行互不相同，行的次序任意。
不满足上述要求的二维表或关系就叫作非规范化关系，必须将其规范化成单纯的和规范的关系。
规范化的目的就是要消除数据冗余，即消除表格中数据的重复； 消除多义性，使关系中的属性含义清楚、单一； 使关系的“概念”单一化，让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组； 方便操作，使数据的插入、删除与修改操作可行并方便； 使关系模式更灵活，易于实现接近自然语言的查询方式。
【案例32】教学管理系统
教学管理系统的数据库概念模型如下。
用学生、教师、课程三个关系保存三个实体型的信息：
学生(学号，姓名，性别，年龄，专业，籍贯)
教师(职工号，姓名，年龄，职称，工资级别，工资)
课程(课程号，课程名，学分，学时，课程类型)
建立两个关系，表示实体型之间的联系：
选课(学号，课程号，听课出勤率，作业完成率，分数)
教课(职工号，课程号)
这五个关系就组成了数据库的概念模型。在每个关系中，属性名下加下画线指明关键字，并规定关键字能唯一地标识一个元组。关键字可以由一个或一组属性组成。
关系规范化的程度通常按属性间的依赖程度来区分，并以范式NF(Normal Form)来表达。常用的范式分为第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
判断规范化程度的条件如下：
(1) 关系中所有属性都是“单纯域”，即不出现“表中有表”；
(2) 非主属性完全函数依赖于关键字；
(3) 非主属性相互独立，即任何非主属性间不存在函数依赖。
如果一个关系连条件(1)都不满足，则这个关系是非规范化的； 如果一个关系仅满足条件(1)，则这个关系满足第一范式； 如果一个关系满足条件(1)和(2)，但不满足(3)，则这个关系满足第二范式； 如果一个关系同时满足三个条件，则这个关系满足第三范式。当数据模型达到3NF，一般情况下就能满足数据库应用的需要。
3.4.2功能建模(数据流图)
数据流图是结构化方法的需求分析最基本的工具，数据流图从数据传递和加工的角度，以图形化的方式刻画数据流从输入到输出的移动和变换过程。在数据流图中，具体的物理元素都已去掉，只剩下数据的存储、流动、加工和使用情况。这种抽象性能使我们总结出信息处理的内部规律性。由于数据流图用图形来表示逻辑系统，即使不是专业的计算机人员也能比较容易地理解数据流图，因此成为一种极好的交流工具。
1. 数据流图的基本表示符号
图3.11是描述储户携带存折去银行办理取款手续的数据流图。
图3.11办理取款手续的数据流图
（1) 数据流图的四种基本表示符号。
从图3.11中可以看到，数据流图的基本图形元素有四种，如图3.12所示。
图3.12数据流图的基本图形符号
（2) 分层数据流图的表示。
为了表达数据处理过程的数据加工情况，用一个数据流图是不够的。稍为复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。这样的数据流图看起来很不清楚。层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达整个系统，使系统更容易理解。
图3.13给出了分层数据流图的示例。数据处理S包括三个子系统1、2、3。顶层下面的第一层数据流图为DFD/L1。第二层数据流图DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，我们称它的上层图为父图，它的下层图为子图，图中F代表外部实体。
图3.13分层数据流图
（3) 四种基本符号的另一种表示方法。
为了使数据流图便于在计算机上输入和输出，免去画曲线、斜线、圆的困难，常常使用如图3.14所示的另一套符号。这一套符号与图3.12给出的符号是完全等价的。
图3.15是一个简单的数据流图，它表示数据X从源S流出，经P1加工转换成Y，接着经P2加工转换为Z，在加工过程P2中从F中读取数据。
2. 数据流图中的主要元素
（1) 数据流。
数据流由一组确定的数据组成。例如发票为一个数据流，它由品名、规格、单位、单价、数量等数据组成。数据流用带有名字的、具有箭头的线段表示，名字称为数
图3.14数据流图的基本符号
图3.15数据流图举例
据流名，表示流经的数据； 箭头表示流向。数据流表明了数据的流动方向及其名称，它是数据载体的表现形式。在数据流的上方写上数据流的名称。数据流可以从加工流向加工，也可以从加工流进、流出文件，还可以从源点流向加工或从加工流向终点。图3.16是常见的几种可能的数据流。
图3.16常见的几种可能的数据流
对数据流的表示有以下约定：
① 对流进或流出文件的数据流不需标注名字，因为文件本身就足以说明数据流; 但其他数据流则必须标出名字，名字应能反映数据流的含义；
② 数据流不允许同名；
③ 两个数据流在结构上相同是允许的，但必须体现人们对数据流的不同理解；
④ 两个加工之间可以有几股不同的数据流，这是由于它们的用途不同，或它们之间没有联系，或它们的流动时间不同；
⑤ 数据流图描述的是数据流而不是控制流。
（2) 加工处理。
加工处理是对数据流进行的操作，它把流入的数据流转换为流出的数据流。每个加工处理都应取一个名字表示它的含义，并规定一个编号用来标识该加工在层次分解中的位置。加工的名字中必须包含一个动词，例如“计算”“打印”等。
对数据流加工转换的方式有两种。
① 改变数据流的结构，例如将数组中的各数据重新排序；
② 产生新的数据流，例如对原来的数据进行汇总计、求平均值等。
加工规格说明用来说明数据流图中的数据加工的细节，描述了数据加工的输入、实现加工的算法以及产生的输出。另外，加工规格说明指明了加工(功能)的约束和限制、与加工相关的性能要求以及影响加工的实现方式的设计约束。必须注意，编写加工规格说明的主要目的是要表达“做什么”，而不是“怎样做”。因此它应描述数据加工实现加工的策略而不是实现加工的细节。
目前用于描写加工规格说明的工具有结构化英语、判定表和判定树。
（3) 文件。
文件是存储数据的工具。文件名应与它的内容一致，写在开口长条内。从文件流入或流出数据流时，数据流方向是很重要的。如果是读文件，则数据流的方向应从文件流出，写文件时则相反； 如果是又读又写，则数据流是双向的。在修改文件时，虽然必须首先读文件，但其本质是写文件，因此数据流应流向文件，而不是双向。数据流从文件流出，箭头应指向加工。
（4) 数据源或终点。
数据源和终点表示数据的外部来源和去处。它通常是系统之外的人员或组织，不受系统控制。为了避免在数据流图上出现线条交叉，同一个源点、终点或文件均可在不同位置多次出现，这时要在源(终)点符号的右下方画小斜线或在文件符号左边画竖线，以示重复。
由图3.15可知，数据流图可通过基本符号直观地表示系统的数据流程、加工、存储等过程，但它不能表达每个数据和加工的具体、详细的含义，这些信息需要在“数据字典”和“加工说明”中表达。
3. 数据流图的画法
画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精； 先确定系统的边界或范围，再考虑系统的内部； 先画加工的输入和输出，再画加工的内部，即:
(1) 识别系统的输入和输出。
(2) 从输入端至输出端画数据流和加工，并同时加上文件。
(3) 加工“由外向里”进行分解。
(4) 数据流的命名要确切，能反映整体。
(5) 各种符号布置要合理，分布均匀，尽量避免交叉线。
对于不同的问题，数据流图可以有不同的画法。具体实行时，可按如下案例的步骤进行。
库存管理系统的顶层数据流图。
(1) 识别系统的输入和输出，画出顶层图。
第一步是确定系统的边界。在需求阶段，系统的功能需求等还不很明确，为了防止遗漏，不妨先将范围定得大一些。系统边界确定后，越过边界的数据流就是系统的输入或输出。将输入与输出用加工符号连接起来，并加上输入数据的来源和输出数据的去向就形成了顶层图。
画出库存管理系统顶层图的主要目的是识别系统的输入和输出，如图3.17 所示。
图3.17库存管理系统的顶层数据流图
(2) 画出系统内部的数据流、加工与文件，画出一级细化图。
从系统输入端到输出端(也可反之)，逐步用数据流和加工连接起来。当数据流的组成或值发生变化时，就在该处画一个“加工”符号。画数据流图时还应同时画上文件，以反映各种数据的存储处，并表明数据流是流入还是流出文件。
最后，再回过头来检查系统的边界，补上遗漏但有用的输入输出数据流，删去那些没被系统使用的数据流。
(3) 对加工进行进一步分解，画出二级细化图。
同样运用“由外向里”的系统方式对每个加工进行分析。如果在该加工内部还有数据流，则可将该加工分成若干子加工，并用一些数据流把子加工连接起来，即可画出二级细化图。二级细化图可在一级细化图的基础上画出，也可单独画出该加工的二级细化图，二级细化图也称为该加工的子图。
(4) 其他注意事项。
一般应先给数据流命名，再根据输入输出数据流名的含义为加工命名。名字含义要确切，要能反映相应的整体。若碰到难以命名的情况，则很可能是分解不恰当造成的，应考虑重新分解。
从左至右画数据流图。通常左侧、右侧分别是数据源和终点，中间是一系列加工和文件。正式的数据流图应尽量避免线条交叉，必要时可用重复的数据源、终点和文件符号。此外，数据流图中的各种符号布置要合理，分布应均匀。
库存管理系统数据流图的一级细化图如图3.18所示。
图3.18库存管理系统数据流图的一级细化图
画数据流图是一项艰巨的工作，要做好重画的思想准备。重画是为了消除隐患，有必要不断改进。
因为作为顶层加工的改变域是确定的，所以改变域的分解是严格的自顶向下分解。由于目标系统目前还不存在，因此分解时开发人员还需凭经验进行，这是一项创造性的劳动。同时，在建立目标系统数据流图时，还应充分利用本章讲过的各种方法和技术。例如，分解时尽量减少各加工之间的数据流； 数据流图中各个成分的命名要恰当； 父图与子图间要注意平衡等。
当画出分层数据流图并为数据流图中的各个成分编写词典条目或加工说明后，就获得了目标系统的初步概念模型。
4. 绘制分层数据流图时应注意的问题
（1) 合理编号。
分层数据流图的顶层称为0层，称为第1层的父图； 而第1层既是0层图的子图，又是第2层图的父图； 依此类推。由于父图中有的加工可能就是功能单元，不能再分解，因此父图拥有的子图数少于或等于父图中的加工个数。为了便于管理，应按下列规则为数据流图中的加工编号：
① 子图中的编号为父图号和子加工的编号组成。
② 子图的父图号就是父图中相应加工的编号。
为简单起见，约定第1层图的父图号为0，编号只写加工编号1，2，3，…，下面各层由父图号1、1.1等加上子加工的编号1，2，3，…组成。按上述规则，图的编号既能反映出它所属的层次以及它的父图编号的信息，还能反映子加工的处理信息。例如1 表示第1层图的1号加工处理，1.1，1.2，1.3，…表示父图号为1号加工的子加工，1.3.1，1.3.2，1.3.3，…表示父图号为1.3加工的子加工。
图3.19简化子图编号示例
为了方便起见，对数据流图中的每个加工，可以只标出局部号，但在加工说明中，必须使用完整的编号。例如图3.19可表示第1层图1号加工的子图，编号可以简化成图中的形式。
（2) 注意子图与父图的平衡。
子图与父图的数据流必须平衡，这是分层数据流的重要性质。这里的平衡指的是子图的输入、输出数据流必须与父图中对应加工的输入、输出数据流相同，如图3.20所示。
图3.20数据流图中的局部文件
（3) 局部文件。
图3.20中的父图和子图是平衡的，但子图中的文件W并没在父图中出现。这是由于对文件W的读写完全局限在加工3.3之内，在父图中各个加工之间的界面上不出现，该文件是子图的局部文件或为临时文件。
应当指出的是，如果一个临时文件在某层数据流图中的某些加工之间出现，则在该层数据流图中就必须画出这个文件。一旦文件被单独画出后，还需画出这个文件同其他成分之间的联系。
（4) 分解的程度。
对于规模较大的系统的分层数据流图，如果一下子把加工直接分解成基本加工单元，一张图上画出过多的加工将使人难以理解，也增加了分解的复杂度。然而，如果每次分解产生的子加工太少，会使分解层次过多而增加作图的工作量，阅读也不方便。经验表明，一般说来，一个加工每次分解量最好不要超过七个为宜。同时，分解时应遵循以下原则：
① 分解应自然，概念上要合理、清晰；
② 上层可分解得快些(即分解成的子加工个数多些)，这是因为上层是综合性描述，对可读性的影响小； 而下层应分解得慢些；
③ 在不影响可读性的前提下，应适当地多分解成几部分，以减少分解层数；
④ 一般说来，当加工用一页纸可以明确地表述时，或加工只有单一输入输出数据流时(出错处理不包括在内)，就应停止对该加工的分解。另外，对数据流图中不再作分解的加工(即功能单元)，必须做出详细的加工说明，并且每个加工说明的编号必须与功能单元的编号一致。
5. 数据流图的修改
对于一个大型系统来说，由于在软件设计初期人们对于问题理解的深度不够，在数据流图上也不可避免地会存在某些缺陷或错误，因此还需要进行修改，才能得到完善的数据流图。这里介绍如何从正确性和可读性方面对数据流图进行改进。
(1) 正确性。
数据流图的正确性，可以从以下几个方面来检查。
① 文件使用。在数据流图中，文件与加工之间数据流的方向应按规定认真标注，这样也有利于对文件使用正确性的检查。例如，在图3.21中，因为W1和W2是子图的局部文件，所以在子图中应画出对文件的全部引用。但子图中W2好像一个“渗井”，数据只有流进，没有流出，显然是一个错误。
图3.21局部文件使用错误
② 子图与父图间的平衡。造成子图与父图不平衡的一个常见原因是在增加或删除一个加工时，忽视了对相应父图或子图的修改。在检查数据流图时应注意这一点。
③ 加工与数据流的命名。加工和数据流的名字必须体现被命名对象的全部内容而不是一部分。对于加工的名字，应检查它的含义与被加工的输入输出数据流是否匹配。
一个加工的输出数据流仅由它的输入数据流确定，这个规则绝不能违背。数据不守恒的错误有两种： 一是漏掉某些输入数据流，二是某些输入数据流在加工内部没有被使用。虽然有时后者并不一定是个错误，但也要认真考虑。对于确实无用的数据应该删去，以简化加工之间的联系。在检查数据流图时，应注意消除控制流。
（2) 可读性。
数据流图的可读性，可以从以下几个方面来提高。
① 简化加工之间的联系。各加工之间的数据流越少，各加工的独立性就越高。因此应当尽量减少加工之间数据流的数目，有必要时可对数据流图重新分解。
② 分解应当均匀。在同一张数据流图上，应避免出现某些加工已是功能单元，而另一些加工却还应继续分解好几层的情况出现。否则应考虑重新分解。
③ 命名应当恰当。理想的加工名由一个具体的动词和一个具体的宾语(名词)组成； 数据流和文件的名字也应具体、明确。
（3) 数据流图重新分解的步骤。
有时需要对做出的部分或全部数据流图作重新分解，可按以下步骤进行。
① 把需要重新分解的所有子图连成一张。
② 根据各部分之间联系最少的原则，把图划分成几部分。
③ 重建父图，即把第②步所得的每一部分画成一个圆圈，各部分之间的联系就是加工之间的界面。
④ 重建各张子图，只需把第②步所得的图，按各自的边界剪开即可。
⑤ 为所有加工重新命名、编号。
例如，图3.23(a)中加工2和其他加工的联系太复杂以致很难独立理解，所以其结构不太合理。将它们的父图加工分成两个更为合适，如图3.22(b)所示。
图3.22结构不合理的数据流图及其修改
根据上述规则检查图3.18，发现库存管理系统数据流图的一级细压图存在如下问题。
(1) 一层细化图缺少了一个输入数据流。应在供货单位和处理P1之间加一个数据流“发货单”，数据从供货单位流入处理P1。
(2) 文件使用错误： 供货单位信息、车间信息和商品信息三个文件在一层细化图中只有流进，没有流出。应在顶层数据流图中添加“供货单位信息”“车间信息”和“商品信息”三个数据存储文件。系统读取三个文件，因此数据从文件流入“库存管理系统”处理。
6. 检查和修改数据流图应遵循的基本原则
(1) 数据流图上的所有图形符号只限于前述四种基本图形元素。
(2) 顶层数据流图必须包括前述四种基本元素，缺一不可。
(3) 顶层数据流图上的数据流必须封闭在外部实体之间。
(4) 每个加工至少有一个输入数据流和一个输出数据流。
(5) 在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。
(6) 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致，即父图与子图必须平衡。
(7) 可以在数据流图中加入物质流，帮助用户理解数据流图。
(8) 图上每个元素都必须有名字。数据流和文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么； 加工的名字应当是“名词+宾语”，表明做什么事情。
(9) 数据流图中不可夹带控制流。
(10) 初画时可以忽略琐碎的细节，以集中精力于主要数据流。
3.4.3行为建模(状态迁移图)
行为建模给出了需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。
1. 状态迁移图
利用如图3.23所示的状态迁移图或状态迁移表来描述系统或对象的状态以及导致系统或对象的状态改变的事件，从而描述系统的行为。
图3.23状态迁移图及与其等价的状态迁移表
每个状态代表系统或对象的一种行为模式。状态迁移图指明系统的状态如何根据相应外部的信号(事件)进行推移。在状态迁移图中，用圆圈“○”表示可得到的系统状态，用箭头“→”表示从一种状态向另一种状态的迁移，在箭头上要写上导致迁移的信号或事件的名字。如图3.25(a)所示，系统中可取得的状态=S1，S2，S3，事件=t1，t2，t3，t4。事件t1将引起系统状态S1向状态S3迁移，事件t2将引起系统状态S3向状态S2迁移等。图3.24(b)就是与图3.24(a)等价的状态迁移表。
另外，状态迁移图指明了作为特定事件的结果(状态)，在状态中包含可能执行的行为(活动或加工)。
如果系统比较复杂，可以把状态迁移图分层表示。例如，在确定了如图3.24所示的状态S1，S2，S3之后，接下来就可把状态S1，S2，S3细化。此外，在状态迁移图中，由一个状态和一个事件所决定的下一状态可能会有多个，实际会迁移到哪一个状态是由更详细的内部状态和更详细的事件信息来决定的，此时可采用状态迁移图的一种变形，如图3.25所示，使用加进判断框和处理框的方法。
图3.24状态迁移图的网
图3.25状态迁移图的变形
2. Petri网
Petri网适用于描述相互独立、协同操作的处理系统，即并发执行的处理系统。在软件需求分析与设计阶段都可以使用。
Petri网是一种有向图。它有两种节点： “○”表示系统的状态，“—”或“|”表示系统中的事件； 图中的有向边表示对事件的输入或从事件的输出： “ ”表示对事件的输入； “ ”表示事件的结果，即从事件的输出。
图3.26用Petri网描述了一个多任务系统中的进程1和进程2使用一个公共资源R时，利用原语LOCK(对资源加锁)和UNLOCK(对资源解锁)控制R的使用，保证进程间同步的例子。
图3.26进程同步机制的PNG
图3.26中，每个进程是一个数据对象，它有三个状态： 等待资源(P1或P4)，占用资源执行的处理(P2或P5)，不占用资源执行的处理(P3或P6)； 系统也有一个状态： 资源空闲(P7)。在有的状态中有一个黑点“”，称为标记或令牌，表明系统或对象当前正处于此状态。当作为一个事件的输入的所有状态都得到或保有令牌时，才能引起该事件“激发”，使得系统和对象的状态向前推移，完成系统和对象的某些行为。
3. 控制规格说明
控制规格说明从两个方面给出系统的行为，其一是状态迁移图，它是行为的“顺序规格说明”； 其二是加工激活表(PAT)，它是行为的“组合规格说明”，表明当事件激发时，数据流图中的哪些加工要被激活。控制规格说明仅描述了系统的行为，不提供被激活的加工的内部工作细节。
分析模型建立后，已经确定的目标系统概念模型应当得到清晰准确的描述。我们把描述目标系统概念模型的文档称为软件需求规格说明书。软件需求规格说明书是软件需求分析阶段最主要的文档。它是连接计划阶段和开发阶段的桥梁，是软件设计的依据。许多事实表明，软件需求规格说明书中的任何一个微小错误都有可能导致系统的错误，在纠正时将会付出巨大的代价。同时，为了准确表达用户对软件的输入输出要求，还需要拟定数据要求说明书及编写初步的手册，以及反映目标系统的人机界面和用户使用的具体要求。此外，依据在需求分析阶段对目标系统的进一步分析，可以更准确地估计被开发项目的成本与进度，从而修改、完善并确定软件开发实施计划。
3.4.4建立数据字典
分析模型中包含了对数据对象、功能和行为的表示。在每种表示中，数据对象和行为项都扮演一定的角色。为表示每个数据对象和行为项的特性，可建立数据词典。
数据词典精确地、严格地定义了每个与系统相关的数据元素，并以字典式顺序将它们组织起来，使用户和分析人员对所有的输入、输出、存储成分和中间计算能有共同的理解。
在数据流图的基础上，还需对其中的每个数据流、文件和数据项加以定义，我们把这些定义所组成的集合称为数据字典。数据流图是系统的大框架，而数据字典以及下面将要介绍的加工说明则是对数据流图中每个成分的精确描述。它们有着密切的联系，必须结合使用。
以下是有关词条的描述方法。
数据词典的每个词条中应包含以下信息。
(1) 名称： 数据对象或控制项、数据存储或外部实体的名字。
(2) 别名或编号。
(3) 分类： 属于数据对象、加工、数据流、文件、外部实体、控制项(事件/状态)中的哪项。
(4) 描述： 描述内容或数据结构等。
(5) 何处使用： 使用该词条(数据或控制项)的加工。
在数据词典的编制中，分析人员最常用的描述内容或数据结构的符号如表3.2所示。
表3.2数据词典定义式中的符号
符号含义解释
=被定义为
+与例如，x=a+b，表示x由a和b组成
［…，…］
［…|…］或例如，x=［a，b］，x=［a | b］，表示x由a或由b组成
{…}重复例如，x={a}，表示x由0个或多个a组成
m{…}n重复例如，x=3{a}8，表示x中至少出现3次a，至多出现8次a
(…)可选 例如，x=(a)，表示a可在x中出现，也可不出现
“…”基本数据元素例如，x=“a”，表示x为取值为a的数据元素
..连接符例如，x=1..9，表示x可取1到9之中的任一值
【案例33】数据文件“存折”
数据文件“存折”在数据词典中的定义格式。
在图3.12表示的取款数据流图中，数据文件“存折”的格式如图3.27所示，它在数据词典中的定义格式如表3.3所示。
图3.27存折格式
表3.3数据文件“存折”在数据词典中的定义格式
名称定义注释
存折户名+所号+账号+开户日+性质+（印密）+1{存取行}50
户名2{字母}24
所号001~999储蓄所编码，规定由3位数字组成
账号00000001~99999999账号规定由8位数字组成
开户日年+月+日
性质1，2，3，4，5，61代表普通户，5代表工资户等
印密0 印密在存折上不显示
存取行日期+（摘要）+支出+存入+余额+操作+复核
日期年+月+日
……
字母［“a”..“z”|“A”..“Z”］
在数据字典中有三种类型的条目： 数据项条目、数据流条目和文件条目。下面分别进行举例说明。
1. 数据项条目
数据项条目用来给出数据项的定义。由于数据项是数据的最小单位，是不可分割的，因此数据项条目只包含名称、代码、类型、长度和值的含义内容等。对于那些足以从名称看出其含义的“自说明”型的数据项，则不必在条目中再解释其含义。
库存管理系统中的部分数据项条目如表3.4所示。
表3.4“库存管理系统”中的部分数据项条目
名称说明
数据项编号101
数据项名称商品编号
别名无
简述某种商品的编号
类型字符型
长度8字节
取值范围数字+英文字母
数据项编号102
数据项名称单价
别名购入单价
简述某种商品的购入单价
类型数值型
长度10位，小数位2位
取值范围0.00～9999999.99
数据项编号103
数据项名称库存数量
别名实际库存数量
简述某种商品的库存数量
类型数值型
长度5位整数
取值范围0～99999
2. 数据流条目
数据流条目用于对每个数据流进行定义，通常由数据流名、别名、组成、注释、流入、流出和流通量等部分组成。其中，别名是前面已定义的数据流的同义词； 组成栏是定义的主要部分，通常列出该数据流的各组成数据项； 注释栏用于记录其他有关的信息，例如该数据流在单位时间中传输的次数等。
如果数据流的组成很复杂，则可采用“自顶向下、逐步分解”的方式来表示。例如 “供应商信息”数据流可写成： 供应商信息=供应商基本信息+供应商通讯信息+供应商经营信息。
库存管理系统中的部分数据流条目如表3.5所示。
表3.5“库存管理系统”中的部分数据流条目
名称说明
数据流名称入库单
编号F1
简述采购人员填写的商品入库凭单
数据流来源采购人员
数据流去向登记库存台账
数据流组成日期+入库单编号+商品编号+购入数量
流通量25份/天
高峰流通量50份/天
数据流名称发货单
编号F2
简述供应商填写的商品发货凭单
数据流来源供应商
数据流去向登记合同台账
数据流组成日期+发货单编号+供应商编号+商品编号+发货数量
流通量25份/天
高峰流通量50份/天
3. 文件条目
文件条目用来对文件(或数据库)进行定义，由文件名、编号、组成、结构和注释五部分组成。其中组成栏的定义方法与前面的数据流条目相同； 结构栏用于说明重复部分的相互关系，如指出是顺序还是索引存取。
数据词典明确地定义了各种信息项。随着系统规模的增大，数据词典的规模和复杂性将迅速增加。
4. 加工说明条目
自然语言不够精确、简练，不适合编写加工说明。目前有许多适用加工说明的描述工具。下面我们介绍三种最常用的工具： 结构化语言、判定表和判定树。
(1) 结构化语言。
自然语言的优点是容易理解，但是它不精确，可能有多意性。程序设计语言的优点是严格精确，但它的语法规定太死板，使用不方便。结构化语言(Structured Language)则是介于自然语言和程序设计语言之间的一种语言，它是带有一定结构的自然语言。在我国，通常采用较易为用户和开发人员双方接受的结构化汉语。
在用结构化语言描述问题时，只允许使用三种基本逻辑结构： 顺序结构、选择结构和循环结构。配合这三种结构所使用的词汇主要有三类： 陈述句中的动词； 在数据字典中定义的名词； 某些逻辑表达式中的保留字、运算符、关系符等。后面我们还会具体说明这三种语句的使用方式。
为了减少复杂性，便于人们理解，编写加工说明需要注意以下几点。
避免结构复杂的长句。
所用名词必须在数据字典中有定义。
不要用意义相同的多种动词，用词名应始终如一。例如，“修正”“修改”“更改”含义相同，一旦确定使用其中一个以后，就不要再用其余两个。
为提高可读性，书写时可采用“阶梯形”格式。
嵌套使用各种结构时，应避免嵌套层次过多而影响可读性。
(2) 判定表。
对于具有多个互相联系的条件和可能产生多种结果的问题，用结构化语言描述则显得不够直观和紧凑，这时可以用以清楚、简明为特征的判定表(Decision Table)来描述。判定表采用表格形式来表达逻辑判断问题，表格分成四个部分： 左上角为条件说明； 左下角为行动说明； 右上角为各种条件的组合说明； 右下角为各条件组合下相应的行动。下面我们通过示例来说明如何使用判定表。
表3.6是使用判定表描述订货折扣政策问题的示例。其中，C1~C3为条件，A1~A4为行动，1~8为不同条件的组合，Y 为条件满足，N 为不满足，X 为该条件组合下的行动。例如，条件4表示若交易额在50000元以上、最近3个月中有欠款且与本公司交易在20年以下，则可享受5%的折扣率。
表3.6判定表描述的折扣政策
说明
不同条件组合
12345678
条件
C1： 交易额在50000元以上YYYYNNNN
C2： 最近3个月无欠款单据YYNNYYNN
C3： 与本公司交易20年以上YNYNYNYN
行动
A1： 折扣率为15%√√
A2： 折扣率为10%√
A3： 折扣率为5%√
A4： 无折扣率√√√√
判定表是根据条件组合进行判断的，表3.6中每个条件只存在“Y(是)”和“N(非)”两种情况，所以3个条件共有23=8种可能性。在实际使用中，有的条件组合可能是矛盾的，需要剔除； 有的则可以合并。因此需在原始判定表的基础上进行整理和综合，才能得到简单明了且实用的判定表。同时，在整理过程中还可能对用户的原有业务过程进行改进和提高。表3.7 是对表3.6合并整理后得到的，其中“—”表示“Y”或“N”均可。
表3.7合并整理后的判定表
说明
不同条件组合
1(1，2)2(3)3(4)4(5，6，7，8)
条件
C1： 交易额在50000元以上YYYN
C2： 最近3个月无欠款单据YNN—
C3： 与本公司交易20年以上—YN—
行动
A1： 折扣率为15%√
A2： 折扣率为10%√
A3： 折扣率为5%√
A4： 无折扣率√
判定表的内容十分丰富，除了以上介绍的有限判定表之外，根据表中条件取值的状态不同，还有扩展判定表和混合判定表。它们都各有特色，若能合理选择和灵活运用，则可描述、处理更为广泛、复杂的判断过程。详细的内容可参阅有关的书籍。
(3) 判定树。
判定树(decision tree)是用来表示逻辑判断问题的一种图形工具。它用“树”来表达不同条件下的不同处理，比语言、表格的方式更为直观。判定树的左侧(称为树根)为加工名，中间是各种条件，所有的行动都列于最右侧。
表3.6描述的折扣政策可以用图3.28所示的判定树来进行描述。
图3.28判定树描述的折扣政策
以上介绍的三种用于描述加工说明的工具各自具有不同的优点和不足，它们之间的比较如表3.8所示。
表3.8几种表达工具的比较
比较指标结构化语言判定表判定树
逻辑检查好很好一般
表示逻辑结构好（所有方面）一般（仅是决策方面）很好
使用方便性一般一般很好
用户检查不好不好（除非用户受过训练）好
程序说明很好很好一般
机器可读性很好很好不好
机器可编辑性一般（要求句法）很好不好
可变性好不好（除非是简单的组合变化）一般
通过比较可以看出它们的适用范围：
结构化语言最适用于涉及具有判断或循环动作组合顺序的问题。
判定表较适用于含有5~6个条件的复杂组合，条件组合过于庞大则将造成不便。
判定树适用于行动在10~15之间的一般复杂程度的决策。必要时可将判定表上的规则转换成判定树，以便于用户使用。
判定表和判定树也可用于软件开发的其他阶段，并被广泛地应用于其他学科。
习题三
一、 判断题
1. 需求规格书描述的是软件如何实现。()
2. 在ER图中，实体与实体之间的连接是通过主键和外键进行的。()
3. 在结构化分析方法中，用以表达系统内数据运动情况的工具是功能结构图。()
4. 各种需求方法都有它们共同适用的方法。()
5. 数据流图的基本成分有六种。
6. 软件需求的逻辑视图描述的是软件要达到的功能和要处理的信息之间的关系。()
7. 软件需求的逻辑视图没有描述实现的细节。()
8. 软件需求的物理视图给出的是处理功能和信息结构的实际表现形式。()
9. 软件需求的物理视图需考虑实际的环境和具体的设备。()
10. 数据流图的主图必须含有四种元素，缺一不可。()
11. 数据流图的主图必须封闭在外部实体之间，实体可以有多个。()
12. 数据流图中包含控制流。()
13. 数据项是数据处理中基本的不可分割的逻辑单位。()
二、 选择题
1. 软件需求分析阶段的工作可以分为以下4个方面： 对问题的识别、分析与综合、编写需求分析文档以及()。
A. 总结
B. 阶段性报告
C. 需求分析评审
D. 以上答案都不正确
2. 各种需求方法都有它们共同适用的()。
A. 说明方法
B. 描述方式
C. 准则
D. 基本原则
3. 在结构化分析方法中，用以表达系统内数据运动情况的工具有()。
A. 数据流图
B. 数据词典
C. 结构化英语
D. 判定表与判定树
4. 在结构化分析方法中用状态迁移图表达系统或对象的行为。在状态迁移图中，由一个状态和一个事件所决定的下一状态可能会有()个。
A. 1
B. 2
C. 多
D. 不确定
5. 软件需求分析的任务不应包括()。
A. 问题分析
B. 信息域分析
C. 结构化程序设计
D. 确定逻辑模型
6. 进行需求分析可使用多种工具，但()是不适用的。
A. 数据流图
B. 判定表
C. PAD图
D. 数据词典
7. 在需求分析中，分析人员要从用户那里解决的最重要的问题是()。
A. 要让软件做什么
B. 要给该软件提供哪些信息
C. 要求软件工作效率如何
D. 要让软件具有什么样的结构
8. 需求规格说明书的内容不应当包括()。
A. 对重要功能的描述
B. 对算法的详细过程性描述
C. 软件确认准则
D. 软件的性能
9. 需求规格说明书在软件开发中具有重要的作用，但其作用不应当包括()。
A. 软件设计的依据
B. 用户和开发人员对软件要“做什么”的共同理解
C. 软件验收的依据
D. 软件可行性分析的依据
三、 填空题
1. 在实体关系图中，表达对象的实例之间的关联有三种类型： 一对一联系、联系、多对多联系。
2. 需求分析的重点是、、、。
3. 获取需求的常用方法有、、、。
4. 数据流图的基本成分有、、、。
5. 数据词典的每个词条中应包含、、、、。
四、 简答题
1. 可行性研究主要研究哪些问题？
2. 需求为什么难获取？
3. 需求分析的原则有哪些？
4. 需求分析的任务有哪些？
5. 数据流图的作用是什么？
6. 数据词典的作用是什么？