软件工程需求分析需求分析

2024/8/221第5章需求分析可行性研究通过以后，下一步就要根据草拟的开发计划，展开详细的需求分析活动。软件需求分析，是详细分析需求，并建立需求分析模型的阶段2024/8/222第5章软件需求分析5.1需求分析概述5.2结构化分析方法5.3数据流图的绘制5.4编制数据字典5.5加工逻辑的分析与表达5.6需求验证与评审2024/8/2235.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2024/8/2245.1.1需求分析的任务完成“分析建模”;拟定“确认测试”计划修订“开发计划”编写“需求规划说明书”需求评审2024/8/2251.分析建模针对用户要求实现的软件功能、性能等目标，与开发人员进一步澄清、达成共识、形成规约;准确讲，需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。2024/8/2261.分析建模发掘需求——调查需求、挖掘潜在需求、预测未来可能的需求；需求求精——对模糊不清的用户需求明确、精化；逻辑建模——在现行系统逻辑模型的基础上，考虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型；形成规约——将双方达成共识的需求文档化、模型化，这份文档被称为“需求规约”和“需求规格说明书”，它将是后需活动开发方努力实现的目标2024/8/2272.拟定“确认测试”计划有了共同的需求约定以后，就可以制定“确认测试”计划，它是用户验证软件是否满足需求的依据；这个计划到综合测试后期执行。2024/8/228

3.修订开发计划系统调查与可行性研究阶段的最后，草拟了初步的开发计划，当时由于需求尚不详细，现可有了详细的需求分析结果以后，应该使开发计划更准确一些。2024/8/2294.编写“需求规划说明书”需求分析阶段的成果集中体现在“需求规格说明书”中，这是一个里程碑；有明确的格式和内容2024/8/22105.需求评审需求评审是“质量保证活动”的内容；体现出瀑布模型的“文档驱动”特点由项目经理、用户、分析员、前一阶段（可行性研究）的主要人员和后一阶段（概要设计）的主要人员组成评审小组；2024/8/2211阶段性成果（主要文档）包括：需求规格说明书细化的项目计划确认测试计划2024/8/2212主要特点:面向问题域（即用户业务领域）只关注“逻辑”，不考虑“物理”只研究应该“做什么？”，暂不考虑用什么手段、如何实现，即“怎么做”的问题；用数流据图、数据字典、加工描述等工具建立逻辑模型2024/8/2213面临的主要困难需求分析活动面临的挑战：使用有效的软件工程方法克服复杂性建立分析员与用户的有效沟通使用有效的工具，克服需求表述的二义性2024/8/22145.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2024/8/22155.1.2人员组成如果是一个企业信息系统开发项目，那么项目团队成员应包括用户和开发人员；参与团队的用户包括：企业负责人、部门负责人、专业岗位上的员工；参开团队的开发人员包括：系统分析师、数据管理员；在需求评审时，还需要”可行性分析“和”系统设计“阶段的主要人员参与；2024/8/22165.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2024/8/22175.1.3分析师的角色是用户与开发人员的桥梁；与项目经理合作，是开发团队的领军人物；具体业务主要集中在可行性研究和需求分析阶段；个人素质方面：具有领导才能，善于沟通；具有实干作风；知识面宽，重在广度而不是深度；技术全面；有时分析师是一个团队，由若干人承担；2024/8/22185.1需求分析概述5.1.1需求分析的任务、特点、主要困难5.1.2人员组成5.1.3分析师的角色5.1.4需求分析的活动和原则2024/8/22195.1.4需求分析的活动和原则活动主要分为：需求获取；分析建模；需求评审2024/8/2220需求获取的目标对用户需求进行鉴别、综合，清除用户需求的模糊性、歧义性和不一致性；把对原始问题的理解和软件开发经验结合起来，鉴别由于用户的片面性或短期行为所导致的不合理要求，发现用户尚未发现的但具有真正价值的潜在需求；2024/8/2221需求获取中风验需求获取隐藏着很大的风险因为任何错误的需求描述，都必然造成错误的设计、错误的编程和错误的软件结果，而实际情形是这种潜在的风险是客观存在的2024/8/2222总的原则分析师关注的焦点是“做什么（What）”，而不是“怎么做How”，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会遇到什么约束？等。这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把“用计算机如何实现”这样的物理因素牵扯进来，影响逻辑功能的分析。2024/8/22235.1.4需求分析的活动和原则活动主要分为：需求获取；分析建模；需求评审2024/8/2224分析建模用户往往会从不同的角度、不同的抽象级别阐述对原始问题的理解和需求，相对比较零乱，有必要借助模型。一方面，模型用于精确地记录用户从各个视角、不同抽象级别上对原始问题及目标软件的描述；另一方面，它将帮助分析人员去伪存真、由表及里地挖掘用户需求。建模不仅是描述系统的工具，也是用户与开发人员进行交流的工具。在结构化分析方法中，数据流图是建模的主要工具。逻辑模块不仅是描述问题的图形工具，同时更是分析问题的一种工作方法。2024/8/2225调研阶段产生的文档，是需求分析的起点，是目标软件系统逻辑模型的雏型。在需求分析阶段，分析师将进一步对它进行细化、扩充，直到足够具体为止。在分析的过程中建立数据字典，对模型进行注解。逻辑模型是分析师与用户交流的主要工具，也是需求分析阶段的成果的主要体现。2024/8/22263.需求评审需求审查和管理复审是需求分析的最后一个环节，通过了这一环节，就等于暂时为需求分析阶段画上了一个“句号”。尽管后期可能还会有些对需求分析的反复，但有了这个“句号”，就可以进入设计阶段了。经过审批之后的文档，在整个项目范围内，相当于用户与开发人员之间达成了一份合约，后期的系统设计和系统测试，都将以这份“规约”为准。任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要经过严格的审批和签约。2024/8/2227例家庭保安系统问题描述：

家庭保安市场正以每年40%的速度增长。希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的防护措施。这些异常事件包括：非法侵入、火灾、水淹等。一旦异常情况被传感器探测出来，系统应自动通过电话向监控中心报警。此外，应允许户主对系统行为进行程序控制。

2024/8/2228家庭保安系统分析初期联合小组的工作程序联合小组首先制定工作制度：每次会议开始前必须有确定的议程，参加者必须针对各项议程进行充分的准备，并用文字表示。经过会议讨论，明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。2024/8/2229例家庭保安系统小组负责人要求每位参加者列出问题及环境中的有关对象，对这些对象施行的操作以及对象间的相互作用。列出的操作和对象尽可能完全，如，控制面板、电话机、监控中心、烟雾传感器、门窗监视器、警报器等对象，以及用户编程控制、电话拔号、报警等操作。负责人应要求小组成员对接收传感器事件、用户编程控制、电话报警等操作进行更详细的描述，必要时可用流程图表示。2024/8/2230例家庭保安系统用户可能提出一些条件，如造价不能超过3，000元，对传感器事件必须在1秒内作出响应，事件必须按优先级进行处理等。会后小组负责人对这些信息进行综合、整理，形成文档，该文档应能反映“家庭保安系统”的全貌。联合小组分成两个小组，分别处理用户编程控制和传感器监测两个子系统。目的是对子系统的软件需求进行细化。对出现的新对象、新操作、新约束应及时添加到相应的子系统。2024/8/2231例家庭保安系统确定子系统需求并形成文档联合小组讨论子系统的集成及需求验证标准。子系统集成包括子系统接口的一致性检查、系统功能和行为的完整性检查。需求验证标准应该是可测试的，以便开发人员在代码生成后能够通过测试结果向用户表明软件系统已完整地实现了用户需求。初步分析活动应形成结论性文档，该文档将作为后续分析活动的基础。2024/8/2232例家庭保安系统

初步分析生成的“家庭保安系统”部分需求文档(不包括约束条件和测试标准)“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。配置操作(1)指定每一传感器的种类和编号；(2)设置开、关机密码；(3)指定报警电话号码；(4)指定报警延迟和电话重拔延迟时间(以秒为单位)。2024/8/2233例家庭保安系统当软件系统接收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。开机后软件系统负责显示当前工作状态，接收并处理用户指令。2024/8/2234第5章软件需求分析5.1需求分析概述5.2结构化分析方法5.3数据流图的绘制5.4编制数据字典5.5加工逻辑的分析与表达5.6需求验证与评审2024/8/2235什么是结构化方法？软件工程方法论：面向对象方法论面向过程方法论——结构化方法解决复杂问题的方法——分解面向对象——按“负责”分解问题，找承担责任的对象结构化方法——按“功能”分解问题，划分模块2024/8/22365.2结构化分析方法5.2.1结构化分析的概念5.2.2细化数据流图5.2.3数据流程图应用实例2024/8/22375.2.1结构化分析的概念用一组标准的工具和策略从事系统分析与设计，以便提高系统分析与设计的质量和效率2024/8/2238结构化分析方法的直接目的就是撇开物理因素，在综合分析用户对系统各项要求的基础上，最终导出新系统的逻辑模型。用数据流图作为主要工具，进一步审查用户的真实需求和新系统必须完成的功能，逐步细化数据流图，直到把“数据流”、“加工”和“数据存贮”分析分解到足够具体为止，最终得到的就是系统的基于功能的逻辑模型。2024/8/2239在对数据细化的过程中，要建立数据字典，对“数据元素”、“数据结构”、“数据流”、“数据存贮”和“加工”都要加以详细的定义和注释。加工的处理逻辑描述，还需要用到专门的分析和表达工具：结构式语言、判定树和判定表等工具2024/8/2240综上所述，结构化系统分析的过程，大致归纳为以下几步：细化数据流图（DFD），必要时，对实时系统还要绘制控制流图（CFD）；编制数据字典；用户复查；修正开发计划；整理文档；审查和复审。2024/8/22415.2结构化分析方法5.2.1结构化分析的概念5.2.2细化数据流图5.2.3数据流程图应用实例2024/8/22425.2.2细化数据流图1．沿数据流图回溯，挖掘想要的内容2．自顶向下逐层分析的分析策略

2024/8/22431．沿数据流图回溯，挖掘想要的内容系统输出的数据流是由哪些数据元素组成的？每个数据元素又是从哪里来的？对这些问题的回答，迫使我们必须从数据流图的输出端开始，沿数据流的方向回溯。既然它们是系统的输出，显然不是从外面输入到系统中来的就是通过加工产生出来的。沿数据流图从输出端向输入端回溯，一定能够找出每个数据元素的来源。同时确认某个数据流是由某个加工产生的，就可以从用户那里调查分析得到该加工的逻辑算法。2024/8/2244记住一个准则：“数据流”一定是和“加工”有关联的。一个数据流不是流入“加工”的就必然是从“加工”流出的，如图5-1所示。图5.1数据流与加工的关系2024/8/2245在调研阶段产生的高层数据流图，许多具体的细节没有包括在里面，因此沿数据流程回溯时常常遇到下述问题：为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法尚不完全清楚。为了解决这些问题，往往需要向用户和其他有关人员请教，他们的回答会使分析师对目标系统的认识更深入更具体，数据流图中的更多的成分就可以被分解出来。2024/8/2246通常把分析过程中得到的有关数据元素的信息描述在数据字典中，把对算法的简明描述记录在IPO图中（输入/处理/输出图）。通过挖掘分解出来的数据流、数据存贮和处理逻辑及时添加到数据流图中，这就是细化的过程。2024/8/2247回溯数据流图的过程中，还要掌握的另外一个原则是：数据流程图不可能一步细化到位，需要按照概括程度逐步细化，逐层分解。2024/8/22485.2.2细化数据流图1．沿数据流图回溯，挖掘想要的内容2．自顶向下逐层分析的分析策略

2024/8/22492．自顶向下逐层分析的分析策略在软件工程中控制复杂性的两个基本手段：“分解“和“抽象”。分析理解问题时，一般不可能一步到位，分解可以“循序渐进”地进行，即先考虑问题最本质的属性和高度概括的情形，以后再逐层剖析内部的细节，直至涉及到最详细的内容。这种用高度概括的手法，先把握主要的功能，忽略细节，避免眉毛胡子一把抓的做法，就用到了“抽象”的手法。2024/8/2250在研究用户业务系统的数据流程时，是以“功能”为对象进行不同级别“抽象”的。在数据流图的细化方面，把处理功能按抽象层次进行逐层分解，把握好抽象的粒度，使其与层次对应。2024/8/2251图5.2对数据流图的分层分解2024/8/22525.2结构化分析方法5.2.1结构化分析的概念5.2.2细化数据流图5.2.3数据流程图应用实例2024/8/22535.2.3数据流程图应用实例某汽车配件公司设有销售、采购、仓库、会计等业务部门。公司每天都要处理大量的销售订单业务。当配件缺货或库存量低于保险贮备量时，就要进货。如果暂不考虑配件公司内部的仓库和会计业务细节，那么，配件公司的TOP图，如5-3所示。2024/8/2254（1）销售子系统TOP图——描述系统边界图5.4汽车配件销售、采购子系统TOP图图5.3汽车配件销售业务系统TOP图2024/8/2255（2）销售子系统第一层图——反映主要功能2024/8/2256（3）销售子系统第二层图——细化数据流图2024/8/2257第5章软件需求分析5.1需求分析概述5.2结构化分析方法5.3数据流图的绘制5.4编制数据字典5.5加工逻辑的分析与表达5.6需求验证与评审2024/8/22585.3.1数据流图的布局为了便于制图和读图，习惯以加工处理为中心，输入来自左侧，输出流向右侧。输入的“数据流”及其“来源”一般画在左侧，如图3-6从“顾客”发来“订货单”。输出的数据流及其去处一般画数据流图的右侧。如图3-6中，“销售报表”输出到“主管”。从全局看“数据流”也是由左侧流向右侧2024/8/22595.3数据流图的绘制5.3.1数据流图的布局5.3.2符号的应用5.3.3避免线条交叉——重复项表示5.3.4抽象数据流的应用5.3.5编号规则5.3.6命名规则5.3.7父图与子图的平衡2024/8/22605.3.2符号的应用关于正规的符号、语义图5.7数据流图符号应用2024/8/22615.3数据流图的绘制5.3.1数据流图的布局5.3.2符号的应用5.3.3避免线条交叉——重复项表示5.3.4抽象数据流的应用5.3.5编号规则5.3.6命名规则5.3.7父图与子图的平衡2024/8/22623.3.3避免线条交叉——重复项表示2024/8/22633.3.3避免线条交叉——重复项表示图5.8避免线条交叉的细法2024/8/22645.3数据流图的绘制5.3.1数据流图的布局5.3.2符号的应用5.3.3避免线条交叉——重复项表示5.3.4抽象数据流的应用5.3.5编号规则5.3.6命名规则5.3.7父图与子图的平衡2024/8/22655.3.4抽象数据流的应用图5.9数据流的合并2024/8/2266图5.10通过分解简化数据流

2024/8/22675.3数据流图的绘制5.3.1数据流图的布局5.3.2符号的应用5.3.3避免线条交叉——重复项表示5.3.4抽象数据流的应用5.3.5编号规则5.3.6命名规则5.3.7父图与子图的平衡2024/8/22685.3.5编号规则在绘制数据流图的过程中，外部项、处理逻辑、数据流和数据存贮都应加以命名和编号，以便对其功能或组成能够直观的理解，尤其对于更细节的内容，可以放在数据字典中详细描述，以便查阅。2024/8/2269编号方法是用“层序号”P1.1——“编辑订货单”P1.1.1——“编辑检查订单”P1.1.2——“登记新顾客信息”P1.3——“办理发货”P1.3.1——表示“开发货单并修改库存”P1.3.2——表示“记销售帐”P1.3.3——表示“销售统计”P1.3.4——表示“登记新配件信息”P1.3.5——表示“生成编码”2024/8/22705.3数据流图的绘制5.3.1数据流图的布局5.3.2符号的应用5.3.3避免线条交叉——重复项表示5.3.4抽象数据流的应用5.3.5编号规则5.3.6命名规则5.3.7父图与子图的平衡2024/8/22715.3.6命名规则①对数据流（或数据存贮）的命名：一般使用名词。当单个名词尚不能说明特指数据流或数据存贮时，前面可以加定语限定。②命名要代表整个数据流或数据存贮。因为一个数据流或数据存贮往往是由一组数据元素组成的数据结构，不要仅使用反映其中某些元素的名子。③不要使用泛指的名字，如“数据”、“信息”、“单据”等。④如果在为某个数据流或数据存贮命名时感到相对困难，就有可能是因为对数据流或数据存贮分解的不恰当造成的，试着重新分解，也许问题就解决了。2024/8/22725.3.6命名规则⑤对处理逻辑的命名：除了子系统级的逻辑功能可以使用名词以外，原则上，其它功能逻辑习惯使用动宾结构的短语命名，如“记销售帐”“处理订货业务”等。⑥通常是，先为数据流命名，然后再为与之相关联的处理功能命名。这样命名比较容易。因为大多数据功能都是针对输入的数据流的。⑦如果某处命名有困难，可能是对处理功能分解不当造成的，试着重新分解，也许问题注解决了。2024/8/22735.3数据流图的绘制5.3.1数据流图的布局5.3.2符号的应用5.3.3避免线条交叉——重复项表示5.3.4抽象数据流的应用5.3.5编号规则5.3.6命名规则5.3.7父图与子图的平衡2024/8/22745.3.7父图与子图的平衡对数据流程图的扩充应注意父图与子图边界的吻合。即所有子图边界的叠加应该与父图描述的系统范围一样大。按经验数据，每张子图分解出来的加工逻辑一般不要超过7到8个，这样可以保持整图清晰，容易理解。如果过多，可能是分解过细，应考虑是否应该再分解一层。2024/8/2275一、问题的描述

在医院ICU病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的组合病症信号实时地传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。根据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。案例一医院病房监护系统2024/8/2276经过初步的需求分析，得到系统功能要求：1、监视病员的病症(血压、体温、脉搏等)。2、定时更新病历。3、病情出现异常情况时报警。4、随机地产生某一病员的病情报告。例1：医院病房监护系统产生病情报告监视病情更新病历请分析软件系统需求!2024/8/22771.监视病员的病症

♦采集病症信号(血压、体温、脉搏等)。♦组合病症信号。♦将模拟病症信号转换为数字信号（A-D转换）。2.定时更新病历♦将病症信号进行格式化并加入更新日期、时间。♦更新病历库中病人的信息。♦可人工设定更新病历的时间间隔。二、系统功能需求—局部监视—更新日志2024/8/22783.病情出现异常情况时报警♦根据标准病症信号库中的值，判断是否报警。♦将报警信号转换为各种模拟信号（D-A转换）。♦实时打印病情报告，立即更新病历。4.随机地产生某一病员的病情报告二、系统功能需求—产生病情报告2024/8/2279非功能需求1、监视器与网络的可靠性要求，涉及人的生命安全。2、效率需求中对时间、空间的需求，所采集的病症信号数据量大。3、互操作需求—如要求监视器采样频率可人工调整等。4、对病人病历的隐私的要求。2024/8/2280病员护士护士病员监护系统病员日志病症信号要求报告病症报告报警顶层DFD图医院病房监护系统分层DFD图顶层确定了系统的范围，其外部实体为病员和护士护士病员护士2024/8/2281第一层：病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据格式化病员数据生理信号极限值1324日志数据日志数据医院病房监护系统顶层DFD图紧急报告2024/8/2282第二层：加工“中央监视”分解医院病房监护系统二层DFD图计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.13.23.33.4紧急报告2024/8/2283计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温、脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.13.23.33.4第二层：加工“中央监视”分解医院病房监护系统分层DFD图第一层格式化病员数据生理信号极限值病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据1324日志数据紧急报告紧急报告2024/8/2284第5章软件需求分析5.1需求分析概述5.2结构化分析方法5.3数据流图的绘制5.4编制数据字典5.5加工逻辑的分析与表达5.6需求验证与评审2024/8/22855.4编制数据字典在数据流图中对一个数据流、数据存贮或加工只能标明一个名字，没有对这些元素的构成细节、内容、特性及加工过程详细说明。分析人员仅靠“图”来完整地理解一个系统的逻辑功能是不可能的。数据定典就是用来定义数据流图中的各个成分的具体含义的工具，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。它和数据流图共同构成了系统的逻辑模型，是“需求规格说明书”的主要组成部分。2024/8/22865.4编制数据字典5.4.1定义数据的方法5.4.2数据字典的内容及格式2024/8/22875.4.1定义数据的方法一般认为，从数据的组成上看是自上而下的分解过程，一直分解的数据元素。因此，在对数据注释、说明和定义的时候，也采取自上而下的方法，符合人们检索信息的习惯。当数据被分解到不需要进一步定义，每个与工程有关的人都清楚其含义时，我们就把它看作是数据元素，分解过程到此就结束了。2024/8/2288由数据元素组成数据的方式只有如下三种基本类型：①顺序以一定的顺序连接两个或多的元素；②选择从两个或多个可能的元素中选取一个；③重复把指定的元素重复零次或多次。④可选理论上，可以使用上述三种关系定义数据字典中的任何条目。因为，当重复次数为0次或一次时，就构成了一种可有可无的可选关系。但由于“可选”是由数据元素组成数据的一种常见方式，把它单独列为一种关系会使数据字典的描述更清晰。2024/8/2289常用的描述数据结构的关系算符表5-12024/8/22905.4编制数据字典5.4.1定义数据的方法5.4.2数据字典的内容及格式2024/8/22915.4.2数据字典的内容及格式1.数据流条目2.数据存储条目3.数据项条目4.加工条件目2024/8/22921.数据流条目数据流条目通常列出组成该数据流的数据项数。2024/8/2293（3）销售子系统第二层图——细化数据流图2024/8/2294数据流：订单名称：订单别名：无简述：顾客订货时填写的项目来源：顾客去向：加工1.1.1“编辑检查订单”数据流量：1000份/每周组成：编号+订货日期+顾客编号+地址+电话+银行帐号+配件名称+数量其中：数据流量指单位时间内（每小时或每天）传输的次2024/8/2295（3）销售子系统第二层图——细化数据流图2024/8/22962.数据存储条目名称：库存记录别名：无简述：存放配件库存信息组成：配件编号+配件名称+供应商编号+单价+库存量组织方式：索引文件，以配件编号为关键字查询要求：要求能立即查询2024/8/2297（3）销售子系统第二层图——细化数据流图2024/8/22983.数据项条目名称：配件编号别名：配件号简述：本公司的所有配件编号类型：字符型长度：10位取值范围及含义：第1位：进口/国产第2-4位：类别第5-7位：规格第8-10位：编号2024/8/22994.加工条件目由于下层的加工是由上层的基本加工分解而来的，只要有了基本加工的说明，就可理解上层的加工。因此，只有把加工分解到足够具体以后，才对基本加工进行描述。具体格式举例如下

2024/8/22100（3）销售子系统第二层图——细化数据流图2024/8/22101名称：确定能否供货编号：1.2激发条件：收到合格订单优先级：普通输入：合格订单输出：可供货订单、缺货订单加工逻辑：根据库存记录IF订单项目的数量<该配件库存量的临界值

THEN可供货处理ELSE此订单缺货，登记缺货情况，待进货后再办理补充订货EDNIF2024/8/22102第5章软件需求分析5.1需求分析概述5.2结构化分析方法5.3数据流图的绘制5.4编制数据字典5.5加工逻辑的分析与表达5.6需求验证与评审2024/8/221035.5加工逻辑的分析与表达在数据流图的分层细化的过程中，上层的处理功能逐步被分解为下层的具体的加工。原则上，只要说明了底层的加工逻辑，也就可以理解上层的功能了。到设计阶段以后，底层的加工说明，就是编程中算法的直接依据。2024/8/22104“小说明”集中描述一个加工的内部对数据是如何加工的，即描述加工逻辑。如，“计算实发工资”是一个加工，它的加工逻辑就是：实发工资=基本工资+应补款-应扣款。这种逻辑说明了输入数据是如何转变为输出数据的规则，这就是基本的算法。另外，再附带说明一些与加工有关的信息，如执行条件、优先级、执行频率、出错处理等。2024/8/22105在对加工处理逻辑进行分析表达时，为了达到直观、严谨、无二义性、不模糊，常需求借助一些工具。用于表示层次结构关系的工具有：层次方框图、Warnier图；用于描述处理过程的有：IPO图；用于描述条件判断的有：结构式语言、判断树、判断表。2024/8/221065.5加工逻辑的分析与表达5.5.1结构式语言5.5.2判断表5.5.3判断树5.5.4层次方框图5.5.5Warnier图2024/8/22107结构式语言是介于自然语言（英语或汉语）和形式语言之间的一种半形式语言。形式语言精确，但不易被理解；自然语言易理解，但不精确，可能产生二义性。结构化语言取“长”补“短”，它是在自然语言基础上加了一些限定，使用有限的词汇和有限的语句来描述加工逻辑，它的结构可分成外和内两层。2024/8/221081.外层外层用来描述控制结构，包括：顺序结构、判断分支结构和循环（重复）结构三种基本结构。（1）顺序结构：顺序结构使用一组祈使语句、判断语句、重复语句的顺序排列。祈使语句至少包含一个动词及一个名词，指出要执行的动作及接受动作的对象。（2）判断分支结构：一般用IF-THEN-ENDIF,CASEOFENDCASE等关键词。（3）重复结构：一般用DO-WHILE-ENDDO,REPEAT-UNTIL等关键词。2024/8/221092.内层内层一般是采用祈使语句，使用数据字典中的名词和有限的自定义词，其动词含义要具体，尽量不用形容词和副词来修饰。还可使用一些简单的算述运算和逻辑运算符号。 例如，5.4.2中的“确定能否供货”加工的描述，就使用了结构式语言。2024/8/22110名称：确定能否供货编号：1.2激发条件：收到合格订单优先级：普通输入：合格订单输出：可供货订单、缺货订单加工逻辑：根据库存记录IF订单项目的数量<该配件库存量的临界值THEN可供货处理ELSE此订单缺货，登记缺货情况，待进货后再办理补充订货EDNIF2024/8/221115.5加工逻辑的分析与表达5.5.1结构式语言5.5.2判断表5.5.3判断树5.5.4层次方框图5.5.5Warnier图2024/8/221125.5.2判断表例如，某数据流图中有一个“确定保险类别”的加工，指的是申请汽车驾驶保险时，要根据申请者的情况，确定不同的保险类别。此策略使用自然语言描述为：如果申请者的年龄在21岁以下，要额外收费；如果申请者是21岁以上，并是26岁以下的女性，适用于A类保险；如果申请者是26岁以下的已婚男性，或者是26岁以上的男性，适用于B类保险；如果申请者是21岁以下的女性，或是26岁以下的单身男性，适用于C类保险。除此之外的其他申请者，都适用于A类保险。2024/8/22113这段叙述使人不能较快地看懂该使用的策略原理，你也无法断定，在上述叙述中，是否完全地包涵盖了所有可能的情况。下面我们讨论使用判定表来分析和描述2024/8/22114下面就分析该分配保险的策略，构造判定表。步骤如下： （1）提取问题中的条件：年龄、性别、婚否 （2）标出条件的取值：为绘制判定表方便，用符号代替条件的取值，见表5-2。 （3）计算条件组合情况：年龄状态数×性别状态数×婚姻状态数=3×2×2=12

（4）提取可能采取的动作或措施：包括A类保险、B类保险、C类保险和客外收费。 （5）制作判定表，如表5-3所示。2024/8/22115表5-2条件取值表条件