软件工程第三讲教案

教案首页周次日期课时序课题软件需求分析教学目的要求理解需求分析阶段所要完成的工作目标；掌握需求分析的分析方法重点理解需求分析的工作目标难点掌握分析方法教学过程设计及时间分配软件需求分析（2*45‘）需求分析的任务与步骤（30‘）需求分析的方法（30‘）图形工具（15‘）需求规格说明与评审（15‘）教学场所或教学方法使用教具作业课后记授课教师第三章软件需求分析3.1需求分析的任务与步骤软件需求分析是软件生存周期中重要的一步，也是最关键的一步。只有通过软件需求分析，才能把软件功能和性能研究清楚，并将其描述为具体的软件需求规格说明，进而建立软件开发的基础。软件需求分析是一个不断认识和逐步细化的过程。在该过程中能将软件计划阶段所确定的软件范围逐步细化到可详细说明的程度。制定软件的需求规格说明不仅是软件开发者的任务，而且用户也起着极其重要的作用。首先用户必须对软件功能和性能提出初步的基本要求，并澄清一些模糊概念。然后软件分析人员了解用户的要求，认真细致地进行调查研究与分析，把用户要做什么的要求最终转换成一个完全的、细致的软件需求规格说明，准确地表达用户的要求，进而为概要设计做好准备工作。3.1.1需求分析的任务需求分析是软件计划时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么”这个问题。需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件与其它系统元素的接口细节，描述软件的其它有效性需求。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示，在软件完成后，制定的软件需求规格说明还要为评价软件质量提供依据。需求分析阶段研究的对象是软件项目的用户需求。虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一些可行的方案，但是，忽略了许多细节。所以可行性研究并不能代替需求分析。需要注意的是，必须全面理解用户的各项要求，但又不能全盘接受用户所有的要求。因为并非所有用户要求都是合理的。对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。对于那些无法实现的要求应向用户做出充分的解释说明。明确地表达所接受的用户要求，是需求分析的另一个重要方面。只有经过确切描述的软件需求才能成为软件设计的基础。软件开发项目是要求实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中。这是软件实现的基础。但是目标系统的具体物理模型是将其逻辑模型实例化，即具体到某个业务领域。与物理模型不同，逻辑模型忽略具体实现机制与细节，只描述系统要完成的功能和要处理的数据。需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的做什么的问题。其实现步骤的描述如图3-1所示。需求分析的任务不是确定系统如何完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。可行性研究阶段产生的文档，特别是数据流图，是需求分析的出发点。在数据流图中已经给出系统必须完成的许多基本功能，在需求分析阶段将仔细研究这些功能并进一步将它们具体化。在这个阶段结束时交出的文档中应该包括详细的数据流图，数据字典和简明的算法描述。需求分析的结果是系统开发的基础，是工程的成功和优秀软件产品的保证。因此，除了对目标系统提出完整、准确、清晰、具体的要求描述外，必须加强对软件需求进行严格的审查验证。一般说来，需求分析阶段的任务包括下述几方面。1．确定对系统的综合需求对系统的综合需求主要有：系统功能需求、系统性能需求、运行需求、将来可能提出的需求。系统分析人员与用户协商，澄清模糊需求，删除无法做到的需求，改正错误需求。对于系统功能需求，应该划分出系统必须完成的所有功能。而系统性能需求包括：响应时间、精确度指标需求、安全性等。运行需求集中表现为对系统运行时所处环境的需求。如软硬件运行环境需求等。最后，对于将来可能提出的需求，应该明确地列出那些虽然不属于当前系统开发范畴，但是根据分析将来很可能会提出来的需求。这样做增强了被设计系统的可扩展性，在设计过程中对系统将来可能的扩充和修改做准备，以便于需要时能比较容易地进行这种扩充和修改，更有利于系统维护。2．分析系统的数据需求任何一个软件系统实际上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的结构。分析系统的数据需求是由系统的信息流归纳抽象出数据元素组成，数据的逻辑关系，数据字典格式，数据模型。并以输入/处理/输出的结构方式表示。因此，必须分析系统的数据需求，这是软件需求分析的一个重要任务。3．提出系统的逻辑模型在理解当前已存在系统结构的基础上，抽取其做什么的本质。需要对当前已存在系统的物理模型进行分析，区分本质和非本质因素，去掉那些非本质因素就可获得反映系统本质的逻辑模型。在综合上述分析的结果和明确目标系统要做什么的基础上，可以提出要设计的软件系统的逻辑模型。具体做法是：首先确定目标系统与当前系统的逻辑差别；然后将变化部分看作是新的处理步骤,对功能图（一般为数据流图）及对象图进行调整；最后由外及里对变化的部分进行分析，推断其结构，获得目标系统的逻辑模型。通常用数据流图、数据字典和主要的处理算法描述逻辑模型。4．修正系统开发计划在经过需求分析阶段的前述工作之后，分析员对目标系统有了更深入更具体的认识，因此可以对系统的成本和进度做出更准确的估计，在此基础上应该对开发计划进行修正。5．开发原型系统在第一章中已介绍了几种主要的软件开发模型，许多方法都涉及到了原型系统问题，这里就是指开发原型系统。在许多工程产品的设计过程中经常使用样机。建造样机的主要目的是：检验关键设计方案的正确性及系统是否真正满足用户的需要。对于软件系统的开发，使用原型系统的主要目的是，使用户通过实践获得未来的系统将怎样工作，从而可以更准确地确定他们的要求。建立原型系统能够解决下述问题：由于认识能力的局限而不能预先指定所有要求；在用户和系统分析员之间存在的通信鸿沟；用户需要一个现实的系统模型，以便获得实践经验；而且在开发过程中重复和反复是必要的和不可避免的；采用原型系统策略也带来了的成本增加副作用。但是，由于正确地提出用户需求是软件开发工程成功的基础，所以原型系统采用逐渐增多。尤其是目前较好的软件开发工具的出现，为快速建立软件的原型系统建立了可实施的基础。3.1.2需求分析的步骤在前面已介绍了需求分析的主要任务，只有在需求分析中采取正确的步骤才能完成上述任务，需求分析的步骤如下。1．调查研究分析人员与程序员共同研究系统数据的流程、调查用户需求或查阅可行性报告、项目开发计划报告，访问现场，获得当前系统的具体模型，以IPO图或DFD图表示。把从外面输入到系统中来的或者是通过计算由系统中产生出来的数据输出。要确定输出数据的元素组成及其来源，并沿数据流图从输出端往输入端回溯，以确定每个数据元素的来源，定义有关的算法。但是，由于高层数据流图不包括具体的细节，因此沿数据流图回溯时常遇到下述问题：为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法不清楚。为了解决这些问题，通过用户向其他相关人员研究，使分析员对目标系统的认识更深入更具体，系统中更多的数据元素被划分出来，算法更清楚。把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中，把通过分析而补充的数据流、数据存储和处理，应添加到数据流图中。还有许多问题存在，如数据字典准确性和完整性、算法的正确性和有没有遗漏必要的处理或数据元素等。一个系统的详细信息只能来源于直接在这个系统上工作的系统的用户。因此，用户对前一个分析步骤中得出的结果仔细地进行复查。用户应该注意倾听分析员的报告，确定对目标系统的认识是否正确、有无遗漏，并及时纠正和补充分析员的认识。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。追踪数据流图和复查系统的逻辑模型这两个步构成一个循环。对数据流图的分析产生问题，这些问题也可能又引出新的问题，每经过一次循环都会了解到未来的逻辑系统的更多细节。2．分析与综合问题分析和方案的综合是需求分析的第二步工作。分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制。通过分析确定满足功能要求的程度，根据功能需求，性能需求，运行环境需求等，删除其不合理的部分，增加其需要部分，最终给出目标系统的详细逻辑模型。在这个步中，分析和综合工作反复地进行。在对现行问题期望的输入和输出信息进行分析的基础上，分析员开始综合出一个或多个解决方案，然后检查它的工作是否符合软件计划中规定的范围等等，再进行修改。对分析和综合的过程将一直到分析员与用户都可正确地制定该软件的规格说明为止。经过上述分析过程，分析员越来越深入地定义了系统中的数据和系统应完成的功能。为了追踪更详细的数据流，分析员把数据流图扩展到更低的层次。通过功能分解可以完成数据流图的细化。在数据流图中选出一个功能比较复杂的处理，并把它的功能分解成若干个子功能，较低层的子功能在一张新数据流图上的处理，在这张新数据流图上还包括数据存储和数据流。应注意下述两条原则：①在分层细化时必须保持信息连续性，也就是说细化前后对应功能的输入／输出数据必须相同；②当进一步细化将实现一个具体地功能时，也就是当把一个功能进一步分解成子功能后，为了完成这些子功能需要写出的程序代码时，就不应该再分解了。3．书写文档经过分析确定了系统必须具有的功能和性能，定义了系统中的数据并且简略地描述了处理数据的主要算法。下一步应该把分析的结果用正式的文档记录下来，作为最终软件配置的一个组成成分。根据需求分析阶段的基本任务，在这个阶段应该完成下述四份文档资料：（1）系统规格说明。主要描述目标系统的概述、功能要求、性能要求、运行要求和将来可能提出的要求。在分析过程中得出的数据流图是这个文档的一个重要组成部分，用IPO图或其他工具简要描述的系统算法是文档的另一个重要组成部分。此外，这个文档中还应包括用户需求和系统功能之间的参照关系以及设计约束等。（2）数据要求。主要包括在需求分析建立的数据字典以及描绘数据结构的层次方框图或Warnier图，还应该包括对存储信息（数据库或普通文件）分析的结果。（3）用户系统描述。这个文档从用户使用系统的角度描述系统，相当于一份初步的用户手册。内容包括对系统功能和性能的扼要描述，使用系统的主要步骤和方法以及系统用户的责任等。这个初步的用户手册使得未来的用户能从使用的角度检查该目标系统，因而比较易于判断这个系统十分符合他们的需要。（4）修正的开发计划。经过需求分析阶段的工作，分析员对目标系统有了更深入更具体的认识，因此可以对系统的成本和进度作出更准确的估计，在此基础上应该对开发计划进行修正。包括修正后的成本计划、资源使用计划和进度计划等。4．需求分析评审作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性以及其他需求给予评价。3.1.3需求分析的原则目前已出现许多分析方法。虽然各种分析方法都有独特的描述方法，但所有分析方法有共同的基本原则。1．能够表达和理解问题的数据域和功能域软件定义与开发的目的是实现数据处理，将一种形式的数据转换成另一种形式的数据。其转换过程必经输入、加工数据和产生结果数据等步骤，其数据域应包括数据流、数据内容和数据结构。数据流是数据通过一个系统时的变化方式。输入数据首先转换成中间数据，然后转换成输出结果数据。在此期间可以从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。对数据进行转换是程序中应有的功能或子功能。两个转换功能之间的数据传递就确定了功能间的接口。数据内容即数据项。2．按自顶向下、逐层分解问题系统太大太复杂很难理解。可以把问题以某种方式分解为多个较易理解的部分，并确定各部分间的接口，从而实现整体功能。在需求分析阶段，软件的功能域和信息域都能进一步的分解。这种分解可以是同一层次上的，称为横向分解；也可以是多层次的纵向分解。把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的子功能，这就属于纵向分解了。3．给出系统的逻辑视图和物理视图给出系统的逻辑表示又称系统的逻辑视图，物理表示又称系统的物理视图。这两种视图满足处理需求所提出的逻辑限制条件和提出的物理限制条件必不可少。进而确定做怎样的实现形式限制，功能限制及算法与数据限制。如数据字典，就对数据流的条目、文件条目、数据项条目及加工条目进行了具体的规定和限制。软件需求的逻辑视图给出软件要达到的功能和要处理数据之间的关系，而不是实现的细节。例如，一个商店的销售处理系统要从顾客那里获取订单，系统读取订单的功能并不关心订单数据的物理形式和用什么设备读入，也就是说无需关心输入的机制，只是获取顾客的订单而已。类似的，系统中检查库存的功能只关心库存文件的数据结构，而不关心在计算机中的具体存储方式。软件需求的逻辑描述是软件设计的基础。软件需求的物理视图给出处理功能和数据结构的实际表示形式，这是由设备决定的。如一些软件靠终端键盘输入数据，另一些软件靠参数转换设备提供数据。分析员必须弄清系统元素对软件的限制，并考虑功能和信息结构的物理表示。3.2需求分析的方法在这里，讨论一下需求分析方法。需求分析方法包括对软件的数据域和功能域的系统分析过程及其表示方法，并定义了系统逻辑视图和物理视图的表示方式。由于需求分析方法是由数据驱动的，所以提供了一种表示数据域的机制。分析员根据这种表示，确定软件功能及其他特性，建立目标系统的逻辑模型。数据域具有三种属性：数据流、数据内容和数据结构。通常，一种需求分析方法总要利用其中的一种或几种属性。归纳起来，需求分析方法具有以下的性质。（1）支持数据域分析的机制

虽然每种分析方法进行数据域分析的方式不同，但它们有共同特点，即都直接或间接地与数据流、数据内容或数据结构等属性有关。在一般情况下，数据流特征是将输入转换成输出的变换功能过程来描述，数据内容可以用数据字典表示，或者通过描述数据或数据对象的层次结构隐含地表示。（2）功能表示的方法

功能用数据变换或加工来表示。每项功能可用规定的记号标识。说明功能可以用自然语言文本，也可以用形式化的规格说明语言，还可以用上述两种方式的混合方式（结构化语言）。（3）接口的定义

接口的说明是数据表示和功能表示的结果。某个功能的流进和流出数据流应是其他相关功能的流出或流入数据流。因此，通过数据流分析可以确定功能间的接口。（4）问题分解的机制

问题分解和抽象主要依靠分析员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。即不仅都能表示这些功能，而且能在这个抽象层次上操纵这个功能。另外，所有的分析方法都提供一种逐层分解的机制，把总的功能划分成一些子功能，每项子功能还可以在更低的一级抽象层次上表示。（5）逻辑视图和物理视图

大多数方法允许分析员在提出问题的逻辑解决方案之前先分析物理视图，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。（6）系统抽象模型

为了比较精确地定义软件需求，可建立待开发软件的一个抽象的模型。用基于抽象模型描述软件系统的功能和性能，形成软件需求规格说明。这种抽象的模型是从外部现实世界的问题领域抽象而来，在高级层次上描述和定义系统的服务。

比较简单的问题，不必建立抽象系统模型。系统模型可在分析员头脑中形成，直接由分析员写成规格说明。但对于较复杂的问题，必须建立形式化的抽象系统模型，才能准确全面地反映问题领域中各种复杂的要求。

不同类型的问题有不同的需要解决的中心问题，因而需建立不同类型的系统模型。如数学软件，设计的中心问题是算法，软件人员的主要力量要用在数学模型算法的考虑上。而对于数据通信软件，中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。对于涉及大量数据的数据处理软件，中心问题是数据处理，包括数据的采集、数据的传送、存储、变换、输出等，一旦明确了数据结构，与它相关的算法就很简单了，因此可以采用面向数据结构的模型。

系统模型的建立过程是对现实世界中存在的有关实体和活动的抽象和精化，如图3-2所示，包括观察分析、模型表示和模型检查三个阶段。第一阶段分析员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准。第二阶段分析员和用户在共同理解的基础上建立系统模型，包括系统提供的各种系统服务，模型表示的细节：系统输入、系统输出、系统数据处理、系统控制等。第三阶段进行模型检查。除了静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界观察得到的系统跟踪信息进行对照，检查模型是否达到要求。3.2.1面向数据流的需求分析方法

结构化分析方法是面向数据流进行需求分析的方法。于20世纪70年代末由E.Yourdon等人提出，至今已得到广泛应用，结构化分析方法的一些重要概念也应用到其他方法中。结构化分析方法使用数据流图DFD与数据字典DD来描述，面向数据流问题的需求分析适合于数据处理类型软件的需求描述。其核心思想是分解化简问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的可实现的软件为止。由于这种方法利用图形来表达需求，显得清晰、层次分明，易于学习和掌握。但其不能表达复合逻辑的需求分析问题，也不能详细表达加工。3.2.2数据流图

数据流图也简称为DFD（Data

Flow

Diagram的英文缩写）,它是描述数据处理过程的工具。

1．数据流图的定义

数据流图从数据传递和加工的角度，以图形的方式描述数据流从输入到输出的传输变换过程。数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能。

2．数据流图的特性

（1）抽象性在数据流图中，具体的组织机构、工作场所、物质流等都去掉，仅剩下信息和数据存储、流动、使用以及加工的情况。这有助于抽象地总结出信息处理的内部规律。（2）概括性数据流图把系统对各种业务的处理过程联系起来考虑，形成一个总体，具有概括性。数据流图描述的主体是抽象出来的数据。（3）层次性数据流图具有层次性，一个系统将用多层次的数据流图描述。3.数据流图基本符号

(1)数据流图中的主要图形元素

数据流图的基本图形元素有4种，有时为了使数据流图便于在计算机上输入和输出，免去画曲线、斜线和圆的困难，常使用对应的另一套符号，这两套符号完全等价。如图3-3所示。

图3-3数据流图基本图形符号

在数据流图中，数据流是沿箭头方向传送数据的通道，它们是在加工之间传输被加工数据的命名通道。也有连接数据存储文件和加工没有命名的数据通道。这些数据流虽然没有命名，但因联接的是有名加工和有名文件，所以其含义也是清楚的。同一数据流图上不能有同名的数据流。多个数据流可以指向同一个加工，也可以从一个加工发出许多数据流。

加工是以数据结构或数据内容作为加工对象。加工的名字通常是一个动词短语，简明地表明完成的是什么加工。文件在数据流图中起保存数据的作用，因而称为数据存储，它也可以是数据库。指向文件的数据流可理解为写入文件或查询文件，从文件中引出的数据流可理解为从文件读取数据或得到查询结果。数据流图中第1种元素是数据源点或汇点，它表示图中要处理数据的输入来源或处理结果要送往何处。由于它在图中的出现仅仅是一个符号，并不需要以软件的形式进行设计和实现，因而，它只是数据流图的外围环境中的实体，故称外部实体。在实际问题中它可能是人员、计算机外围设备或是传感装置。

（2）数据流与加工之间的关系图3-4数据流图加工关系在数据流图中，如果有两个以上数据流指向一个加工，或从一个加工中引出两个以上的数据流，这些数据流之间存在一定的关系。在图3—4中给出描述这些关系所用符号及其含义。其中星号“*”表示相邻的一对数据流同时出现，则表示相邻的两数据流只取其一。（3）分层的数据流图

为了表达数据处理过程的数据加工情况，用一层数据流图是不够的，需要按照问题的层次结构进行逐步分解，并以多层的数据流图反映这种结构关系。先把整个数据处理过程暂且看成一个加工，它的输入数据和输出数据实际上反映了系统与外界环境的接口，这就是分层数据流图的顶层。但仅此一层并未表明数据的加工要求，需要进一步细化。如果一个数据处理包括3个子系统，就可以画出表示这3个子系统1、2、3的加工及其相关的数据流。这是顶层下面的第一层数据流图,继续分解这3个子系统，可得到第二层数据流图，它们分别是子系统1、2和3的细化。这样得到的多层数据流图可十分清晰地表达整个数据加工系统的真实情况。对任何一层数据流图来说，称它的上层图为父图，在它下一层的图则称为子图。在多层数据流图中，可以把顶层流图、底层流图和中间层流图区分开来。顶层流图仅包含一个加工，它表示被开发系统。它的输入流是该系统的输入数据，输出流是系统的输出数据。顶层流图的作用在于表明被开发系统的范围，以及它和周围环境的数据交换关系。底层流图是指其加工不须再做分解的数据流图，其加工称为“原子加工”。中间层流图则表示对其上层父图的细化。它的每一加工可以继续细化，形成子图。中间层次的多少视系统的复杂程度而定。4．数据流图的用途

利用数据流图把对现有系统的认识或目标系统的设想描绘出来，供有关人员审查确认。由于在数据流图中通常仅使用四种基本符号，而且不包含任何有关物理实现的细节，因此，绝大多数用户都可以理解和评价它。

数据流图的作用主要有以下几条：(1)系统分析员用这种工具可以自顶向下分析系统信息流程。(2)可在图上画出需要计算机处理的部分。(3)根据数据存贮，进一步作数据分析，向数据库设计过渡。(4)根据数据流向，定出存取方式。(5)对应一个处理过程，用相应的语言、判定表等工具表达处理方法。

5．数据流图的特点

(1)总体概念强，每一层都明确强调干什么，需要什么，给出什么。

(2)可以反映出数据的流向和处理过程。

(3)由于自顶向下分析，容易及早发现系统各部分的逻辑错误，也容易修正。

(4)容易与计算机处理相对照。

(5)不直观，一般都要在作业流程分析的基础上加以概括、抽象、修正来得到。

如果没有计算机系统帮助的话，人工绘制太麻烦，工作量较大。

6．数据流图画法

(1)画数据流图的一般原则

画数据流图的基本原则是:就是自外向内，自顶向下，逐层细化，完善求精。具体步骤如下。

①先找系统的数据源点与汇点。它们是外部实体，由它们确定系统与外界的接口。

②找出外部实体的输出数据流与输入数据流。

③在图的边上画出系统的外部实体。

④从外部实体的输出数据流（即系统的源点）出发，按照系统的逻辑需要，逐步画出一系列逻辑加工，直到找到外部实体所需的输入数据流（即系统的汇点），形成数据流的封闭。⑤按照下述的原则进行检查和修改。

·数据流图的主图必须包括前述四种基本元素，缺一不可；

·数据流图上所有图形符号只限于前述四种基本图形元素；

·数据流图的主图上的数据流必须封闭在外部实体之间，外部实体可以不只一个；

·每个加工至少有一个输入数据流和一个输出数据流；

·在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。

·任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致，此即父图与子图的平衡，表明了在细化过程中输入与输出不能有丢失与添加。

·图上每个元素都必须有名字。表明数据流和数据文件是什么数据，加工做什么事情。

·数据流图中不可带有控制流。因为数据流图是实际业务流程的客观映象，说明系统做什么而不是要表明系统如何做，因此不是系统的执行顺序，不是程序流程图。

·初画时可以忽略琐碎的细节，以集中精力于主要数据流。

⑥按照上述步骤，再从各加工出发，画出所需的子图。

(2)数据流图的分层方法

描述一个复杂的系统，不可能用一张数据流图画出所有的数据流和处理逻辑，否则这张图将极其庞大而复杂，因而难以绘制，更难以理解。所以必须用分层的方法将一个数据流图分解成多层数据流图来分别表示。一个分层的数据流图由顶图、底图和中间层的数据流图所组成。顶图说明了系统的边界，即系统的输入和输出的数据流，顶图只有一张。底图由一些不必再分解的处理逻辑组成，

图3-5分层数据流图这些处理逻辑称为基本的处理逻辑。在顶图和底图之间是中间层。称上层图为下层图的“父”图，下层图称为上层图的“子”图。通过对层次的数据流图的描述，一个复杂的系统，可以按层次逐级分解，一直分解到最简单、不需再分的基本处理逻辑为止，这样对一个系统可以由粗到细逐级地分解，使用户、系统分析员以及系统设计人员能对系统有一个从总体到具体，逐层地、清晰地描绘与理解一个复杂系统的逻辑。图3-5是一个分层数据流图的父图和子图示例。

(3)分层法绘制流程图的几个问题

①编号的设置

子图的编号是父图相应的处理逻辑的编号。

子图中处理逻辑编号由子图号、小数点与局部号组成。如上例中，对应父图中3的子图中的处理逻辑相应的用3.1、3.2、3.3。

②父图与子图的平衡

子图详细地描述父图中处理逻辑，因而子图的输入、输出数据流应该同父图中处理逻辑的输入、输出数据流相一致。

③局部数据存贮

局部数据存贮在子图中出现的数据存贮，可以不出现在父图中，画父图时只需画出处理逻辑之间的联系，不必画出各个处理逻辑内部的细节。

④处理逻辑的分解与分细的程度

分得太细，则使得层次太多；分得太粗，则达不到分层的目的。

从管理的层次结构原理来看，在分解一层时一般不宜超过7个逻辑。一个处理逻辑分解到基本处理逻辑为止。基本处理逻辑能表达系统所有的逻辑功能和必要的数据输入与输出，这些功能与数据的描述能使用户清楚地理解，并且还能使以后的系统设计人员看到每一个处理逻辑，并据此能设计程序模块实现这些逻辑功能。

⑤由左到右绘制数据流图

先从左侧开始，标出外部实体。外部实体通常是系统主要的数据来源。然后画出由该外部实体产生的数据流和相应的处理逻辑。如果需要将数据保存，则在数据流图上加上数据存贮。最后画出接受系统输出信息的系统的外部实体。

⑥绘制数据流图时，可以先忽略次要的信息

这一点相当重要且易被忽视，不要试图仅用一两层数据流图就想描述整个系统。这样不仅会使数据流图缺乏条理而给后来的使用造成不便，而且也容易在绘制时造成错误。绘制第0层与第1层的草图时，应该集中反映系统中主要的、正常的逻辑功能以及与之相关的数据交换,然后再将其余次要的处理逻辑补上，完成一张完整的数据流图。

⑦合理地命名

数据流图中对每一个元素都要命名，恰当地命名有助于数据流图的理解与阅读。命名原则如下：

·为了避免引起错觉，为每个元素所取的名字要能反映该元素的整体性内容，而不只是它的部分内容。

·每个元素的名字都能有唯一地标识该元素。

·避免用空洞的名字，要具体的含义。

·如果出现很难为某个数据流或处理逻辑命名时，这往往是数据流图分解不当的征兆，可重新分解。

7．数据流图的绘制与其它流程图的差别（1）数据流图与系统流程图的区别系统流程图中不仅有数据流，还有物流、资金流。数据流图将物流与资金流排除在外，或者将它们抽象为数据流的形式。也就是说数据流图仅以数据流的形态来反映一个组织中整个管理业务的过程。

（2）数据流与程序流程图的区别

程序流程图中的处理框之间有严格的时间上的顺序，也就先执行哪个处理框，起始点以及终止点等。而数据流图只反映数据的流向、处理逻辑和必要的数据存贮，它不反映处理逻辑的先后的时间顺序。

（3）数据流与程序结构图的区别

程序结构图反映模块之间的控制关系，以及模块之间的调用关系，而数据流图则不反映控制关系、调用关系、控制流，只画数据流。

（4）数据流与控制流的区别

如果某条线上没有数据（指表示事物的信息，而不是控制信号）流过，则是控制流。

8．实例

下面通过一个简单的例子具体说明如何画数据流图。分析一家公司的营销系统。其采购部门每天须要按销售部门提供的定货单（须定的货物）向供应商采购货物。每种货物的数量都存放在数据存储货物库存中，销售和采购使每种货物数量发生的变化能够在此数据存储中及时被反映出来。而资金的汇总、核对等工作由其会计部门处理。这样此系统的顶层结构就大致可以分析出来。如图3-6所示，为本系统的第一层数据流图。

为了更加清晰的描述系统，可把顶层数据流图的三个主要加工：销售、采购、会计再进行逐步分解，这样形成第二层数据流图。首先分析销售加工：先根据顾客的定货单和货物目录确定定货，在这期间要修改和维护货物目录和顾客两个数据存储。对于正当的定货，目前有货可发的则直接产生发货单准备发货；而如果暂时缺货则产生暂存定货单，等采购到所需的货物再产生发货单。按顾客要求发货后，要修改货物库存、销售历史和应收款帐目这三个数据存储。对于库存和销售历史的变化要分别编写库存检索和库存销售报表提供给经理，其数据流图如图3-7所示。图3-7销售系统再来分析采购加工：首先根据暂存定货单和货物的库存情况确定须定的货物，产生须定货物的数据存储。对须定货物按供应商汇总，产生采购定货单分别发给不同的供应商。如果供应商发出的发货单正确无误，提货后向销售部门发出到货通知并修改库存、应付款帐目和须定货物数量。这样为以后的定货提供依据。其数据流图如图3-8所示。最后，分析会计加工：顾客付款后应得到收据，收款处理还应该修改数据存储。应收款帐目。而对供应商的应付款通知进行核对后要进行付款处理。这个操作要修改另一数据存储：应付款帐目。这时要根据应收款帐目和应付款帐目的修改情况进行修改总帐目的处理。最后把总帐目的变化情况编制成会计报表提交给经理，其数据流图如图3-9所示。

图3-9会计系统

以上两层四张数据流图一起组成了这家公司营销系统的分层数据流图。第二层的加工比第一层要细，且为足够简单的“基本加工”，不必再分解。

3.2.3数据字典数据字典的作用是在软件分析和设计的过程中提供关于数据的描述信息。在数据流图上描述了系统由哪几部分组成，各部分之间的联系等，但并未说明各个元素含义与包含的内容。数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难以发挥作用。只有数据流图对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

1．数据字典的定义

数据字典是关于数据的信息的集合，对数据流图中的各个元素作完整的定义与说明，是数据流图的补充工具。数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数据流图就不严格，然而没有数据流图数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。

2．数据字典的内容

一般说来，数据字典应该由对下列六类元素的定义组成。

（l）数据流在一个数据流图上，数据按数据流为单位传输。主要内容有；

①数据流名称及其称号表示。②数据流的来源：一个外部实体、处理逻辑、数据存贮。③数据流的去处：一个外部实体。④数据流的组成：一个数据流可能包括若干个数据结构，若只有一个数据结构，就不需要专门定义。⑤数据流的流通量：单位时间的传输次数。⑥高峰时期的流通量：业务的频繁程度和时间有关。

（2）数据项数据项也称数据元素，是不可再分的数据最小组成单位，主要内容有：①数据项名称及编号：数据项名称必须唯一地标识这个数据项，以区别于其他数据项；给数据项取名时，要反映该数据项的含义，易于他人理解与记忆。②别名：同一数据项的名称可能不止一个，称为别名。③取值的范围和取值的含义④数据项的长度：指数据项所包含的字符或数字的位数。

（3）数据结构数据结构描述了某些数据项之间的关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据组成，也可以由若干个数据项和数据结构组成。主要内容包括如下。①数据结构的名称及其编号②数据结构的组成：如果是一个简单的数据结构，只要列出它所包含的数据项即可。如果是一个嵌套的数据结构，只需列出它所包含的数据结构名称，因为这些数据结构同样在数据字典中有定义。例如：对于顾客的订货单就包括：①订货单标识：订货单编号、订货单日期②顾客档案：顾客名称、顾客地址、联系人姓名、电话、开户银行、帐号③配件详情：配件名称、规格、订货数量

（4）数据存贮数据存贮是数据结构停留或保存的场所。主要内容：①数据存贮的名称及其编号：在数据流程图中对数据存贮给以命名，并编上一个唯一的编号。②流入、流出的数据流：流入的数据流指出其来源，流出的数据流指出其去向。③数据存贮的组成：指它所包含的数据项或数据结构。例如：①数据存贮名称：销售历史②编号：F05-01③简述：公司从月初到目前为止所有配件的销售量。④流入的数据流：“顾客的发货单”，来源是“产生发货单”处理逻辑。⑤流出的数据流：“销售量”，去向是“产生销售报表”处理逻辑。⑥数据存贮的组成：配件编号+日期+销售量

（5）处理逻辑。主要内容：①处理逻辑的名称及编号②简述：对处理逻辑的简明描述，其目的是使人了解这个处理逻辑是做什么用的。③处理逻辑的输入和输出。④处理逻辑的主要功能⑤处理逻辑的小说明（文档之一）处理逻辑小说明对处理逻辑的功能作明确的描述，详细地描述其输入/输出的数据流，以及这些数据的基本转换路径和策略，它补充了数据字典的不足。目前较流行的表达处理逻辑小说明的工具有：结构式语言、判断树、判断表等。

（6）外部实体外部实体是系统的“人-机”界面，也就是系统的数据流由外部实体流入，或者系统的数据向外部流出。主要内容：①外部实体的名称及编号②与外部实体有关的数据流例如：①外部实体名称：供应商②编号：GS03-22③简述：向本公司供应货物的个人和单位④有关的数据流：从外部实体流入：D01-11“发货单”D01-12“收据”、输出给外部实体：D01-01“订货单”D01-05“付款单”

除了数据定义之外，数据字典中还应该包含关于数据的一些其他信息。典型的情况是，在数据字典中记录数据元素的下列信息：一般信息（名字，别名，描述等等），定义（数据类型，长度，结构等等），使用特点（值的范围，使用频率，使用方式——输入／输出／本地，条件值等等），控制信息（来源，用户，使用它的程序，改变权，使用权等等）和分组信息（父结构，从属结构，物理位置——记录、文件和数据库等等）。

数据元素的别名就是该元素的其他等价的名字，出现别名主要有下述三个原因：

①对于同样的数据，不同的用户使用了不同的名字；

②一个分析员在不同时期对同一个数据使用了不同的名字；

③两个分析员分别分析同一个数据流时，使用了不同的名字。

虽然应该尽量减少出现别名，但是不可能完全消除别名。

3．定义数据的方法

大多数复杂事物的定义方法，都是用被定义的事物的成分的某种组合表示这个事物，这些组成成分又由更低层的成分的组合来定义。从这个意义上说，定义就是自顶向下的分解，所以数据字典中的定义就是对数据自顶向下的分解。一般说来，当分解到不需要进一步定义，每个和工程有关的人也都清楚其含义的元素时，这种分解过程就完成了。

由数据元素组成数据的方式只有下述三种基本类型；

（l）顺序：即以确定次序连接两个或多个分量；

（2）选择：从两个或多个可能的元素中选取一个；（3）重复：指定的分量重复零次或多次；（4）可选：一个分量是可有可无的（重复零次或一次）。

可以使用上述前三种关系算符定义数据字典中的任何条目。为了说明重复次数，重复算符通常和重复次数的上下限同时使用（当上下限相同时表示重复次数固定）。当重复的上下限分别为1和0时，可以用重复算符表示某个分量是可选的（可有可无的）。但是，“可选”是由数据元素组成数据时一种常见的方式，把它单独列为一种算符可以使数据字典更清晰一些。因此，增加了上述的第四种关系算符。

虽然可以使用自然语言描述由数据元素组成数据的关系，但是为了更加清晰简洁起见，建议采用下列符号：

=意思是等价于（或定义为）；

+意思是和（即，连接两个分量）；

[]意思是或（即，从方括号内列出的若干个分量中选择一个）；

｛｝意思是重复（即，重复花括号内的分量）；

（）意思是可选（即，圆括号里的分量可有可无）。常常使用上限和下限进一步注释表示重复的花括号。一种注释方法是在开括号的左边用上角标和下角标分别表明重复的上限和上限；另一种注释方法是在开括号左侧标明重复的下限，在闭括号的右侧标明重复的上限。例如：

在方括号中列出的供选择的分量可以从上而下排成若干行，也可以写成一行中间用“|”号分开。例如下面两种写法是等价的。

例子：如数据流：发票的组成为学号，姓名，发票项，书费合计，则可定义为：发票=（学号）+姓名+｛发票项｝+书费合计学号=5｛数字｝5

*如：1205，2035*发票项=书号+单价+数量+总价书号=｛文字｝+3｛数字｝3*如：英语001，软件工程002，编译原理012*

从上面例子可以看出对于较复杂的数据流，分层描述更为清晰。

4．数据字典的用途

数据字典是分析阶段重要的工具。在数据字典中建立的定义有助于改进分析员和用户之间的通信，对数据的严密的定义有助于改进在不同的开发人员或不同的开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。

5．数据字典的实现

实现数据字典有三种途径；全人工过程，全自动化过程（利用数据字典处理程序）和混合过程（用正文编辑程序，报告生成程序等已有的实用程序帮助人工过程）。不论使用哪种途径实现的数据字典都应该具有下述特点

（1）通过名字能方便地查阅数据的定义；

（2）没有冗余；

（3）尽量不重复在规格说明的其他组成部分中已经出现的信息；

（4）容易更新和修改；

（5）能单独处理描述每个数据元素的信息；

（6）定义的书写方法简单方便而且严格。

如果暂时还没有自动的数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据元素的信息。这种做法较好地实现了上述要求，特别是更新和修改起来很方便，能够单独处理每个数据元素的信息。每张卡片上主要应该包含下述信息：

名字、别名、描述、定义、位置。

当开发过程进展到能够知道数据元素的控制信息和使用特点时，把这些信息记录在卡片的背面。

本节数据流图的实例中几个数据元素的字典卡片如下。

名称：定货单

编号：D01-05

描述：送交采购员的需要定货的货

物表

定义：定货单=货物编号+货物名称

+定货数量+货物单价+供应

商+0｛备用供应商｝3

位置：在打印机输出

名称：销售历史

编号：F05-01

描述：公司从月初到目前为止所

有配件的销售量。

定义：配件编号+日期+销售量

位置：销售库存报表3.3图形工具在描绘复杂的关系时，图形比文字直观、一目了然。下面简要介绍在需求分析阶段常用到的三种图形工具，即层次方框图、Warnier图、IPO图。3.3.1层次方框图

层次方框图是用具有多层次的树形结构的矩形框描述数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际的、不能再分割的元素的数据元素。

例如,某计算机公司全部产品的数据结构如图3-10所示.这家公司的产品由硬件、软件和服务三类产品组成，软件产品又分为系统软件和应用软件，系统软件又进一步分为操作系统、编译程序和软件工具，......。

图3-10某计算机公司全部产品的数据结构随着结构的精细化，层次方框图对数据结构也描绘的越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节为止。3.3.2Warnier图

法国计算机科学家Warnier提出了表示信息层次结构的一种图形工具。与层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘能力。

用Warnier图可以表明信息的逻辑组织，它可以指出一类信息或一个信息量是重复出现的，也可以表示特定信息在某一类信息中是有条件出现的。因为重复和条件约束是说明软件处理的基础，所以很容易把Warnier图变成软件设计的工具。

图3-11是用Warnier图描绘一类软件产品的例子，它说明了这种图形工具的用法。图中的花括号用来区分数据结构的层次，在一个花括号中的所有名字都属于一类信息；异或信息⊕表明一类信息或者一个数据元素在一定条件下才出现，而且在这个符号上、下方的两个名字所代表的数据只能出现一个；在一个名字下面（或右边）的括号中的数字表明了这个名字所代表的信息类（或元素）在这个数据结构中重复出现的次数。3.3.3IPO图IPO图是输入/处理/输出图的简称,它是美国IBM公司提出的一种图形工具,能方便的描述输入数据\对数据的处理和输出数据的关系。IPO图使用的基本符号少而简单，因此很容易学会使用这种工具。它的基本形式是在左边的框中列出有关的输入数据，在中间的框中列出主要的处理，在右边的框中列出产生的输出数据。处理框中列出的处理的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。图3-12是一个主文件更新的例子，通过此例可以加快理解IPO图的用法。

3.4需求规格说明与评审

应当清晰准确的描述已确定的需求。通常把描述需求的文档叫做软件需求规格说明书。为了确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册，侧重反映被开发软件的用户界面和用户使用的具体要求。此外，根据在需求分析阶段对系统的进一步分析，从目标系统的精细模型出发，可以更准确地估计所开发项目的成本与进度，从而修改、完善与确定软件开发实施计划。3.4.1需求规格说明的主要内容软件需求规格说明作为分析结果，它是软件开发，软件验收和管理的依据。因此，必须特别重视这一项工作，否则将可能要付出很大代价。软件需求规格说明的一般格式如下。

-------------------------------------------------------------------------

1．引言

（1）编写目的(阐明编写需求说明书的目的，指明读者对象。)

（2）项目背景(应包括：项目的委托单位、开发单位和主管部门；该软件系统与其他系统的关系。)

（3）定义(列出文档中所用到的专门术语的定义和缩写词的原文。)

（4）参考资料(可包括：项目经核准的计划任务书、合同或上级机关的批文；项目开发计划；文档所引用的资料、标准和规范。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。)

2．任务概述

（1）目标

（2）运行环境

（3）条件与限制

3．数据描述

（1）静态数据

（2）动态数据(包括输入数据和输出数据。)

（3）数据库描述(给出使用数据库的名称和类型。)

（4）数据词典

（5）数据采集

4．功能要求

（1）功能划分

（2）功能描述

5．性能需求

（1）数据精确度

（2）时间特性(如响应时间、更新处理时间、数据转换与传输时间、运行时间等。)

（3）适应性(在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。)

6．运行需求

（1）用户界面(如屏幕格式、报表格式、菜单格式、输入输出时间等。)

（2）硬件接口

（3）软件接口

（4）故障处理

7．其他要求

如可使用性、安全保密、可维护性、可移植性等

8．附录

---------------------------------------------------------------------------3.4.2需求分析的评审需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15％的错误来源于错误的需求。因此，软件需求说明书完成以后，需要认真进行技术评审和修改。作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审的主要内容是：·系统定义的目标是否与用户的要求一致；·系统需求分析阶段提供的文档资料是否齐全；·文档中的所有描述是否完整、清晰、准确反映用户要求；·与所有其他系统成分的重要接口是否都已经描述；·所开发项目的数据流与