计算机三级数据库技术——第二章 需求分析学习笔记

第二章 需求分析

概述

需求分析是软件开发阶段的前提和基础，软件需求与目标产品之间存在着一定的依赖关系，这种依赖关系和软件的规模以及软件复杂性成正比，这个阶段的工作做得越深入、详尽，目标系统的满意度越高。

需求分析

需求分析的概念与意义

所谓需求分析，就是对待开发的系统要做什么，完成什么功能的全面描述。

需求分析工作是通过对需求的调查、了解、观察、分析，采用已证实是有效的技术、方法或工具，对原始资料进行加工整理，得到有关目标系统需要实现的功能及其相互关系等一系列活动的集合。

Kotonya和Sommerville（1998）把需求定义为“系统服务或约束的描述”。

需求是软件项目的投资方和使用者对一个待开发的系统在实现目标、完成功能、应达到的性能、安全性、可靠性等诸方面指标的一个期望和要求的集合。

通常应以一种清晰、简洁、准确、一致且无二义性的方式表述和描述。

由于软件产品的下列特性常常使需求获取困难重重：

• 软件功能复杂
• 需求的可变性
• 软件产品的不可见性。软件产品在产品和性能方面的指标是在一定的硬件环境中通过对软件的操作来展示和体现的。因而软件产品的功能在运行阶段通过在实际环境中的运行才得以实现。

需求分析阶段的主要任务是分析清楚当前系统的业务流程，包括系统的体系结构，各职能部门完成的主要任务，各职能部门之间的关系及其交流的信息。

在需求分析的过程中还要搞清楚现行系统存在的问题，包括亟待解决的问题。

分析结果以功能模型和软件需求规格说明书方式展示。

通常，该工作是在系统分析人员与用户不断交互的过程中完成的。

需求获取的方法

方法	简述
面谈	是获取需求最基本的方法
实地观察	实际观察用户的操作过程
问卷调查	问卷设计应简洁、问题容易理解、表格易填写
查阅资料

需求分析过程

标识问题

通过对问题的识别和标识获得对所求解问题及其运行环境的理解。应当对应用领域的各类问题进行全面细致的分析。

标识问题从现行系统的业务流程做起，理解现行系统的业务流程，包括现行流程存在的问题以及需要改进的方面。

还要注意确定系统的人机界面。所谓人机界面，即手工处理和计算机处理相衔接的部分。系统分析员应当清楚地界定计算机不能承担的工作，对于上述工作，应当向用户说明理由并描述清楚计算机不能承担部分的人机接口的实现方法。

建立需求模型

模型是对现实原型的一种抽象，其本质是只关心与研究内容有关的因素而忽略无关的因素。其目的是将复杂事务简单化。

描述需求

包括对功能性需求以及非功能性需求的描述。

功能性需求：需要计算机系统实际解决的问题或实现的具体功能，即数据处理要求，侧重描述系统在一定条件下的活动。通常，应用信息系统或软件所有功能模块描述的集合就是系统的功能需求。

非功能性需求：通常是指信息系统或软件项目对实际环境的要求，关心的是系统的整体特性。

需求描述是对待开发系统从宏观和整体上的一个完整描述。

它精确地定义和说明了系统做什么以及交付的目标产品的约束条件，为软件生命周期中后续的活动提供了工作的依据和蓝图，是项目开发方和使用者或用户方的一个约定，也是项目后期审核和验收的依据。

需求描述由需求模型（系统功能模型）和软件需求说明书组成。

软件需求说明书：

内容	简述
需求概述	项目的研发背景及意义、指导思想与研究目标，是对目标系统的总体描述
功能需求	系统的总体结构和功能，系统覆盖的功能范围
信息需求	系统涉及的信息范围、数据的属性特征、数据之间的关系和约束
性能需求	对系统的性能要求
环境要求	对系统运行环境的要求
其他需求	对目标系统检测或验收方面的要求

需要思考的问题

• 系统的主要功能
• 描述的需求是否完全，是否囊括问题域中的所有的环节，每个环节可能的状态及其变化而无遗漏
• 需求描述是否正确且一致，其内容是否没有任何的冲突和含糊
• 描述的需求是否可行、实际可操作
• 是否是用户需要的

应当注意消除重复、不完整、甚至是模糊的需求

需求文档是需求分析工作完成的标志，其成果是软件生命周期后续阶段工作的依据，力求论述全面、结构清晰、内容准确、描述清楚。

确认需求

需求确认或评审的目的是进一步检查确信需求说明书中不包含任何不一致和含糊的内容，进一步证实需求说明书描述的内容是用户所期望和需要的。

这项工作由评审组或评审委员会组成。

对需求分析的结果的合理性、正确性和有效性进行检查，以确保需求分析的结果是全面的、准确的和一致的。评审过程也将使得用户和设计人员对需求有进一步的理解、沟通且达成一致。

在评审过程中，如果出现小的遗漏或不一致，则需更正后进行下一阶段；如果有大的遗漏或不一致，则不能通过评审，需重新进行相关的需求分析工作。

评审委员会将逐项审核下列内容：

1. 功能需求。审查DFD图或IDEF0图或其他需求模型所描述的内容是否与需求说明书中说明的相关内容一致，对待开发系统的功能要求是否满足使用要求，处理功能之间的关系及交换信息的方式是否合理。
2. 数据需求。审查数据需求。
3. 性能。
4. 数据管理。审查需求分析及相关描述是否合理，是否满足数据存储和管理的要求。
5. 其他需求。例如安全性、可操作性、可维护性、可扩充性以及运行环境等方面的分析。

需求分析

需求分析方法概述

结构化分析与功能建模方法主要有DFD、IDEF0等。

结构化分析方法产生于20世纪70年代，DeMacro正式将结构化分析方法作为一种需求分析方法提出。

结构化分析方法的基本特征是抽象和分解。

抽象是一种手段，将具体事物或问题的非主要方面剔除，把握事物的内部规律或本质。

利用自顶而下逐步求精的方法对复杂的事物和问题进行分解，对分解的简单问题进行求解，所得解的集合就是我们的解空间。

结构化分析及建模方法主要优点：

• 不过早陷入具体的细节。
• 从整体或宏观入手解决问题。
• 通过图形化的模型对象直观地表示系统要做什么、完成什么功能。
• 图形化的建模方法方便系统分析员理解和描述系统。
• 模型对象不涉及太多技术术语，便于用户理解模型。

DFD建模方法

DFD方法的基本元素

• 数据流（data flow），箭头
• 处理（process），方框
• 数据存储，圆角框
• 外部项（也称数据源或数据终点），圆角框或平行四边形。

DFD图：

自顶而下逐步细化的结构化分析方法表示目标系统，直到每项功能活动都是具体的、可操作的、用一个程序模块可以实现的功能为止。

DFD建模过程

1. 明确目标、确定系统范围。

2. 建立顶层DFD图。抽象出目标系统将要实现的主要功能。

3. 构建第一层DFD分解图。

4. 开发DFD层次结构图。对第一层DFD分解图的处理框（矩形或圆角框）做进一步的分解。并要注意分解图中的处理与信息必须包括父图的全部内容。分解可采用以下原则：

   1. 保持均匀的模型深度

      给定父图P1，则应工作在P1.1,P1.2,P1.3,P1.4上，而不是P1.1,P1.1.1,P1.1.1.1上。可避免较高层次的变化影响较低层次，造成可能的重复工作。

      有时为了更好的理解一个图，常常要了解较深的基层，重要的是要把这种特殊处理作为草图直到水平层次都已确定为止

   2. 按困难程度进行选择。

      1. 从最不熟悉及最不清楚的处理开始分解
      2. 选择某一处理框分解，该处理框的分解将产生更多关于其他处理框的信息。

   3. 如果一个处理难以确切命名，可以考虑对其进行重新分解。

5. 检查确认DFD图。按以下规则进行检查和确认，以保证构建的模型是正确的、一致的，且满足要求。

   1. 父图中描述过的数据流必须要在相应的子图中出现
   2. 一个处理中至少有一个输入流和一个输出流
   3. 一个存储必定有流入的数据流和流出的数据流
   4. 一个数据流至少有一端是数据框
   5. 模型图中表达和描述的信息是全面的、完整的、正确的和一致的。

通过以上过程，顶层图被逐步细化，同时也把面向问题的属于逐渐转化为面向实现的解法，并得到了最终的DFD层次结构图。

其他需求建模方法

IDEF0方法简介

IDEF是ICAM DEFinition Method的缩写。最初由IDEF0，IDEF1与IDEF2三部分组成，前者描述系统功能及相互关系，中者描述系统信息及其数据之间的联系，后者用于系统模拟，建立动态模型。该方法已被发展成为一个系列，后有IDEF3-8等。

组成IDEF图的基本元素是矩形框和箭头。

左边的输入箭头表示完成活动需要的数据；

上方进入的控制箭头描述了影响这个活动执行的事件或约束条件；

输出箭头说明由活动产生的结果及信息。

下方的进入的机制箭头表示实施该活动的物理手段或完成活动需要的资源（计算机系统、人或组织）

输入与控制的区别：

输入强调被活动消耗或变换的内容；

控制强调对活动的约束条件。

顶层图编号为A-0

A-0分解为A0

A0中的第三个模块分解为A3

当一个功能活动被分解为几个子功能活动时，用箭头表示各子功能活动的接口。每个子功能活动的名字加上带标记的接口确定了一个范围，规定了子功能活动细节的内容。

通常，子功能活动应当以既不增加也不减少的方式反映各自父功能活动包含的信息。

IDEF0的基本思想也是结构化分析。

模型由图形、文字说明、词汇表及交叉引用表组成。图形是其主要成分。

由于IDEF方法更加规范，具有模型元素单一、语义丰富、容易理解、更易于从全局角度分析考察问题等特点，使得IDEF方法被广泛地应用于一些大型复杂系统地分析设计中。

IDEF于1989年首次被用于国家863计划项目计算机集成制造系统CIMS实验工程中，从20世纪90年代之后被推广在国内CIMS重点应用工厂使用，取得了良好的效果。

UML用例模型简介

UML统一建模语言

UML方法采用面向对象思想建模，其中的用例模型用于描述系统功能需求。

UML的用例模型由用例图组成，用例图由系统、角色、用例三种模型元素及其之间的关系组成。详见第5章。

DFD与IDEF0比较

• DFD用箭头也叫做数据流来描述数据移动的方向、数据处理以及处理之间的依赖关系。

  IDEF0也用箭头代表数据流，但在IDEF0中不是强调流或顺序，而是强调数据约束。

  连在矩形上的这些箭头描述他们是如何影响这个矩形所描述的活动的。

• 从表达形式上看，DFD和IDFE0都是用箭头和处理来表达业务流程；

  但IDEF0中的箭头有更加丰富的语义，不仅表示数据流，还表示控制流和说明处理或活动实施方式的一些约束。

• 从模型元素的组成来看，DFD模型由四种元素组成：外部项（数据源及终点）、数据流、数据存储和处理；

  IDEF0模型只有两种元素组成：箭头和活动。

  通过这两种元素可以清楚地描述出一个目标系统将要做什么，完成什么功能及处理之间的约束，而进出IDEF0图的箭头究竟从哪儿来、到哪儿去，可在专门的文档中说明，不必表示在IDEF0图中。

  这使得IDEF0模型结构清楚，容易理解，更适合于大型复杂系统的需求建模。

  需求分析示例

  习题

  获取需求的主要方法包括面谈、实地观察、问卷调查、查阅资料

  信息系统需求分析常用的建模方法有IDEF0、DFD、UML

  DFD中的（数据流）用一个箭头描述数据的流向，并可在箭头上标注信息说明或数据项。

  IDEF0图的基本元素是（矩形框）和（箭头），其中（矩形框）代表功能活动。

  顶层DFD中包含的处理有（1）个。

  注：本篇仅供学习参考，详细内容参见数据库技术官方教材。