管理信息系统L

第6章可行性分析与需求分析1171可行性分析的任务明确开发应用项目的必要性和可行性。可行性分析的内容管理上的可行性技术上的可行性经济上的可行性

一、可行性分析-11172管理可行性

用户使用可能性时间进度可行性

组织和文化上的可行性法律可行性§2.2可行性研究1173技术可行性──度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题开发风险分析资源分析相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）§2.2可行性研究1174经济可行性

──度量系统解决方案的性能价格比考虑的问题成本/效益分析有形成本、效益无形成本、效益价值和成本的关系质量与价值、成本的关系价值/成本的均衡§2.2可行性研究1175经济可行性考虑的问题成本和效益的估算开发成本的估算开发效益的估算运行成本的估算运行效益的估算§2.2可行性研究1176经济可行性──成本分析代码行（LOC，lineofcode）技术

通常先根据经验和历史数据来估计实现一个功能所需要的源程序行数，然后用每行代码的平均成本乘以行数就可以确定软件的成本。任务（过程）估算技术

首先把软件开发工程分解为若干个相对独立的任务，再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发工程的总成本。估计每个任务的成本时，通常先估计完成该项任务所需要使用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本。划分任务时最常用的办法是按开发阶段进行。

总成本、总人力相对误差在内经验估算模型（page234）构造性成本（COCOMO，ConstructiveCostModel）模型（page234）

§2.2可行性研究1177经济可行性──成本分析经验估算模型

用经验公式来进行项目的估算。由于公式是通过对有限样本集的分析得出的，因此得到的结果并不一定适合当前项目类型。构造性成本模型（COCOMO，ConstructiveCostModel）模型

分为基本COCOMO、中级COCOMO和高级COCOMO，分别适于不同类型的软件项目。§2.2可行性研究1178经济可行性──效益分析系统的经济效益＝使用新系统增加的收入＋使用新系统可以节省的费用总的效益和软件生存周期有关货币的时间价值投资回收期投资回收率纯收入§2.2可行性研究1179系统开发和每年运行费用举例1.系统开发费用（一次）2名系统分析员(450小时/名,45美元/小时)$40,5005名系统开发人员(275小时/名,36美元/小时)$49,5001名数据库管理员(30小时/名,42美元/小时)$1,2602名技术写作者(120小时/名,25美元/小时)$6,0001名秘书(160小时/名,15美元/小时)$2,4001名数据通讯专家(60小时/名,42美元/小时)$2,4002名在转换期间数据输入人员$49,500(40小时/名,12美元/小时)

§2.2可行性研究11710系统开发和每年运行费用举例培训：三天的开发人员内部培训课程$7,00030个用户，三天的内部培训课程$10,000物资：复印$500

磁盘、纸张等消耗品$650§2.2可行性研究11711系统开发和每年运行费用举例购买硬件、软件：20台工作站Windows软件$1,00020台工作站内存升级$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$161,670§2.2可行性研究11712系统开发和每年运行费用举例2.年运行费用（每年）人员：维护程序员/分析员(250小时/年,42美元/小时)$10,500

网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级：硬件$5,000

软件$6,000物资和杂项$3,500每年总运行费用$40,000§2.2可行性研究11713可行性分析报告是可行性分析结果的表述内容包括：•系统简述•项目的目标

•所需资源、预算、期望效益

•可行性的结论可行性结论要求明确指出以下三者之一：

•可以立即开发

•改进原系统

•目前不可行，推迟开发一、可行性分析-211714§6.1需求分析的概念和任务为什么要进行需求分析？开发人员往往急于求成希望对开发进行指导希望开发人员对用户的要求理解希望用户理解开发人员测试部门有理可依11715需求分析的重要性5点事实事实1：软件生命周期中，一个错误发现得越晚，修复错误的费用越高§6.1需求分析的概念和任务11716需求分析的重要性事实2：许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来事实3：在需求过程中会产生很多错误DeMarco在一份研究报告中指出，被检查出来的错误的56％产生的根源可以追溯到需求阶段。AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。§6.1需求分析的概念和任务11717需求分析的重要性事实4：在需求阶段，代表性的错误为疏忽、不一致和二义性美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A—7E—飞机上的”飞行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A—7E项目中77％的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是：49％不正确的事实，31％疏忽，l3％不一致，5％二义性§6.1需求分析的概念和任务11718需求分析的重要性事实5：需求错误是可以被检查出来的§6.1需求分析的概念和任务11719需求分析的重要性在需求过程中会产生很多错误许多错误并没有在早期被发现这样的错误是能够在产生的初期被检查出来的如果没有及时检查出来这些错误，软件费用会直线上升§6.1需求分析的概念和任务11720需求的概念IEEE软件工程标准中的定义用户解决问题或达到目标所需的条件或能力──反映了系统的外部行为系统或系统部件要满足合同、标准、规范或其他正式规定文档所需要具有的条件或能力──反映了系统的内部特性一种反映上述两方面的条件或能力的文档说明──反映的方式是需求文档§6.1需求分析的概念和任务11721一、用户需求的分类功能性需求:

定义了系统做什么（描述系统必须支持的功能和过程）业务需求：是反映组织机构或客户对软件高层次的目标要求，是用户高层领导机构决定的，它确定了系统的目标、规模和范围。

用户需求：是用户使用该软件要完成的任务非功能性需求（技术需求）是对功能需求的补充。一类是用户关心的一些重要属性；一类是对开发者来说很重要的质量属性。♂业务需求用户需求功能需求§6.1需求分析的概念和任务11722两类需求包括的内容功能性能环境界面用户或人的因素文档数据资源安全保密软件成本消耗 与开发进度质量保证♂§6.1需求分析的概念和任务──用户需求分类11723功能需求系统做什么？系统何时做什么？系统何时及如何修改或升级？§6.1需求分析的概念和任务──用户需求分类11724性能需求软件开发的技术性指标，如：存储容量限制执行速度、相应时间吞吐量§6.1需求分析的概念和任务──用户需求分类11725环境需求硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统网络数据库§6.1需求分析的概念和任务──用户需求分类11726界面需求有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？§6.1需求分析的概念和任务──用户需求分类11727用户或人的因素用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？§6.1需求分析的概念和任务──用户需求分类11728文档需求需哪些文档？文档针对哪些读者？§6.1需求分析的概念和任务──用户需求分类11729数据需求输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？§6.1需求分析的概念和任务──用户需求分类11730资源需求软件运行时所需的数据、软件、内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。§6.1需求分析的概念和任务──用户需求分类11731安全保密要求需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？§6.1需求分析的概念和任务──用户需求分类11732软件成本消耗与开发进度需求开发有规定的时间表吗？软硬件投资有无限制？§6.1需求分析的概念和任务──用户需求分类11733质量保证

系统的可靠性要求？系统必须监测和隔离错误吗？规定系统平均出错时间？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性？§6.1需求分析的概念和任务──用户需求分类11734二、需求分析的任务基本任务：准确地回答“系统必须做什么？”

随着软件系统规模的扩大，需求分析从仅限于软件开发的最初阶段，逐渐演变为贯穿于系统开发的整个生命周期，并将需求工作分为需求开发和需求管理两部分，称为需求工程（RequirementEngineering，RE）需求工程需求开发需求管理需求获取分析编写规格说明验证需求状态跟踪需求跟踪版本控制变更控制§6.1需求分析的概念和任务11735需求开发──需求获取（elicitation）

分析员通过详细调查，准确、完整地获取用户需求，确定软件系统的、综合要求：从系统的角度来理解软件并评审软件范围是否恰当确定对目标系统的综合要求，即软件的需求（功能与非功能需求）提出这些需求实现条件，以及需求应达到的标准§6.1需求分析的概念和任务──需求分析的任务11736需求获取面临的挑战对需求的理解问题分析人员与用户的通信问题需求易变性问题的复杂性和对问题空间理解的不完备性与不一致性分析方法与分析工具问题§6.1需求分析的概念和任务──需求分析的任务11737

需求获取的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。§6.1需求分析的概念和任务──需求分析的任务11738需求开发──需求分析建模(analysis)从信息流和信息结构出发，逐步细化所有的系统要求，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。§6.1需求分析的概念和任务──需求分析的任务11739需求开发──需求分析建模(analysis)目标系统当前系统物理模型逻辑模型模型化抽象化物理模型逻辑模型具体化实例化理解需求表达需求导出怎么做做什么§6.1需求分析的概念和任务──需求分析的任务11740

逻辑模型物理模型

(本质模型、概念模型)

(实施模型、技术模型)现行系统目标系统描述重要的业务功能，无论系统是如何实施的描述现实系统是如何在物理上实现的描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。描述新系统是如何实施的（包括技术）。11741需求开发──编写需求规格说明(specification）

该阶段的主要工作是需求描述，以文档形式表达系统逻辑模型。该阶段的文档包括：需求规格说明

用户手册，包括用户界面描述以及有关目标系统使用方法的初步构想在需求分析中确立测试标准（或测试用例），作为系统开发目标是否完成的验收依据修改的项目开发计划是根据新的分析结果，对可行性分析和软件计划阶段中制订的初步的项目开发计划作必要的修改、补充和完善

§6.1需求分析的概念和任务──需求分析的任务11742需求开发──需求验证（verification）对需求文档进行正式审查

主要从完整性、正确性、一致性、必要性、无歧义性、可验证性、优先级的划分等几方面进行评审和验证§6.1需求分析的概念和任务──需求分析的任务11743需求开发──需求验证（verification）完整性：需求无遗漏并清楚、完整地描述正确性：每项需求都必须准确地反映用户需求一致性：用户需求与业务需求一致，功能需求与用户需求一致必要性：每项需求都应是客户所需要的无歧义性：对需求描述的理解应该是一致的可验证的：每项需求都应该是可验证的优先级的划分：为每项需求按照重要性分配优先级，开发中，可先实现优先级高的核心需求11744需求管理──需求变更控制确定一个选择、分析和决策需求变更的过程建立变更控制委员会评估每项选择的需求变更衡量需求稳定性记录基准需求的数量和变更数量§6.1需求分析的概念和任务──需求分析的任务11745需求管理──配置标识与版本控制（1）

在项目数据库中，每个软件配置项由一个惟一的名字进行标识，同时还给出它的一组属性和与其他软件配置项的“连接”。（下图中双向箭头表示配置之间的相互依赖关系，单向箭头说明配置项之间的构造关系）11746需求管理──配置标识与版本控制（2）软件配置是一个动态概念。一方面，随着软件开发的进展，一些文档经过转换生成一些新的文档，软件配置项在不断增加。另一方面由于为满足变更要求，这些文档又会出现新的版本。在版本控制中，应该：建立需求基准版本和需求控制版本，确定一个需求基线，可采用版本控制工具自动完成这些任务，如微软SourceSafe（VSS）11747需求管理──需求跟踪及需求状态跟踪需求跟踪跟踪所有受需求变更影响的工作产品让每项需求都能与其对应的设计、源代码和测试用例联系起来需求状态跟踪定义需求状态，在整个项目过程中跟踪需求每一个状态及其变更情况跟踪每项需求的状态建立一个数据库维护需求变更的历史记录§6.1需求分析的概念和任务──需求分析的任务11748需求开发与需求管理之间的界限

分析编写文档评审，商议基准需求说明需求变更过程管理客户需求市场当前基线修正后基线市场客户管理项目环境需求开发需求管理需求变更项目变更§6.1需求分析的概念和任务──需求分析的任务11749§6.2获取需求的方法通过需求（详细）调查，获取需求需求（详细）调查的内容：组织概况──组织结构图组织的业务活动、组织的业务状态、业务的详细内容──业务（系统）流程图输入输出信息（信息流向、信息种类、利用的目的、信息的使用者和制造者、输入和输出地点、输入和输出信息量）存在问题、约束条件、未来要求等11750需求（详细）调查对象对组织的高层管理者，进行组织管理目标或经营方针等组织战略问题的调查（业务需求）对中层的管理者，进行全部业务流的调查（用户需求）对业务工作人员，进行详细业务信息的调查（用户需求）§6.2获取需求的方法11751常用调查方法访谈：正式和非正式问卷调查情景分析实地考查构造原型建立分析小组领域专家：主角系统分析员：导演§6.2获取需求的方法11752准备调研的资料（可能的问题）部门的名称、人员数量和结构部门发展或变化简单介绍部门的主要任务部门各岗位的职责部门接受哪些部门或外界的信息及信息的内容和格式部门产生哪些信息部门产生的信息送到哪些其他部门、格式要求是什么现有的哪些设备要继续使用？11753准备调研的资料（可能的问题）业务处理流程业务处理过程中涉及哪些专业领域的知识主要算法描述哪些业务需要实时处理哪些业务需要交互操作业务处理有高峰期吗？高峰期的时间及业务量对信息的输入和输出方式和设备有何要求数据要求实时备份吗？备份设备及时间策略工作需要的审批流程是什么？11754准备调研的资料（可能的问题）对产品的运行环境有要求吗对界面风格和操作方式有要求吗在系统运行过程中允许停机吗需要的操作权限有哪些需要记录系统操作运行日志吗需要分布式处理吗需要什么方式的用户操作培训需要制作联机帮助吗用户有能力进行系统维护吗？⊙11755某出版社管理系统问卷调查表编号提出问题1您在哪个部门工作？2出版业务流程是什么？3您每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？11756某出版社管理系统问卷调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？11757⊙1175811759117601176111762117631176411765二、组织结构图组织结构图是用来描述组织的总体结构以及组织内部各部分之间的联系。要建立管理信息系统，就必须知道现行系统的组织机构设置情况和它们之间的隶属关系。当然，最为关心的是那些与计算机管理有关的机构和关系。用矩形框表示组织机构，用箭头表示领导关系。在画组织结构图时应注意：

1.不能只画组织中的从属关系、领导和被领导关系。（因为它们不是全部信息流）2.应具体调查结构的职能，不能仅按结构名称画图。3.实际情况往往较复杂，很难设计出面面俱到的IS。（应突出重点、目标）11766某企业组织结构图⊙11767三、业务流程图

业务流程图（TransactionFlowDiagram,TFD）是描绘物理系统的传统工具。系统流程图可用图形符号来表示系统中的各个元素。例如，人工处理、数据处理、数据库、文件等。业务流程图表示所描述部件的信息流程，而不表示信息加工的控制过程。系统流程图在可行性研究阶段也可以使用画系统流程图时，要搞清业务处理过程即处理中的各个元素，同时要理解系统的流程图各个符号的含义。11768业务流程图符号──基本符号

当以概括方式描述一个实际系统时，基本符号即可；当需要更具体地描绘一个物理系统时，还需使用系统符号。业务处理单位业务流向业务处理某项业务参与的人或事务业务处理功能业务数据的流动方向11769工资管理系统业务流程图11770业务流程图符号──系统符号符号名称说明文档表示打印输出，也可表示打印终端输入磁带磁带输入/输出或表示一个磁带文件联机存储表示任何种类的联机存储磁盘磁盘输入/输出显示终端显示部件，可表输入/输出人工输入人工脱机处理,如填表格人工操作人工完成处理,如支票签字通信链路远程通信线路送数据11771学生成绩管理流程每学期课程考核结束后，各任课教师须分班填写学生成绩登记表，经系主任审核签字后交学生所在学院及教务处教务员使用成绩管理系统登记所有成绩并将成绩单及补考通知书交给学生学生所在班级根据综合成绩计算综合评分，并将综合评分交给学生科1177211773§6.3需求分析的原则和方法一、需求分析的原则解决逻辑问题以运行环境为基础用户参与的原则构造高质量的需求规格说明11774二、需求分析方法的基本要求1、必须能够表达和理解问题的信息域和功能域

软件可看作是一个黑盒子，输入数据通过转换产生输出信息，就是软件所要具有的功能。因此可通过对数据的描述和数据转换的描述，实现对系统的理解和描述。信息域应包括：数据内容：单个数据或控制对象，即数据项数据结构：数据项的组织形式数据流：数据通过系统时的变化方式11775二、需求分析方法的基本要求2、以层次化的方式对问题进行分解和不断细化软件的功能域和信息域都能做进一步的分解。这种分解可以是同一层次上的，称为横向分解；也可以是多层次的纵向分解。纵向分解横向分解11776二、需求分析方法的基本要求3、要给出系统的逻辑视图和物理视图软件需求的逻辑视图给出的是软件要达到的功能和要处理的数据之间的关系，而不是实现的细节──软件需求的逻辑描述是软件设计的基础。软件需求的物理视图给出的是处理功能和数据结构的实际表现形式，这往往是由设备本身决定的

如一些软件靠终端键盘输入数据，另一些软件靠参数转换设备提供数据。分析员必须清楚系统元素对软件的限制，并考虑功能和信息结构的物理表示，如结构化方法中的数据字典就描述了各条目的具体规定和限制

11777§6.4结构化分析方法一、结构化分析方法的基本思想

详细调查→获取用户需求→描述用户需求

SA（structuredanalysis）方法以数据流分析作为需求分析的出发点，遵循以下原则：用户参与的原则“先逻辑，后物理”的原则“自顶向下，逐层分解”的原则工作成果描述标准化原则11778二、SA方法的描述工具用半形式化的描述方式表达需求，简明易懂。数据流图（DFD）：描绘系统逻辑模型的图形工具，描述了系统的组成部分及各部分之间的联系数据字典（DD）加工说明：结构化英语、判定树和判定表11779三、数据流图──DFD的符号数据源点和终点（外部项）：是系统之外的实体（本系统的动作方），标识出系统与环境的接口，给出系统的有效作用范围(系统边界)为了避免在数据流图上出现线条交叉，同一个源点、终点可在不同位置多次出现，这时要在源点或终点符号的右下方画小斜线，以示重复

11780三、数据流图──DFD的符号加工：是对数据进行处理的逻辑单元，它把对输入数据流转变成输出数据流对数据加工转换的方式有两种：改变数据的结构，例如将数组中各数据重新排序产生新的数据，例如对原来的数据总计、求平均等值。标识：

P＋加工编号＋加工名加工名一般用：“动词＋宾语”例如：计算应发工资，生成工资存款清单

11781数据流图──DFD的符号数据流：是系统处理的对象和数据流动的方向，由一组或一个确定的数据组成。数据流的方向：从一加工指向另一加工从加工指向数据存储或反之从源点指向加工或从加工指向终点标识：F＋编号＋数据流名数据流命名数据流名应能直观地反映数据流的含义，如成绩单，工资单不能用动作名和实物名作为数据流名，如现金

流入、流出数据流可以有相同的数据结构，但必须有不同的数据或具有不同的含义，如成绩单与合理成绩单两个加工之间可以有几股不同的数据流，这是由于它们的用途不同，或它们之间没有联系，或它们的流动时间不同

11782数据流图──数据流与加工之间的关系与：数据A和B同时输入变成C或：数据A或B，或者A和B同时输入变成C异或：数据A或B其中之一变成C11783数据流图──DFD的符号数据存储（文件）：逻辑上是信息的静态存储；物理上，可以是计算机系统中的外部或内部文件、文件的一部分、数据库的元素等，还可以是人工系统中的表册、账单等。在分层DFD中，通常是局部于某一分解层次的。数据流的方向从加工流向数据存储从数据存储流向加工双向标识：D＋编号＋数据存储名称11784数据流图──分层DFD对于大型系统，往往使用一张数据流图画出所有数据流和加工是不可能的，不要一下子引入过多细节，应该逐步增加细节自顶向下逐层分解──分层DFD顶层图0层图1层图11785数据流图──分层DFD父图与子图：顶层-中间层-底层（基本加工）分层DFD的编号：图号：父图中加工的编号加工编号：图号＋局部顺序号父图和子图数据流的平衡局部文件：如果某个中间层的DFD中的数据存储不是父图中相应加工的外部接口，而只是本图中某些加工之间的接口，则称为局部文件。应在需要表达时才画出来11786数据流图──分层DFD局部文件示意图CC11787数据流图──分层DFD的画法规则：由外向里画找出外部项，确定系统的边界，确定数据流源点和终点，画顶层图画系统的内部，确定0层图画加工的内部。自顶向下，对每个加工进行内部分解，画出分层DFD检查DFD，进行复查求精11788数据流图──学生成绩管理现行系统顶层图11789数据流图──学生成绩管理现行系统0层图11790数据流图──DFD的改进检查数据流图的正确性数据守恒：文件的写和读局部文件的使用父图和子图的平衡11791数据流图──DFD的改进提高数据流图的可读性简化加工间的联系分解的均匀（层次分解的均匀及加工分解的均匀）适当地命名重新分解11792数据流图──DFD的改进结构不合理的DFD13245ABHIJCDFGEKLNM11793数据流图──DFD的改进数据流图重新分解的步骤把需要重新分解的所有子图连成一张；根据各部分之间联系最少的原则，把图划分成几部分；重建父图，即把第二步所得的每一部分画成一个圆圈，各部分之间的联系就是加工之间的界面；重建各张子图，只需把第二步所得的图，按各自的边界剪开即可；为所有加工重新命名、编号。11794数据流图──DFD的改进改进后的DFD11795四、数据字典（DataDictionary,DD）

DD是SA方法中另一个重要的分析工具。DD给出了DFD中所有元素的严格的数据定义，它可以：减少了分析员和用户之间的通信，消除误解是以后进行系统设计及维护的重要依据是进行系统设计的最有价值的文档之一11796数据字典──DD编写的基本要求对DFD中各元素的定义必须明确、一致且易理解命名、编号应与DFD一致对DFD中各元素的定义与说明应无遗漏、无同名异义或异名同义格式规范，文字精练，符号正确11797数据字典──数据流条目系统名：属于哪个子系统数据流编号、名称、别名及其简要描述数据流的来源：一个外部实体、处理逻辑、数据存贮数据流的去向：同上数据流的组成：一个数据流可能包括若干个数据结构，若只有一个数据结构，就不需要专门定义数据流的流通量：单位时间的传输次数高峰时期的流通量：业务的频繁程度和时间有关11798数据字典──数据流条目系统名：成绩管理系统数据流编号：

F1数据流名称：单科成绩单别名：无简述：某学期、某个班、某门课的成绩来源：教师去向：加工P1“成绩单审核”数据流量：2000份/每学期组成：学期＋班级＋DS1（学生成绩）＋教师姓名＋日期11799数据字典──数据项条目数据项也称数据元素，是不可再分的数据最小组成单位，主要内容有：系统名数据项名称：数据项名称必须唯一地标识这个数据项，以区别于其他数据项；名称要反映该数据项的含义，易于他人理解与记忆别名：同一数据项的名称可能不止一个简要说明属于数据流

存储处（属于文件）数据项的类型、长度、取值范围、取值的含义117100数据字典──数据项条目系统名：成绩管理系统数据项名称：学号别名：无简要说明：是每个学生的惟一识别码属于数据流：F1～F4属于数据存储：D1类型：字符型长度：10位取值范围：“0”～“9”含义：1～4位：入学年份；5～7位：专业；第8位：班级；9～10位：序号117101数据字典──数据结构条目

数据结构描述了某些数据项之间的关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，也可以由若干个数据项和数据结构组成。主要内容包括如下。系统名数据结构的名称及其编号

数据结构的组成：如果是一个简单的数据结构，只要列出它所包含的数据项即可。如果是一个嵌套的数据结构，只需列出它所包含的数据结构名称，因为这些数据结构同样在数据字典中有定义117102数据字典──数据结构条目系统名：成绩管理系统数据结构编号：DS1数据结构名称：学生成绩别名：无数据结构组成：课程号＋课程名＋{学号＋姓名＋成绩}117103数据字典──数据项间关系描述符号符号含义例及说明=被定义为+与x=a+b表示x由a和b组成[...|...]或x=[a|b]表示x由a或b组成m{...}n或{...}mn重复x=2{a}5表示x中最少出现2次a，最多出现5次a,2为重复次数的上、下限。{...}重复x={a}表示x由0个或多个a(...)可选x=(a)表示a可在x中出现，也可不出现。"..."基本数据元素x="a"，表示x是取值为字符a的数据元素..连接符x=1..9，表示x可取1到9中任意一个值117104数据字典──数据存贮条目数据存贮是数据结构停留或保存的场所。主要内容：系统名数据存贮的名称及其编号：在数据流程图中对数据存贮给以命名，并编上一个唯一的编号。来源、去向存储组织数据存贮的组成：指它所包含的数据项或数据结构。117105数据字典──数据存贮条目系统名：成绩管理系统数据存储编号：D2数据存储名称：成绩档案别名：无数据来源：加工P2“成绩登记”数据去向：加工P3“成绩统计”存储组织：二维表数据结构组成：

DS1＋补考成绩＋学分117106数据字典──加工条目加工的名称及编号

加工的输入和输出加工的主要功能：对处理逻辑的简明描述，其目的是使人了解这个处理逻辑是做什么用的加工的小说明（文档之一）117107数据字典──加工条目系统名：成绩管理系统加工编号：P2加工名称：成绩登记别名：无输入：F2“合格单科成绩单”，D1“课程”输出：D2“成绩档案”加工说明：如果为普通考试，若及格，登记成绩及学分，否则登记实际成绩，学分为0；如果是补考，若及格，则登记成绩及学分，否则只登记补考成绩。117108数据字典──外部项条目外部实体是系统的“人-机”界面，也就是系统的数据流由外部实体流入，或者系统的数据向外部流出。主要内容：外部实体的名称及编号

与外部实体有关的数据流

117109数据字典──外部项条目系统名：成绩管理系统外部项编号：S1外部项名称：任课教师别名：无输入数据流：输出数据流：F1“单科成绩单”简要说明：学生授课的任课教师，为系统提供学生成绩信息117110五、基本加工逻辑描述如何对DFD中的基本加工进行描述，是结构化分析的关键部分。对基本加工的描述称为“加工说明”。加工说明编写要求：对DFD中的每个基本加工，必须有一个加工说明加工说明必须描述加工把输入数据流转换为输出数据流的转换规则，即加工“做什么”，而不是用程序设计语言来描述具体加工过程常用工具：结构化语言、决策树、决策表117111加工说明──结构化语言（StructuredLanguage）

在用结构化语言描述问题时只允许使用三种基本逻辑结构，顺序结构、选择结构和循环结构。顺序结构：简单陈述名结构，避免复合语句选择结构：IF-THEN-ELSE或CASE循环结构：WHILE-DO或DO（REPEAT）-UNTIL配合这三种结构所使用的词汇主要有三类：在数据字典中定义的名词；有限的自定义词；某些逻辑表达式中的保留字、运算符、关系符等117112加工说明──StructuredLanguage接受单科成绩从课程管理系统中查出课程的学分IF

普通考试成绩

DOWHILE

对于成绩单中每个学生

IF学生的成绩大于合格成绩 记录学生的成绩，学分

ELSE

记录学生的成绩，学分为0

ENDIF

ENDDOELSE

DOWHILE

对于成绩单中每个学生

IF

学生的补考成绩大于合格成绩 记录学生的补考成绩，学分

ELSE

记录学生的补考成绩，学分为0

ENDIF

ENDDOENDIF

117113加工说明──判定树（DecisionTree）判定树是用来表示逻辑判断问题的一种图形工具。它用“树”来表达不同条件下的不同处理，比语言、表格的方式更为直观。判定树的左侧（称为树根）为加工名，中间是各种条件，所有的行动都列于最右侧。117114加工说明──判定树（DecisionTree）成绩登记处理逻辑普通考试成绩登记补考考试成绩登记成绩合格：登记学生成绩及学分成绩不合格：登记学生成绩，学分为0成绩合格：登记学生成绩及学分成绩不合格：登记学生成绩，学分为0成绩登记处理逻辑117115加工说明──判定树（DecisionTree）学生升留级处理逻辑升留级处理逻辑考试总分≥600考试总分<600单科无不及格：发升级通知书单科有不及格：发升级及重修单科通知书单科有满分：发留级免重修单科通知书单科无满分：发留级通知书117116加工说明──判定表（DecisionTable）对于具有多个互相联系的条件和可能产生多种结果的问题，用结构化语言描述则显得不够直观和紧凑，这时可以用以清楚、简明为特征的判定表来描述。判定表采用表格形式来表达逻辑判断问题，表格分成四个部分：基本判断条件基本判断条件组合基本动作执行动作规则：将条件取值组合及其相应要执行的动作称为规则117117加工说明──判定表（DecisionTable）升留级处理判定表规则1规则2规则3规则4规则5规则6规则7规则8考试总分≥600≥600≥600

≥600<600<600<600<600

单科满分有有无无有有无无单科不及格有无有无有无有无发升级通知书发单科免修通知书发留级通知书发单科重修通知书

YYYYNNNNNNNNYYNNNNNNYYYYYNYNNNNN117118加工说明──判定表（DecisionTable）1234考试总分≥600≥600<600<600

单科满分

--有无单科不及格有无--发升级通知书发单科免修通知书发留级通知书发单科重修通知书YYNNNNYNNNYYYNNN如果表中有两条或更多的规则具有相同的动作，并且条件项之间存在着某种关系，则可设法将其合并。简化后的升留级处理判定表117119加工说明