软件工程课件教案3-需求分析.ppt

《软件工程课件教案3-需求分析.ppt》由会员分享，可在线阅读，更多相关《软件工程课件教案3-需求分析.ppt（84页珍藏版）》请在三一办公上搜索。

1、教学目标 掌握需求分析的主要内容；掌握数据流图、数据字典、ER图的绘制，能创建目标系统的逻辑模型。教学重点 目标系统逻辑模型的建立。教学难点 结构化分析技术,第3章 需求分析,第3章 需求分析,3.1 需求分析的任务3.2 获取需求的方法3.3 分析建模与规格说明3.4 实体-联系图3.5 数据规范化3.6 状态转换图3.7 其他图形工具3.8 验证软件需求,需求分析概述,需求分析的意义,软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。,需求分析概述,需求分析的目的,需求分析是软件定义时期的最后一个

2、阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。-准确地回答“系统必须做什么?”,需求分析的相关人,在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。,近几年来已提出许多软件需求分析与说明的方法，每一种分析方法都有独特的观点和表示方法，但都适用下面的基本原则。1、能够表达和理解问题的信息域和功能域对于计算机程序处理的数据，其信息域包括信息流（如下图，即数据通过一个系统时的变化方式)、

3、信息内容和信息结构，而功能域反映上述三方面的控制信息。,需求分析的原则,2、建立描述系统信息、功能和行为的模型 建立模型的过程是“逐步精化”的综合分析的过程。通过对模型的不断深化认识，来达到对实际问题的深刻认识。,需求分析的原则,3、能够对问题进行分解和不断细化，建立问题的层次结构。分解是为了降低问题的复杂性，增加问题的可解性和可描述性。分解可以在同一个层次上进行（横向分解），也可以在多层次上进行（纵向分解）。,需求分析的原则,4、需要给出系统的逻辑视图和物理视图软件需求的逻辑视图给出的是软件要达到的功能和要处理信息之间的关系，而不是实现的细节。软件需求的物理视图给出的是处理功能和信息结构的实

4、际表现形式，这往往是由设备本身决定的。请大家特别注意：需求分析只研究软件系统“做什么？”，而不考虑“怎样做？”。,需求分析的原则,3.1 需求分析的任务,3.1.1 确定对系统的综合要求功能需求-系统提供的服务性能需求-定时约束或容量约束可靠性和可用性需求-系统的可靠性出错处理需求-如何响应环境错误接口需求-与环境通信的格式约束-应遵守的限制条件，精度，工具，标准逆向需求-不应该做什么未来的需求-不属于当前系统的开发范畴,软件系统本质上是信息处理系统，因此，必须考虑：数据（需要哪些数据、数据间联系、数据性质、结构）数据处理（处理的类型、处理的逻辑功能）3.1.3 导出系统的逻辑模型通常系统的逻

5、辑模型用DFD 图,E-R图，状态转换图等来描述。3.1.4 修正系统的开发计划通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。,分析系统的数据要求,由于需求分析方法不同，描述形式不同。其实现步骤如下图所示：,问题识别,分析与综合,编写文档,分析评审,双方确定问题的综合需求。这些需求包括功能需求（最主要的需求）、性能需求、环境需求和用户界面需求，另外还有可靠性、安全性、保密性、可移植性和可维护性等方面的需求。,需求工程过程,问题识别,分析与综合,编写文档,分析评审,导出软件的逻辑模型,需求工程过程,问题识别,分析与综合,编写文档,分析评审,编写“需求说明书”，把双方共同的理解

6、与分析结果用规范的方式描述出来；编写初步用户使用手册；编写确认测试计划；修改完善项目开发计划。,需求工程过程,问题识别,分析与综合,编写文档,分析评审,作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评价。,需求工程过程,不同的开发方法，需求分析的方法也有所不同，常见的分析方法有：,功能分析方法 将系统看作若干功能模块的集合，每个功能又可以分解为若干子功能,子功能还可继续分解,分解的结果已经是系统的雏形。,结构化分析方法 是一种以数据、数据的封闭性为基础，从问题空间到某种表示的映射方法，由数据流图（DFD图）表示。,需求分析的方法,面向对象的分析方法 面向对

7、象的分析方法（OOA）的关键是识别问题域内的对象，分析它们之间的关系，并建立起三类模型。,信息建模法 是从数据的角度对现实世界建立模型的,基本工具是E-R图。,需求分析的方法,需求获取和分析的难度,1）需求难以表达出来项目相关人员通常并不真正知道希望计算机做什么，让他们清晰的表达出需要系统做什么是件困难的事，他们或许提出不切实际的要求。2）需求具有专业性项目相关人员用自己的语言表达需求，这些语言包含很多工作中的专业术语和专业知识。系统分析员没有这些知识和经验，而他们又必须了解这些需求。3）需求的不一致性不同的项目相关人员有不同的需求，可能以不同的方式表达，分析人员必须发现所有潜在的需求资源，而

8、且能够发现这些需求的相容或冲突之处。4）需求的变化性经济和业务环境决定了分析是动态的，需求在分析过程中会发生变更。个别需求的重要程度可能会改变，新的需求可能会从新的项目相关人员那里得到。,需求分析小组建立由客户（用户）、系统分析员、领域专家参加的联合小组。需求获取的方法个别访谈、召集会议、文档研究、问卷调查、观察用户工作流程、建立原型。需求表达的技术（1）需求列表：需求与系统的特殊视角或环境的关系（2）业务流程图（状态/活动图）（3）数据流图（4）实体-联系图,需求获取方法与技术,3.2 获取需求的方法,3.2.1 访谈访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析

9、技术。访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。,访谈的基本形式非正式访谈：获取用户(高端用户)的想法、理念;正式访谈：获取用户（业务部门用户）的具体需求，如功能需求、数据需求等。访谈技术开放性问题（非正式访谈）具体问题（正式访谈）问卷调查表情景分析技术座谈会,3.2.2 面向数据流自顶向下求精,数据决定了需要的处理和算法，数据显然是需求分析的出发点，结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。把一个复杂的问题划分成若干小

10、问题，然后再分别解决，将问题的复杂性降低到人可以掌握的程度。分解的方法可分层进行，方法原理是先考虑问题最本质的方面，忽略细节，形成问题的高层概念。然后再逐层添加细节。即在分层过程中采用不同程度的“抽象”级别，最高层的问题最抽象，而低层的较为具体。,3.2.2 面向数据流自顶向下求精,3.2.2 面向数据流自顶向下求精,当认为某一层比较复杂时到底应该划分为多少个子系统，针对不同的系统的处理不同。划分的原则可以根据业务工作的范围、功能性质、被处理数据对象的特点。一般情况下上面一些层的划分往往按照业务类型划分的比较多，下面一些层往往按照功能的划分比较多。依照这个策略，对于任何复杂的系统，分析工作都可

11、以有计划、有步骤及有条不紊地进行。,数据流分析重要性数据是需求分析的出发点和落脚点信息系统的基本模型：输入数据数据处理输出数据数据在流动中被处理，数据决定了处理所需的算法结构化分析方法可实现数据流自顶向下逐步求精从可行性研究得出的顶层模型（顶层数据流图）开始，将数据流和数据存储及其处理向下分解，直到元素级。数据流分析的结果清晰地定义了可实际操作的个数据元素；明确地展现了数据的来源与去处；初步描绘了数据处理的可能算法（方法）。数据流描述方法数据流图：数据及其处理关系数据字典：数据元素IPO图：处理算法,面向数据流自顶向下求精迭代过程（图）,3.2.3简易的应用规格说明技术,前叙方法的缺陷问题面谈

12、调研、数据流图、数据字典等是具有一定技术性的、形式性方法，一般用于难以掌握，不好交流，不能有效地构建需求分析团队。简易的应用规格说明技术这是一种面向团队的需求收集方法。提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。,简易的应用规格说明技术的过程,确定问题进行初步的访谈，初步确定问题范围和解决方案；编制“产品需求”开发者、用户分别写出“产品需求”，发给双方有关人员预审；“产品需求”预审相关预审人员分别列出系统有关对象、服务要求、约束条件、性能要求召开协调会开发者和用户双方组织的代表出席会议确定是否开发该新软件产品讨论各自提出的“产品需求”预审表项：保留、增

13、加、删除、修改针对每一个子项目（对象、服务、约束、性能）创建一张组合列表小组制定每个子项目小型规格说明按子项目划分小组，每个小组为每张列表中的项目制定小型规格说明各小组向项目全体人员说明制定的小型规格说明，讨论、修改、细化、规范化项目组起草完整的软件需求规格说明书由专人或专门小组整合各小型规格说明，起草起草完整的软件需求规格说明书。,3.2.4 快速建立软件原型,构建原型的要点是，它应该实现用户看得见的功能(例如屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如修改文件)。快速原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户

14、和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。,3.2.4 快速建立软件原型,快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户的需求。在实际开发软件产品时，“修改试用反馈”的过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间。,构建软件原型按照“快速原型法”构建系统的软件原型，这是最准确、最有效、最强大的需求分析技术。软件原型的要点是展现用户看得见、直接交互的功能，如输入、输出、检索、显示、打印等。软件原型构建特性快速易于修改软件原型构建方法和工具（综合使用）第四代程序设计

15、技术可重用的软件构建形式化规格说明工具和软件环境工具,3.3 分析建模与规格说明,3.3.1 分析建模为了更好地理解复杂事物，人们常常采用建立事物模型的方法。模型由一组图形符号和组织这些符号的规则组成。三种模型：面向流的建模：数据流图（DFD/CFD）数据建模：实体关系图（E-RD）基于行为的建模：Petri网、状态转换图,结构化分析模型的组成结构,3.3.2 软件需求规格说明,通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。通常用自然语言,完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、

16、约束、逆向需求以及将来可能提出的要求。由于自然语言的不一致、歧义、含糊、不完整及抽象层次混乱等问题，有些人主张用形式化方法描述用户对软件系统的需求，第4章将简要地介绍形式化说明技术。,需求规格说明书,封面：,需求规格说明书内容：,系统规格说明：系统概貌 功能要求 性能要求 运行要求 可能增加的要求 DFD IPO,数据要求：DD Hierarchy 或 Warnier Diagram,用户系统描述 初步用户手册：从用户的观点考虑系统 系统功能、性能 使用与步骤 等,修正的开发计划：成本估计 资源使用计划 进度计划,需求规格说明书的基本格式框架,目录1 引言 1.1 本说明的编写目的 1.2 软

17、件产品的作用范围 1.3 定义、同义词与缩写 1.4 参考文献2 概述 2.1 产品与其环境间的关系 2.2 功能概述 2.3 用户特征 2.4 约束条件 2.5 假设与前提条件,需求规格说明书的基本格式框架,3功能或行为需求 3.1 功能或行为需求1：1）引言 2）输入 3）处理过程描述 4）输出 3.2 功能或行为需求2：1）引言 2）输入 3）处理过程描述 4）输出 3.n 功能或行为需求n:1）引言 2）输入 3）处理过程描述 4）输出,需求规格说明书的基本格式框架,4外部界面需求 4.1 用户界面 4.2 硬件界面 4.3 软件界面5性能需求 5.1 精度 5.2 时间特征 5.3

18、灵活性6设计约束 6.1 标准化约束 6.2 硬件约束,需求规格说明书的基本格式框架,7其他需求 7.1 数据库需求 7.2 用户操作需求 7.3 工作场地需求8软件产品属性 8.1 可用性 8.2 安全性 8.3 可维护性 8.4 可移植性附录索引,3.4 实体-联系图,数据对象的描述:描述从用户角度看到的数据 数据模型包含三种相互关联的信息：数据对象、描述数据对象的属性及数据对象彼此间相互连接的关系。数据对象 数据对象是对软件必须理解的复合信息的表示。所谓复合信息是指具有一系列不同性质或属性的事物，因此，仅有单个值的事物(例如宽度)不是数据对象。,3.4 实体-联系图,3.4.2 属性 属

19、性定义了数据对象的性质。应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。3.4.3 关系 数据对象彼此之间相互连接的方式称为关系，也称为联系。(1)一对一联系(11)(2)一对多联系(1N)(3)多对多联系(MN)联系也可能有属性。,3.4.4 实体关系图的符号 通常，使用实体关系图(EntityRelationship Diagram)来建立数据模型，实体关系图简称为ER图，相应地，用ER图描绘的数据模型也可以称为ER模型。ER图中包含了实体(即数据对象)、关系和属性等三种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)

20、的属性，并用无向边把实体(或关系)与其属性连接起来。,3.4 实体-联系图,3.4 实体-联系图,实体-关系图实例,制造商,生产,经销商,汽车,经销,存储,标识码,颜色,型号,制造商,车体类型,买主,一对一联系（1:1）实例一个班级只有一个正班长一个班长只在一个班中任职定义：如果对于实体集A中的每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1:1。,两个实体型之间的联系,一对多联系（1:n）实例一个班级中有若干名学生，每个学生只在一个班级中学习定义：如果对于实体集A中的每一个实体，实体集B中有n个实体（n0）与之联系，反之，对于

21、实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1:n。,两个实体型之间的联系,多对多联系（m:n）实例课程与学生之间的联系：一门课程同时有若干个学生选修一个学生可以同时选修多门课程定义：如果对于实体集A中的每一个实体，实体集B中有n个实体（n0）与之联系，反之，对于实体集B中的每一个实体，实体集A中也有m个实体（m0）与之联系，则称实体集A与实体B具有多对多联系，记为m:n。,两个实体型之间的联系,两个以上实体型之间一对多联系若实体集E1，E2，.，En存在联系，对于实体集Ej（j=1，2，.，i-1，i+1，.，n）中的给定实体，最多只和

22、Ei中的一个实体相联系，则我们说Ei与E1，E2，.，Ei-1，Ei+1，.，En之间的联系是一对多的。,两个以上实体型之间的联系,实例 课程、教师与参考书三个实体型一门课程可以有若干个教师讲授，使用若干本参考书，每一个教师只讲授一门课程，每一本参考书只供一门课程使用。,两个以上实体型之间的联系,多个实体型间的一对一联系一对夫妇一个孩两个以上实体型间的多对多联系供应商、项目、零件三个实体型一个供应商可以供给多个项目多种零件每个项目可以使用多个供应商供应的零件每种零件可由不同供应商供给。,两个以上实体型之间的联系,联系的属性：联系本身也是一种实体型，也可以有属性。如果一个联系具有属性，则这些属性

23、也要用无向边与该联系连接起来。,联系的属性,数据规范化使用“范式”，到达消除数据冗余的目的，数据库原理进行,3.5 数据规范化,规范化的目的,消除数据冗余消除数据库中/表格中数据的重复；消除多义性使关系中的属性含义清楚、单一；使关系的“概念”单一化让每个数据项只是一个简单的数或字符串，而不是一个组项或重复组；方便操作使数据的插入、删除与修改操作可行并方便；使关系模式更灵活易于实现接近自然语言的查询方式。,结构化分析方法应当遵循准则：（1）必须理解并描述问题的信息域建立数据模型；（2）必须定义软件应完成的功能建立功能模型；（3）必须描述作为外部事件结果的软件行为建立行为模型。状态转换图(简称为状

24、态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。,3.6 状态转换图,此外，状态图还指明了作为特定事件的结果，系统将做哪些动作(例如，处理数据)。因此，状态图提供了行为建模机制，可以满足第3条分析准则的要求。,3.6 状态转换图,3.6.1 状态,状态:是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。初态(即初始状态)状态 终态(即最终状态)中间状态,一张状态图中只能有一个初态，而终态则可以有0至多个。,3.6.2

25、事件,事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。“事件”例子内部时钟表明某个规定的时间段已经过去，引发某种操作。用户移动或点击鼠标，启动某个功能。,3.6.3 符号,初态用实心圆表示终态用一对同心圆(内圆为实心圆)表示。中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。状态转换状态图中两个状态之间带箭头连线称为状态转换，箭头指明转换方

26、向。,3.6.3 符 号（续）,活动表活动表的语法格式：事件名(参数表)/动作表达式“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。,3.6.3 符 号（续）,事件状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。事件表达式的语法：事件说明守卫条件动作表达式事件说

27、明的语法为：事件名(参数表)。守卫条件是一个可选的布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。动作表达式是一个过程表达式，当状态转换开始时执行该表达式。,三要素：事件(event)：引发 object 状态改变的控制信息（瞬时）。状态(status):即 object 的 attributes 所处的情形（可持续）。行为(action):Object 要达到某种 status 所做的操作（耗时）。,Dynamic Model：表示系统瞬时的控制性质。,表示方法：,注：当描述循环

28、运行过程时，通常不关心是怎样启动的。,3.6.4 例子,图中表明，没有人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态；如果拿起听筒很长时间不拨号(超时)，则进入超时状态；。,3.7 其他图形工具,3.7.1 层次方框图层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。例如，描绘一家计算机公司

29、全部产品的数据结构可以用层次方框图表示。,层次方框图的一个例子,随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。,Warnier图是表示信息层次结构的另外一种图形工具，比层次方框图提供了更丰富的手段。用Warnier图可以表明信息的逻辑组织：可指出一类或一个信息元素是重复出现的；也可表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。,3.7.2 Warnier图,如图

30、是用Warnier图描绘一类软件产品的例子，它说明了这种图形工具的用法。图中表示一种软件产品：要么是系统软件要么是应用软件。系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。,Warnier图,IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。可用于对DFD图中加工的描述。,3.7.3 IPO图,如图是一个主文件更新的例子在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，

31、在右边的框内列出产生的输出数据。,1.校验主记录2.校验事务记录3.更新主记录,旧的主文件事务文件,有效的主记录有效的事务记录更新后的主文件,3.7.3 IPO图,建议使用一种改进的IPO图(也称为IPO表)，这种图中包含某些附加的信息，在软件设计过程中将比原始的IPO图更有用。,改进的IPO图的形式,3.8 验证软件需求,3.8.1 从哪些方面验证软件需求的正确性软件系统中15%的错误起源于错误的需求，因此，应该从下述4个方面进行验证：(1)一致性，需求不能和其他需求互相矛盾。(2)完整性，规格说明书应该包括用户需要的每一个功能或性能。(3)现实性，指定的需求应该是用现有的硬件技术和软件技术

32、基本上可以实现的。(4)有效性，必须证明需求是正确有效的，确实能解决用户面对的问题。,1.验证需求的一致性自然语言书写的需求，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。由于人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发不能在正确的基础上顺利进行。形式化的描述软件需求的方法较好地弥补了上述缺点。,3.8.2 验证软件需求的方法,2.验证需求的现实性为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求

33、规格说明书的现实性。,3.8.2 验证软件需求的方法,2.验证需求的现实性为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。,3.8.2 验证软件需求的方法,3.验证需求的完整性和有效性只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。然而许多用户只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。使用原型系统是一个比较现实的方法。,3.8.2 验证软件需求的方法,3.8.3 用于需求分析的软件工具,需求

34、分析软件工具为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。需求分析软件工具例RSL(需求陈述语言)PSL/PSA(问题陈述语言/问题陈述分析器),需求分析软件工具要求,(1)必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；(2)使用这个软件工具能够导出详细的文档；(3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；(4)使用这个软件工具之后，应该能够改进交流状况。,RSL(需求陈述语言),用RSL语言描述需求，RSL可有相应的计算机软件处理；经RSL语言处

35、理程序处理后的信息统一存储在ASSM（抽象系统语义模型）数据库中；RSL的另一组软件工具处理ASSM数据库中的信息，产生用PASCAL语言书写的模拟程序（需求分析的原型）；提交需求原型检验需求的一致性、完整性、现实性、有效性。,PSL/PSA,PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理等8个方面描述信息系统。(1)描述任何应用领域的信息系统；(2)创建一个数据库保存对该信息系统的描述符；(3)对描述符施加增加、删除和更改等操作；(4)产生格式化的文档和关于规格说明书的各种分析报告。,3.9 小结,需求分析的任务功能需求+其他需求(functions+other requirements)获取需求的方法访谈(visit),构造原型(prototyping),逐步求精(refinement)分析建模与规格说明数据、功能和行为模型需求分析工具实体-联系图、数据规范化、状态转换图、数据字典、其他图形工具验证软件需求一致性、完整性、现实性和有效性,