基于新信息技术的软件工程与UML教程(第二版) 课件 项目三 需求分析

项目三需求分析任务一认识需求分析任务二熟悉需求分析图形工具任务三掌握结构化分析技术任务四编写文档

任务一认识需求分析

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

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

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

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

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

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

一、需求分析概述

需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约(需求规格说明)的过程。需求分析虽处于软件开发过程的开始阶段，但它对于整个软件开发过程以及软件产品质量是至关重要的。在计算机发展的早期，所求解问题的规模小，需求分析容易被忽视。

1.需求分析的难点

难点主要体现在以下几个方面：

(1)问题的复杂性。

(2)交流障碍。

(3)不完备性和不一致性。

(4)需求易变性。

2.需求分析的基本原则

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

(2)可以把一个复杂问题按功能进行分解并可逐层细化。

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

结构化分析方法和面向对象分析方法都遵循以上原则。

3．需求分析的任务

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

1)确定系统的综合需求

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

2)分析系统的数据要求

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

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

3)导出系统的逻辑模型

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

4)修正系统开发计划

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

5)开发原型系统

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

4．需求分析的步骤

1)问题识别

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

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

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

分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细分软件功能，划分成各个子功能。

3)编写文档

编写文档的步骤如下：

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

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

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

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

4)需求评审

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

二、需求分析方法

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

图3-2需求分析的过程

1．功能分解方法

功能分解方法是将一个系统看成是由若干功能构成的一个集合，每个功能又可划分成若干个加工(即子功能)，一个加工又进一步分解成若干加工步骤(即子加工)。因此，功能分解方法有功能、子功能和功能接口三个组成要素。它的关键策略是利用已有的经验，对一个新系统预先设定加工和加工步骤，着眼点放在这个新系统需要进行什么样的加工上。

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

2．结构化分析方法

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

该方法的一个难点是确定数据流之间的变换，而且数据词典的规模也是一个问题，它会引起所谓的“数据词典爆炸”，同时对数据结构的强调很少。

3．信息建模方法

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

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.绘制数据流图的注意事项

(1)命名。

(2)编号。

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

(4)画数据流而不是控制流。

(5)父图与子图的平衡。

(6)局部数据存储。

(7)可理解性。

二、数据字典

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

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

1．数据字典的内容

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

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

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

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

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

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

2．定义数据的方法

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

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

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

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

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

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

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

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

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

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

“{ }”：重复；

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

3．实例

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

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

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

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

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

加工的数据字典如表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-6中活动表的语法格式为：事件名(参数表)/动作表达式。

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

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

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

4．例子

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

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

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

任务三掌握结构化分析技术

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

模型一般由一组图示符号和组织这些符号的规则组成。因此，分析时期的建模，就是针对用户需求、系统需求等，采用图示方式进行直观描述。软件问题往往是复杂的，而建模可以使问题简化。人的头脑每次只能处理一定数量的信息，模型通过把系统分解成人的头脑一次能处理的若干个子部分，从而减少系统的复杂程度。分析时期建立软件模型的作用是多方面的，可以通过模型实现由用户需求向系统需求的过渡，并可通过模型获得对系统需求的更具细节性的推论。实际上，分析时期产生的模型还可以被引用到系统设计中去，作为设计前导。

二、实例分析

在对教务管理信息系统调研阶段的业务流程图进行分析的基础上，从系统的科学性、管理的合理性、实际运行的可行性等角度出发，将信息处理功能和彼此之间的联系自顶向下、逐层分解，从逻辑上精确地描述