大3下软件工程第03章需求分析

需求分析的任务与用户沟通获取需求的方法分析建模与规格说明实体-联系图数据规范化状态转换图其他图形工具验证软件需求第3章需求分析需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。3.1.1

确定对系统的综合要求功能需求:性能需求:3.1

需求分析的任务任何一个软件系统本质上都是信息处理系统，因此，必须分析系统的数据要求，分析系统的数据要求通常采用建立数据模型的方法。利用数据字典可以定义数据，但是数据字典的缺点是不够形象直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。软件系统经常使用的信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。3.1.2

分析系统的数据要求3.1.3

导出系统的逻辑模型综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。需求分析的目标之一就是把数据流和数据存储定义到元素级。3.2.2

面向数据流自顶向下求精图3.1

面向数据流自顶向下求精过程正如第1章已经讲过的，快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能(例如，屏幕显示或打印报表)。3.2.4

快速建立软件原型3.3

分析建模与规格说明3.3.1

分析建模为了更好地理解复杂事物，人们常常采用建立事物模型的方法。通常，模型由一组图形符号和组织这些符号的规则组成。需求分析过程应该建立3种模型，它们分别是数据模型、功能模型和行为模型。实体-联系图描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。前面讲过的数据流图，描绘当数据在软件系统中流动时被变换的逻辑过程，数据流图是建立功能模型的基础。将要介绍的状态转换图，用来描绘系统的各种行为模式(称为“状态”)和在不同状态间转换的方式。状态转换图是行为建模的基础。通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，也可用形式化方法描述用户对软件系统的需求，第4章将简要地介绍形式化说明技术。3.3.2

软件需求规格说明为了把用户的数据要求准确地描述出来，通常建立一个概念性的数据模型,它反映了用户的现实环境，而与实现方法无关。数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。3.4

实体-联系图数据对象是对软件必须理解的复合信息的抽象。所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。3.4.1

数据对象属性定义了数据对象的性质。根据对所要解决的问题的需要，来确定特定数据对象的一组合适的属性。3.4.2

属性数据对象彼此之间相互连接的方式称为联系，联系可分为以下3种类型：一对一联系(1∶1)一对多联系(1∶N)多对多联系(M∶N)3.4.3

联系通常，使用实体-联系图(entity-relationshipdiagram)来建立数据模型。可以把实体-联系图简称为ER图。ER图中包含了实体(即数据对象)、关系和属性等3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。例如，图3.2是某学校教学管理的ER图。3.4.4

实体-联系图的符号图3.2

某校教学管理ER图软件系统经常使用的信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常、修改异常或删除异常，通常需要把数据结构规范化。通常用“范式(normalforms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5

NF)数据冗余程度最小。3.5

数据规范化通常用“范式(normalforms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5

NF)数据冗余程度最小。第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。3.6

状态转换图在需求分析过程中应该建立起软件系统的行为模型。状态转换图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图提供了行为建模机制，可以满足第3条分析准则(行为建模)的要求。例如:在操作系统中，当存在多个申请占用CPU运行的进程(进程是分配CPU的最小处理单位)时，系统将按照某种调度策略为各个进程分配CPU。此时，进程的状态可能有三种：就绪、运行和等待。就绪：等待分配CPU；运行：占用CPU进行相应的处理；挂起：放弃CPU的使用。导致系统状态发生转换的事件有四种：t1、t2、t3、t4，分述如下：t1：因I/O等事件的发生而要求中断；t2：中断事件已经处理完毕；t3：分配CPU；t4：已用完分配的CPU时间。在上面描述的情况下，有关CPU分配的进程的状态转换图如下图所示。S1S2S3t4t3t1t2(a)状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有多个。3.6.1

状态事件是在某个特定时刻发生的事情，它是对引起系统从一个状态转换到另一个状态的控制信息。3.6.2

事件在状态图中，初态用实心圆表示，终态用一对同心圆(内圆为实心圆)表示。中间状态用圆角矩形表示，状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态转换通常是由事件触发的。3.6.3

符号例：电话系统的状态图图中表明，没有人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态；如果拿起听筒很长时间不拨号(超时)，则进入超时状态；……。3.6.4

例子图3.4验证软件需求从哪些方面验证软件需求的正确性需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中

15%的错误起源于错误的需求。必须严格验证这些需求的正确性。一般说来，应该从下述4个方面进行验证：需求分析的第一步是进一步了解用户当前所处的情况，发现用户所面临的问题和对目标系统的基本需求；接下来应该与用户深入交流，对用户的基本需求反复细化逐步求精，以得出对目标系统的完整、准确和具体的需求。3.9

小结为了更好地理解问题，人们常常采用建立模型的方法，结构化分析实质上就是一种建模活动，在需求分析阶段通常建立数据模型、功能模型和行为模型。在需求分析阶段还应该写出软件需求规格说明书，经过严格评审并得到用户确认之后，作为这个阶段的最终成果(从一致性、完整性、现实性和有效性等4个方面复审软件需求规格说明书)。3-3

银行计算机储蓄系统的工作过程大致如

下：储户填写的存款单或取款单由业务员键

入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等

信息，并印出存单给储户；如果是取款而且

存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算

利息并印出利息清单给储户。用实体-联系图描绘系统中的数据对象。