软件工程 第4章-需求分析课件

第四章4需求分析4.1需求分析概述

需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：

----准确地回答“系统必须做什么?”在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。

4.1.1软件需求的重要性

软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。因而，需求分析是软件开发的基础，所产生的需求规格说明书是以后各阶段开发工作的依据。美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。

分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。未完成完成未实施完成需求分析的重要性软件开发的基础和前提最终目标软件系统验收的标准避免或者尽早剔除早期的错误4.1.2需求分析的困难软件需求是软件工程中最复杂的过程之一：应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。非功能性需求建模技术的缺乏，及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。沟通上的困难，由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。需求内容一般包括：功能需求性能需求环境需求可靠性需求安全保密要求用户界面需求资源使用需求成本消耗需求开发进度需求预先估计以后系统可能达到的目标软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出软件需求的内容软件需求内容功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。领域需求是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。4.1.3需求分析的任务需求分析的任务通过对应用问题及其环境的理解和分析，准确、一致和完全地刻划用户需求，形成软件需求规格说明书(SRS:SoftwareRequirementSpecification)。借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。需求分析阶段(需求分析过程)的基本活动获取和理解用户需求。深入实际，在充分理解用户需求的基础上，获取系统需求。描述和分析用户需求。进行需求建模、对模型或原型进行分析。对用户需求进行评审。确认需求，进化需求。确保需求说明准确、完整地表达系统的主要特性，且客户的需要总是不断（连续）增长的，进化需求是必要的。步骤1:获取和理解用户需求阶段任务获取并理解用户需求,清除用户需求的不一致性,模糊性和歧义性，帮助用户发现潜在的需求原则和用户进行交流和合作将对原始问题理解与软件开发经验结合步骤2:描述和分析用户需求阶段任务对用户需求进行建模，生成SRS和初步用户手册SRS:用户需求(功能,行为,性能等)用户手册:如何操作和使用目标软件，界面描述和使用初步构想，目的…原则确保SRS的完整性、一致性和准确性鼓励用户参与SRS以及用户手册的制定尽可能做到SRS结构清晰，措辞准确和简洁步骤3:对用户需求进行评审任务多方人员一起对SRS进行复核和评审，以确保用户手册和SRS全面、准确、一致地反映用户需求原则支持各方（用户，需求分析人员、设计人员）共同参与评审工作获取需求的方法访谈面向数据流自顶向下求精简易的应用规格说明技术快速建立软件原型(1).访谈正式的访谈

---系统分析员将提出一些事先准备好的具体问题。非正式的访谈

---分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。情景分析技术的用处主要体现在下述两个方面：(1)它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。(2)由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的惟一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。有办法吗？有！GoNext!

问题：使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。

这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。(3).简易的应用规格说明技术

---

一种面向团队的需求收集法使用简易的应用规格说明技术

分析需求的典型过程1.初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。2.开发者和用户分别写出“产品需求”。3.开发者和用户开会讨论，共同创建一张意见一致的组合列表。4.把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。5.每个小组向全体与会者展示他们制定的小型规格说明，讨论，以创建出意见一致的确认标准。6.由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。快速构建和修改原型，

通常使用下述3种方法和工具：第四代技术(2)可重用的软件构件(3)形式化规格说明和原型环境因此系统应该具备以下功能：⑴基本数据维护功能⑵基本业务功能⑶数据库管理功能⑷信息查询功能例1：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。1.功能需求⑴基本数据维护功能：提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。⑵基本业务功能：读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，如果书籍已经借出，可以进行预留操作，书籍的编目、入库、更新等操作。⑶数据库管理功能：对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。⑷信息查询功能：提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息，预留信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。2.非功能需求①系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。②对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。③对系统查询速度的需求：要求系统在20S之内响应查询服务请求。

④对系统可靠性的需求：要求系统失败发生率小于1%。3.领域需求例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：⑴图书编目要求按照《中国图书馆分类法》进行；⑵由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。

4.1.4需求分析的方法功能解析法结构化分析法信息建模法面向对象分析法功能解析法将一个系统堪称由若干功能构成的集合，每个功能又可划分成若干个加工（即子功能），一个加工又进一步可分解成若干个子加工功能分解法由功能、子加工和功能接口三要素组成本质是用过程抽象的观点看待系统需求结构化分析法一种从问题空间到某种表示的映射方法由数据流图和数据字典组成适用于数据处理领域的问题信息建模法从数据角度对现实世界进行建模基本工具是E-R图，由实体、属性和联系三个基本要素组成E-R图中，数据不封闭，没有继承性和消息传递机制面向对象分析法是把E-R图中的概念与面向对象程序设计语言中的主要概念结合起来形成的一种分析方法既采用实体、属性、关系等信息建模方法中的概念，又采用了封闭、类结构和继承性等面向对象程序设计语言中的概念4.2结构化分析法一种面向数据流的传统软件开发方法以数据流为中心构建软件的分析模型和设计模型分为：结构化分析(StructuredAnalysis简称SA)结构化设计(StructuredDesign简称SD)结构化程序设计(StructuredProgramming简称SP)4.2.1结构化分析（SA）概述1.自顶向下逐层分解的分析策略基本思想：抽象与自顶向下的逐层分解

(控制复杂性的两个基本手段)抽象：在每个抽象层次上忽略问题的内部复杂性，只关注整个问题与外界的联系分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为止结构化分析方法中的抽象与分解抽象：从作为整体的软件系统开始(顶层),每一抽象层次上只关注于系统的输入输出分解：将系统不断分解为子系统、模块……随着分解层次的增加，抽象的级别越来越低，也越接近问题的解(算法和数据结构)2.42.32.22.121431.31.21.1X结构化分析过程理解当前的现实环境，获得当前系统的具体模型(物理模型)从当前系统的具体模型抽象出当前系统的逻辑模型分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型为目标系统的逻辑模型作补充2.结构化分析工具数据流图（DataFlowDiagram,DFD）。用于描述系统分解，即描述系统由哪些部分组成，各部分间有什么联系等数据字典（DataDictionary,DD）。用于定义数据流图中的数据和加工。加工规格描述（ProcessSpecification,PS）。描述加工逻辑的结构化语言、判定树、判定表等，是描述数据流图中不能被再分解的每一个基本加工的处理逻辑。结构化分析模型的描述工具数据字典是模型的核心，包含软件使用和产生所有数据的描述。数据流图：用于功能建模，描述系统的输入数据流如何经过一系列的加工变换逐步变换成系统的输出数据流。ER图：用于数据建模，描述数据字典中数据之间的关系。实体-关系图数据流图状态转换图控制规约数据字典加工规约数据对象描述状态转换图：用于行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下的状态迁移情况。3.SA分析步骤（1）建立当前系统的物理模型（2）抽象出当前系统人的逻辑模型去掉模型中非本质因素，抽取本质因素（固有的，不依赖运行环境变化而变化的因素）（3）建立目标系统的逻辑模型分析比较目标系统与当前系统逻辑上的差别，将改变的部分抽象为一个加工（4）作进一步补充和优化4.2.2数据流图DFD数据流图（DataFlowDiagram，简称DFD）是结构化系统分析的主要工具，它能图形化地显示出系统中数据的使用，表达数据在系统内部的逻辑流向以及系统的逻辑功能和数据的逻辑变换数据流图有四种基本符号：数据源、数据流、加工和数据存储数据流图数据流数据存储数据源加工数据流图数据源（source/externalentity）是指不受系统控制的，在系统以外的人、程序、机构或其他实体，数据源与系统通过数据交互，表达了该数据的外部来源或去处

确定系统的数据源，实际上就是确定系统与外界的分界线数据流图数据流（dataflow）就是一束按特定的方向从源点流到终点的数据，它指出了数据及其流动方向

对每一条数据流都要给予简单的描述数据流图数据流的画法示例数据流图加工（process）是对数据进行变换操作，即把流向它的数据进行一定的变换处理，产生出新的数据处理过程对数据的操作主要有两类：变换数据的结构，如将数据的格式重新排列；在原有数据内容基础上产生新的数据内容，如对数据进行累计或计算平均值。数据流图数据存储（datastore）指出了数据保存的地方这里所说的地方，并不指保存数据的物理地点或物理存储介质，而是数据存储的逻辑描述数据流图的建立—自顶向下扩展方法：先用少数几个处理过程高度概括、抽象地描述整个系统的逻辑功能，然后针对处理过程逐步地分解、扩展，从而详细地加以描述数据流图可在不同的层次上描述，以表示系统在该层的内容数据流图的建立—自顶向下扩展建立方法：

——决定系统或处理过程的范围，即通过输入、输出数据确定系统的边界或处理过程的范围——决定系统或处理过程内部的细节，并加以描述数据流图的建立—自顶向下扩展示例：销售部门接到顾客送来的订货单后，根据库存情况向用户发货——订货单处理——确定发货量——开发货单及其相关处理——填写暂存订货单——对照暂存订货单订货处理—顶层DFD顾客销售处理订货单发货单库存帐4.2.2数据流分析技术顾客1验收订货单订货单库存帐2确定发货量合格订货单3开发货单修改库存可发货的订货单应收帐订货单存档4填写暂存订货单5对照暂存订货单暂存订货单未满足的订货单采购部门到货通知顾客发货单订货处理—第0层DFD不合格订货单4.2.2数据流分析技术数据流图的建立—建立原则建立原则：数据流图的建立过程必须遵循自顶向下、逐层分解的原则分层的数据流图总是由顶层、中间层和底层组成的（或：上下文图+0级图+n级图）：顶层数据流图确定了系统的边界中层图描述了某个处理过程的分解，而它的组成部分又要进一步被分解底层图描述的是无须分解的基本处理过程4.2.2数据流分析技术确定系统的数据源及系统正常运行时的输入与输出，在高层的数据流图中只反映主要的、正常的逻辑功能，突出系统的总体情况由外向里、从左到右地画数据流图，先在左侧画数据源，然后画出由该数据源产生的数据流和其对应的处理过程，接收系统数据的数据源一般画在数据流图的右侧数据流图的建立—建立原则4.2.2数据流分析技术适当地命名及给出编号，有利于系统的理解。对处理过程的编号，随着逐层展开，也应反映出它的层次关系应集中精力于主要的数据流，对一些诸如例外情况、出错处理等问题不必花较多精力分析下去，只需标出即可数据流图的建立—建立原则4.2.2数据流分析技术一个数据流图中所包含的处理过程应限在七个以内，经验证明，多于七个将会影响分解效果数据流图逐层分解时，应在概念上合理、清晰、自然，不影响图的易理解性。合理的分解是将一个问题分成相对独立的几个部分，减少相互之间的联系。分解应力求均匀，避免在同一张数据流图中，有些处理过程描述的是细节，而另一些描述的却是较高层的抽象数据流图的建立—建立原则4.2.2数据流分析技术分解是处理功能的分解，我们称某一处理过程细化后的图是该处理的子图，该处理所在的图为子图的父图。子图与父图应保持输入与输出数据流的一致随着数据流图的细化，图越来越复杂，为便于阅读和绘图，允许以父图和子图对应的方式分别绘图，也可以将几个子图绘制在一张图中。为保证各子图的整体性，子图之间应通过公共的数据存储联系起来数据流图的建立—建立原则4.2.2数据流分析技术在数据流图中，数据存储的输入来源与输出去向不能是数据源，而只能是处理过程数据流图与程序流程图不同。前者不反映时间的顺序，只反映数据的流向、逻辑处理和必要的逻辑数据存储；后者有严格的时间顺序，有起始点和终止点数据流图的建立—建立原则4.2.2数据流分析技术理解一个问题总要经过从不正确到正确，从不恰当到恰当的过程，系统分析人员要随时准备修改甚至抛弃旧的数据流图，而用更好的来替代。分析阶段重画几张图的代价是小的，倘若草草了事，留下隐患，那么到开发后期再去纠正，代价就太大了数据流图不反映判断和控制条件，不应在数据流图上出现表明控制逻辑的数据流数据流图的建立—建立原则4.2.2数据流分析技术数据流图的扩充符号描述一个加工的多个数据流之间的关系星号(＊)：表示数据流之间存在“与”关系所有输入数据流同时存在时，才能进行加工处理或加工处理的结果是同时产生所有输出数据流加号(＋)：表示数据流之间存在“或”关系至少存在一个输入数据流时才能进行加工处理或加工处理的结果是至少产生一个输出数据流异或(⊕)：表示数据流之间存在“异或”(互斥)关系必须存在且仅存在一个输入数据流时，才能进行加工处理或加工处理的结果是产生且仅产生一个输出数据流数据流图的扩充符号TAB*CTAB*CTAB+CTAB+CTABC+TABC+*与

+

或互斥+对数据流图进行分层根据自顶向下逐层分解的思想将数据流图画成层次结构。数据流图的层次大致分为顶层图、0层图、中间层和底层图。每个层次画在独立的数据流图中，加工个数可大致控制在“7加减2”的范围中。数据流图的各个层次顶层图只有代表整个软件系统的1个加工，描述了软件系统与外界(数据源)之间的数据流顶层图中的加工经分解后的图称为0层图(只有1张)中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图处于最底层的图称为底层图，其中所有的加工不再分解成新的子图图和加工的编号顶层图只有一个代表整个软件系统的加工，该加工不必编号。0层图中的加工编号分别为1，2，3，…子图号：若父图中的加工号x分解成某一子图，则该子图号记为“图x”子图中加工的编号：若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为x.1、x.2、x.3…画分层数据流图的步骤1.画系统的输入和输出2.画系统内部3.画加工内部4.重复第3步，直至每个尚未分解的加工都足够简单(即不必再分解)分层数据流图示例——

资格和水平考试的考务处理系统简化的资格和水平考试的考务处理系统分成多个级别，如初级程序员、程序员、高级程序员、系统分析员等，凡满足一定条件的考生都可参加某一级别的考试考试的合格标准将根据每年的考试成绩由考试中心确定考试的阅卷由阅卷站进行，因此，阅卷工作不包含在软件系统中资格和水平考试的考务处理系统

—功能需求1.对考生送来的报名单进行检查2.对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站3.对阅卷站送来的成绩清单进行检查，并根据考试中心制订的合格标准审定合格者4.制作考生通知单送给考生5.进行成绩分类统计(按地区、年龄、文化程度、职业、考试级别等分类)和试题难度分析，产生统计分析表资格和水平考试的考务处理系统

—部分数据流的组成报名单＝地区＋序号＋姓名＋文化程度＋职业＋考试级别＋通信地址正式报名单＝准考证号＋报名单准考证＝地区＋序号＋姓名＋准考证号＋考试级别＋考场考生名单＝｛准考证号＋考试级别｝

其中｛w｝表示w重复多次考生名册＝正式报名单统计分析表＝分类统计表＋难度分析表考生通知单＝准考证号＋姓名＋通信地址＋考试级别＋考试成绩＋合格标志系统的输入输出(顶层图)确定源：考生、阅卷站和考试中心顶层图唯一的加工：软件系统(考务处理系统)确定数据流：系统的输入/输出信息输入数据流：报名单(来自考生)、成绩清单(来自阅卷站)、合格标准(来自考试中心)输出数据流：准考证(送往考生)、考生名单(送往阅卷站)、考生通知书(送往考生)、统计分析表(送往考试中心)额外的输出流(考虑系统的健壮性)：不合格报名单(返回给考生)，错误成绩清单(返回给阅卷站)顶层图通常没有数据存储考务处理系统顶层图考务处理系统考试中心考生不合格报名单阅卷站错误成绩清单成绩清单考生名单合格标准报名单准考证考生通知单统计分析表系统内部(0层图)-1以下确定加工、数据流、文件、数据源的一般方法适用于0层图及其各层子图确定加工：将父图中某加工分解而成的子加工根据功能分解来确定加工：将一个复杂的功能分解成若干个较小的功能，较多应用于高层DFD中的分解根据业务处理流程确定加工：分析父图中待分解加工的业务处理流程，业务流程中的每一步都可能是一个子加工特别要注意在业务流程中数据流发生变化或数据流的值发生变化的地方，应该存在一个加工，例如：编制

准考证号正式报名单合格报名单系统内部(0层图)-2确定数据流在父图中某加工分解而成的子图中，父图中相应加工的输入/输出数据流都是且仅是子图边界上的输入/输出数据流分解后的子加工之间应增添相应的新数据流表示加工过程中的中间数据如果某些中间数据需要保存以备后用，那么可以成为流向文件的数据流同一个源或加工可以有多个数据流流向一个加工，如果它们不是一起到达和一起加工的，那么可以将它们分成若干个数据流，例如：读取银行卡信息客户银行卡数据密码系统内部(0层图)-3确定文件（数据存储）如果父图中该加工存在读写文件的数据流，则相应的文件和数据流都应画在子图中在分解子图中，如果需要保存某些中间数据以备后用，则可以将这些数据组成一个新的文件新文件(首次出现的文件)至少应有一个加工为其写入记录，同时至少存在另一个加工来读该文件的记录注意：从父图中继承下来的文件在子图中可能只对其进行读，或只进行写系统内部(0层图)-4确定数据源0层图和其它子图中通常不必画出数据源有时为提高可读性，可将顶层图中的数据源画在0层图中最终得到考务处理系统0层图根据功能分解方法识别出两个加工：考试报名、统计成绩数据流继承顶层图中的输入数据流和输出数据流定义二个加工之间的数据流：由于这二个加工分别在考试前后进行，因此登记报名单所产生的结果“考生名册”应作为文件保存以便考试后由统计成绩加工引用考务处理系统0层图考生名册1考试报名报名单考生名单不合格报名单准考证2统计成绩统计分析表合格标准考生通知单错误成绩清单成绩清单加工内部(1…n层图)复杂的加工可以继续分解成1张DFD子图分解方法将该加工看作一个小系统，该加工的输入/输出数据流就是这个假设的小系统的输入/输出数据流然后采用画0层图的方法，画出该加工的子图以0层图中加工1(考试报名)为例根据业务处理流程来确定由加工1的分解与加工1相关的业务流程：首先检查考生送来的报名单，然后编准考证号，并产生准考证，最后产生考生名单和考生名册(文件)考务处理系统加工1子图3个子加工：检查报名单、编准考证号、登记考生“合格报名单”和“正式报名单”是新增加的数据流，其它数据流都是加工1原有的在加工1的分解中没有新的文件产生1.3登记考生考生名单1.2编准考证号准考证正式报名单1.1检查报名单合格报名单报名单不合格报名单考生名册考务处理系统加工2子图2.5分析试题难度难度分析表2.4分类统计成绩分类统计表考生名册2.3制作通知单考生通知单2.2审定合格者正式成绩清单合格标准试题得分清单2.1检查成绩清单成绩清单正确成绩清单错误成绩清单分层数据流图的审查检查图中是否存在错误或不合理(不理想)的部分一致性：分层DFD中不存在矛盾和冲突完整性：分层DFD本身的完整性，即是否有遗漏的数据流、加工等元素可从分层DFD的一致性和完整性、构造分层DFD时需注意的问题以及分解程度等几个方面来说明如何审查分层DFD的合理性分层数据流图的一致性父图与子图平衡

任何一张DFD子图边界上的输入/输出数据流必须与其父图中对应的加工的输入/输出数据流保持一致数据守恒一个加工所有输出数据流中的数据，必须能从该加工的输入数据流中直接获得，或者能通过该加工的处理而产生多余的数据流：加工未使用其输入数据流中的某些数据项局部文件

一个加工的输出数据流不能与该加工的输入数据流同名父图与子图不平衡的实例加工2的输入数据流有M和N，输出数据流是T而子图(右图)边界上的输入数据流是N，输出数据流是S和T123ABCMNT2.12.22.3NPSTQ父图与子图平衡的实例注意：如果父图某加工的一个数据流，对应于子图中几个数据流，而子图中组成这些数据流的数据项全体正好等于父图中的这个数据流，那么它们仍算是平衡的e2.52.42.32.22.1b2b1acdb21acde(a)父图(b)子图a：考生通知单；b：统计分析表；b1：分类统计表；b2：难度分析表；c：错误成绩清单；d成绩清单；e合格标准。数据不守恒的实例

由于“正式成绩清单”中缺少“考生通知单”中的姓名、通信地址等数据，这些数据也无法由加工2.3自己产生，因此，加工2.3不满足数据守恒的条件考生名册2.5分析试题难度难度分析表2.4分类统计成绩分类统计表2.3制作通知单考生通知单2.2审定合格者正式成绩清单合格标准试题得分清单2.1检查成绩清单成绩清单正确成绩清单错误成绩清单由此可见：

1.数据流的组成对DFD是有影响的2.构建DFD与建立数据字典应交替进行，以便于对分层DFD的校验局部文件考虑分层数据流中一个文件应画在哪些DFD中，而不该画在哪些DFD中任何一个文件都应同时包含读和写该文件的数据流，除非该文件是当前系统与另一个软件系统所共享在一张DFD中当一个文件作为若干个加工之间的交界面(一个写另一个读)时该文件应画出在一张DFD中当一个文件仅与一个加工进行读写操作，并且在该DFD的父(祖先)图中未出现过该文件则该文件是相应加工的内部文件，在当前DFD中不应画出一个文件一旦在某张DFD中画出，那么在它的子孙图中应根据父图与子图平衡的原则画出该文件局部文件示例

“试题得分清单”文件是加工2的局部文件，根据抽象原则不应该将这类表示加工细节的局部文件画在其父图(如图c)中，正确的画法是图a和b21(a)父图考生名册(b)子图2.52.42.32.22.1试题得分清单考生名册(c)含局部文件的父图21试题得分清单考生名册加工的输出数据流不能与该加工的输入数据流同名同一个加工的输出数据流和输入数据流即使组成成份相同，仍应对它们取不同的名字，以表示它们是不同数据流例如，“报名单”和“合格报名单”允许一个加工有二个相同的数据流分别流向二个不同的加工分层数据流图的完整性每个加工至少有一个输入数据流和一个输出数据流在整套分层数据流中，每个文件应至少有一个加工读该文件，有另一个加工写该文件分层数据流图中的每个数据流和文件都必须命名(除了流入或流出文件的数据流)，并保持与数据字典的一致分层DFD中的每个基本加工(即不再分解子图的加工)都应有一个加工规约其它需注意的问题-1适当命名：每个数据流、加工、文件、源和宿都应被适应地命名，名字应符合被命名对象的实际含义名字应反映整个对象(如数据流、加工)，而不是仅反映它的某一部分避免使用空洞的、含义不清的名字，如数据、信息、处理、统计等如果发现某个数据流或加工难以命名时，往往是DFD分解不当的征兆，此时应考虑重新分解画数据流而不是画控制流判断准则：这条线上是否有数据流过其它需注意的问题-2避免一个加工有过多的数据流当一个加工存在许多数据流时往往意味着分解不合理解决办法：重新分解1)把需要重新分解的某张图(含有该复杂加工的图)的所有子图连接成一张图2)把连接后的图重新划分成几个部分，使各部分之间的联系最小3)重新定义父图，即第2)步中的每个部分作为父图中的一个加工4)重新建立各子图，即第2)步中的每个部分都是一张子图5)为所有的加工重新命名和编号数据流图重新分解示例(b)原加工2子图2．22.12.32.42.5HJICKLEMN(d)重新分解后的父图452′32″1ABHGJICKLDEMFPN(a)原父图34512HABJICKLDEMFPNG(c)合并4532.42.52.22.12.31FABHJICKLDEMPNG其它需注意的问题-3分解尽可能均匀理想目标：任何两个加工的分解层数之差不超过1应尽可能使分解均匀，对于分解不均匀的情况应重新分解先考虑稳定状态，忽略琐碎的枝节先考虑稳定状态下的各种问题，暂时不考虑系统如何启动、如何结束、出错处理以及性能等问题随时准备重画对于一个复杂的软件系统，往往要经过反复多次的重画和修改才能构造出完整、合理、满足用户需求的分层DFD分析阶段遗漏下来的一个错误，到开发后期要化费几百倍代价来纠正这个错误分解的程度可参照以下几条与分解有关的原则：7加减2分解应自然，概念上合理、清晰只要不影响DFD的易理解性，可适当多分解几个加工，以减少层数一般说来，上层分解得快些(即多分解几个加工)，下层分解得慢些(即少分解几个加工)分解要均匀4.2.3数据字典数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型(分析模型)数据字典由字典条目组成，每个条目描述DFD中的一个元素数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、数据源加工逻辑的详细说明可以用“加工逻辑描述”来表示数据字典的描述符号符号名称举例＝定义为x＝…表示x由…组成＋与a＋b表示a和b［…，…］或［a，b］表示a或b［…│…］或［a│b］表示a或b｛…｝重复｛a｝表示a重复0或多次｛…｝重复｛a｝表示a重复3到8次(…)可选(a)表示a重复0或1次″…″基本数据元素″a″表a是基本数据字典条目不同的开发组织或团队可以根据项目的需要定义字典条目的描述内容字典条目中的描述内容主要包括DFD元素的基本信息(名称、别名、简述、注解)定义(数据类型、数据组成)使用特点(取值范围、使用频率、激发条件)控制信息(来源、去向、访问权限)等数据流条目的描述内容名称：数据流名(可以是中文名或英文名)别名：名称的另一个名字简述：对数据流的简单说明数据流组成：描述数据流由哪些数据项组成数据流来源：描述数据流从哪个加工或源流出数据流去向：描述数据流流入哪个加工或宿数据量：系统中该数据流的总量如考务处理系统中“报名单”的总量是100000张或者单位时间处理的数据流数量，如80000张/天峰值：某时段处理的最大数量如每天上午9：00至11：00处理60000张表单注解：对该数据流的其它补充说明数据流组成数据流组成是数据流条目的核心，它列出组成该数据流的各数据项，例如：培训报名单＝姓名＋单位＋课程运动员报名单＝队名＋姓名＋性别＋｛参赛项目｝当一个数据流的组成比较复杂时，可以将其分解成几个数据流，例如：课程＝课程名＋任课教师＋教材＋时间地点时间地点＝｛星期几＋第几节＋教室｝31数据流组成示例(发票)发票＝单位名称＋｛商品名＋数量＋单价＋金额｝

＋总金额＋日期＋(营业员)

单位名称商品名数量单价金额总金额日期营业员

51文件条目的描述内容名称：文件名别名：同数据流条目简述：对文件的简单说明文件组成：描述文件的记录由哪些数据项组成(与数据流条目中的文件组成描述方法相同)写文件的加工：描述哪些加工写文件读文件的加工：描述哪些加工读文件文件组织：描述文件的存储方式(顺序、索引)，排序的关键字使用权限：描述各类用户对文件读、写、修改的使用权限数据量：文件的最大记录个数存取频率：描述对该文件的读写频率注解：对该文件的其它补充说明数据项条目的描述内容名称：数据项名别名：同数据流条目简述：对数据项的简单描述数据类型：描述数据项的类型，如整型、实型、字符串等计量单位：指明数据项值的计量单位，如公斤、吨等取值范围：描述数据项允许的值域，如1…100编辑方式：描述该数据项外部表示的编辑方式，如23,345.67与其它数据项的关系：描述该数据项与数据字典中其它数据项的关系注解：对数据项的其它补充说明加工逻辑描述的内容名称：加工名别名：同数据流条目加工号:加工在DFD中的编号简述：对加工的功能的简要说明输入数据流：描述加工的输入数据流，包括读哪些文件名输出数据流：描述加工的输出数据流，包括写哪些文件名加工逻辑：简要描述加工逻辑，或者对加工规约的索引基本加工的加工逻辑用加工逻辑描述，在加工条目中可填写对加工规约的索引非基本加工分解而成的DFD子图已反映了它的加工逻辑，不必书写加工逻辑描述异常处理：描述加工过程中可能出现的异常情况，及处理方式加工激发条件：描述执行加工的条件，如，“身份认证正确”，“收到报名单”执行频率：描述加工的执行频率，如，每月执行一次注解：对加工的其它补充说明数据源条目的描述内容名称：数据源的名(外部实体名)别名：同数据流条目简要描述：对数据源的简要描述(包括指明该外部实体在DFD中是用作“源”，还是“宿”，还是“既是源又是宿”)输入数据流：描述源向系统提供哪些输入数据流输出数据流：描述系统向宿提供哪些输出数据流注解：对数据源的其它补充说明别名条目的描述内容只有那些有必要补充说明的别名才给出相应的别名条目别名：别名的名字类型：指出别名属于那个种类(数据流、文件、数据、加工、数据源)基本名：别名的正式名称(原名)简述：同正式名称的简述说明：对别名的补充说明示例原始的数据项条目如下：数据项名称：开户日期别名：开设日期简述：客户建立帐户的日期类型：日期注解：年≥1949

其别名条目如下：别名：开设日期类型：数据项基本名：开户日期简述：客户建立帐户的日期说明：1986年以后不再使用此别名数据字典的实现提倡采用专用的软件工具或者常用的实用程序(如正文编辑程序、电子表格)来建立数据字典的电子文档，其好处是便于字典条目的检索，字典的管理和维护如果数据字典由辅助绘制DFD的工具自动产生的话，那么可以利用数据字典来检查DFD的一致性和完整性，并保持数据字典与DFD的一致如果数据字典是由人工制作的，可以为每个字典条目制作一张卡片，所有卡片按字典条目的种类(数据流、文件、加工等)分类成册，每类卡片按某种约定排序例子：编写学籍管理的DD例子：编写学籍管理的DD4.2.4加工逻辑描述加工逻辑描述是基本加工的规约说明，应精确地描述用户要求一个加工“做什么”包括加工的激发条件、加工逻辑、优先级、执行频率、出错处理等最基本的部分是加工逻辑，即该加工的输出数据流与输入数据流之间的逻辑关系加工逻辑不是对加工的设计，不涉及数据结构、算法实现、编程语言等与设计和实现有关的细节加工逻辑的描述方法结构化语言：介于自然语言和形式语言之间的一种半形式语言判定表：适用于加工逻辑包含多个条件，而不同的条件组合需做不同的动作判定树：判定表的变种，它本质上与判定表是相同的，只是表示形式不同结构化语言没有严格的语法加工规约分为若干个段落，每个段落可分为内外两层：外层有严格的语法来描述它的控制结构如结构化英语中可使用if_then_else、while_do、repeat_until、for_do、case等结构内层可以用自然语言来描述允许使用嵌套结构“计算信用度”的结构化英语描述Case1(NoBounced－ChecksinCustomerRecord)：WriteExemplary－Customer―CitationtoAnnual―Summary.Case2(OneBounced－check)：IfYearly―Average―Balanceexceeds$1000.RemoveBounced―CheckfromCustomer―Record.Otherwise. RecuceCredit―Limitby10%.Case3(MultipleBounced－Checks)：ForeachBounced―Check.RecuceCredit―Limitby15%.SetCredit―RatingtoDeadbeat.WriteScathing―CommenttoAnnual―Summary.WriteCustomer―Name―and―AddresstoIRS―Enemies―List.结构化语言书写加工规约注意事项语句力求精炼语句必须易读、易理解、无二义主要使用祈使句，祈使句中的动词要明确表达要执行的动作所有名字必须是数据字典中有定义的名字不使用形容词、副词等修饰语不使用含义相同的动词，如“修改”、“修正”等可以使用常用的算术和关系运算符总之要尽可能精确、无二义、简明扼要、易理解判定表判定表的组成元素条件框：列出各种条件的对象，如发货单金额，赊欠天数等，每行写一个条件对象条件条目：列出各条件对象的取值，条件条目的每一列表示了一个可能的条件组合动作框：列出所有可能采取的动作，如发出发货单等，每行写一个动作动作条目：列出各种条件组合下应采取的动作

条件框条件条目动作框动作条目构造判定表的步骤提取问题中的条件标出条件的取值计算所有条件的组合数N提取可能采取的动作和措施制作判定表完善判定表发货单金额＞500≤500－赊欠天数＞60＞60≤60发不批准通知√发出批准书√√发出发货单√√发出赊欠报告√“审批发货单”加工的简化判定表“审批发货单”加工的判定表发货单金额＞500＞500≤500≤500赊欠天数＞60≤60＞60≤60发不批准通知√发出批准书√√√发出发货单√√√发出赊欠报告√判定表的其它形式发货单金额≤5000011发货单金额＞5001100赊欠天数≤600101赊欠天数＞601010发不批准通知√发出批准单√√√发出发货单√√√发出赊欠报告√“审批发货单”加工的另一种判定表判定树本质上与判定表是相同的，只是表示形式不同例如“审批发货单”加工逻辑的判定树描述入下：

1992年由Jacobson提出了Usecase的概念及可视化的表示方法—Usecase图，并加入由他提出的面向对象的软件工程(OOSE)。Usecase的概念受到了IT界的欢迎，被广泛应用到了面向对象的系统分析中。基于用例的需求方法，已成为面向对象的分析方法的主流。

用例模型被推荐为获取和识别需求的首选工具!!基于用例的方法4.3面向对象的分析方法(OOA)Usecase图采用“基于用例的方法”来识别和获取需求，是从外部的角度来看系统功能，建立系统的Usecase模型。描述外部执行者(Actor)所理解的系统功能。即待开发系统的功能需求。用例—表示一个子系统，或者系统一个独立的功能。角色—表示外部的“执行者”。描述方法：用例：角色：连接：用例ATM机验证储户身份的Usecase图创建用例模型的工作包括：

定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。3.2.2面向对象的分析方法(OOA)案例3网上拍卖系统