2.1 需求分析
考点1 需求分析的概念与意义
（1）概念
需求分析工作是通过对需求的调查、了解、观察和分析，采用已证实是有效的技术、方法或工具，对原始资料进行加工整理，得到有关目标系统需要实现的功能及其相互关系等一系列活动的集合。
（2）意义
需求分析的目标是以使用者和开发人员都容易理解的文档形式提供一个关于目标系统所完成的全部功能及性能等需求的完整描述，以保证目标系统后续阶段工作的顺利完成，为最终开发出一个满意度高的系统打下基础。
（3）难度
①软件功能复杂
用户难以在项目初期就详尽地表述清楚目标系统的全部功能。
②需求的可变性
用户在项目初期往往对项目的完整需求不明确。
③软件产品的不可见性
不可见性是指软件的功能性能指标是在一定的硬件环境中通过操作运行体现，因此用户通常只能在软件产品的投入使用过程中才能进一步发现还需要实现某种功能。
（4）任务
①分析当前系统的业务流程，包括系统的体系结构，各职能部门完成的主要任务，各职能部门之间的关系及其交流的信息。
②分析现行系统存在的问题，包括亟待解决的问题。
③在对现行系统充分分析的基础上确定待开发系统的目标、实现的功能及接口、待开发系统对性能和安全性等方面的要求。
（5）结果表示
①通常以模型形式表示，并把描述系统功能的这类模型称为功能模型。
②需要编写需求规格说明书对待开发系统的目标、功能、约束、开发技术和数据库管理系统的选型等给出书面详尽的说明。
（6）要求
需求描述要准确、清楚、一致，不存在任何不完全、含混或者二义性的描述。
（7）参与者
通常需求分析工作是在系统分析人员与用户不断交互的过程中完成的。
考点2 需求获取的方法
（1）面谈
面谈是获取需求最基本的方法。系统分析员需要在面谈前准备好相关问题，然后深入到部门，找到相关的业务人员面谈，获取业务流程、各流程之间的关系和用户对系统的期望及要求等细节信息。
（2）实地观察
在实际观察过程中，分析人员要注意考虑到处理效率的问题，分析和考察原有业务流程和操作过程的合理性。
（3）问卷调查
建模人员把需要了解和调查的内容编制成表格交给用户填写，从用户返回的结果中获取对提出的问题较为准确且详细的回答。但是问卷形式缺乏交互性，对调查表的问题和格式的设计要求较高。
（4）查阅资料
建模人员需要注意收集和查阅相关的文献资料。
考点3 需求分析过程
（1）标识问题
①定义
标识问题是指通过对问题的识别和标识获得对所求解问题及其运行环境进行全面细致的分析和理解。
②内容
a．理解现行系统的业务流程、现行流程存在的问题及需要改进的方面。
b．确定系统的人机界面，即手工处理和计算机处理相衔接的部分。系统分析员要清楚地界定计算机不能承担的工作，并向用户说明理由且描述清楚计算机不能承担部分的人机接口的实现方法。
c．在问题识别过程中对原始数据建立模型，记录用户需求和梳理问题，同时可以帮助系统分析员发现需求中的不一致性，排除不合理的部分。
（2）建立需求模型
借助模型或者抽象方法，把复杂的事物简化，便于系统分析员及建模人员认识和分析复杂的事物，有利于理解需求、梳理需求。
（3）描述需求
①需求描述的类型
需求描述包括对应用信息系统或软件项目的功能性需求和非功能性需求的描述。
a．功能性需求即常说的数据处理要求。通常，应用信息系统或软件所有功能模块描述的集合就是系统的功能需求。
b．非功能性需求的描述通常指信息系统或软件项目对实际运行环境的要求。非功能性需求不仅与软件开发周期各阶段的工作有关，还与系统软硬件环境、软件系统的容错性、软件的质量和分布式应用环境下系统之间的互操作性等因素有关。
②定义
需求描述精确地定义和说明了系统做什么以及交付的目标产品的约束条件，为软件生命周期中后续的活动提供了工作的依据和蓝图，是项目开发方和使用者或用户方的一个约定，也是项目后期审核和验收的依据。
③内容
需求描述主要由需求模型（系统功能模型）和软件需求说明书组成。
a．系统功能模型，通常采用一些流行的建模方法如DFD等构建；
b．软件需求说明书，侧重文字说明，主要内容包括以下六个方面：
第一，需求概述
概要描述软件项目的研发背景及意义，现行系统的运行、管理及经营的方式、特点及状况、存在的问题和亟待解决的问题等，是对目标系统的总体描述。
第二，功能需求
详细描述系统的总体结构及功能，系统覆盖的功能范围。
第三，信息需求
完整描述系统涉及的信息范围、数据的属性特征、数据之间的关系及约束。
第四，性能需求
对系统的性能要求。
第五，环境要求
对系统运行环境的要求。
第六，其他需求
需求描述中还应该包含对目标系统检测或验收方面的要求。
④需求分析要解决的问题
a．系统的主要功能；
b．需求是否为全部需求；
c．确保需求的正确性；
d．确保需求的可行性和可操作性；
e．需求是否都是客户需要的；
f．消除重复或不完整甚至是模糊的需求。
⑤需求分析的结果
形成需求分析文档，为软件生命周期后续阶段工作提供依据。
（4）确认需求
①目的
进一步检查确信需求说明书中不包含任何不一致和含糊的内容，进一步证实需求说明书描述的内容是客户所期望和需要的。
②参与人员
需求的确认和评审工作由评审组或评审委员会完成。评审委员会的成员由项目负责人聘请的专家、分析人员、相关人员及用户组成。评审过程也将使得用户和设计人员对需求有进一步的理解、沟通且达成一致。
③评审内容
a．功能需求
审查需求模型所描述的内容是否与需求说明书中说明的相关内容一致，需求说明中描述的对待开发系统的功能要求是否满足使用要求，处理功能之间的关系及交换信息的方式是否合理。
b．数据需求
审查数据需求是否满足需求。
c．性能
审查系统的性能是否满足需求。
d．数据管理
根据系统存储和管理的关系表、记录规模和可预见的增长量，审查需求分析及相关描述是否合理，是否满足数据存储和管理的要求。
e．其他需求
审查安全性、可操作性，可维护性、可扩充性，以及运行环境等方面的分析、设想及软硬件方面的选型是否合理且满足需求。
【真题演练】
下列不属于需求建模内容的是（ ）。
A．分析与描述目标系统需要完成的功能 √
B．分析与描述每项功能活动需要的输入数据、业务规则和输出数据 √
C．分析与描述目标系统涉及的数据范围、数据属性及数据之间的联系 ×
D．分析与描述目标系统的总体结构、功能活动及各活动间的联系 √
【答案】C，需求分析最大的特点就是根据需求进行分析，对内部的深入不需要涉及
2.2 需求分析方法
考点1 需求分析方法概述
目前在信息系统的需求分析中广为使用的结构化分析与功能建模方法主要有DFD、IDEFO等。
（1）结构化分析方法的基本特征
①抽象
抽象是一种手段，用抽象方法把一个个具体事物或问题的非主要方面剔除，从而把握住事物的内部规律或本质。
②分解
采用自顶向下逐步求精的方法对复杂的事物和问题进行分解，对分解后的简单问题进行分析和求解，这些解的集合就是解空间。
（2）结构化分析及建模方法的主要优点
①不过早陷入具体的细节；
②从整体或宏观入手分析问题，如业务系统的总体结构、系统及子系统的关系；
③通过图形化的模型对象直观地表示系统要做什么，完成什么功能；
④图形化建模方法方便系统分析员理解和描述系统；
⑤模型对象不涉及太多技术术语，便于用户理解模型。
考点2 DFD需求建模方法
（1）定义
DFD建模方法（过程建模和功能建模方法）从应用系统的数据流着手以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流，其核心是数据流。
（2）DFD方法的基本元素（模型对象）
①数据流（Data Flow）
数据流用一个箭头描述数据的流向，箭头上标注的内容可以是信息说明或数据项。
②处理（Process）
表示对数据进行的加工和变换，在图中用矩形框表示。指向处理的数据流为该处理的输入数据，离开处理的数据流为该处理的输出数据。
③数据存储
表示用数据库形式（或文件形式）存储的数据，对其进行的存取分别以指向或离开数据存储的箭头表示。（圆角矩形框）
④外部项（也称数据源或数据终点）
描述系统数据的提供者或数据的使用者，在图中用圆角框或平行四边形框表示。
DFD建模方法使用的基本元素和符号如图2-1所示。
图2-1 DFD方法的基本元素
（3）DFD图
DFD图采用自顶向下逐步细化的结构化分析方法表示目标系统，以应用信息系统或软件项目的功能为中心进行抽象和分解，以数据流的变换来分析和考察数据对企业及组织中各类业务活动的影响（层次结构如图2-2所示）。然后，再对每个功能活动进行分解，直到每项功能活动都是具体的、可操作的、用一个程序模块可以实现其功能为止。
图2-2 DFD层次结构图
（4）DFD建模过程
①明确目标，确定系统范围
明确目标系统的功能需求，并将用户对目标系统的功能需求完整、准确、一致地描述出来，然后确定模型要描述的问题域。
②建立顶层DFD图
根据系统目标抽象出目标系统将要实现的主要功能，并根据抽象出的主要功能命名顶层DFD图中的处理，然后画出完成这些功能需求的输入数据、产生的结果以及数据的提供者和使用者。顶层DFD图是进一步分解的基础。
③构建第一层DFD分解图
根据应用系统的逻辑功能，把顶层DFD图中的处理分解成多个更细化的处理。
④开发DFD层次结构图
对第一层DFD分解图中的每个处理框（矩形或圆角框）进行进一步分解，在分解图中要列出所有的处理及其相关的信息，并要注意分解图中的处理与信息必须包括父图中的全部内容。
分解原则：
a．保持均匀的模型深度
可避免较高层次的变化影响较低层次，从而造成可能的重复工作。同时可较早查出错误及遗漏。
b．按困难程度进行选择
标准如下：
第一，从其中最不熟悉及最不清楚的处理开始分解。
第二，选择某一处理框分解，该处理框的分解将产生更多的关于其他处理框的信息。
c．重新分解的条件
若一个处理难以确切命名，可以考虑对它进行重新分解。
⑤检查确认DFD图
为保证构建的DFD模型（图）是正确一致且满足要求的，检查标准如下：
a．父图中描述过的数据流必须要在相应的子图中出现；
b．一个处理至少有一个输入流和一个输出流；
c．一个存储必定有流入的数据流和流出的数据流；
d．一个数据流至少有一端是处理框；
e．模型图中表达和描述的信息是全面的、完整的、正确的和一致的。
【真题演练】
下列不属于DFD方法基本元素的是（ ）。
A．数据流
B．数据处理
C．数据存储
D．数据结构
【答案】D
考点3 其他需求建模方法
除了DFD方法以外，还可以用IDEFO、UML的用例模型等建立系统的功能模型。
（1）IDEFO方法简介
①产生与发展
a．IDEF是ICAM DEFinition Method的缩写，因1981年在美国空军公布的ICAM工程中被命名为“IDEF”而得名。
b．此方法最初由IDEFO、IDEFl和 IDEF2三部分组成，IDEFO描述系统功能及相互关系，IDEFl描述系统信息及其数据之间的联系，IDEF2用于系统模拟，建立动态模型。
c．该方法现已发展成为一个系列，包括IDEF3过程描述及获取方法、IDEF4面向对象设计方法、IDEF5本体论获取方法、IDEF6设计原理获取方法、IDEF7信息系统审定方法、IDEF8用户接口建模方法等。
②基本元素
组成IDEFO图的基本元素是矩形框和箭头，如图2-3所示。
图2-3 矩形框与箭头语法和其实例
a．矩形框
矩形框代表功能活动，写在矩形框内的动词短语描述功能活动的名称，活动的编号按照要求写在矩形框右下角指定的位置。
b．箭头
第一，输入箭头表示完成活动需要的数据；控制箭头描述了影响这个活动执行的事件或约束条件；输出箭头说明由活动产生的结果及信息；机制箭头表示实施该活动的物理手段或完成活动需要的资源（计算机系统、人或组织）。
第二，输入与控制的作用是有区别的，输入强调被活动消耗或变换的内容，而控制强调对活动的约束条件。
第三，每个箭头所表示的数据用一个名词短语描述，数据可以是信息或对象。
③IDEFO模型的组成
IDEFO模型由一组图形组成，这些图形组成了一个由父到子的层次结构图，如图2-4所示。它把一个复杂事物按自顶向下逐步细化的方式分解成多个简单的事物或组成部分。
a．当一个功能活动被分解成几个子功能活动时，用箭头表示各子功能活动之间的接口。每个子功能活动的名字加上带标记的接口确定了一个范围，规定了子功能活动细节的内容。
b．子功能活动必须忠实地描述父功能活动的细节，以既不增加也不减少的方式反映各自父功能活动所包含的信息。
图2-4 IDEFO层次结构图
④基本思想
IDEFO的基本思想是结构化分析，强调自顶向下有控制地逐步地展开细节，精准全面地描述系统，通过建模过程与模型来理解系统。
⑤特点及应用
IDEFO方法具有模型元素单一、语义丰富、容易理解、更易于从全局角度分析考察问题等特点，因此被广泛地应用于一些大型复杂系统的分析设计中。
（2）UML用例模型简介
①建模思想
UML方法采用面向对象思想建模，其中的用例模型用于描述系统功能需求。
②用例模型
UML的用例模型由用例图组成，用例图由系统、角色和用例三种模型元素及其之间的关系构成。
【真题演练】
下列不属于信息系统需求分析常用建模方法的是（ ）。
A．ER
B．DEFO
C．DFD
D．LML
【答案】A
考点4 DFD与IDEFO比较
（1）共同点
DFD与IDEFO方法的基础都是结构化分析思想，强调用自顶向下逐步求精的方法对现实世界建模，由粗到细，由表及里地逐步细化，逐步涉及问题的具体细节。
（2）不同点
①从表达含义上看，DFD图和IDEFO图都是用箭头代表数据流，但是在DFD图中箭头强调流或者顺序，IDEFO图中箭头强调数据约束。
②从表达形式上看，DFD图和IDEFO图都是用箭头和处理来表达一个企业或组织的业务流程，但IDEFO图中的箭头不仅能够表示出数据流，还可以表示出控制流和说明处理或活动实施方式的一些约束。
③从模型元素的组成上看，DFD模型由四种元素组成：外部项（数据源及终点）、数据流、数据存储和处理，而IDEFO模型元素的组成只有两种元素：箭头和活动，对箭头和活动的说明可以写入专门的文档而不必表示在图中。这使得IDEFO模型结构清楚，容易理解，更适合于大型复杂系统的需求建模。
