软件工程第3章-需求分析课件

第三章

需求分析第3章需求分析3.1需求分析的任务3.2与用户沟通获取需求的方法3.3分析建模与规格说明3.4实体-联系图3.5数据规范化3.6状态转换图3.7其他图形工具3.8验证软件需求为什么要进行需求分析软件需求分析是软件开发的基础。在需求阶段修复一个错误的费用是编码阶段的1/5-1/10，是维护阶段修复费用的1/100-1/200，即设计错误的修复费用要远远高于编码错误的修复费用。通过“分析”，理解用户的各种需求，通过“规格说明”把需求表达出来。要求大家：（1）掌握具体的步骤和方法（2）提高分析问题和解决问题的能力（3）熟练运用一些图形工具基本概念目的澄清用户的各种需求基本任务（1）软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。（2）确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。（3）写出软件需求规格说明书，以书面形式准确地描述软件需求。结构化分析方法遵守的准则(1)必须理解并描述问题的信息域，根据这条准则应该建立数据模型。(2)必须定义软件应完成的功能，这条准则要求建立功能模型。(3)必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。需求：正在构建的系统必须符合的事务。需求管理：是一种获取、组织并记录系统需求的系统化方案以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程。传统需求分析：强调需求的记录，以一成不变的观点对待需求，不重视需求实现与维护。现代需求过程：包括需求的获取、分析、处理、验证、实现和全过程的需求管理。需求管理覆盖软件工程的整个过程。有关需求的概念需求管理存在的问题：范围问题：系统目标、边界未被良好定义，用户和开发团队理解不一致。理解问题：用户不能完全了解自己需要什么，对系统能力、局限更加不清楚；工程师不理解用户的问题域和应用环境。易变问题：需求随时间发生变化。3.1需求分析的任务

确定对系统的综合要求

功能需求性能需求可靠性和可用性需求出错处理需求接口需求约束逆向需求将来可能提出的要求3.1需求分析的任务

分析系统的数据要求

建立数据模型（实体—联系图）分析数据结构（层次方框图、Warnier图）规范数据结构（范式）

导出系统的逻辑模型

数据流图实体—联系图状态转换图数据字典主要的处理算法修正系统开发计划需求分析的过程（3）需求描述需求规格说明书初步的用户手册修改、完善与确定软件开发实施计划（4）需求验证系统定义的目标是否与用户的要求一致系统需求分析阶段提供的文档资料是否齐全文档中的所有描述是否完整、清晰、准确地反映用户要求与所有其它系统成分的重要接口是否都已经描述《用户需求说明书》与《软件需求规格说明书》的主要区别与联系：

前者主要采用自然语言和应用域语言来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求。软件需求规格说明书是软件系统设计的直接依据，软件开发人员应当依据《软件需求规格说明书》来开发产品。3.2需求获取的方法访谈面向数据流自顶向下求精简易的应用规格说明技术快速建立软件原型情景分析技术是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。系统分析人员利用情景分析技术往往能获知用户的具体需求。情景（场景）分析是从软件系统的一个交互情景示例中得到需求分析信息。情景分析中用户在某种程度上演示产品的应用“样本”，通过交互实例片断细节（情景）的描述，实现对某个目标产品的表述。每个情景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型的情景信息。

情景分析技术的用处：(1)它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。(2)由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。让用户起积极主动的作用对需求分析工作获得成功是至关重要的。

面向数据流自顶向下求精软件系统本质上是信息处理系统，基本功能是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，数据显然是需求分析的出发点。通过可行性研究已经得出了目标系统的高层数据流图，但当时许多实际的数据元素被忽略了，需求分析的目标之一就是把数据流和数据存储定义到元素级。示意图图3.1面向数据流自顶向下求精过程简易的应用规格说明技术是一种面向团队的需求收集法。访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。为此，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同分析问题，解决问题。分析需求的典型过程如下：1.初步访谈，准备会议首先进行初步的访谈，初步确定待解决的问题的范围和解决方案。然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举协调人。2.会前审查需求，确定列表要求每位与会者在开会的前几天认真审查产品需求，并且列出对象、操作这些对象或与这些对象交互的服务、约束条件和性能标准。3.会上讨论列表，创建组合列表每位与会者展示列表供大家讨论。大家共同创建一张组合列表。由协调人主持讨论这些列表。4.分组制定小型规格说明与会者分成更小的小组，为每张列表中的项目制定小型规格说明。每个小组都向全体与会者展示他们制定的小型规格说明，供大家讨论。5.制定确认标准，起草需求规格说明书每个与会者都制定出产品的一整套确认标准，并提交会议讨论，以创建出意见一致的确认标准。最后，起草完整的软件需求规格说明书。3.2.4快速建立软件原型快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。快速原型的特性：“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型。因此，原型的某些缺陷是可以忽略的。“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。如果修改耗时过多，势必延误软件开发时间。快速原型通常使用下述3种方法和工具：(1)第四代技术（4GL）第四代技术包括众多数据库查询（如SQL）和报表语言（如ADF）、程序和应用系统生成器（如PowerBuilder和Oracle的应用开发环境）以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，它们是较理想的快速原型工具。(2)可重用的软件构件另外一种快速构建原型的方法，是使用一组已有的软件构件(也称为组件)来装配(而不是从头构造)原型。软件构件可以是数据结构(或数据库)，或软件体系结构构件(即程序)，或过程构件(即模块)。(3)形式化规格说明和原型环境非形式化方法：自然语言描述半形式化方法：数据流图或实体-联系图形式化方法：基于数学的技术快速原型过程示意图短时间内建立原型用户满意修改，完善原型否是完成原型3.3分析建模与规格说明分析建模模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。分析建模是指通过抽象、概括和一般化的方法，把研究的具体对象或问题转化为本质相同的抽象对象或问题，从而加以解决。分析建模的目的是构造系统的详细逻辑模型。建模过程物理模型和逻辑模型物理模型：具体描述系统是如何在物理上实现的。逻辑模型：抽象描述系统的业务功能，不关心系统是如何实施的。分析建模过程示意(1)通过对现实环境的调查，获得当前系统的物理模型。分析建模过程示意

(2)去掉物理模型中的非本质因素，抽象出当前系统的逻辑模型。

分析建模过程示意

(3)分析当前系统与目标系统的差别，建立目标系统的逻辑模型。分析建模的方法结构化分析方法(SA)面向对象的分析方法(OOA)SA结构化分析方法（StructuredAnalysis，简称SA方法）是一种面向数据流自顶向下逐步求精进行需求分析的方法。这个方法通常与设计阶段的结构化设计方法（SD）衔接起来。自顶向下逐步求精体现了分解和抽象的原则，可以有控制地逐步实现更多的细节，所以SA方法有效地控制了复杂性。结构化分析方法示意图结构化分析方法中使用的建模工具：数据模型---实体-联系图功能模型---数据流图行为模型---状态转换图结构化分析模型的体系结构模型的核心是数据字典（DD），它描述了目标系统中所有的数据对象。数据流图（DFD）描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。实体-联系图（E-RD）描述数据对象及相互之间的关系，是用于建立数据模型的图形。状态转换图（STD）描述系统对外部事件如何响应，如何动作，是行为建模的基础。模型的外层是描述信息。在实体-关系图中出现的每个数据对象可以使用数据对象描述来描述。在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。软件控制方面的附加信息包含在控制规约中。各模型图说明软件需求规格说明通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。通常用自然语言或形式化方法描述。我国定义了GB856D-1988国家标准，给出了需求规格说明的内容框架：1引言

1.1编写目的

1.2项目背景（单位和其他系统的关系）

1.3定义（专门术语和缩写词）2任务概述

2.1目标

2.2运行环境

2.3条件限制3数据描述

3.1静态数据3.2动态数据3.3数据库描述3.4数据字典3.5数据采集4功能需求4.1功能划分4.2功能描述5性能需求5.1数据精确度5.2时间特性5.3适应性6运行需求6.1用户界面6.2硬件接口6.3软件接口6.4故障处理7其他需求（检测或验收标准、可用性、可维护性、可移植性、安全保密性）3.4实体-联系图为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型。概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，且与在软件系统中的实现方法无关。数据模型中包含3种相互关联的信息：数据对象数据对象的属性数据对象彼此间相互连接的关系3.4实体-联系图数据对象数据对象是指具有一系列不同性质或属性的事物，仅有单个值的事物(例如，宽度)不是数据对象。数据对象可以是现实世界的人、物、抽象的概念、事物之间的联系等。数据对象可以是外部实体（例如产生或使用信息的任何事物）、事物（如报表）、行为（如打电话）、事件（如响警报）、角色（如教师、学生）、单位（如会计科）、地点（如仓库）等总之，可以由一组属性来定义的实体都可以被认为是数据对象。3.4实体-联系图2．属性“属性”定义了数据对象的性质。属性是对实体的进一步描述。如学生实体可由学号、姓名、年龄、性别、学院、年级等属性来刻画。(属性有属性名和属性值的概念)。例如，汽车属性有品牌、型号、发动机号码、车体类型、颜色、生产日期等3.4实体-联系图3．联系现实世界里的事物总是存在着这样或那样的联系，这种联系必然要在信息世界中得到反映。在信息世界中，事物之间的联系可分为两类：一是实体内部的联系，如组成实体的各属性之间的关系；另一是实体之间的联系，这里我们主要讨论实体与实体之间的联系。实体彼此间的联系分为三类：一对一（1:1）联系，一对多（1:N）联系，多对多（M:N）联系。

一对一联系（1∶1）

如果对于A中的每一个实体，B中至多有一个实体与其对应；B中的每一个实体也至多对应A中的一个实体，则称A与B是一对一的，记作1:1。比如：学校校长领导11工厂厂长管理11科室主任病区负责11属性1属性n属性1属性n校名属性n属性1校址姓名职称属性1属性n属性1属性n属性1属性n属性1属性n一对多联系（1∶N）

如果对于A中的一个实体，B中有一个以上的实体与之对应；B中的每一个实体至多对应A中的一个实体，则称A与B是一对多的，记作1:n。比如：学校班级下设1n工厂车间有1n病区医生拥有1n属性1属性n属性1属性n属性1属性n校名校址属性1属性n属性1属性n班名人数属性1属性n属性1属性n多对多联系（M∶N）如果A中有实体对应B中一个以上实体；B中也有实体对应A中一个以上实体，则称A与B为多对多的，记作m:n。比如：

学生课程选课mn项目职工参加mn医生病人诊治mn成绩属性1属性n记录学号姓名属性1属性n属性1属性n课程号课程名属性1属性n属性1属性n3.4.4实体—联系图的符号通常，使用实体-联系图(entity-relationshipdiagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。ER图中包含了实体(即数据对象)、关系和属性3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。比较接近人的习惯思维方式；用简单的图形符号表达系统分析员对问题域的理解，用户也容易理解，可以作为用户与分析员之间有效的交流工具。数据建模工具：以自动化的方式创建ER图、数据字典及相关模型。PowerDesigner是Sybase公司的CASE工具集,几乎包括了数据库模型设计的全过程.ERDesignerNG是一个实体关系建模工具，开源

ModelRight3是一款数据库开发、支持、转换工具OracleDesigner建模、应用系统和数据库设计OpenSystemArchitect开源数据库建模软件ER图的优点：如何设计E-R图考察客观事物及其联系，抽象出实体，并一一命名(不能重名)根据需求确定实体的属性根据属性外在的联系，描述实体间的联系先作出局部E-R图，再综合产生总体E-R图。总体E-R图不是各局部E-R图的简单拼合，而是有可能增加了某些联系，也有可能减少了某些联系

实例1一个学生管理系统的实体-联系图【步骤】（1）考察客观事物及其联系，抽象出实体，并一一命名(不能重名)实体：教师，学生，课程（2）根据需求确定实体的属性教师：教工号，姓名，性别，职称，职务学生：学号，姓名，性别，系，年级课程：课程号，课名，学时，学分例1：（3）根据属性外在的联系，描述实体间的联系

教：教师教课程

学：学生学课程（4）画出E-R图例2：习题3.3银行储蓄系统的ER图银行计算机储蓄系统的工作过程大致如下：储户填写的存款单或取款单由业务员键入系统，如果是存款则系统记录存款人姓名、住址(或电话号码)、身份证号码、存款类型、存款日期、到期日期、利率及密码(可选)等信息，并印出存单给储户；如果是取款而且存款时留有密码，则系统首先核对储户密码，若密码正确或存款时未留密码，则系统计算利息并印出利息清单给储户。例2：银行储蓄系统的ER图ER图练习题：请为某仓库的管理设计一个ER模型。该仓库主要管理零件（包括零件编号、名称、颜色、重量）的定购和供应等事项。仓库向工程项目（包括项目编号、项目名称、开工日期）供应零件，并且根据需要向供应商（包括供应商编号、名称、地址）定购零件。仓库管理系统的ER图3.5数据规范化软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。范式通常用“范式(normalforms)”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)数据冗余程度最小。范式级别越高，存储同样数据需要分解成更多张表，因此，“存储自身”过程越复杂。随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。范式级别提高则需要访问的表增多，因此性能(速度)将下降。从实用角度来看，在大多数场合选用第三范式都比较恰当。第一范式，每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。第二范式，满足第一范式条件，而且每个非关键字属性都由整个关键字决定(而不是由关键字的一部分来决定)。第三范式，符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。下面以一个学校的学生系统为例分析说明，假设数据库中包括如下信息：学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话等信息。首先我们考虑，把所有这些信息放到一个表中，因此不满足第二范式的要求，会产生如下问题：数据冗余：同一门课程由n个学生选修，学分重复n-1次；同一个学生选修m门课程，姓名和年龄就重复m-1次。更新异常：

1）若调整了某门课程的学分，数据表中所有行的“学分”值都要更新，否则会出现同一门课程学分不同的情况。

2）假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有“学号”关键字，课程名称和学分也无法记录入数据库。删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。解决方案，改为如下三个表：学生：Student（学号，姓名，年龄，性别，系别，系办地址、系办电话）；课程：Course（课程名称,学分）；选课关系：SelectCourse（学号，课程名称，成绩）。3.6状态转换图是通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。

状态模型一般采用状态转换图（状态图）表示，状态图提供了行为建模机制。

状态1状态2事件/触发行为3.6.1状态状态：是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。状态主要有：初态(即初始状态)，只能有1个终态(即最终状态)，可以有0至多个中间状态状态图分类：表示系统循环运行过程，通常不关心循环是怎样启动的。表示系统单程生命期，需要标明初始状态和最终状态。3.6.2

事件事件：是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。简而言之，事件就是引起系统做动作或(和)转换状态的控制信息。3.6.3符号初态：用实心圆表示；终态：用一对同心圆(内圆为实心圆)表示；中间状态：用圆角矩形表示，分成上、中、下3部分。上面部分-----为状态的名称；中间部分-----为状态变量的名字和值；下面部分-----是活动表。带箭头的连线：称为状态转换，箭头指明了转换方向。3.6.4例子例1：电话系统例3：银行储蓄系统——存款过程的状态图例3：银行储蓄系统——取款过程的状态图

状态图练习题：习题3.6

复印机的工作过程大致如下：未接到复印命令时处于闲置状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲置状态，等待下一个复印命令；如果执行复印命令时发现没纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲置状态，准备接收复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告等待维修人员来排除故障，故障排除后回到闲置状态。3.7其他图形工具

3.7.1层次方框图层次方框图：用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构；下面的各层矩形框代表这个数据的子集；最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。某计算机公司的全部产品的层次方框图3.7.2Warnier图Warnier图：和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。特点：用Warnier图可以表明信息的逻辑组织，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。软件产品的Warnier图3.7.3IPO图IPO图：是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。基本形式：是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。图3.7IPO图的一个例子图IPO图改进的IPO图：这种图中包含某些附加的信息，在软件设计过程中将比原始的IPO图更有用。在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。改进的IPO改进IPO示例IPO表系统：定货系统作者：祁燕模块：处理事务日期：2010.3编号：1.0被调用：定货系统调用：接受事务更新库存清单处理定货输入：事务输出：定货信息

库存清单处理：（用过程描述工具描述本模块的算法，如PAD图、N-S图、伪代码等）局部数据元素：注释：3.8验证软件需求

3.8.1从哪些方面验证软件需求的正确性一致性，所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。完整性，需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。现实性，指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。有效性，必须证明需求是正确有效的，确实能解决用户面对的问题。3.8.2验证软件需求的方法1.验证需求的一致性人工技术审查形式化的描述软件需求的方法2.验证需求的现实性仿真或性能模拟技术3.验证需求的完整性和有效性开发原型系统3.8.3用于需求分析的软件工具软件工具应该满足下列要求：必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；使用这个软件工具能够导出详细的文档；必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；使用这个软件工具之后，应该能够改进通信状况。用结构化分析方法分析图书馆系统

【问题描述】 ①一个图书馆藏有图书和期刊杂志两大类书籍，每种图书/杂志可以有多册。 ②图书馆可以维护（注册、更新和删除）图书资料。 ③图书馆管理员负责与借书者打交道。 ④借书者可以预约目前借不到的书或杂志。 ⑤所有人员都可以浏览图书馆的图书信息和各种告示。 ⑥系统能在流行的技术环境下运行，有一个良好的图形交互界面。 ⑦系统应具有良好的可扩展性。

【功能分析】①浏览功能：所有人员都可以浏览图书馆的图书信息。 ②借还功能：借书者可以借/续借、还、预约图书。 ③图书管理功能：图书管理人员可以做录入、更新和销毁等图书信息维护工作。 ④借书者管理：系统管理人员可以进行注册、更改、注销借书者信息等维护工作。【建立数据流图】

分析图书馆系统有哪些外部用户，即角色。图书馆系统主要有一般浏览者、借书者、一般管理员和系统管理员四类外部用户。浏览者浏览图书图书馆系统的基本逻辑模型图书信息浏览命令【借/还功能数据流图】

借/还功能（第一步）DFD