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

《软件工程需求分析需求分析》由会员分享，可在线阅读，更多相关《软件工程需求分析需求分析（131页珍藏版）》请在金锄头文库上搜索。

1、第5章 需求分析可行性研究通过以后，下一步就要根据草拟的开发计划，展开详细的需求分析活动。软件需求分析，是详细分析需求，并建立需求分析模型的阶段2024/9/41第5章 软件需求分析5.1 5.1 需求分析概述需求分析概述5.2 5.2 结构化分析方法结构化分析方法5.3 5.3 数据流图的绘制数据流图的绘制5.4 5.4 编制数据字典编制数据字典5.5 5.5 加工逻辑的分析与表达加工逻辑的分析与表达5.6 5.6 需求验证与评审需求验证与评审2024/9/425.1 需求分析概述5.1.1 5.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难5.1.2 5.1.2 人员

2、组成人员组成5.1.3 5.1.3 分析师的角色分析师的角色5.1.4 5.1.4 需求分析的活动和原则需求分析的活动和原则2024/9/435.1.1 需求分析的任务1.1.完成完成“分析建模分析建模”; ;2.2.拟定拟定“确认测试确认测试”计划计划3.3.修订修订“开发计划开发计划”4.4.编写编写“需求规划说明书需求规划说明书”5.5.需求评审需求评审2024/9/441. 分析建模针对用户要求实现的软件功能、性能等目标，针对用户要求实现的软件功能、性能等目标，与开发人员进一步澄清、达成共识、形成规与开发人员进一步澄清、达成共识、形成规约约; ;准确讲，需求分析是发掘需求、分析求精、准

3、确讲，需求分析是发掘需求、分析求精、逻辑建模、形成规约的过程。逻辑建模、形成规约的过程。2024/9/451. 分析建模发掘需求发掘需求调查需求、挖掘潜在需求、预测未调查需求、挖掘潜在需求、预测未来可能的需求；来可能的需求；需求求精需求求精对模糊不清的用户需求明确、精化；对模糊不清的用户需求明确、精化；逻辑建模逻辑建模在现行系统逻辑模型的基础上，考在现行系统逻辑模型的基础上，考虑新的用户需求、限制和约束的基础上导出新系虑新的用户需求、限制和约束的基础上导出新系统的逻辑模型；统的逻辑模型；形成规约形成规约将双方达成共识的需求文档化、模将双方达成共识的需求文档化、模型化，这份文档被称为型化，这份文

4、档被称为“需求规约需求规约”和和“需求规需求规格说明书格说明书”，它将是后需活动开发方努力实现的，它将是后需活动开发方努力实现的目标目标2024/9/462. 2. 拟定拟定“确认测试确认测试”计划计划有了共同的需求约定以后，就可以制定有了共同的需求约定以后，就可以制定“确认测试确认测试”计划，它是用户验证软件是否满足需求的依据；计划，它是用户验证软件是否满足需求的依据；这个计划到综合测试后期执行。这个计划到综合测试后期执行。2024/9/473. 3. 修订开发计划修订开发计划系统调查与可行性研究阶段的最后，草拟了初步系统调查与可行性研究阶段的最后，草拟了初步的开发计划，当时由于需求尚不详细

5、，现可有了的开发计划，当时由于需求尚不详细，现可有了详细的需求分析结果以后，应该使开发计划更准详细的需求分析结果以后，应该使开发计划更准确一些。确一些。2024/9/484 . 4 . 编写编写“需求规划说明书需求规划说明书”需求分析阶段的成果集中体现在需求分析阶段的成果集中体现在“需求规格说明需求规格说明书书”中，这是一个里程碑；中，这是一个里程碑；有明确的格式和内容有明确的格式和内容2024/9/495. 5. 需求评审需求评审需求评审是需求评审是“质量保证活动质量保证活动”的内容；的内容；体现出瀑布模型的体现出瀑布模型的“文档驱动文档驱动”特点特点由项目经理、用户、分析员、前一阶段（可由

6、项目经理、用户、分析员、前一阶段（可行性研究）的主要人员和后一阶段（概要设行性研究）的主要人员和后一阶段（概要设计）的主要人员组成评审小组；计）的主要人员组成评审小组；2024/9/410阶段性成果（主要文档）包括：阶段性成果（主要文档）包括：需求规格说明书需求规格说明书细化的项目计划细化的项目计划确认测试计划确认测试计划2024/9/411主要特点主要特点: :面向问题域（即用户业务领域）面向问题域（即用户业务领域）只关注只关注“逻辑逻辑”，不考虑，不考虑“物理物理”只研究应该只研究应该“做什么？做什么？”，暂不考虑用什么，暂不考虑用什么手段、如何实现，即手段、如何实现，即“怎么做怎么做”的

7、问题；的问题；用数流据图、数据字典、加工描述等工具建立用数流据图、数据字典、加工描述等工具建立逻辑模型逻辑模型2024/9/412面临的主要困难需求分析活动面临的挑战：需求分析活动面临的挑战：使用有效的软件工程方法克服复杂性使用有效的软件工程方法克服复杂性建立分析员与用户的有效沟通建立分析员与用户的有效沟通使用有效的工具，克服需求表述的二义性使用有效的工具，克服需求表述的二义性2024/9/4135.1 5.1 需求分析需求分析概述概述5.1.1 5.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难5.1.2 5.1.2 人员组成人员组成5.1.3 5.1.3 分析师的角色

8、分析师的角色5.1.4 5.1.4 需求分析的活动和原则需求分析的活动和原则2024/9/4145.1.2 5.1.2 人员组成人员组成如果是一个企业信息系统开发项目，那么项目团队如果是一个企业信息系统开发项目，那么项目团队成员应包括用户和开发人员；成员应包括用户和开发人员；参与团队的用户包括：参与团队的用户包括：企业负责人、部门负责人、专业岗位上的员工；企业负责人、部门负责人、专业岗位上的员工；参开团队的开发人员包括：参开团队的开发人员包括：系统分析师、数据管理员；系统分析师、数据管理员；在需求评审时，还需要在需求评审时，还需要”可行性分析可行性分析“和和”系统设系统设计计“阶段的主要人员参

9、与；阶段的主要人员参与；2024/9/4155.1 5.1 需求分析需求分析概述概述5.1.1 5.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难5.1.2 5.1.2 人员组成人员组成5.1.3 5.1.3 分析师的角色分析师的角色5.1.4 5.1.4 需求分析的活动和原则需求分析的活动和原则2024/9/4165.1.3 5.1.3 分析师的角色分析师的角色是用户与开发人员的桥梁；是用户与开发人员的桥梁；与项目经理合作，是开发团队的领军人物；与项目经理合作，是开发团队的领军人物；具体业务主要集中在可行性研究和需求分析阶段；具体业务主要集中在可行性研究和需求分析阶段；

10、个人素质方面：个人素质方面：具有领导才能，善于沟通；具有领导才能，善于沟通；具有实干作风；具有实干作风；知识面宽，重在广度而不是深度；知识面宽，重在广度而不是深度；技术全面；技术全面；有时分析师是一个团队，由若干人承担；有时分析师是一个团队，由若干人承担；2024/9/4175.1 5.1 需求分析需求分析概述概述5.1.1 5.1.1 需求分析的任务、特点、主要困难需求分析的任务、特点、主要困难5.1.2 5.1.2 人员组成人员组成5.1.3 5.1.3 分析师的角色分析师的角色5.1.4 5.1.4 需求分析的活动和原则需求分析的活动和原则2024/9/4185.1.4 5.1.4 需求

11、分析的活动和原则需求分析的活动和原则活动主要分为：活动主要分为：需求获取需求获取；分析建模；分析建模；需求评审需求评审2024/9/419需求获取的目标需求获取的目标对用户需求进行鉴别、综合，清除用户需求的对用户需求进行鉴别、综合，清除用户需求的模糊性、歧义性和不一致性；模糊性、歧义性和不一致性；把对原始问题的理解和软件开发经验结合起来，把对原始问题的理解和软件开发经验结合起来，鉴别由于用户的片面性或短期行为所导致的不鉴别由于用户的片面性或短期行为所导致的不合理要求，发现用户尚未发现的但具有真正价合理要求，发现用户尚未发现的但具有真正价值的潜在需求；值的潜在需求；2024/9/420需求获取中

12、风验需求获取中风验需求获取隐藏着很大的风险需求获取隐藏着很大的风险因为任何错误的需求描述，都必然造成错误的因为任何错误的需求描述，都必然造成错误的设计、错误的编程和错误的软件结果，而实际设计、错误的编程和错误的软件结果，而实际情形是这种潜在的风险是客观存在的情形是这种潜在的风险是客观存在的2024/9/421总的原则总的原则 分析师关注的焦点是分析师关注的焦点是“做什么（做什么（WhatWhat）”，而不，而不是是“怎么做怎么做HowHow”，系统会产生和使用什么数据？，系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会遇系统必须完成什么功能？将定义什么界面？会遇到什么约束？等

13、。到什么约束？等。这一阶段主要精力集中在获取和分析系统的逻辑这一阶段主要精力集中在获取和分析系统的逻辑功能上。不要把功能上。不要把“用计算机如何实现用计算机如何实现”这样的物这样的物理因素牵扯进来，影响逻辑功能的分析。理因素牵扯进来，影响逻辑功能的分析。2024/9/4225.1.4 5.1.4 需求分析的活动和原则需求分析的活动和原则活动主要分为：活动主要分为：需求获取；需求获取；分析建模；分析建模；需求评审需求评审2024/9/423分析建模分析建模用户往往会从不同的角度、不同的抽象级别阐述对用户往往会从不同的角度、不同的抽象级别阐述对原始问题的理解和需求，相对比较零乱，有必要借原始问题的

14、理解和需求，相对比较零乱，有必要借助模型。助模型。一方面，模型用于精确地记录用户从各个视角、不一方面，模型用于精确地记录用户从各个视角、不同抽象级别上对原始问题及目标软件的描述；另一同抽象级别上对原始问题及目标软件的描述；另一方面，它将帮助分析人员去伪存真、由表及里地挖方面，它将帮助分析人员去伪存真、由表及里地挖掘用户需求。掘用户需求。建模不仅是描述系统的工具，也是用户与开发人员建模不仅是描述系统的工具，也是用户与开发人员进行交流的工具。在结构化分析方法中，数据流图进行交流的工具。在结构化分析方法中，数据流图是建模的主要工具。逻辑模块不仅是描述问题的图是建模的主要工具。逻辑模块不仅是描述问题的

15、图形工具，同时更是分析问题的一种工作方法。形工具，同时更是分析问题的一种工作方法。2024/9/424调研阶段产生的文档，是需求分析的起点，是目标调研阶段产生的文档，是需求分析的起点，是目标软件系统逻辑模型的雏型。软件系统逻辑模型的雏型。在需求分析阶段，分析师将进一步对它进行细化、在需求分析阶段，分析师将进一步对它进行细化、扩充，直到足够具体为止。在分析的过程中建立数扩充，直到足够具体为止。在分析的过程中建立数据字典，对模型进行注解。据字典，对模型进行注解。逻辑模型是分析师与用户交流的主要工具，也是需逻辑模型是分析师与用户交流的主要工具，也是需求分析阶段的成果的主要体现。求分析阶段的成果的主要

16、体现。2024/9/4253.3.需求评审需求评审 需求审查和管理复审是需求分析的最后一个环节，需求审查和管理复审是需求分析的最后一个环节，通过了这一环节，就等于暂时为需求分析阶段画通过了这一环节，就等于暂时为需求分析阶段画上了一个上了一个“句号句号”。尽管后期可能还会有些对需。尽管后期可能还会有些对需求分析的反复，但有了这个求分析的反复，但有了这个“句号句号”，就可以进，就可以进入设计阶段了。入设计阶段了。经过审批之后的文档，在整个项目范围内，相当经过审批之后的文档，在整个项目范围内，相当于用户与开发人员之间达成了一份合约，后期的于用户与开发人员之间达成了一份合约，后期的系统设计和系统测试，

17、都将以这份系统设计和系统测试，都将以这份“规约规约”为准。为准。任何对合约的修改，都将影响到整个项目的工期任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要经过严格的审批和签约。和开发成本，都需要经过严格的审批和签约。2024/9/426例家庭保安系统问题描述：家庭保安市场正以每年40%的速度增长。希望建立一种基于微处理器的家庭保安系统，它能够识别异常事件并采取相应的防护措施。这些异常事件包括：非法侵入、火灾、水淹等。一旦异常情况被传感器探测出来，系统应自动通过电话向监控中心报警。此外，应允许户主对系统行为进行程序控制。2024/9/427家庭保安系统分析初期联合小组的工作程序联合小

18、组首先制定工作制度：每次会议开始前必须有确定的议程，参加者必须针对各项议程进行充分的准备，并用文字表示。经过会议讨论，明确问题的范围、问题与环境的关系，并就开发软件产品的必要性达成共识。2024/9/428例家庭保安系统小组负责人要求每位参加者列出问题及环境中的有关对象，对这些对象施行的操作以及对象间的相互作用。列出的操作和对象尽可能完全，如，控制面板、电话机、监控中心、烟雾传感器、门窗监视器、警报器等对象，以及用户编程控制、电话拔号、报警等操作。负责人应要求小组成员对接收传感器事件、用户编程控制、电话报警等操作进行更详细的描述，必要时可用流程图表示。2024/9/429例家庭保安系统用户可能

19、提出一些条件，如造价不能超过3，000元，对传感器事件必须在1秒内作出响应，事件必须按优先级进行处理等。会后小组负责人对这些信息进行综合、整理，形成文档，该文档应能反映“家庭保安系统”的全貌。联合小组分成两个小组，分别处理用户编程控制和传感器监测两个子系统。目的是对子系统的软件需求进行细化。对出现的新对象、新操作、新约束应及时添加到相应的子系统。2024/9/430例家庭保安系统确定子系统需求并形成文档联合小组讨论子系统的集成及需求验证标准。子系统集成包括子系统接口的一致性检查、系统功能和行为的完整性检查。需求验证标准应该是可测试的，以便开发人员在代码生成后能够通过测试结果向用户表明软件系统已

20、完整地实现了用户需求。初步分析活动应形成结论性文档，该文档将作为后续分析活动的基础。2024/9/431例家庭保安系统初步分析生成的“家庭保安系统”部分需求文档(不包括约束条件和测试标准)“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。配置操作(1)指定每一传感器的种类和编号；(2)设置开、关机密码；(3)指定报警电话号码；(4)指定报警延迟和电话重拔延迟时间(以秒为单位)。2024/9/432例家庭保安系统当软件系统接收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拔报警电话号码，拔号操作将按照重拔延迟反复进行

21、，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。开机后软件系统负责显示当前工作状态，接收并处理用户指令。2024/9/433第第5 5章章 软件需求分析软件需求分析5.1 5.1 需求分析概述需求分析概述5.2 5.2 结构化分析方法结构化分析方法5.3 5.3 数据流图的绘制数据流图的绘制5.4 5.4 编制数据字典编制数据字典5.5 5.5 加工逻辑的分析与表达加工逻辑的分析与表达5.6 5.6 需求验证与评审需求验证与评审2024/9/434什么是结构化方法？什么是结构化方法？软件工程方法论：软件工程方法论：面向对象方法论面向对象方法论面向过程方法论面向过程方法论结构化方

22、法结构化方法解决复杂问题的方法解决复杂问题的方法分解分解面向对象面向对象按按“负责负责”分解问题，找承担责分解问题，找承担责任的对象任的对象结构化方法结构化方法按按“功能功能”分解问题，划分模分解问题，划分模块块2024/9/4355.2 5.2 结构化分析方法结构化分析方法5.2.15.2.1结构化分析的概念结构化分析的概念5.2.25.2.2细化数据流图细化数据流图5.2.35.2.3数据流程图应用实例数据流程图应用实例2024/9/4365.2.15.2.1结构化分析的概念结构化分析的概念用一组标准的工具和策略从事系统分析与设用一组标准的工具和策略从事系统分析与设计，以便提高系统分析与设

23、计的质量和效率计，以便提高系统分析与设计的质量和效率 2024/9/437结构化分析方法的直接目的就是撇开物理因结构化分析方法的直接目的就是撇开物理因素，在综合分析用户对系统各项要求的基础素，在综合分析用户对系统各项要求的基础上，最终导出新系统的逻辑模型。上，最终导出新系统的逻辑模型。用数据流图作为主要工具，进一步审查用户用数据流图作为主要工具，进一步审查用户的真实需求和新系统必须完成的功能，逐步的真实需求和新系统必须完成的功能，逐步细化数据流图，直到把细化数据流图，直到把“数据流数据流”、“加工加工”和和“数据存贮数据存贮”分析分解到足够具体为止，分析分解到足够具体为止，最终得到的就是系统的

24、基于功能的逻辑模型。最终得到的就是系统的基于功能的逻辑模型。2024/9/438在对数据细化的过程中，要建立数据字典，对在对数据细化的过程中，要建立数据字典，对“数据元素数据元素”、“数据结构数据结构”、“数据流数据流”、“数数据存贮据存贮”和和“加工加工”都要加以详细的定义和注释。都要加以详细的定义和注释。加工的处理逻辑描述，还需要用到专门的分析和加工的处理逻辑描述，还需要用到专门的分析和表达工具：结构式语言、判定树和判定表等工具表达工具：结构式语言、判定树和判定表等工具2024/9/439综上所述，结构化系统分析的过程，大致归纳为以综上所述，结构化系统分析的过程，大致归纳为以下几步：下几步

25、：细化数据流图（细化数据流图（DFD），必要时，对实时系统还要），必要时，对实时系统还要绘制控制流图（绘制控制流图（CFD）；）；编制数据字典；编制数据字典；用户复查；用户复查；修正开发计划；修正开发计划；整理文档；整理文档；审查和复审。审查和复审。2024/9/4405.2 5.2 结构化分析方法结构化分析方法5.2.15.2.1结构化分析的概念结构化分析的概念5.2.25.2.2细化数据流图细化数据流图5.2.35.2.3数据流程图应用实例数据流程图应用实例2024/9/4415.2.25.2.2细化数据流图细化数据流图1沿数据流图回溯，挖掘想要的内容沿数据流图回溯，挖掘想要的内容2自顶向

26、下逐层分析的分析策略自顶向下逐层分析的分析策略 2024/9/4421沿数据流图回溯，挖掘想要的内容沿数据流图回溯，挖掘想要的内容 系统输出的数据流是由哪些数据元素组成的？每系统输出的数据流是由哪些数据元素组成的？每个数据元素又是从哪里来的？对这些问题的回答，个数据元素又是从哪里来的？对这些问题的回答，迫使我们必须从数据流图的输出端开始，沿数据迫使我们必须从数据流图的输出端开始，沿数据流的方向回溯。流的方向回溯。既然它们是系统的输出，显然不是从外面输入到既然它们是系统的输出，显然不是从外面输入到系统中来的就是通过加工产生出来的。沿数据流系统中来的就是通过加工产生出来的。沿数据流图从输出端向输入

27、端回溯，一定能够找出每个数图从输出端向输入端回溯，一定能够找出每个数据元素的来源。同时确认某个数据流是由某个加据元素的来源。同时确认某个数据流是由某个加工产生的，就可以从用户那里调查分析得到该加工产生的，就可以从用户那里调查分析得到该加工的逻辑算法。工的逻辑算法。 2024/9/443记住一个准则：记住一个准则：“数据流数据流”一定是和一定是和“加工加工”有有关联的。一个数据流不是流入关联的。一个数据流不是流入“加工加工”的就必然的就必然是从是从“加工加工”流出的，如图流出的，如图5-1所示。所示。图图5.1 数据流与加工的关系数据流与加工的关系2024/9/444在调研阶段产生的高层数据流图

28、，许多具体的细在调研阶段产生的高层数据流图，许多具体的细节没有包括在里面，因此沿数据流程回溯时常常节没有包括在里面，因此沿数据流程回溯时常常遇到下述问题：遇到下述问题：为了得到某个数据元素需要用到数据流图中目前为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要还没有的数据元素，或者得出这个数据元素需要用的算法尚不完全清楚。为了解决这些问题，往用的算法尚不完全清楚。为了解决这些问题，往往需要向用户和其他有关人员请教，他们的回答往需要向用户和其他有关人员请教，他们的回答会使分析师对目标系统的认识更深入更具体，数会使分析师对目标系统的认识更深入更具体，数据流图中的更

29、多的成分就可以被分解出来。据流图中的更多的成分就可以被分解出来。2024/9/445通常把分析过程中得到的有关数据元素的信息描通常把分析过程中得到的有关数据元素的信息描述在数据字典中，把对算法的简明描述记录在述在数据字典中，把对算法的简明描述记录在IPO图中（输入图中（输入/处理处理/输出图）。通过挖掘分解出输出图）。通过挖掘分解出来的数据流、数据存贮和处理逻辑及时添加到数来的数据流、数据存贮和处理逻辑及时添加到数据流图中，这就是细化的过程。据流图中，这就是细化的过程。2024/9/446回溯数据流图的过程中，还要掌握的另外一个原回溯数据流图的过程中，还要掌握的另外一个原则是：数据流程图不可能

30、一步细化到位，需要按则是：数据流程图不可能一步细化到位，需要按照概括程度逐步细化，逐层分解。照概括程度逐步细化，逐层分解。2024/9/4475.2.25.2.2细化数据流图细化数据流图1沿数据流图回溯，挖掘想要的内容沿数据流图回溯，挖掘想要的内容2自顶向下逐层分析的分析策略自顶向下逐层分析的分析策略 2024/9/4482自顶向下逐层分析的分析策略自顶向下逐层分析的分析策略 在软件工程中控制复杂性的两个基本手段：在软件工程中控制复杂性的两个基本手段：“分分解解“和和“抽象抽象”。 分析理解问题时，一般不可能一步到位，分解可分析理解问题时，一般不可能一步到位，分解可以以“循序渐进循序渐进”地进

31、行，即先考虑问题最本质的地进行，即先考虑问题最本质的属性和高度概括的情形，以后再逐层剖析内部的属性和高度概括的情形，以后再逐层剖析内部的细节，直至涉及到最详细的内容。细节，直至涉及到最详细的内容。这种用高度概括的手法，先把握主要的功能，忽这种用高度概括的手法，先把握主要的功能，忽略细节，避免眉毛胡子一把抓的做法，就用到了略细节，避免眉毛胡子一把抓的做法，就用到了“抽象抽象”的手法。的手法。2024/9/449在研究用户业务系统的数据流程时，是以在研究用户业务系统的数据流程时，是以“功功能能”为对象进行不同级别为对象进行不同级别“抽象抽象”的。的。在数据流图的细化方面，把处理功能按抽象层在数据流

32、图的细化方面，把处理功能按抽象层次进行逐层分解，把握好抽象的粒度，使其与次进行逐层分解，把握好抽象的粒度，使其与层次对应。层次对应。 2024/9/450图图5.2 对数据流图的分层分解对数据流图的分层分解 2024/9/4515.2 5.2 结构化分析方法结构化分析方法5.2.15.2.1结构化分析的概念结构化分析的概念5.2.25.2.2细化数据流图细化数据流图5.2.35.2.3数据流程图应用实例数据流程图应用实例2024/9/4525.2.35.2.3数据流程图应用实例数据流程图应用实例某汽车配件公司设有销售、采购、仓库、会计等业某汽车配件公司设有销售、采购、仓库、会计等业务部门。公司

33、每天都要处理大量的销售订单业务。务部门。公司每天都要处理大量的销售订单业务。当配件缺货或库存量低于保险贮备量时，就要进货。当配件缺货或库存量低于保险贮备量时，就要进货。如果暂不考虑配件公司内部的仓库和会计业务细节，如果暂不考虑配件公司内部的仓库和会计业务细节，那么，配件公司的那么，配件公司的TOP图，如图，如5-3所示。所示。2024/9/453（1）销售子系统）销售子系统TOP图图描述系统边界描述系统边界图5.4汽车配件销售、采购子系统TOP图图5.3汽车配件销售业务系统TOP图2024/9/454（2）销售子系统第一层图）销售子系统第一层图反映主要功能反映主要功能2024/9/455（3）

34、销售子系统第二层图细化数据流图2024/9/456第第5 5章章 软件需求分析软件需求分析5.1 5.1 需求分析概述需求分析概述5.2 5.2 结构化分析方法结构化分析方法5.3 5.3 数据流图的绘制数据流图的绘制5.4 5.4 编制数据字典编制数据字典5.5 5.5 加工逻辑的分析与表达加工逻辑的分析与表达5.6 5.6 需求验证与评审需求验证与评审2024/9/4575.3.15.3.1数据流图的布局数据流图的布局为了便于制图和读图，习惯以加工处理为中为了便于制图和读图，习惯以加工处理为中心，输入来自左侧，输出流向右侧。心，输入来自左侧，输出流向右侧。输入的输入的“数据流数据流”及其及

35、其“来源来源”一般画在左一般画在左侧，如图侧，如图3-6从从“顾客顾客”发来发来“订货单订货单”。输出的数据流及其去处一般画数据流图的右输出的数据流及其去处一般画数据流图的右侧。如图侧。如图3-6中，中，“销售报表销售报表”输出到输出到“主管主管”。从全局看从全局看“数据流数据流”也是由左侧流向右侧也是由左侧流向右侧 2024/9/4585.3 5.3 数据流图的绘制数据流图的绘制5.3.1数据流图的布局数据流图的布局5.3.2符号的应用符号的应用5.3.3避免线条交叉避免线条交叉重复项表示重复项表示5.3.4抽象数据流的应用抽象数据流的应用5.3.5编号规则编号规则5.3.6命名规则命名规则

36、5.3.7父图与子图的平衡父图与子图的平衡2024/9/4595.3.25.3.2符号的应用符号的应用n关于正规的符号、语义关于正规的符号、语义图图5.7 数据流图符号应用数据流图符号应用 2024/9/4605.3 5.3 数据流图的绘制数据流图的绘制5.3.1数据流图的布局数据流图的布局5.3.2符号的应用符号的应用5.3.3避免线条交叉避免线条交叉重复项表示重复项表示5.3.4抽象数据流的应用抽象数据流的应用5.3.5编号规则编号规则5.3.6命名规则命名规则5.3.7父图与子图的平衡父图与子图的平衡2024/9/4613.3.33.3.3避免线条交叉避免线条交叉重复项表示重复项表示20

37、24/9/4623.3.33.3.3避免线条交叉避免线条交叉重复项表示重复项表示图图5.8 避免线条交叉的细法避免线条交叉的细法2024/9/4635.3 5.3 数据流图的绘制数据流图的绘制5.3.1数据流图的布局数据流图的布局5.3.2符号的应用符号的应用5.3.3避免线条交叉避免线条交叉重复项表示重复项表示5.3.4抽象数据流的应用抽象数据流的应用5.3.5编号规则编号规则5.3.6命名规则命名规则5.3.7父图与子图的平衡父图与子图的平衡2024/9/4645.3.45.3.4抽象数据流的应用抽象数据流的应用图图5.9 数据流的合并数据流的合并2024/9/465图5.10通过分解简化

38、数据流 2024/9/4665.3 5.3 数据流图的绘制数据流图的绘制5.3.1数据流图的布局数据流图的布局5.3.2符号的应用符号的应用5.3.3避免线条交叉避免线条交叉重复项表示重复项表示5.3.4抽象数据流的应用抽象数据流的应用5.3.55.3.5编号规则编号规则5.3.6命名规则命名规则5.3.7父图与子图的平衡父图与子图的平衡2024/9/4675.3.55.3.5编号规则编号规则在绘制数据流图的过程中，外部项、处理逻辑、在绘制数据流图的过程中，外部项、处理逻辑、数据流和数据存贮都应加以命名和编号，以数据流和数据存贮都应加以命名和编号，以便对其功能或组成能够直观的理解，尤其对便对其

39、功能或组成能够直观的理解，尤其对于更细节的内容，可以放在数据字典中详细于更细节的内容，可以放在数据字典中详细描述，以便查阅。描述，以便查阅。2024/9/468编号方法是用编号方法是用“层序号层序号” 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/9/4695

40、.3 5.3 数据流图的绘制数据流图的绘制5.3.1数据流图的布局数据流图的布局5.3.2符号的应用符号的应用5.3.3避免线条交叉避免线条交叉重复项表示重复项表示5.3.4抽象数据流的应用抽象数据流的应用5.3.5编号规则编号规则5.3.65.3.6命名规则命名规则5.3.7父图与子图的平衡父图与子图的平衡2024/9/4705.3.65.3.6命名规则命名规则对数据流（或数据存贮）的命名：一般使用名词。当对数据流（或数据存贮）的命名：一般使用名词。当单个名词尚不能说明特指数据流或数据存贮时，前面单个名词尚不能说明特指数据流或数据存贮时，前面可以加定语限定。可以加定语限定。命名要代表整个数据

41、流或数据存贮。因为一个数据流命名要代表整个数据流或数据存贮。因为一个数据流或数据存贮往往是由一组数据元素组成的数据结构，或数据存贮往往是由一组数据元素组成的数据结构，不要仅使用反映其中某些元素的名子。不要仅使用反映其中某些元素的名子。不要使用泛指的名字，如不要使用泛指的名字，如“数据数据”、“信息信息”、“单单据据”等。等。如果在为某个数据流或数据存贮命名时感到相对困难，如果在为某个数据流或数据存贮命名时感到相对困难，就有可能是因为对数据流或数据存贮分解的不恰当造就有可能是因为对数据流或数据存贮分解的不恰当造成的，试着重新分解，也许问题就解决了。成的，试着重新分解，也许问题就解决了。2024/

42、9/4715.3.65.3.6命名规则命名规则对处理逻辑的命名：除了子系统级的逻辑功能可对处理逻辑的命名：除了子系统级的逻辑功能可以使用名词以外，原则上，其它功能逻辑习惯使以使用名词以外，原则上，其它功能逻辑习惯使用动宾结构的短语命名，如用动宾结构的短语命名，如“记销售帐记销售帐”“处理处理订货业务订货业务”等。等。通常是，先为数据流命名，然后再为与之相关联通常是，先为数据流命名，然后再为与之相关联的处理功能命名。这样命名比较容易。因为大多的处理功能命名。这样命名比较容易。因为大多数据功能都是针对输入的数据流的。数据功能都是针对输入的数据流的。如果某处命名有困难，可能是对处理功能分解不如果某处

43、命名有困难，可能是对处理功能分解不当造成的，试着重新分解，也许问题注解决了。当造成的，试着重新分解，也许问题注解决了。2024/9/4725.3 5.3 数据流图的绘制数据流图的绘制5.3.1数据流图的布局数据流图的布局5.3.2符号的应用符号的应用5.3.3避免线条交叉避免线条交叉重复项表示重复项表示5.3.4抽象数据流的应用抽象数据流的应用5.3.5编号规则编号规则5.3.6命名规则命名规则5.3.75.3.7父图与子图的平衡父图与子图的平衡2024/9/4735.3.75.3.7父图与子图的平衡父图与子图的平衡对数据流程图的扩充应注意父图与子图边界对数据流程图的扩充应注意父图与子图边界的

44、吻合。即所有子图边界的叠加应该与父图的吻合。即所有子图边界的叠加应该与父图描述的系统范围一样大。按经验数据，每张描述的系统范围一样大。按经验数据，每张子图分解出来的加工逻辑一般不要超过子图分解出来的加工逻辑一般不要超过7到到8个，这样可以保持整图清晰，容易理解。如个，这样可以保持整图清晰，容易理解。如果过多，可能是分解过细，应考虑是否应该果过多，可能是分解过细，应考虑是否应该再分解一层。再分解一层。2024/9/474一、问题的描述一、问题的描述一、问题的描述一、问题的描述在医院在医院ICU病房里，将病症监视器安置在每个病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的组合病症

45、病床，对病人进行监护。监视器将病人的组合病症信号实时地传送到中央监护系统进行分析处理。信号实时地传送到中央监护系统进行分析处理。 在中心值班室里，值班护士使用中央监护系统在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报出现异常时，系统会立即自动报警，并打印病情报告和更新病历。告和更新病历。 根据医生的要求随时打印病人的病情报告，系根据医生的要求随时打印病人的病情报告，系统还定期自动更新

46、病历。统还定期自动更新病历。案案 例例 一一 医院病房监护系统医院病房监护系统2024/9/475经过初步的需求分析，得到系统功能要求：经过初步的需求分析，得到系统功能要求：1 1、监视病员的病症、监视病员的病症( (血压、体温、脉搏等血压、体温、脉搏等) )。2 2、定时更新病历。、定时更新病历。3 3、病情出现异常情况时报警。、病情出现异常情况时报警。4 4、随机地产生某一病员的病情报告。、随机地产生某一病员的病情报告。例例1 1：医院病房监护系统：医院病房监护系统产生产生病情报告病情报告监视病情监视病情更新病历更新病历请分析软件请分析软件系统系统需求需求!2024/9/4761. 监视病

47、员的病症监视病员的病症 采集病症信号采集病症信号( (血压、体温、脉搏等血压、体温、脉搏等) )。 组合病症信号。组合病症信号。 将模拟将模拟病症信号转换为数字信号（病症信号转换为数字信号（A-D转换）。转换）。2. 定时更新病历定时更新病历 将将病症信号进行格式化并加入更新日期、时间。病症信号进行格式化并加入更新日期、时间。 更新病历库中病人的信息。更新病历库中病人的信息。 可人工设定更新可人工设定更新病历的时间间隔。病历的时间间隔。二、系统功能需求二、系统功能需求局部监视局部监视局部监视局部监视更新日志更新日志更新日志更新日志2024/9/4773. 病情出现异常情况时报警病情出现异常情况

48、时报警 根据标准病症信号库中的值，判断是否报警。根据标准病症信号库中的值，判断是否报警。 将报警信号转换为各种模拟信号（将报警信号转换为各种模拟信号（D-A转换）。转换）。 实时打印病情报告，立即更新病历。实时打印病情报告，立即更新病历。4. 随机地产生某一病员的病情报告随机地产生某一病员的病情报告二、系统功能需求二、系统功能需求产生病情报告产生病情报告产生病情报告产生病情报告2024/9/478非功能需求1、监视器与网络的、监视器与网络的可靠性要求可靠性要求，涉及人的生命安，涉及人的生命安全。全。2、效率需求效率需求中对时间、空间的需求，所采集的病中对时间、空间的需求，所采集的病症信号数据量

49、大。症信号数据量大。3、互操作需求互操作需求如要求监视器采样频率可人工调如要求监视器采样频率可人工调整等。整等。4、对病人病历的、对病人病历的隐私的要求。隐私的要求。2024/9/479病员病员护士护士护士护士病员监病员监护系统护系统病员病员日志日志病症信号病症信号要求报告要求报告病症病症报告报告报警报警顶顶 层层DFD图图医院病房监护系统分层医院病房监护系统分层医院病房监护系统分层医院病房监护系统分层DFDDFDDFDDFD图图图图顶层确定了系统的范围，其外部实体为病员和护士顶层确定了系统的范围，其外部实体为病员和护士护士护士病员病员护士护士2024/9/480第一层：第一层：病员病员护士护

50、士护士护士中央监视中央监视病员病员日志日志病症信号病症信号要求报告要求报告病症病症报告报告报警报警局部监视局部监视生成报告生成报告病员极限病员极限更新日志更新日志病员数据病员数据格式化格式化病员数据病员数据生理信号生理信号极限值极限值1324日志数据日志数据日志数据日志数据医院病房监护系统顶层医院病房监护系统顶层DFDDFD图图紧急报告紧急报告2024/9/481第二层：加工第二层：加工“中央监视中央监视”分解分解医院病房监护系统二层医院病房监护系统二层DFDDFD图图计算超过计算超过极限值否极限值否病员病员数据数据超过超过极限值极限值报警报警开解信号开解信号产生产生报警信息报警信息病员极限病

51、员极限格式化格式化病员数据病员数据体温体温血压、体温血压、体温脉搏脉搏生理信号生理信号极限值极限值时间时间脉搏脉搏血压血压日期日期时钟时钟格式化格式化病员数据病员数据3.13.23.23.33.33.43.4紧急报告紧急报告2024/9/482计算超过计算超过极限值否极限值否病员数据超过极限值报警开解信号开解信号产生产生报警信息报警信息病员极限病员极限格式化格式化病员数据病员数据体温血压、体温、脉搏生理信号极限值时间脉搏血压日期时钟时钟格式化病员数据3.13.23.23.33.33.43.4第二层：加工第二层：加工“中央监视中央监视”分解分解医院病房监护系统分层医院病房监护系统分层医院病房监护

52、系统分层医院病房监护系统分层DFDDFDDFDDFD图图图图第一层第一层格式化格式化病员数据病员数据生理信号生理信号极限值极限值病员病员护士护士护士护士中央监视中央监视病员病员日志日志病症信号病症信号要求报告要求报告病症病症报告报告报警报警局部监视局部监视生成报告生成报告病员极限病员极限更新日志更新日志病员病员数据数据1324日志数据日志数据紧急报告紧急报告紧急报告紧急报告2024/9/483第第5 5章章 软件需求分析软件需求分析5.1 5.1 需求分析概述需求分析概述5.2 5.2 结构化分析方法结构化分析方法5.3 5.3 数据流图的绘制数据流图的绘制5.4 5.4 编制数据字典编制数据

53、字典5.5 5.5 加工逻辑的分析与表达加工逻辑的分析与表达5.6 5.6 需求验证与评审需求验证与评审2024/9/4845.4 5.4 编制数据字典编制数据字典在数据流图中对一个数据流、数据存贮或加工只在数据流图中对一个数据流、数据存贮或加工只能标明一个名字，没有对这些元素的构成细节、能标明一个名字，没有对这些元素的构成细节、内容、特性及加工过程详细说明。分析人员仅靠内容、特性及加工过程详细说明。分析人员仅靠“图图”来完整地理解一个系统的逻辑功能是不可来完整地理解一个系统的逻辑功能是不可能的。能的。数据定典就是用来定义数据流图中的各个成分的数据定典就是用来定义数据流图中的各个成分的具体含义

54、的工具，它以一种准确的、无二义性的具体含义的工具，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。元素的一致的定义和详细的描述。它和数据流图共同构成了系统的逻辑模型，是它和数据流图共同构成了系统的逻辑模型，是“需求规格说明书需求规格说明书”的主要组成部分。的主要组成部分。2024/9/4855.4 5.4 编制数据字典编制数据字典5.4.1定义数据的方法定义数据的方法5.4.2数据字典的内容及格式数据字典的内容及格式2024/9/4865.4.15.4.1定义数据的方法定义数据的方法一般认为，从数据的组

55、成上看是自上而下的分解一般认为，从数据的组成上看是自上而下的分解过程，一直分解的数据元素。因此，在对数据注过程，一直分解的数据元素。因此，在对数据注释、说明和定义的时候，也采取自上而下的方法，释、说明和定义的时候，也采取自上而下的方法，符合人们检索信息的习惯。符合人们检索信息的习惯。当数据被分解到不需要进一步定义，每个与工程当数据被分解到不需要进一步定义，每个与工程有关的人都清楚其含义时，我们就把它看作是数有关的人都清楚其含义时，我们就把它看作是数据元素，分解过程到此就结束了。据元素，分解过程到此就结束了。2024/9/487由数据元素组成数据的方式只有如下三种基本类由数据元素组成数据的方式只

56、有如下三种基本类型：型：顺序顺序 以一定的顺序连接两个或多的元素；以一定的顺序连接两个或多的元素；选择选择 从两个或多个可能的元素中选取一个；从两个或多个可能的元素中选取一个；重复重复 把指定的元素重复零次或多次。把指定的元素重复零次或多次。可选可选 理论上，可以使用上述三种关系定义数据理论上，可以使用上述三种关系定义数据字典中的任何条目。因为，当重复次数为字典中的任何条目。因为，当重复次数为0次或一次或一次时，就构成了一种可有可无的可选关系。但由次时，就构成了一种可有可无的可选关系。但由于于“可选可选”是由数据元素组成数据的一种常见方是由数据元素组成数据的一种常见方式，把它单独列为一种关系会

57、使数据字典的描述式，把它单独列为一种关系会使数据字典的描述更清晰。更清晰。2024/9/488常用的描述数据结构的关系算符常用的描述数据结构的关系算符 表表5-12024/9/4895.4 5.4 编制数据字典编制数据字典5.4.1定义数据的方法定义数据的方法5.4.2数据字典的内容及格式数据字典的内容及格式2024/9/4905.4.25.4.2数据字典的内容及格式数据字典的内容及格式1. 数据流条目数据流条目 2. 数据存储条目数据存储条目3. 数据项条目数据项条目4. 加工条件目加工条件目2024/9/4911.数据流条目数据流条目通常列出组成该数据流的数据项数据流条目通常列出组成该数据

58、流的数据项数。数。2024/9/492（3）销售子系统第二层图细化数据流图2024/9/493数据流：订单数据流：订单名称：订单名称：订单别名：无别名：无简述：顾客订货时填写的项目简述：顾客订货时填写的项目来源：顾客来源：顾客去向：加工去向：加工1.1.1“编辑检查订单编辑检查订单”数据流量：数据流量：1000份份/每周每周组成：编号组成：编号+订货日期订货日期+顾客编号顾客编号+地址地址+电话电话+银行帐号银行帐号+配件名称配件名称+数量数量其中：数据流量指单位时间内（每小时或每其中：数据流量指单位时间内（每小时或每天）传输的次天）传输的次2024/9/494（3）销售子系统第二层图细化数据

59、流图2024/9/4952.2.数据存储条目数据存储条目名称：库存记录名称：库存记录别名：无别名：无简述：存放配件库存信息简述：存放配件库存信息组成：配件编号组成：配件编号+配件名称配件名称+供应商编号供应商编号+单价单价+库存量库存量组织方式：索引文件，以配件编号为关键字组织方式：索引文件，以配件编号为关键字查询要求：要求能立即查询查询要求：要求能立即查询2024/9/496（3）销售子系统第二层图细化数据流图2024/9/4973. 数据项条目名称：配件编号名称：配件编号别名：配件号别名：配件号简述：本公司的所有配件编号简述：本公司的所有配件编号类型：字符型类型：字符型长度：长度：10位位

60、取值范围及含义：第取值范围及含义：第1位：进口位：进口/国产国产 第第2-4位：类别位：类别 第第5-7位：规格位：规格 第第8-10位：编号位：编号 2024/9/4984. 加工条件目由于下层的加工是由上层的基本加工分解而来的，由于下层的加工是由上层的基本加工分解而来的，只要有了基本加工的说明，就可理解上层的加工。只要有了基本加工的说明，就可理解上层的加工。因此，只有把加工分解到足够具体以后，才对基因此，只有把加工分解到足够具体以后，才对基本加工进行描述。本加工进行描述。n具体格式举例如下 2024/9/499（3）销售子系统第二层图细化数据流图2024/9/4100名称：确定能否供货名称

61、：确定能否供货编号：编号：1.2激发条件：收到合格订单激发条件：收到合格订单优先级：普通优先级：普通输入：合格订单输入：合格订单输出：可供货订单、缺货订单输出：可供货订单、缺货订单加工逻辑：根据库存记录加工逻辑：根据库存记录 IF 订单项目的数量订单项目的数量该配件库存量的临界值该配件库存量的临界值 THEN 可供货处理可供货处理 ELSE 此订单缺货，登记缺货情况，待进货后再此订单缺货，登记缺货情况，待进货后再办理补充订货办理补充订货 EDNIF2024/9/4101第5章 软件需求分析5.1 需求分析概述5.2 结构化分析方法5.3 数据流图的绘制5.4 编制数据字典5.5 加工逻辑的分析

62、与表达5.6 需求验证与评审2024/9/41025.5 加工逻辑的分析与表达在数据流图的分层细化的过程中，上层的处理功能逐步被分解为下层的具体的加工。原则上，只要说明了底层的加工逻辑，也就可以理解上层的功能了。到设计阶段以后，底层的加工说明，就是编程中算法的直接依据。2024/9/4103“小说明”集中描述一个加工的内部对数据是如何加工的，即描述加工逻辑。如，“计算实发工资”是一个加工，它的加工逻辑就是：实发工资=基本工资+应补款-应扣款。这种逻辑说明了输入数据是如何转变为输出数据的规则，这就是基本的算法。另外，再附带说明一些与加工有关的信息，如执行条件、优先级、执行频率、出错处理等。202

63、4/9/4104在对加工处理逻辑进行分析表达时，为了达到直观、严谨、无二义性、不模糊，常需求借助一些工具。用于表示层次结构关系的工具有：层次方框图、Warnier图；用于描述处理过程的有：IPO图；用于描述条件判断的有：结构式语言、判断树、判断表。 2024/9/41055.5 加工逻辑的分析与表达5.5.1 结构式语言5.5.2 判断表5.5.3 判断树5.5.4 层次方框图5.5.5 Warnier图2024/9/4106结构式语言是介于自然语言（英语或汉语）和形式语言之间的一种半形式语言。形式语言精确，但不易被理解；自然语言易理解，但不精确，可能产生二义性。结构化语言取“长”补“短”，它

64、是在自然语言基础上加了一些限定，使用有限的词汇和有限的语句来描述加工逻辑，它的结构可分成外和内两层。 2024/9/41071. 外层 外层用来描述控制结构，包括：顺序结构、判断分支结构和循环（重复）结构三种基本结构。（1）顺序结构：顺序结构使用一组祈使语句、判断语句、重复语句的顺序排列。祈使语句至少包含一个动词及一个名词，指出要执行的动作及接受动作的对象。（2）判断分支结构：一般用IF-THEN-ENDIF,CASE OF ENDCASE等关键词。（3）重复结构：一般用DO-WHILE-ENDDO, REPEAT-UNTIL等关键词。2024/9/41082. 内层 内层一般是采用祈使语句，

65、使用数据字典中的名词和有限的自定义词，其动词含义要具体，尽量不用形容词和副词来修饰。还可使用一些简单的算述运算和逻辑运算符号。例如，5.4.2中的“确定能否供货”加工的描述，就使用了结构式语言。2024/9/4109名称：确定能否供货编号：1.2激发条件：收到合格订单优先级：普通输入：合格订单输出：可供货订单、缺货订单加工逻辑：根据库存记录IF 订单项目的数量该配件库存量的临界值THEN 可供货处理ELSE 此订单缺货，登记缺货情况，待进货后再办理补充订货EDNIF2024/9/41105.5 加工逻辑的分析与表达5.5.1 结构式语言5.5.2 判断表5.5.3 判断树5.5.4 层次方框图

66、5.5.5 Warnier图2024/9/41115.5.2 5.5.2 判断表判断表例如，某数据流图中有一个“确定保险类别”的加工，指的是申请汽车驾驶保险时，要根据申请者的情况，确定不同的保险类别。此策略使用自然语言描述为：如果申请者的年龄在21岁以下，要额外收费；如果申请者是21岁以上，并是26岁以下的女性，适用于A类保险；如果申请者是26岁以下的已婚男性，或者是26岁以上的男性，适用于B类保险；如果申请者是21岁以下的女性，或是26岁以下的单身男性，适用于C类保险。除此之外的其他申请者，都适用于A类保险。2024/9/4112这段叙述使人不能较快地看懂该使用的策略原理，你也无法断定，在上

67、述叙述中，是否完全地包涵盖了所有可能的情况。下面我们讨论使用判定表来分析和描述 2024/9/4113下面就分析该分配保险的策略，构造判定表。步骤如下：（1）提取问题中的条件：年龄、性别、婚否（2）标出条件的取值：为绘制判定表方便，用符号代替条件的取值，见表5-2。（3）计算条件组合情况：年龄状态数性别状态数婚姻状态数=322=12（4）提取可能采取的动作或措施：包括A类保险、B类保险、C类保险和客外收费。（5）制作判定表，如表5-3所示。2024/9/4114表5-2 条件取值表条件名取值符号条件状态数年龄年龄21C32126L性别男M2女F婚姻未婚S2已婚E2024/9/4115表5-3

68、初始判定表123456789101112年龄CCCCYYYYLLLL性别FFMMFFMMFFMM婚姻SESESESESESEA类保险 B类保险 C类保险 额外收费 2024/9/4116判定表由判定表由4个部分组成，用双线分割开个部分组成，用双线分割开4个区个区域，如下图所示。域，如下图所示。2024/9/4117（6）完善判定表初始的判定表可能不完善，表现在两个方面。第一，缺少判定列中应采取的动作。例如，“确定保险类别”的说明中，若没有最后一句“除此之外”，那么，第9、10两例就是没有考虑完全的情况。即对于年龄26岁的女性，无论有无结婚这两种情况，该策略没有考虑。因此，判定表或以检查出你的策

69、略有没有遗漏的情况。第二，该判定表按列进行合并。例如，第1和第2例，第5和第6例，第11和第12例，它们前两个条件相同，而对于婚姻，不论有没有结婚，都给了相同的动作。即婚姻情况可以不考虑。合并后的判定表为表5-4。2024/9/4118表5-4 合并后的判定表 1/2345/6789/1011/12年龄CCCYYYLL性别FMMFMMFM婚姻SESEA类保险B类保险C类保险额外收费2024/9/4119判定表能够把在什么条件下系统应做什么动作准确无遗漏地表示出来，但不能描述循环的处理特性，循环处理还需要使用结构式语言。对于复杂的判断结构，用判定表表示不清晰，考虑使用决策树。2024/9/412

70、05.5.3判断树判定树是一种较直观的表达判定策略的工具，一般情况下用判定表分析的结构，需要用判定树再表达成比较直观的形式。后最，再用结构式语言表达，以利于编程实现。上面判定表的分析结构，可用判定树表示为图5-11。2024/9/4121图图5-11 策略树策略树 2024/9/41225.5.4 层次方框图图5-12 用层次方框图表示信息的层次结构 图图5-12 用层次方框图表示信息的层次结构用层次方框图表示信息的层次结构 2024/9/41232024/9/41245.5.5 Warnier图（1 1）某种信息是有条件出现的。）某种信息是有条件出现的。（2 2）某种信息是重复出现的。）某种

71、信息是重复出现的。2024/9/41255.5.6 IPO图2024/9/41262024/9/4127例：某企业的订单处理系统，根据下面的DFD图，把“订单处理”模块分解为输入、处理和输出，画出IPO图。2024/9/4128根据DFD把模块分解为输入、处理、输出三个功能模块，得到总体IPO图2024/9/4129在HIPO图基础上，绘制低层主要模块的IPO图，作为程序模块结构设计的依据。2024/9/41305.6 需求验证与评审需求分析阶段的成果是软件设计的基础。统计表明，软件系统中15%的错误来源于对需求的错误的分析。为确保软件开发成功，一般说来，应该对需求规格说明加以验证。分析阶段结束之前，除了要对需求进行验证以外，还应组织比较正式的需求评审活动，软件需求评审是软件质量保证的一个重要的管理措施。通过评审的需求规格说明，就成为一项被严格控制的软件配置项。2024/9/4131