基于新信息技术的软件工程与UML教程课件：需求分析

需求分析任务一认识需求分析任务二需求分析图形工具任务三结构化分析技术任务四编写文档习题

项目引导

本项目主要对软件进行需求分析的任务步骤、所用到的图形工具，重点介绍结构化分析技术。

知识目标

(1)了解需求分析的任务、方法和过程。

(2)掌握需求分析图形工具。

(3)掌握结构化分析方法。

(4)会编写需求规格说明书。

能力目标

会对小型软件进行需求分析，并建立逻辑模型，书写需求规格说明书。

任务一认识需求分析

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。它的基本任务是准确地回答“系统必须做什么?”这个问题。

在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。用户不知道怎样用软件实现自己的需求，因此，用户必须把他们对软件的需求尽量准确、具体地描述出来；分析员对用户的需求并不十分清楚，必须通过与用户沟通获取用户对软件的需求。

需求分析和规格说明是一项十分艰巨且复杂的工作。不仅在整个需求分析过程中应采用行之有效的通信技术，而且必须严格审查、验证需求分析的结果。

目前，有很多用于需求分析的结构化分析方法，所有这些分析方法都遵守下述准则：

(1)必须理解并描述问题的信息域(建立数据模型)。

(2)必须定义软件应完成的功能(建立功能模型)。

(3)必须描述作为外部事件结果的软件行为(建立行为模型)。

(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

一、需求分析概述

需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约(需求规格说明)的过程。

随着软件系统复杂性的提高及规模的扩大，需求分析在软件开发中所处的地位愈加突出，从而也愈加困难，它的难点主要体现在以下几个方面：

(1)问题的复杂性。这是由用户需求所涉及的因素繁多引起的，如运行环境和系统功能等。

(2)交流障碍。需求分析涉及人员较多，如软件系统用户、问题领域专家、需求工程师和项目管理员等，这些人具备不同的背景知识，处于不同的角度，扮演不同的角色，造成了相互之间交流的困难。

(3)不完备性和不一致性。由于各种原因，用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着矛盾，需求分析要消除其矛盾，形成完备及一致的定义。

(4)需求易变性。用户需求的变动是一个极为普遍的问题，即使是部分变动，也往往会影响到需求分析的全部，导致不一致性和不完备性。

近几年来已提出许多软件需求分析与说明的方法(如结构化分析方法和面向对象分析方法)，每一种分析方法都有独特的观点和表示法，但都适用下面的基本原则：

(1)必须能够表达和理解问题的数据域和功能域。数据域包括数据流(即数据通过一个系统时的变化方式)数据内容和数据结构，而功能域反映上述三方面的控制信息。

(2)可以把一个复杂问题按功能进行分解并可逐层细化。通常软件要处理的问题如果太大太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体功能。

(3)建模。模型可以帮助分析人员更好地理解软件系统的信息、功能和行为，这些模型也是软件设计的基础。

1．需求分析的任务

软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。在可行性研究和项目开发计划阶段对这个问题的回答是概括的、粗略的。

1)确定系统的综合需求

系统分析员和用户共同确定对问题综合需求。表3-1给出了综合需求的类别、定义和相关举例，其中最重要的是功能需求，其应确定系统必须完成的所有功能。在确定功能需求的基础上，还应根据组织机构和使用用户的具体情况，确定系统在性能、运行等方面的一系列需求。

2)分析系统的数据要求

任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法。

软件系统复杂的数据由许多基本的数据元素组成，数据元素之间的逻辑关系用数据结构来表示。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。

3)导出系统的逻辑模型

综合上述两项分析结果可以导出系统详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

4)修正系统开发计划

根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统开发的成本和进度，修正以前制定的开发计划。

5)开发原型系统

快速原型系统核心思想是：在软件开发的早期快速建立目标软件的原型，让用户对原型进行评估并提出修改意见，当原型几经改进最终确定后，它将由软件设计和编码阶段进化成软件产品；或者设计和编码人员遵循原型所确立的外部特征实现软件产品。

2．需求分析的步骤

1)问题识别

问题识别是指从系统的角度来理解软件并评审软件范围是否恰当，确定对目标系统的综合要求，即软件的需求，提出这些需求实现条件，以及需求应达到的标准。问题识别的另一项工作是建立分析所需要的通信途径(如图3-1所示)，以保证能顺利地对问题进行分析。

图3-1问题识别的通信途径

2)分析与综合，导出软件的逻辑模型

分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细分软件功能，划分成各个子功能。这里也包括对数据域进行分解，并分配到各个子功能上，以确定系统的构成及主要成分，并用图文结合的形式，建立起新系统的逻辑模型。

3)编写文档

编写文档的步骤如下：

(1)编写“需求说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。

(2)编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的角度考虑软件。

(3)编写确认测试计划，作为今后确认和验收的依据。

(4)修改完善项目开发计划。在需求分析阶段对开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。

4)需求评审

需求评审的内容包括：系统定义的目标是否与用户的要求一致；系统需求分析阶段提供的文档资料是否齐全；文档中的所有描述是否完整、清晰、准确反映用户要求；与所有其他系统成分的重要接口是否都已经描述；被开发项目的数据流与数据结构是否足够确定；所有图表是否清楚，在不补充说明时能否被理解；主要功能是否已包括在规定的软件范围之内，是否都已充分说明；设计的约束条件或限制条件是否符合实际；开发的技术风险是什么；是否考虑过软件需求的其他方案；是否考虑过将来可能会提出的软件需求；是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。

二、需求分析方法

需求分析的过程如图3-2所示。需求分析方法有功能分解方法、结构化分析方法、信息建模方法和面向对象分析方法等。

图3-2需求分析的过程

1．功能分解方法

功能分解方法是将一个系统看成是由若干功能构成的一个集合，每个功能又可划分成若干个加工(即子功能)，一个加工又进一步分解成若干加工步骤(即子加工)。

能分解方法本质上是用过程抽象的观点来看待系统需求，符合传统程序设计人员的思维特征，而且分解的结果一般已经是系统程序结构的一个雏形，实际上它已经很难与软件设计明确分离。

这种方法存在一些问题，它需要人工来完成从问题空间到功能和子功能的映射，即没有显式地将问题空间表现出来，也无法对表现的准确程度进行验证，而问题空间中的一些重要细节更是无法提示出来。可以看出，功能分解方法缺乏对客观世界中相对稳定的实体结构进行描述，而将基点放在相对不稳定的实体行为上，因此，基点是不稳定的，难以适应需求的变化。

2．结构化分析方法

结构化分析方法(StructuredMethod)是一种软件开发方法，一般利用图形表达用户需求，强调开发方法的结构合理性以及所开发软件的结构合理性。结构化分析方法是一种从问题空间到某种表示的映射方法，它由数据流图表示，是结构化重要的、被普遍接受的表示系统，它由数据流图和数据词典构成。这种方法简单实用，适于数据处理领域。

该方法沿现实世界中的数据流进行分析，把数据流映射到分析结果中。但现实世界中的有些要求不是以数据流为主干的，就难于用此方法。如果分析是在现有系统的基础上进行的，应先除去原来物理上的特性，增加新的逻辑要求，再追加新的物理上的考虑，这时，分析面对的并不是问题空间本身，而是过去对问题空间的某一映射，在这种焦点已经错位的前提下进行分析显然是十分困难的。

3．信息建模方法

信息建模方法是从数据的角度来对现实世界建立模型的，它对问题空间的认识是很有帮助的。该方法的基本工具是ER图(实体联系图)，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实世界中找出实体，然后再用属性来描述这些实体。

信息模型和语义数据模型是紧密相关的，有时被看做是数据库模型。在信息模型中，实体E是一个对象或一组对象，实体把信息收集在其中，关系R是实体之间的联系或交互作用，有时在实体和关系之外，再加上属性。实体和关系形成一个网络，描述系统的信息状况，给出系统的信息模型。

4．面向对象分析方法

面向对象分析方法是把ER图中的概念与面向对象程序设计语言中的主要概念结合在一起而形成的一种分析方法。在该方法中采用了实体、关系和属性等信息模型分析中的概念，同时采用了封闭、类结构和继承性等面向对象程序设计语言中的概念。

三、需求获取方法

1．访谈

访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。

访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。

在访问用户的过程中往往使用情景分析技术。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。该技术非常有效，主要体现在下述两个方面：

(1)它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。

(2)由于情景分析较易为用户所理解，使用户在需求分析过程中始终扮演一个积极主动的角色，以获得更多的用户需求。

2．面向数据流自顶向下求精

软件系统的基本功能都是把输入数据转变成需要的输出数据，从本质看，数据决定了系统的处理和算法，因而，数据是需求分析的出发点。结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

通常把自顶向下逐步求精分析过程中得到的相关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO(输入—处理—输出)图中。经过分析而补充的数据流、数据存储和处理，也应该添加到数据流图的适当位置上。

通过用户对数据流的复查与验证，可补充未知的数据元素，或修正原有的数据元素。

通过自顶向下逐步求精的功能分解，可以完成数据流图的细化。

反复进行上述分析过程，分析员将越来越深入具体地定义目标系统，最终达到对系统数据和功能要求的满意了解。图3-3粗略地概括了上述分析过程。

图3-3自顶向下逐步求精分析过程

3．快速建立软件原型

快速建立软件原型是最准确、最有效、最强大以需求分析技术。

快速原型就是根据用户需求，快速建立起可运行的目标系统。其要点是：它应该实现用户看得见的功能(如：屏幕显示或打印报表)，省略“隐含”的功能(如：修改文件)。

快速原型应该具备以下特性：

(1)快速。目的是尽快向用户提供一个可在计算机上运行的目标系统模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。

(2)容易修改。根据用户的意见迅速地修改，以便满足用户需求。原型的修改是“修改—试用—反馈”过程。

为了快速地构建和修改原型，通常使用下述三种方法和工具：

(1)第四代技术。第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。

(2)可重用的软件构件。快速构建原型的另一种方法，是使用一组已有的软件构件(也称为组件)来装配(而不是从头构造)原型。软件构件可以是数据结构(或数据库)，或软件体系结构构件(即程序)，或过程构件(即模块)。

(3)形式化规格说明和原型环境。

任务二需求分析图形工具

一、数据流图数据流图(DataFlowDiagram，DFD)从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

基本概念和符号

1.数据流图有四种基本符号，如表3-2所示。

注意，数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。

2．绘制数据流图的步骤

画数据流图有以下两步：

(1)首先画系统的输入/输出，即先画顶层数据流图。

(2)绘制系统内部，即画下层数据流图。一般将层号从0开始编号，采用自顶向下、由外向内的原则。

(3)注意事项如下：

①命名；

②编号；

③每个处理(加工)至少有一个输入和输出数据流；

④画数据流而不是控制流；

⑤父图与子图的平衡；

⑥局部数据存储；

⑦可理解性。

(4)命名。数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。在命名时应注意，为数据流(或数据存储)命名时，名字应代表整个数据流(或数据存储)的内容，使人容易理解其含义。如库存信息、订货报表等。为处理命名时，名字应该反映整个处理的功能。如处理订货、产生报表等。

二、数据字典

数据字典(Datadictionary)是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明，使用数据字典为简单的建模项目。简而言之，数据字典是描述数据信息的集合，是对系统中使用的所有数据元素定义的集合。

数据流图和数据字典共同构成系统的逻辑模型，没有数据字典，数据流图就不严格；然而没有数据流图，数据字典也难以发挥作用。

数据字典的作用是给数据流程图上每个成分加以定义和说明。换句话说，数据流程图只能给出系统逻辑功能的一个总框架，而缺乏详细、具体的内容。数据字典对数据流程图的各种成分起注解、说明作用，给这些成分赋予实际的内容。除此以下，数据字典还要对系统分析中其他需要说明的问题进行定义和说明。

1．数据字典的内容

数据字典的内容包括五个方面：数据流、数据存储、数据元素、外部项、加工。其中，数据元素是组成数据流的基本成分。

数据流：由一个或一组固定的数据元素组成。定义数据流时，不仅要说明数据流的名称、组成等，还应指明它的来源、去向和流通量等。

数据存储：是数据结构停留的场所。数据存储只是描述数据的逻辑存储的结构，不涉及物理组织。通常包括编号、名称、简述、组成、关键字和相关联的处理等。

数据元素：又称为数据项，是数据的最小单位。数据应从静态及动态两个方面去分析。在数据字典中，主要是对数据的静态特性加以定义。

外部项：包括外部项名称、编号、简述及有关数据流的输入和输出。

加工：是对数据流程图中最底层的处理逻辑加以说明，内容包括加工名称、简述、输入、处理过程、输出和处理频率。

2．定义数据的方法

数据字典中的定义就是对数据自顶向下的分解，应把数据分解到什么程度，一般以其含义清楚作为标准。

由数据项(元素)组成数据的方式有四种类型：

(1)顺序：以确定次序连接两个或多个分量；

(2)选择：从两个或多个可能的元素中选择一个；

(3)重复：指定的分量重复零次或多个；

(4)可选：一个分量是可有可无的。

数据字典中常用的一些符号如下：

“＝”：等价于(定义为)；

“＋”：和(连接两个分量)；

“[ ]”：或(选其中之一)；

“{ }”：重复；

“( )”：可选(可有可无)。

3．实例

以下列出本系统部分主要数据流、数据元素、数据存储及加工的数据字典。

(1)数据流的数据字典(如表3-3所示)。

(2)数据存储的数据字典(如表3-4所示)。

(3)数据元素的数据字典(如表3-5所示)。

(4)外部项的数据字典(如表3-6所示)。

(5)加工的数据字典(如表3-7所示)。

三、实体联系图

为了清楚、准确地描述用户对数据的要求，分析员通常建立一个概念性的数据模型(也称信息模型)—实体—联系模型(Entity-RelationshipModel，E-R模型)，它是一种面向问题的数据模型，是按用户的观点对数据建立的模型。

1．基本概念和符号

数据模型包含3种信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。

1)数据对象(实体)

数据对象是对软件的复合信息的抽象，它是指具有一系列不同性质或属性的事物，仅有单个值的事物(如宽度)不是数据对象。

2)属性

属性是数据对象或联系所具有的性质。一个数据对象通常由若干个属性来刻画，如：学生有学号、姓名、性别、系、年级等。联系也可能有属性，如学生“学”某门课程。

3)联系

联系是数据对象彼此之间相互连接的方式，也称为关系。联系分为3种类型：

(1)一对一联系(1∶1)，如：一个部门有一个经理。

(2)一对多联系(1∶N)，如：教师与课程。

(3)多对多联系(M∶N)，如：学生与课程。

4)实体-联系图(Entity-Relationshipdiagram，E-R图)的符号

通常用矩形框代表实体，菱形框表示联系，用椭圆形或圆角矩形表示实体(或关系)的属性，如图3-4所示。

图3-4实体联系图的符号

2．E-R图实例

数据库设计中十分重视数据分析、抽象与概念结构的设计，概念结构的设计是整个数据库设计的关键。用于描述概念结构模型的工具是E-R模型。需求分析采用自顶向下的结构设计方法，而概念结构设计通常采用自底向上的设计方法，这种方法是首先定义各局部应用的概念结构，然后将他们集成，得到全局的概念结构，即从需求分析的数据流(DFD)、数据字典DD概念结构设计中的分E-R图总E-R图。

概念模型的特点：是对现实世界的抽象和概括；简洁、明晰、独立于机器，很容易理解；易于更动；容易向关系、网状、层次等各种数据模型转换。

概念模型最常用的表示方法是实体—联系方法。以某中学的教务管理信息系统为例，按照数据库的概念设计本系统的E-R图(见图3-5)。

图3-5教务管理信息系统的实体联系图

四、状态转换图

状态转换图简称状态图，是描述行为模型的常用工具。它通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了事件将做的动作(如处理数据)。因此，状态图提供了在需求分析过程中建立软件系统的行为模型的机制。

1．状态

状态是系统行为模式，一个状态代表系统的一种行为模式。

状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。

在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态)和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。

2．事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象，是一种控制信息，没有持续时间，是瞬间完成的。

例如，敲击键盘或点击鼠标等都是事件。

3．符号

初态用实心圆表示：· 。

终态用一对同心圆(内圆为实心圆)表示：⊙。

中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，是必须有的；中间部分为状态变量的名字和值，是可选的；下面部分是活动表，是可选的。

状态转换图如图3-6所示。

图3-6状态转换图

其中活动表的语法格式为：事件名(参数表)/动作表达式。

在活动表中经常使用3种标准事件：entry，exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。

状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，因此，在箭头线上要标出触发状态转换的事件表达式。如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。

事件表达式的语法为：事件说明［守卫条件］/ 动作表达式。

其中，事件说明的语法为：事件名(参数表)。

守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。

动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

4．例子

打电话时的系统状态图如图3-7所示。

图3-7电话系统的状态转换图

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

任务三结构化分析技术

一、结构化分析技术人在求解问题时，首要需要做的是理解问题，并且对问题理解得越透彻，这个问题就越容易解决。所谓模型，就是为了理解问题而对问题做的一种符号抽象。可以把模型看作为一种思维工具，利用这种工具可以把问题规范地表示出来。

为了开发复杂的软件系统，往往需要从不同角度去构造系统模型。例如：用于描述系统功能组织结构的层次模型，用于描述系统中数据加工流程的数据流模型，用于描述数据实体及其关系的数据关系模型，用于描述系统行为过程的系统状态模型等。

结构化分析方法适合于数据处理类型软件的需求分析。具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。

二、实例分析

在对教务管理系统调研阶段的业务流程图进行分析的基础上，从系统的科学性、管理的合理性、实际运行的可行性等角度出发，将信息处理功能和彼此之间的联系自顶向下、逐层分解，从逻辑上精确地描述新系统应具有的数据加工功能和数据输入、数据存储、数据来源、去向和外部项。

绘制数据流程图应遵循的原则如下：

(1)确定