软件需求分析

第三章软件需求工程

§3.1软件需求分析

准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用<需求规格说明书>规范的形式准确地表达用户的需求。在进行可行性研究和项目开发计划以后，如果确认开发一个新的软件系统是必要的而且是可能的，那么就可进入需求分析阶段。

需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约(需求规格说明)的过程。需求分析概述

软件需求是指用户对目标系统在功能、行为、性能等方面的期望。需求分析是发现、求精、建模和产生规格说明的过程，软件开发人员需对应用问题及环境的理解、分析，为问题涉及的信息、功能及行为建立模型。需求分析实际上是对系统的理解与表达的过程，是一种软件工程的活动。理解的含义就是开发人员充分理解用户的需求，对问题及环境的理解、分析与综合，逐步建立目标系统的模型。通常软件人员和用户一起完全了解系统的确切的要求，即系统要做什么。表达的含义是产生规格说明书等有关的文档。规格说明就是把分析的结果完全地、精确地表达出来。系统分析员经过调查分析后建立好模型，在这个基础上，逐步形成规格说明书，需求规格说明书是一个非常重要的文档。经过软件的需求分析建立起来的模型可以称它为分析模型或者需求模型，注意到分析模型实际上是一组模型，它是一种目标系统逻辑表示技术，它可以用图形描述工具来建模，选定一些图形符号分别表示信息流、加工处理、以及系统的行为等，还可以用自然语言给出加工说明。软件需求分析的困难性

(1)问题的复杂性。这是由用户需求所涉及的因素繁多引起的，如运行环境和系统功能等。(2)交流障碍。需求分析涉及人员较多，如软件系统用户、问题领域专家、需求工程师和项目管理员等，这些人具备不同的背景知识，处于不同的角度，扮演不同角色，造成了相互之间交流的困难。(3)不完备性和不一致性：由于各种原因，用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着予盾，需求分析要消除其矛盾，形成完备及一致的定义(4)需求易变性。用户需求的变动是—个极为普便的问题，即使是部分变动，也往往会影响到需求分析的全部，导致不一致性和不完备性。软件需求

（1）用户解决问题或达到目标所需的条件或权能（Capability）。（2）系统或系统部件要满足合同、标准、规范或其他正式规定文件所需具有的条件或权能。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。

软件需求的层次

·业务需求:业务需求反映了组织机构或者客户对系统、产品高层的目标要求，它们在项目视图与范围文档中给予说明。·用户需求:用户需求描述了用户使用产品必须要完成的任务，这可以在使用实例文档给予说明。用户需求应该只描述系统的外部行为，尽量避免对系统设计特性描述。用户需求通常用自然语言、图表以及直观的图形来描述。在用户需求描述时，可能会出现描述不够清楚、需求混乱、需求混合等问题。系统需求又可以分成功能需求、非功能需求性和领域需求。

功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。在需求规格说明中，功能需求充分描述了软件系统所具有的外部行为（服务）。

非功能性需求是不直接与系统具体功能相关的一类需求，例如，可靠性、响应时间、存储空间等。非功能需求可以分类：（1）产品需求。（2）机构需求。（3）外部需求。领域需求来自系统的应用领域的需求，反映了该领域的特点。它们可能是一个新的特有的功能需求、或者是对已存在的功能需求的约束，也可能是一种非功能需求。需求工程

软件需求工程领域的层次分解:需求分析原则

必须理解和表示问题的信息域，可用数据模型描述；·必须定义软件将完成的功能，可用功能模型描述；·必须表示软件的行为（服务、操作），可用行为模型描述；·对描述的信息、功能和行为模型必须被划分，使得分析模型可以用层次的方法展示细节。·分析过程应该从要素信息移到实现细节。可以采用逐步求精的技术。需求分析的步骤当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化抽象化具体化实例化怎么做做什么当前系统目标系统需求定义逻辑模型和物理模型

模型是对对象系统的形式化的特征抽象，概括性或近似地表示；

构造模型的过程是一个抽象、分析的过程。对象系统模型系统抽象（映射）模型应用模型构造的过程

逻辑模型物理模型

(本质模型、概念模型)

(实施模型、技术模型)现行系统目标系统描述重要的业务功能，无论系统是如何实施的。描述现实系统是如何在物理上实现的。描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。描述新系统是如何实施的（包括技术）。获得当前系统的物理模型

了解当前系统的组织机构、输入输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映对当前系统的理解。需求分析过程示意学生(1)通过对现实环境的调查，

获得当前系统的物理模型

学生购书申请购书单发票领书单书107张教务科206王会计室206李出纳员303赵教材科学生购买教材的物理模型抽象出当前系统的逻辑模型

在理解当前系统“怎样做”的基础上，抽取出“做什么”的本质，从当前系统的物理模型中抽象出当前系统的逻辑模型。

需求分析过程示意(2)去掉具体模型中的非本质因素，

抽象出当前系统的逻辑模型

学生购买教材的逻辑模型学生学生购书申请购书单发票领书单书审查有效性开发票开领书单发书建立目标系统的逻辑模型

（1）决定变化的范围，即决定目标系统与当前系统在逻辑上的差别；（2）对功能图（数据流图）及对象图等进行调整，将变化的部分看成是新的处理步骤；（3）由外向里对变化的部分进行分析，推断其结构，获得目标系统的逻辑模型。需求分析过程示意(3)分析当前系统与目标系统的差别，

建立目标系统的逻辑模型

计算机售书系统的逻辑模型学生学生购书单发票领书单审查并开发票开领书单无效书单对得到的逻辑模型做一些补充：

（1）说明目标系统的用户界面。根据目标系统所处的应用环境及它与外界环境的相互关系，研究所有可能与它发生联系和作用的部分，从而决定人机界面。（2）说明至今尚未详细考虑的细节。这些细节包括系统的启动和结束、出错处理、系统的输入／输出、系统性能等。（3）系统必须满足的其他性能。具体任务：

·绘制系统关联图；·创建用户接口原型；·分析需求可行性；·确定需求的优先级；·为需求建立模型；·创建数据字典。需求开发过程

需求获取

·功能需求·性能需求·环境需求·安全保密要求·用户界面需求

·资源使用需求

软件成本消耗与开发进度需求

软件质量属性

·有效性（availability）有效性=系统的平均故障时间/（平均故障时间＋故障修复时间）·高效性（efficiency）·灵活性（flexibility）·完整性（integrity）·互操作性（interoperability）·可靠性（reliability）·健壮性（robustness）·可用性（usability）·可维护性（maintainability）·可移植性（Portability）·可重用性（reusability）·可测试性（testability）需求分析

需求分析包括提炼、分析、和审查已收集的需求，以确保所有的风险承担者都明白它们的含义，并且找出其中的错误、遗漏或者不足的地方。

需求规格说明描述需求的文档叫做软件需求规格说明，分析模型是需求规格说明中的其中一部分。分析员应以调查分析及分析模型为基础，逐步形成规格说明书。

制定数据要求说明书及编写初步的用户手册。

修改、完善并确定软件开发实施计划。

需求评审

对功能的正确性、完整性和清晰性，以及其他需求给予评价。评审应指定专人负责，并严格按规程进行。评审结束后应由评审负责人签署评审意见。通常，在评审意见中包括了一些修改意见，须按这些修改意见对软件进行修改，待修改完成后还要再评审，直至通过才可进行软件设计。软件需求建模

所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。简单地说，模型就是某一事物的抽象表示方式。通常，软件工程中的模型可以由一组图形符号和组织这些符号的规则组成。

最终确立的分析模型是生成需求规格说明的基础，也是软件设计和实现的基础。模型的作用建模的原因：在建模过程中了解系统通过抽象降低复杂性有助于回忆所有的细节有助于开发小组间的交流有助于与用户的交流为系统的维护提供文档

模型化或模型方法是通过抽象、概括和一般化，把研究的对象或问题转化为本质（关系或结构）相同的另一对象或问题，从而加以解决的方法。模型化方法要求所建立的模型能真实反映所研究对象的整体结构、关系或某一过程、某一局部、某一侧面的本质特征和变化规律。模型的类型数学模型描述模型图形模型软件分析模型

的基本要求·描述用户对软件系统的需求；·为软件设计奠定一个良好的基础；·定义一组需求，并且可以作为软件产品验收的标准。数据模型

数据模型用于描述数据对象之间的关系，数据模型应包含有三种相关的信息，即数据对象、属性和关系。

·数据对象数据对象是几乎所有必须被软件理解的复合信息的表示。复合信息是指具有若干不同特性或者属性的事物。所以，仅有单个值的事物不是对象，例如，宽度、长度等等。数据对象可以是一个外部实体、事物、行为、事件、角色、单位、地点、结构等等。

属性定义了数据对象的性质，它具有三种不同的特性之一。（1）为数据对象实例命名；（2）描述该实例；（3）引用另一个实例。

·关系数据对象彼此之间是有关联的，也称为关系。例如，数据对象“教师”和“课程”的连接关系是“教”；数据对象“学生”和“课程”的连接关系是“学”等等。这种关联的形态有三种。（1）一对一关联（1：1）。例如，一个间学校只有一位校长，所以，学校与校长的关联是一对一的。（2）一对多关联（1：N）。例如，一位教师可以“教”多门课程，所以，教师和课程的关联是一对多的。（3）多对多关联（M：N）。例如，一名学生可以学多门课程，一门课程有多名学生学习，所以，学生和课程的关联是多对多的。实体—关系图

ERD包含三种基本元素，即实体、属性、关系。通常用矩形表示实体即数据对象；用圆角矩形或者椭圆形表示实体的属性；用菱形连接相关实体表示关系。功能模型

数据流图中的基本元素有：

·数据流·加工处理·文件·源点和终点分解的程度

系统自顶向下逐层分解时，可以把一个加工分解成几个加工，当每一个加工都已分解到足够简单时，分解工作就可以结束了。足够简单的不再分解的加工称为基本加工。如果某一层分解不合理、不恰当就要重新分解。加工说明

加工说明或者说加工处理（ProcessSpecification）过程，它用于描述系统的每一个基本加工处理的逻辑，说明输入数据转换为输出数据的加工规则。加工逻辑仅说明“做什么”就可以了，而不是实现加工的是细节。加工说明的描述方式可以用结构化语言、判定表、判定树、IPO（输入/处理/输出）图等等。行为模型

状态机模型通过描述系统的状态以及引起系统状态转换的事件，来表示系统的行为。状态图中的基本元素有事件、状态和行为等。数据字典

数据字典（DataDictionary）用于描述软件系统中使用或者产生的每一个数据元素，是系统数据信息定义的集合。数据字典方便于人们对不了解的条目进行查阅，人们可以借助于数据字典查出每一个名字（包括数据流、加工名、文件名等）的定义和组成，以免产生误解。面向对象模型

分析模型有3个子模型—对象模型、动态模型和功能模型。其中，对象模型描述软件系统的静态结构；动态模型描述软件系统的控制结构；功能模型描述软件系统必须要完成的功能。

需求规格说明书(SRS)

(SoftwareRequirementSpecification)需求分析阶段要完成的文档。SRS的作用：开发者与用户间事实上的技术合同书开发者下一步设计和编码的基础测试验收目标系统的依据软件需求规格与评审

SRS也是客户和开发小组对将要开发的产品达成一致的协议，这个协议应该综合业务需求、用户需求和一个详细系统需求描述；它能精确地反映和描述一个软件系统必须提供的功能（应该做什么）以及实现和运行的约束条件。软件需求规格不应该包括设计、构造、测试或者工程管理的细节。·用结构化和自然语言编写文本型文档；·建立图形化模型，这些模型可以描绘数据变换过程、系统状态和它们之间的变化、数据关系、逻辑流、对象类以及它们的关系；·用形式化语言编写，通过使用数学上精确的形式化逻辑语言来定义需求。

软件需求规格目标

·便于用户、分析员和软件设计人员进行理解及交流；·支持目标系统的确认，反映问题的结构，可作为设计和编程的基础；·控制系统的实施过程；·作为软件测试和验收以及维护的依据。

需求规格说明的内容

见文档。软件需求规格的评审

需求评审是一个手工过程，需要用户和开发者共同参与，检查文档中是否存在不规范和遗漏的地方，如果在评审过程中发现存在错误或者缺陷，应该及时进行更改和补充，重新进行相应部分的需求分析、需求建模等，然后再进行评审。

评审指标

正确性。无歧义性。完全性。需求规格说明不能遗漏任何用户需求。可验证性。对于规格说明中的任意需求，均存在技术和经济可行的手段进行验证和确认。一致性。需求规格说明的各部分之间不能相互矛盾。可理解性。可修改性。可追踪性。需求规格说明必须将分析后获得的每一项需求与用户的原始需求联系起来。

·系统定义的目标是否与用户的要求一致；·系统需求分析提供的文档资料是否齐全；·文档中的所有描述是否完整、清晰、准确；·与所有其他系统成分的重要接口是否都已经描述；·所开发项目的数据流与数据结构是否足够，是否确定；·所有图表是否清楚，是否易于理解；·主要功能是否已包括在规定的软件范围之内；·设计的约束条件或限制条件是否符合实际；·开发的技术风险是什么；·是否考虑过软件需求的其他方案；·是否考虑过将来可能会提出的软件需求；·是否详细制定了检验标准；·有没有遗漏、重复或不一致的地方；·用户是否审查了初步的用户手册；·软件开发计划中的估算是否受到了影响。需求管理

需求管理是一个对系统需求变更了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的初稿，需求管理活动就开始了需求管理强调：·控制对需求基线的变动；·保持项目计划与需求一致；·控制单个需求和需求文档的版本情况；·管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；

需求管理原则

·需求管理的关键过程领域不涉及收集和分析项目需求。

·开发人员在向客户以及有关部门承诺（commitment）某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等等。

·关键处理领域同样建议通过版本控制和变更控制来管理需求文档。

需求规格说明的版本控制

每一个新版本的需求文档，应该公布的包括一个修正版本的历史情况，例如，变更的内容、变更日期、变更人员的姓名以及变更的原因等等。

需求属性

·创建需求的时间；·需求的版本号；·创建需求的作者；·负责认可该软件需求的人员；·需求状态；·需求的原因和根据；·需求涉及的子系统；·需求涉及的产品版本号；·使用的验证方法或者接受的测试标准；·产品的优先级或者重要程度；·需求的稳定性。

需求变更

毫无控制的变更是项目陷入混乱、不能按进度完成，或者软件质量无法保证的主要原因之一。

·仔细评估已建议的变更；·挑选合适的人选对变更做出决定；·变更应及时通知所有涉及的人员；·项目要按一定的程序来采纳需求变更；变更控制过程

·问题分析和变更描述。

这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。·变更分析和成本计算。

使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该制定是否执行这一变更的决策。·变更实现。

这要求需求文档以及系统设计和实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地出现需求文档和程序的不一致。需求变更策略

·所有需求变更必须遵循变更控制过程；·对于未获得批准的变更，不应该做设计和实现工作；·变更应该由项目变更控制委员会决定实现哪些变更；·项目风险承担者应该能够了解变更数据库的内容；·决不能从数据库中删除或者修改变更请求的原始文档；·每一个集成的需求变更必须能跟踪到一个经核准的变更请求。需求变更工具·可以定义变更请求的数据项；·可以定义变更请求生存期的状态转换图；·可以加强状态转换图使经授权的用户仅能做出所允许的状态变更；·记录每一种状态变更的数据，确认做出变更的人员；·可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员；·可以根据需要生成标准的或定制的报告和图表。变更控制委员会

变更控制委员会负责决定哪一些已建议需求变更或者新产品特性付诸应用，决定在哪一些版本中纠正哪一些错误。广义上，变更控制委员会对项目中任何基线工作产品的变更都可以做出决定，需求变更文档仅是其中之一。

A．制定决策制定决策过程（程式）的描述应确认：·变更控制委员会必须到会的人数或做出有效决定必须出席的人员数；·决策的方法（例如投票，一致通过或其它机制）；·变更控制委员会主席是否可以否决该集体的决定。变更控制委员会应该对每个变更权衡利弊后做出决定。“利”包括节省的资金或额外的收入、增强的客户满意度、竞争优势、减少上市时间。“弊”是指接受变更后产生的负面影响，包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意。如果估计的费用超过了本级变更控制委员会的管理范围，上报到高一级的委员会，否则用制订的决策程式来对变更做出决定。B．交流情况一旦变更控制委员会做出决策时，指派的人员应及时更新数据库中请求的状态。有的工具可以自动通过电子邮件来通知相关人员。若没有这样的工具，就应该人工通知，以保证他们能充分处理变更。C．重新协商约定变更总是有代价的。即使拒绝的变更也因为决策行为（提交、评估、决策）而耗费了资源。变更对新的产品特性会有很大的影响。如果向一个工程项目中增加很多新功能，又要求在原先确定的进度计划、人员安排、资金预算和质量要求限制内完成整个项目是不现实的。当工程项目接受了重要的需求变更时，为了适应变更情况要与管理部门和客户重新协商约定。协商的内容可能包括推迟“交货”时间、要求增加入手、推迟实现尚未实现的较低优先级的需求，或者质量上进行折衷。要是不能获得一些约定的调整，应该把面临的威胁写进风险管理计划中，这样当项目没有达到期望的结果时就不会有人惊奇了。需求跟踪

需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必须的工作。需求可跟踪能力

·客户需求向前追溯到软件需求。这样就能区分出开发过程中或者开发结束后，由于需求变更受到影响的需求。这也就可以确保需求规格说明包括所有客户需求。·从软件需求回溯相应的客户需求。这也就是确认每个软件需求的源头，如果用使用实例的形式来描述客户需求，那么客户需求与软件需求之间的跟踪情况就是使用实例和功能性需求。·从软件需求向前追溯到下一级工作产品。由于开发过程中系统需求转变为软件需求、设计、编码等，所以通过定义单个需求和特定的产品元素之间的（联系）链，可以从需求向前追溯到下一级工作产品。这种联系链告诉我们每个需求对应的产品部件（构件），从而确保产品部件满足每个需求。·从产品部件回溯到软件需求。使你知道每个部件存在的原因，如果不能把设计元素、代码段或测试回溯到一个需求，可能有一个“画蛇添足”的程序。然而，如果这些孤立的元素表明了一个正当的功能，则说明需求规格说明书漏掉了一项需求。

需求变更的代价和风险

影响分析是需求管理的一个重要组成部分。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。通过对变更内容的检验，确定对现有的系统做出是修改或者抛弃的决定；或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。软件需求分析工具

需求分析的自动工具按不同的方式可以归为两类。一类工具是为自动生成和维护系统的规格说明（以前是以手工方法制作的）而设计的。这类工具主要利用图形记号进行分析，它们产生一些图示，辅助问题分解，维护系统的信息层次，并使用试探法来发现规格说明中的问题。

另一类需求分析工具要用到一种特殊的以自动方式处理的表示法（多数情况是需求规格说明语言）。用需求规格说明语言来描述需求，它是由关键字指示符号与自然语言（例如英语）叙述组合而成。

需求管理的工具

以数据库为核心的产品把所有的需求、属性和跟踪能力信息存储在数据库中。依赖于这样的产品，数据库可以是商业（通用）的或者是专有的，关系型或者面向对象的。可以从不同的源文档中产生需求，但结果都存在数据库中。在大多数情况下，需求的文本描述被简单地处理为必须的属性。

分析建模方法结构化分析(传统建模方法)面向对象分析第3章作业1、什么是需求分析？需求分析有哪些原则？2、简述建立目标系统逻辑模型的一般步骤。3、软件的质量属性有哪些？各自含义是什么？4、需求规格说明评审指标有哪些？各自含义是什么？5、简述需求管理的主要活动。结构化方法包含：SA-SD-SP原理：自顶向下、逐步求精基本原则：抽象与分解结构化分析方法(StructuredAnalysis,SA)基本原则：P153

抽象:先把分析对象抽象成为一个系统。

分解：由顶向下，层层分解，使复杂的系统分解成足够简单，能被清楚地理解和表达的若干子系统。结构化分析方法SA结构化分析（StructuredAnalysis，SA）是由DouglasRoss提出的，由DeMarco进行推广的。采用自顶向下、逐层进行功能分解的系统分析方法来定义系统的需求。适用于分析大型的数据处理系统。方法的特点：利用数据流图（DataFlowDiagram，DFD）来帮助理解问题，对问题进行分析。一般工具：DFD、数据字典、结构化英语、判定表、判定树等。SA分析模型的主要目标描述用户需要建立创建软件设计的基础定义软件完成后可被确认的一组需求SA分析模型的结构数据字典数据流图E-R图状态变迁图加工规约控制规约数据对象描述结构化分析方法功能分析工具：DFD、DD、结构化英语、判定表和判定树。行为分析工具：状态迁移图、Petri网等。数据分析工具：ER图或者EER（扩展ER）图。SA主要针对数据处理领域，因此，系统分析的侧重点在于功能分析和数据分析，而行为分析使用得较少。分析模型的构成元素数据字典(DD)

模型核心，包含了所有数据对象的描述的中心库。E-R图(ERD)表示数据对象以及相互的关系，用于数据建模。数据流图(DFD)指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能;DFD中每个功能的描述包含在加工规约(小说明)。用于功能建模。状态变迁图(STD)指明作为外部事件的结果,系统将如何动作。用于行为建模。数据建模最常用的表示概念性数据模型的方法，是实体联系方法（Entity-RelationshipApproach）ER图描述现实世界中的实体，而不涉及这些实体在系统中的实现方法。E-R图元素⑴Entities例：,

,StudentInstructorClass实体是客观世界中存在的且可相互区分的事务。实体可以是人也可以是物，可以是具体的事物也可以是抽象概念。例如，职工、学生、课程、教师等都是实体。E-R图元素客观世界中的事物彼此间往往是有联系的，例如，教师与课程间存在“教”这种联系。⑵Relations例：EnrolledinTeach111NMNE-R图元素属性是实体或联系所具有的性质。通常一个实体由若干个属性来刻画。例如，“学生”实体有学号、姓名、性别、系、年级⑶Attributes例：,NameID#E-R图…………InstructorStudentEnrolledinTeachClassID#ID#NameNameSexSexTitleInstructorIDClassIDGradeStudentIDClassIDCreditID#Subject例：变换输入信息信息流模型输出信息外部实体外部实体外部实体输入信息外部实体外部实体输出信息输出信息功能建模和信息流数据存储1数据流图数据流图说明(Yourdon表示)：表示外部实体，代表数据源和数据池。表示加工，代表接收输入，经过变换，继而产生输出的处理过程。表示数据流，代表数据的流向和路径。表示数据存储，代表系统加工的数据所存储的地方。外部实体变换数据存储图7.3数据流图的符号1数据流图数据流图(DFD，DataFlowDiagram)描述逻辑模型的图形工具，表示数据在系统内的变化。DFD可以分层表示信息流和功能的细节，既提供了功能建模的机制，又提供了信息流建模的机制。第0层的DFD也被称为基本系统模型或语境模型。DFD没有提供显式的处理顺序，过程或顺序式隐含在DFD中的，显式的推迟到系统设计时。不要混淆DFD和程序流程图！例1

下面通过一个简单例子具体说明怎样画数据流图。假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。数据流图有四种成分：源点或终点、处理、数据存储和数据流。因此，画出上述定货系统的数据流图可采用以下步骤。从问题描述中提取数据流图的四种成分。表1总结了上面分析的结果，其中加星号标记的是在问题描述中隐含的成分。一旦把数据流图的四种成分都分离出来以后，就可以着手画数据流图了。任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。从基本系统模型这样非常高的抽象层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点/终点是一目了然的，因此它是很有价值的通信工具。

下一步应该把基本系统模型细化，描绘系统的主要功能。给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。定货系统的基本系统模型(突出表明了数据的源点和终点)定货系统的功能级数据流图把处理事务的功能进一步分解后的数据流图人事部门人事工资管理系统会计部门职工出缺勤报表职工出缺勤信息职工工资信息职工工资报表职工职工基本信息职工工资单例2：人事工资管理系统的顶层DFD(概图)范例职工基本信息管理子系统1.02.0人事工资管理系统0层DFD范例职工出缺勤信息职工工资管理子系统3.0职工出缺勤管理子系统职工基本信息职工工资信息人事部门会计部门职工职工出缺勤报表职工出缺勤信息职工工资信息职工工资报表职工基本信息职工工资单建立职工出缺勤信息3.1人事工资管理系统1层DFD：加工3.0的分解图职工出缺勤信息3.2制作职工出缺勤信息统计表职工基本信息职工出缺勤报表职工出缺勤信息例3：分层DFD实例一个简单的考务处理系统功能描述：(1)对考生送来的报名单进行检查;(2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站;(3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者;(4)制作考生通知单(含成绩及合格/不合格标志)送给考生;(5)按地区进行成绩分类统计和试题难度分析，产生统计分析表。考生考务处理系统考试中心阅卷站不合格报名单报名单准考证考生通知单成绩清单合格标准错误成绩清单考生名单统计分析表顶层数据流图登记报名单报名单准考证1统计成绩2不合格报名单考生通知单成统计分析表考生名册绩清单合格标准考生名单成绩清单错误0层数据流图1层数据流图(a)检查报名单报名单准考证1.1编准考证号1.2不合格报名单考生名册考生名单合格报名单登记考生1.3一层数据流图(b)检查成绩清单2.1审定合格者2.2考生名册正确成绩清单制作通知单2.3分析统计成绩2.4分析试题难度2.5试题得分清单考生通知单难度分析表合格标准分类统计表成绩清单错误成绩清单经审定的成绩清单数据流图分解原则DFD可以用来表示一个系统或软件在任何层次上的抽象。较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。顶层数据流图应当把系统或软件作为一个单一的功能来描述。应当注意原始的输入和输出。每个过程的每次细化一般控制在3－4个分过程。所有圆圈和箭头应用有意义的名称标注。一个名称标注在同一个DFD中只能出现一次。每次细化时，细化部分的输入和输出必须保持一致，即保持信息流连续性，有时称为平衡。一次最好只对一个圆圈细化。S2132.22.12.33.13.2顶层（不编号）0层1层数据流图的画法P156注意事项P1578条数据流图与其他流程图的区别P159行为建模采用动态分析方法，直观地分析系统的动作。最常用的动态分析方法：

状态转换图STDSTD通过描述状态以及导致系统改变状态的事件来表示系统的行为。状态是任意可观察的行为模式，一个状态代表系统的一种行为模式。STD指明了系统如何在状态间移动。时序图Petri网就绪t1t4t2t3等待运行状态事件运行就绪等待t1t2t3t4运行就绪就绪等待进程的状态迁移图和状态迁移表状态转换图数据字典DD是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。数据字典4种条目：数据流数据文件数据项加工

操作符含义描述

＝定义为＋与(顺序结构)｛...}n重复n次(循环结构)〔..｜..〕或(选择结构)〔..,..〕(...)任选m..n界域＊...,＊注释符DD内容描述符号表示数据流条目给出DFD中某个数据流的定义，通常包括：

数据流标识数据流来源数据流去向数据流的数据组成流动属性描述：频率、数据量购书单发票领书单审查并开发票开领书单无效书单学生12各班学生用书表举例：学生教材存量表数据流条目说明举例数据流名:购书单别名:

无简述:

学生购书时填写的项目来源:

学生去向:

加工1“审查并开发票”组成:(学号)＋姓名＋｛书号＋数量｝数据流量:1000次/周

高峰值：开学期间1000次/天

数据存储条目(数据文件条目)对某个文件的定义，包括：

文件名描述数据结构数据存储方式关键码存取频率和数据量安全性要求数据存储条目说明举例文件名:库存记录别名:无简述:存放库存所有可供货物的信息组成：货物名称＋编号＋生产厂家＋单价＋库存量组织方式：索引文件，以货物编号为关键字查询要求:要求能够立即查询F1:航班信息文件＝{航空公司名称＋航班号＋起点＋终点＋日期＋起飞时间＋降落时间}航空公司名称＝2{字母}4航班号＝3{十进制数字}3字母＝“A”…“Z”十进制数字＝“0”…“9”起点＝终点＝1{汉字}10起飞时间＝降落时间＝时＋分时＝“00”…“23”分＝“00”…“59”日期＝年＋月＋日年＝[2000｜2001｜2002｜2004]月＝“01”…“12”日＝“01”…“31”数据项条目说明举例数据项名:货物编号别名:G-No,G-num简述:本公司的所有货物的编号类型:字符串长度：11取值范围及含义:第1位：[J｜G](进口/国产)第2-5位：LB01..LB29(类别)第6-8位：“A00”..“A99”(规格)第9-11位：“001”..“999”(品名编号)加工条目(加工逻辑说明)