《软件工程导论》第三章需求分析.ppt

需求分析,第三章,山东师范大学信息科学与工程学院 王化雨,09-10 学 年 第 一 学 期张海藩软件工程导论(第5版),2009年10月,2023/6/1,2,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,3,需求分析,回顾：软件生命周期由 3个时期组成：软件定义、软件开发、软件维护（运行维护）软件定义时期一般为3个阶段：问题定义、可行性研究、需求分析需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。,2023/6/1,4,需求分析的要点,为了开发出真正满足用户需求的软件产品，必须知道用户的需求，对软件需求的深入理解是需求分析是为了知道用户的需求，它的基本任务是回答“做什么”。它无法解决“如何做”的问题。与可行性研究相比，需求分析的工作更为细致。由系统分析员负责，通过与用户交流完成工作。成果是软件需求规格说明书。,2023/6/1,5,需求分析的关键在于分析员和用户的交流,在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用：只有用户才真正知道自己需要什么，但是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户沟通获取用户对软件的需求。,2023/6/1,6,需求分析与规格说明是艰巨复杂的工作,用户与分析员之间需要的内容很多；双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。因此，整个需求分析过程中应该采用行之有效的通信技术，集中精力细致工作。必须严格审查验证需求分析的结果。,2023/6/1,7,需求分析需要遵守的准则,用于需求分析的结构化分析方法应遵守下述准则：必须理解并描述问题的信息域，以此建立数据模型。信息流：数据和控制通过一个系统时的变化方式。两个功能之间的数据/控制传递就确定了功能间的接口。信息内容：单个数据或控制对象，它们构成了某个更大的由软件变换生成的信息的集合。信息结构：各种数据和控制项的内部组织。必须定义软件应完成的功能，它要求建立功能模型。必须描述作为外部事件结果的软件行为，要求建立行为模型。必须对信息、功能和行为模型进行分解，用层次的方式展示细节。,2023/6/1,8,数据模型、功能模型、行为模型的两种视图,逻辑视图给出的是软件要达到的功能和要处理的数据之间的关系（是通过行为结合在一起的），而不是实现的细节。逻辑描述是软件设计的基础。物理视图给出的是处理功能和数据结构的实际表现形式，这往往是由设备本身决定的。,2023/6/1,9,以层次化的方式对问题进行分解和不断细化 软件的功能域和信息域都能做进一步的分解。这种分解可以是同一层次上的，称为横向分解；也可以是多层次的纵向分解。,纵向分解,横向分解,两种层次化方式,需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题。通常软件开发项目是要实现目标系统的物理模型。目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。,目标系统,当前系统,物理模型,逻辑模型,模型化,抽象化,物理模型,逻辑模型,具体化,实例化,理解需求,表达需求,导出,怎么做,做什么,需求分析的实现步骤,2023/6/1,11,需求分析流程,2023/6/1,12,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,13,需求分析的任务内容,确定对系统的综合要求分析系统的数据要求导出系统的逻辑模型修正系统的开发计划,2023/6/1,14,确定对系统的综合要求,功能需求是对软件系统的一项基本需求，但并不是唯一的需要。通常对软件系统的需要是综合性的，大约包括功能需求性能需求可靠性和可用性需求出错处理需求接口需求约束逆向需求将来可能提出的要求,2023/6/1,15,系统的综合要求-1功能需求,指定系统必须提供的服务划分出系统必须完成的所有功能。,2023/6/1,16,系统的综合要求-2性能需求,性能需求指定系统必须满足的定时约束或容量约束，通常包括：速度(响应时间)信息量速率主存容量磁盘容量安全性例如：“应力分析程序必须在一分种之内生成任何一个梁的应力报告。”,2023/6/1,17,系统的综合要求-3可靠性和可用性需求,可靠性需求定量地指定系统的可靠性，如：“机场雷达系统在一个月内不能出现2次以上故障”；可用性：可用性与可靠性密切相关，它量化了用户可以使用系统的程度。例如：“在任何时候，主机或备份机上的机场雷达系统应该至少有一个是可用的，而且在一个月内在任何一台计算机上该系统不可用的时间不能超过总时间的2。”,2023/6/1,18,系统的综合要求-4出错处理需求,这类需求说明系统对环境错误应该怎样响应。环境错误：非应用系统本身造成的错误。例如：如果它接收到从另一个系统发来的违反协议的消息，应该做什么？某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行为。应该有选择地提出这类错误处理需求。这是因为：目标是开发出正确的系统不是用无休止的出错处理代码掩盖自己的错误。对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。,2023/6/1,19,系统的综合要求-5接口需求,接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。例如：“把商品从货源地运送到目的地所需要的成本，应该一直显示在成本正文框中。”应用系统与用户的接口。“向运输公司传送需运送的商品信息的格式是exp，其中是从商品目录中选取的字符串。”应用系统与其他应用系统通信的信息格式。,2023/6/1,20,系统的综合要求-6约束,设计约束(或实现约束)描述在设计(或实现)应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度工具和语言约束设计约束应该使用的标准应用使用的硬件平台,2023/6/1,21,系统的综合要求-7逆向需求,逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，人们应该仅注意能澄清真实需求且可消除可能发生的误解的那些逆向需求。例如：“应力分析程序无须分析桥梁倒塌数据。”,2023/6/1,22,系统的综合要求-8将来可能提出的要求,应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来可能会提出来的要求。这样做的目的是：在设计过程中对系统将来可能的扩充和修改项做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。,2023/6/1,23,需求分析的任务内容,确定对系统的综合要求分析系统的数据要求导出系统的逻辑模型修正系统的开发计划,2023/6/1,24,分析系统数据要求必要性和方法,任何一个软件系统都本质上都是信息处理系统：系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件的需求有深远的影响。因此，必须分析系统的数据要求。分析系统的数据要求是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法。,2023/6/1,25,分析系统的数据要求工具,复杂的数据由许多基本的数据元素组成；数据结构表示数据元素之间的逻辑关系。数据字典可以全面准确地定义数据，但不够直观。为提高可理解性，常用层次方框图和Warnier图来形象直观描述数据结构。,2023/6/1,26,分析系统的数据要求数据需要规范化,软件系统中经常使用长期保存的信息。信息通常以一定方式组织并存储在数据库或文件中。为减少数据冗余，简化修改数据的过程，通常要把数据结构规范化。,2023/6/1,27,需求分析的任务内容,确定对系统的综合要求分析系统的数据要求导出系统的逻辑模型修正系统的开发计划,2023/6/1,28,导出系统的逻辑模型,通过确定对系统的综合要求、分析系统的数据要求，即可导出系统的逻辑模型。逻辑模型通常下列工具或方法描述：数据流图实体联系图状态转换图数据字典主要的处理算法前面介绍过：逻辑视图给出的是软件要达到的功能和要处理的数据之间的关系（是通过行为结合在一起的），而不是实现的细节。逻辑描述是软件设计的基础。物理视图给出的是处理功能和数据结构的实际表现形式，这往往是由设备本身决定的。,2023/6/1,29,需求分析的任务内容,确定对系统的综合要求分析系统的数据要求导出系统的逻辑模型修正系统的开发计划,2023/6/1,30,修正系统的开发计划,如果完成：确定对系统的综合要求分析系统的数据要求导出系统的逻辑模型即可较为准确地估计开发系统的成本和进度，修正以前制定的开发计划。,2023/6/1,31,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,32,与用户沟通获取需求的方法内容,访谈面向数据流自顶向下求精简易的应用规格说明技术快速建立软件原型,2023/6/1,33,访谈,最早使用的，也是使用最为广泛的。分正式和非正式访谈；既可访问用户，也可访问用户领域的专家；可以考查现场，亦应考查市场。有时需要设计、分发、收集、分析调查表。可以使用情景分析技术,2023/6/1,34,情景分析技术的含义,所谓情景分析技术是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。例如：目标系统是一个制定减肥计划的软件，当给出某个肥胖症患者的年龄、身高、体重、腰围及其他数据时，就出现一个可能的情景描述。系统分析员根据自己对目标系统应具备的功能的理解，给出适用于该患者的菜单。客户公司的饮食专家可能指出，那些菜单对于有特殊饮食需求的患者（如：糖尿病人、素食者等）是不合适的。这就使分析员认识到，目标系统在制定菜单之前还应该先询问患者的特殊饮食需求。系统分析员利用情景分析技术，往往能够获知用户的具体需求。,2023/6/1,35,情景分析技术的用处,能在某种程度上演示目标系统的行为：便于用户理解可以揭示出一些分析员目前还不知道的需求可以保证用户在需求分析过程中始终处于积极主动的地位。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。,2023/6/1,36,与用户沟通获取需求的方法内容,访谈面向数据流自顶向下求精简易的应用规格说明技术快速建立软件原型,2023/6/1,37,面向数据流自顶向下求精数据、数据流的重要性,软件系统本质上是信息处理系统，而任何信息处理系统都是把输入数据变成需要的输出信息。数据决定的需要的处理和算法，显然是需求分析的出发点。可行性研究阶段许多实际的数据元素被忽略了，需求分析阶段则应定义所有数据元素。,2023/6/1,38,面向数据流自顶向下求精如何实施,结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法：可行性研究得到了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为此需要从数据流图的输出端着手分析，因为系统的基本功能就是产生输出数据，而输出数据决定了系统必须具有的最基本组成元素。沿数据流从输出端往输入端回溯，可确定每个数据元素的来源，同时初步定义了某个算法。有时，某个输出的数据元素尚未在数据流图中描述，或描述有误，或需要的算法还不明确。对这些，应及时纠正和补充。分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中。通过系统分析员的上述工作，数据流图会扩展到更低层次，从而完成数据流图的细化。必须请用户对数据分析得出的结果进行复查。最终得到对系统数据和功能要求的满意了解。,2023/6/1,39,面向数据流自顶向下求精求精过程图,上述过程可图示如下：,2023/6/1,40,与用户沟通获取需求的方法内容,访谈面向数据流自顶向下求精简易的应用规格说明技术快速建立软件原型,2023/6/1,41,简易的应用规格说明技术,传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。简易的应用规格说明技术，是一种面向团队的需求收集法。今天，它已经成为信息系统领域使用的主流技术。简易的应用规格说明技术分析需求，提倡用户与开发者密切合作，共同：标识问题提出解决方案要素商讨不同方案指定基本需求,2023/6/1,42,简易的应用规格说明技术典型过程,对用户初步访谈、初步确定需求，开发者与用户分别写出“产品需求”；确定双方代表开会地点、时间、协调人；开会前所有与会者都将得到“产品需求”初稿。与会者开会前要认真审查资料，列出系统环境对象、系统将产生的对象以及系统为完成功能而使用的对象；列出操作这些对象的服务、约束条件、性能标准。根据自己理解。会议上，在确定需要这个软件产品后，将每人的列表进行组合。除去冗余，加入讨论中的新项目，由协调人主持讨论表中的每个议题。讨论的目标是，针对每个议题（对象、服务、约束和性能）都创建出一张的表。一致的条例继续细化由双方更小的小组讨论、所有条例都细化到“原子项”。每个小组形成的“小型规格说明”均需提交给全体人员讨论。最终，形成完整的“软件需求规格说明书”。,2023/6/1,43,简易的应用规格说明技术优点,开发者与用户不分彼此，齐心协力，密切合作；即时讨论并求精；有能导出规格说明的具体步骤。,2023/6/1,44,与用户沟通获取需求的方法内容,访谈面向数据流自顶向下求精简易的应用规格说明技术快速建立软件原型,2023/6/1,45,快速建立软件原型,快速建立软件原型是较为准确、有效的需求分析技术。快速原型：快速建立起来旨在演示目标系统主要功能的可运行程序。构建原型的要点：应该实现用户看得见的功能(例如，屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如，修改文件)。,2023/6/1,46,快速建立软件原型特点,快速：尽快向用户提供一个可在计算机上运行的目标系统的模型，以便用户和开发者在目标系统应该“做什么”问题上尽快达成共识。因此它的某些错误可以忽略。容易修改：原型的“修改-试用-反馈”将重复多遍，如果修改耗时过多，势必延误开发。,2023/6/1,47,快速建立软件原型方法和工具,可快速构建和修改原型的工具：第四代技术：如数据库查询和报表语言、程序和应用系统生成器等非过程语言。可重用的软件构件：使用一组已有的软件构件（组件）来装配原型。软件构件可以是数据结构（或数据库）构件，或软件体系结构构件（即程序），或过程构件（即模块），必须把软件构件设计成能在不知其内部工作细节的条件下重用。形式化规格说明和原型环境：形式化规格说明语言和工具，用于替代自然语言规格说明技术。当前的开发交互式环境，可以调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码，用户能够使用可执行的原型代码去进一步精化形式化的规格说明。,2023/6/1,48,原型化方法的必要性,在开发初期，要想得到一个完整准确的规格说明不是一件容易的事。特别是对一些大型的软件项目。用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求。软件开发者对于所要解决的应用问题认识更是模糊不清随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也能随之变化；开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难，需要以改变需求来解脱困境。因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。为解决这些问题，逐渐形成了软件系统的快速原型的概念。,2023/6/1,49,软件原型的分类,探索型：目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。,2023/6/1,50,原型使用策略,废弃策略追加策略,2023/6/1,51,建立快速原型的好处,增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。软件原型化方法提供了一种有力的学习手段。使用原型化方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。,2023/6/1,52,2023/6/1,53,2023/6/1,54,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,55,分析建模,模型：为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。需求分析(教材为结构化分析)实际上是一种创建模型的活动，系统分析员应该：从不同角度抽象出目标系统的特性使用精确的表示方法构造系统的模型验证模型是否满足用户对目标系统的需求在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。需求分析(结构化分析)应该建立数据、功能和行为3种模型：实体-联系图，描述数据对象及数据对象之间的关系，是用于建立数据模型的图形。数据流图：描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，是建立功能模型的基础。状态转换图，也叫状态图：指明作为外部事件结果的系统行为。描绘了系统的各种行为模式和在不同状态间转换的方式。是行为建模的基础。,2023/6/1,56,规格说明,需求分析：创建分析建模写出软件需求规格说明书软件需求规格说明书是需求分析阶段得出的最主要文档。可用自然语言书写。准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。为消除自然语言的缺陷，亦可用形式化方法描述。,2023/6/1,57,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,58,实体-联系图,为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型，也叫信息模型。它是一种面向问题的数据模型，是按照用户的观点对数据建立的模型，描述了从用户角度看到的数据，反映了用户的现实环境，而且在软件系统中的实现方法无关。它包含3种相互关联的信息：数据对象数据对象的属性数据对象彼此间相互连接的关系,2023/6/1,59,实体-联系图数据对象,数据对象是对软件必须理解的复合信息的抽象。复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象。数据对象可以是外部实体、事物、行为、事件等，是可以由一组属性来定义的实体都可被认为是数据对象。数据对象彼此间有关联，数据对象只封装了数据而没有对施加于数据上的操作。这是数据对象与OO中的“类”和“对象”的显著区别。,2023/6/1,60,实体-联系图数据对象的属性,属性定义了数据对象的性质。某数据对象的一个或多个属性可作为它的关键字，因为可以通过它识别数据对象的一个实例。应该根据对所要解决问题的理解，来确定特定数据对象的一组合适的属性。,2023/6/1,61,实体-联系图数据对象彼此间相互连接的关系,联系定义了数据对象彼此之间相互连接的方式。联系的种类：一对一一对多多对多联系也可以有属性,2023/6/1,62,实体-联系图实体-联系图的符号,使用实体-联系图(entity-relationship diagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。ER图中包含了实体(即数据对象)、关系和属性等3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。ER模型比较接近人的习惯思维方式，不熟悉计算机技术的用户也能理解它。,2023/6/1,63,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,64,数据规范化,软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。通常用“范式(normal forms)”定义消除数据冗余的程度。范式越高，数据冗余度越小：1 NF的数据冗余度最大5 NF的数据冗余度最小,2023/6/1,65,范式定义,第一范式：每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。第二范式：满足第一范式，且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分决定)。非关键字属性完全函数依赖于关键字第三范式：符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。任何非关键字属性间不存在函数依赖,2023/6/1,66,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,67,状态转换图的功能,状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果，系统将做哪些动作(例如，处理数据)。因此，状态图提供了行为建模机制。状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。,2023/6/1,68,状态,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。状态图中定义的状态主要有：初态、终态和中间状态。一张状态图中只能有1个初态，可有0个或多个终态。状态图既可表示系统循环运行过程，也可表示系统单程生命期。前者并不关心循环是怎样启动的，而后者则需要标明初始状态和最终状态。,2023/6/1,69,事件,事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。事件是引起系统做动作或(和)转换状态的控制信息。,2023/6/1,70,符号,初态用实心圆表示：终态用内圆为实心圆的一对同心圆表示：中间状态用圆角矩形表示：,状态名称(必须有),活动表(可选),状态变量的名字或值(可选),2023/6/1,71,状态图的表示,状态变量：中间状态的第2部分，没有可以省略活动表：中间状态的第3部分语法格式：事件名(参数表)/动作表达式其中，事件名是任何事件的名称。常用3种标准事件：entry(进入该状态的动作)，exit(退出该状态的动作)，do(该状态下的动作)。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。状态转换是状态图中两个状态之间带箭头的连线。状态变迁通常是由事件触发的，可在表示状态转换的箭头线上标出触发转换的事件表达式。如未标出事件，则表示在源状态的内部活动执行完后自动触发转换。事件表达式（标注在状态转换箭头线上）：语法格式：事件说明守卫条件/动作表达式事件说明的语法是：事件名(参数表)守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就会发生。动作表达式是一个过程表达式，当状态转换开始时执行该表达式。,2023/6/1,72,电话系统状态转换图,没有人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态；如果拿起听筒很长时间不拨号(超时)，则进入超时状态；开始拨号则进入拨号状态,2023/6/1,73,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,74,图形工具,图形工具在描述复杂事物时非常重要。前面已经介绍：用于建立功能模型的数据流图用于建立数据模型的实体-联系图用于建立行为模型的状态图将介绍：层次方框图Warnier图IPO图,2023/6/1,75,层次方框图,层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构；下面的各层矩形框代表这个数据的子集；最底层的框代表组成这个数据的实际数据元素(不能再分割的元素)。,例如，描绘一家计算机公司全部产品的数据结构可以用如图的层次方框图表示：,2023/6/1,76,Warnier图,法国计算机科学家Warnier提出了表示信息层次结构的Warnier图，Warnier图也用树形结构描绘信息，这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。,2023/6/1,77,Warnier图的例子,图中的Warnier图表示一种软件产品要么是系统软件要么是应用软件。系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。,2023/6/1,78,IPO图,IPO是“输入、处理、输出”的简称。IPO图能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。IPO图的基本形式：在左边的框中列出有关的输入数据；在中间的框内列出主要的处理；在右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。,2023/6/1,79,改进的IPO图IPO表,IPO表中增加了某些附加信息，在软件设计过程中比原始的IPO图更有用IPO表包含的附加信息：系统名称图的作者完成的日期本图描述的模块名字模块在层次图中的编号调用本模块的模块清单本模块调用的模块清单注释本模块使用的局部数据元素等,2023/6/1,80,IPO图的优点,在需求分析阶段，可以使用IPO图简略地描述系统的主要算法（即数据流图中各个处理的基本算法）。当然，需求分析阶段，IPO图中的许多附加信息暂时还不具备，但在软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档。这正是在需求分析阶段用IPO图作为描述算法的工具的重要优点。,2023/6/1,81,主要内容,引言需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求,2023/6/1,82,验证软件需求内容,从哪些方面验证软件需求的正确性验证软件需求的方法用于需求分析的软件工具,2023/6/1,83,验证软件需求的必要性,需求分析阶段的工作结果是开发软件系统的重要基础。大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。,2023/6/1,84,需求分析评审的依据,一般说来，应该从下述4个方面验证软件需求的正确性：一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。,2023/6/1,85,验证软件需求内容,从哪些方面验证软件需求的正确性验证软件需求的方法用于需求分析的软件工具,2023/6/1,86,验证软件需求的方法,前面说过，需要从4个不同角度验证软件需求的正确性：一致性完整性现实性有效性验证需求正确性的角度不同，验证的方法也不同。,2023/6/1,87,验证软件需求的方法-1使用形式化的陈述语言描述需求,验证需求的一致性：当需求分析的结果是用自然语言书写时，除了靠人工技术审查验证软件系统规格说明书的正确性外，目前还没有更好的方法。自然语言容易产生不一致性，在规格说明书篇幅较长的情况下，人工审查的效果得不到保障。为了克服自然语言的缺陷，人们提出了形式化的描述软件需求的方法。当用形式化的需求陈述语言描述需求时，可用CASE工具验证需求的一致性，从而能有效地保证软件需求的一致性。,2023/6/1,88,验证软件需求的方法-2参照以往验或类似系统,验证需求的现实性：分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要时应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。,2023/6/1,89,验证软件需求的方法-3积极与用户交流,验证需求的完整性和有效性：只有最终用户才能真正验证软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要(即需求的有效性)只有在用户的密切合作下才能完成。许多用户并不能清楚地认识到他们的需要，不能有效地比较陈述需求的语句和实际需要的功能。这时可采用原型法，快速建立软件原型。使用原型的目的，通常是显示目标系统的主要功能而不是性能。,2023/6/1,90,验证软件需求内容,从哪些方面验证软件需求的正确性验证软件需求的方法用于需求分析的软件工具,2023/6/1,91,用于需求分析的软件工具,这类软件工具应该满足下列要求：必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；使用这个软件工具能够导出详细的文档；必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；使用这个软件工具之后，应该能够改进通信状况。,2023/6/1,92,用于需求分析的软件工具的研发,1977年出现了RSL(需求陈述语言)。RSL语句可由计算机处理，结果放在ASSM(抽象系统语义模型)数据库中。经软件工具处理后可产生PASCAL语言书写的模拟程序，从而验证一致性、完整性和现实性。1977年，美国密执安大学开发了PSL/PSA(问题陈述语言/问题陈述分析程序)系统：是CADSAT(计算机辅助设计和规格说明分析工具)的一部分，基本结构类似于RSL，但功能更强。PSL是用来描述系统的形式语言，PAS是处理PSL描述的分析程序。用PSL描述的系统属性放在一个数据库中，一旦建立起数据库后即可增加、删除、修改信息，并且保持信息的一致性。PAS对数据库进行处理以产生各种报告，测试不一致性或遗漏，并且生成文档。,2023/6/1,93,PSL/PSA的功能,描述任何应用领域的信息系统创建一个数据库保存对该信息系统的描述符对描述符施加增加、删除和更改等操作产生格式化的文档和关于规格说明书的各种分析报告,2023/6/1,94,PSL/PSA的作用,PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理共8个方面描述信息系统。一旦用PSL对系统做了完整描述，就可以调用PSA产生一组分析报告，其中包括所有修改规格说明数据库的记录，用各种形式描述数据库信息的参照报告（包括图形形式的描述），关于项目管理信息的总结报告，以及评价数据库特性的分析报告。借助PSL/PSA系统可以边对目标系统进行自顶向下的逐层分解，边将需求分析过程中遇到的数据流、文件、处理等对象用PSL描述出来并输入到PSL/PSA系统中。PSA将对输入信息作一致性和完整性检查，并且保存这些描述信息。,2023/6/1,95,PSL/PSA的优点,改进了文档质量，能保证文档具有完整性、一致性和无二义性减少管理和维护的费用数据存放在数据库中，便于增加、删除和更改,2023/6/1,96,小结-1,需求分析的任务：借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。需求阶段的工作：问题识别分析与综合编制需求分析阶段的文档需求分析评审,2023/6/1,97,小结-2,结构化分析方法的含义结构化分析方法是一种建模技术在模型的核心是数据字典，它描述了所有的在目标系统中使用的和生成的数据对象。以数据字典为中心，结构化分析方法用三种图来表示模型。,2023/6/1,98,小结-3,围绕数据词典的三种图实体关系图(ERD)描述数据对象及数据对象之间的关系；数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）；状态迁移图(STD)描述系统对外部事件如何响应，如何动作。ERD 用于数据建模，DFD用于功能建模，STD用于行为建模。,2023/6/1,99,小结-4,结构化分析的分析模型,2023/6/1,100,小结-5,三种建模方法与工具数据建模：数据对象描述、E-R图功能建模：数据流图、基本加工逻辑说明(结构化英语、判定表、判定树)行为建模：状态迁移图、时序图、Petri网,2023/6/1,101,作业,习题3-33-5任选一题习题3-6,谢谢大家 欢迎指教,电子信箱：,