《软件工程》学习笔记三

主 题： 《软件工程》学习笔记 内 容：

《软件工程》学习笔记三

——需求分析

1.软件需求分析的概念和任务

1.1需求的概念和层次 概念

用户解决问题或达到目标所需要的条件或权能

系统或系统部件要满足合同，标准，规范，或其它正式规定文档所需要的条件或权能

反映上述内容的文档说明 需求的重要性 Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：

开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。

需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。

国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。 层次 业务需求:反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明.

用户需求:文档描述了用户使用产品必须要完成的任务，这在使用实例（ use case）文档或方案脚本（ scenario）说明中予以说明。

功能需求:定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

非功能需求:对功能需求的补充，分成了两类。

软将工程—学习笔记三

1.2软件需求分析的目标和任务 需求工程基本概念 什么是需求工程

把所有与需求直接相关的活动通称为需求工程。

需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。 需求工程的结构图

软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。

需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。

通俗地说,需求分析的任务就是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 <需求规格说明书> 规范的形式准确地表达用户的需求。

需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。

1.3需求分析的过程 需求分析流程

需求分析过程示意图

l 通过对现实环境的调查，获得当前系统的物理模型

软将工程—学习笔记三

l 去掉具体模型中非本质因素，抽象出当前系统的逻辑模型 l 分析当前系统与目标系统的差别，建立目标系统的逻辑模型 通常软件开发项目是要实现目标系统的物理模型。

目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。

软件需求分析过程图

1) 问题识别

l 从系统的角度来理解软件并评审 软件范围是否恰当 l 确定对目标系统的综合要求，即软件的需求 l 提出这些需求实现条件，以及需求应达到的标准 软件的需求包括： l 功能需求 l 性能需求 l 环境需求 l 可靠性需求 l 安全保密要求 l 用户界面需求 l 资源使用需求 l 成本消耗需求 l 开发进度需求

l 预先估计以后系统可能达到的目标

问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。

2) 分析与综合

从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。

常用的分析方法：

l 面向数据流的结构化分析方法（SA） l 面向数据结构的Jackson方法（JSD） l 结构化数据系统开发方法（DSSD） l 面向对象的分析方法（OOA）等 3) 编制文档

编制需求分析阶段的文档 l 软件需求说明书 l 数据要求说明书 l 初步的用户手册

l 修改、完善与确定软件开发实施计划 4) 需求分析评审

l 作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备

性、准确性和清晰性，以及其它需求给予评价。 l 为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。

评审结束应有评审负责人的结论意见及签字。除分析员之外，用户／需求者，

软将工程—学习笔记三

开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。 1.4需求开发的主要困难与对策 l 知识技能问题 l 态度问题 l 合作关系

l 用户说不清楚需求 l 双方误解需求

l 开发人员写不好需求文档 l 用户经常变更需求 2.获取软件需求的方法 软件需求分析的原则

l 需要能够表达和理解问题的数据域和功能域 数据域包括数据流,数据内容和数据结构.

l 要能以层次化的方式对问题进行分解和不断细化 l 要给出系统的逻辑视图和物理视图

逻辑视图给出软件要达到的功能和处理数据之间的关系 物理视图给处理功能和数据结构的实际表示形式 3.结构化分析方法

需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成 大多数的需求分析方法是由信息驱动的 信息域具有三种属性: 信息流、信息内容和信息结构 以数据流分析作为需求分析的出发点。

结构化分析方法适合于数据处理类型软件的需求分析

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

结构化分析方法使用工具：数据流图，数据词典，结构化英语，判定表与判定树 数据流图

数据流图中的主要图形元素

数据流与数据加工之间的关系

软将工程—学习笔记三

数据流图的层次结构

为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统

在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据

底层流图是指其加工不需再做分解的数据流图，它处在最底层

中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。 检查和修改数据流图的原则

数据流图上所有图形符号只限于前述四种基本图形元素 数据流图的主图必须包括前述四种基本元素，缺一不可 数据流图的主图上的数据流必须封闭在外部实体之间 每个加工至少有一个输入数据流和一个输出数据流

在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系

规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡

可以在数据流图中加入物质流，帮助用户理解数据流图 图上每个元素都必须有名字 数据流图中不可夹带控制流

初画时可以忽略琐碎的细节，以集中精力于主要数据流 数据词典

数据词典与数据流图配合，能清楚地表达数据处理的要求 词条描述 —— 对于在数据流图中每一个被命名的图形元素，均加以定义，其内容有:名字，别名或编号，分类，描述，定义，位置，其它，等

1）数据流词条描述 数据流名：

说明：简要介绍作用即它产生的原因和结果 数据流来源：来自何方 数据流去向：去向何处 数据流组成：数据结构

数据量流通量：数据量，流通量 2）数据元素词条描述 数据元素名：

类型：数字（离散值，连续值），文字（编码类型） 长度： 取值范围：

软将工程—学习笔记三

相关的数据元素及数据结构： 3）数据文件词条描述 数据文件名：

简述：存放的是什么数据 输入数据： 输出数据：

数据文件组成：数据结构

存储方式：顺序，直接，关键码 存取频率： 4）加工逻辑词条描述 加工名：

加工编号：反映该加工的层次 简要描述：加工逻辑及功能简述 输入数据流： 输出数据流：

加工逻辑：简述加工程序，加工顺序 5）源点及汇(终)点词条描述 名称：外部实体名

简要描述：什么外部实体 有关数据流： 数目：

基本加工逻辑说明

对数据流图的每一个基本加工，必须有一个基本加工逻辑说明

基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则

加工逻辑说明必须描述实现加工的策略而不是实现加工的细节

加工逻辑说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息 用于写加工逻辑说明的工具 结构化英语 判定表 判定树 4.原型化方法

概念：模拟某种产品的原始模型 产生原因

在开发初期，要想得到一个完整准确的规格说明不是一件容易的事。特别是对一些大型的软件项目。

用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求。 软件开发者对于所要解决的应用问题认识更是模糊不清

规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。

为了解决这些问题，逐渐形成了软件系统的快速原型的概念。 软件原型的分类

在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。

l 探索型：目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方

软将工程—学习笔记三

案的可行性。

l 实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明

是否可靠。

l 进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，

在改进原型的过程中，逐步将原型进化成最终系统。 原型使用策略 l 废弃策略 l 追加策略

建立快速原型，进行系统的分析和构造的好处：

增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求(主要是功能)明确化。

软件原型化方法提供了一种有力的学习手段。 使用原型化方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。

软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。

原型开发技术

l 可执行规格说明 l 基于脚本(scenario)的设计 l 自动程序设计 l 专用语言 l 可复用(reusable)的软件 l 简化假设 可执行规格说明

可执行规格说明是用于需求规格说明的一种自动化技术。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。包括

l 代数规格说明

代数规格说明使用集合、定义于这些集合上的函数和定义于这些函数上的方程来描述对象。规格说明的操作语义用这些方程表示。

l 有限状态模型 parnas提出的使用最广泛的一种可执行规格说明形式。从一个初始状态开始接收输入，到产生输出，状态在推移变化。施加在状态元素上的约束确定了有效状态的推移。

l 可执行的数据流图

数据流图是基于结构化开发方法的结构化规格说明

用一种可执行的语言程序代替定义处理逻辑的结构化英语，数据流图就成为由可执行语言程序模块组成的网络，在一定环境或工具的支持下就可成为一个可以执行的原型系统。

基于脚本的设计

脚本是指用户界面的原型。一个脚本用以模拟在系统运行期间用户经历的事件。它提供了输入─处理─输出的屏幕格式和有关对话的模型。因此，软件开发者能够给用户显示系统的逼真的视图，使用户得以判断是否符合他的意图。

可在任一脚本中使用一套可复用的软件模块，以表达某一方面的要求。

可使用一种原型语言来描述原型系统。原型开发过程中用这种语言来定义屏幕、数据项、及其相关的操作。从系统的外部描述开始，开发与数据库的接口、错误处理和恢复过程等系统的与外部视图一致的细节。

自动程序设计

软将工程—学习笔记三

自动程序设计是指在程序自动生成环境的支持下，利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序。

自动程序设计是从形式的软件功能规格说明到可执行的程序代码这一过程的自动化。

软件复用技术

利用可复用的模块，做出适当的组合，就可得到快速构造的原型系统。 为了快速地构造原型，这些模块 首先，必须有简单而清晰的界面；

其次，它们应当尽量不依赖其它的模块或数据结构； 第三，它们应具有一些通用的功能。 简化假设

简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。

在修改一个文件时，可以假设这个文件确实存在 在存取文件时，待存取的记录总是存在

一旦计划中的系统满足用户所有的要求，就可以撤消这些假设，并追加一些细节。 快速原型模型开发过程 l 快速分析 l 构造原型

l 运行和评价原型 l 修正和改进 l 判定原型完成

l 判定原型细部是否说明 l 原型细部说明 l 判定原型效果

l 整理原型并提供文档

注：本章相关概念、定义和具体需要掌握的内容请参见教材和课件。