软件工程概论-3-需求分析

软件工程概论

SoftwareEngineering

贾恒彬李恒

E-mail:jiahengbin@E-mail:liheng@

第3章需求分析

软件工程师所解决的问题往往十分复杂。尤其是

开发全新的系统时，了解问题的性质可能是非常困难

的。因此，搞清楚系统应该做什么也是困难的。

对系统应提供的服务和所受到的约束的描述就是

系统需求关心的内容，对服务和约束的发现、分析、

建立文档、检验的过程叫做需求工程。

软件需求分析是软件生存周期中最关键一步。

第3章需求分析

■3.1软件需求分析的基本概念

■3.2软件需求

■3.3需求工程

■3.4图形工具

■3.5验证软件需求

3.1软件需求分析的基本概念

3.1.1需求分析定义

A百度百科的定义

所谓“需求分析”，是指对要解决的问题进行详细的分析，弄清楚问题

的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以

说，在软件工程当中的“需求分析”就是确定要计算机“做什么”。

＞通俗的定义

在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑

系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是

软件工程中的一个关键过程。

在这个过程中，系统分析员和软件工程师确定顾客的需要，只有在确

定了这些需要后，他们才能够分析和寻求新系统的解决方法。在软件工程的

历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个

步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过

程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最

后的软件实际上不可能达到顾客的真正需要，或者软件无法在规定的时间里

完工。

3.1.2软件需求分析概述

＞软件需求分析的任务

口软件需求分析的任务是准确地定义未来系统的目

标，确定为了满足用户的需求，系统必须做什么

O用《需求规格说明书》规范的形式准确地表达

用户的需求，以及对需求进行审查。

»需求分析的具体内容包括

□深入描述软件的功能和性能

□确定软件设计的约束

□确定软件同其他系统元素的接口细节

□定义软件的其他有效性需求

＞需求分析阶段的产品——需求规格说明书

3.1.3软件需求分析的任务

由于需求分析方法不同，描述形式不同。其实现步

骤如下图所示：

理

解

导

需

抽象化出

逻辑模型求

一

表

实例化达

逻辑模型需

求

3.1.3软件需求分析的任务

3.1.3软件需求分析的任务

根据上述分析得知，需求分析的具体任务是：

1.确定系统的综合要求

■确定系统功能要求一这是最主要的需求，确定系统必

须完成的所有功能。

•确定系统性能要求一应而就具体系统定，例如可靠性、

联机系统的响应时间、存储容量、安全性能等。

■确定系统运行要求一主要是对系统运行时的环境要求；

如系统软件、数据库管理系统、外存和数据通信接口等。

•将来可能提出的要求一对将来可能提出的扩充及修改

作预准备。

3.1.3软件需求分析的任务

2.分析系统的数据要求

软件系统本质上是信息处理系统，因此，必须考虑：

•数据（需要哪些数据、数据间联系、数据性质、结

构）

■数据处理（处理的类型、处理的逻辑功能）

3.导出系统的逻辑模型——通常系统的逻辑模型用DFD

图来描述。

4.修正系统的开发计划——通过需求对系统的成本及进

度有了更精确的估算，可进一步修改开发计划。

3.1.4需求分析原则

近几年来已提出许多软件需求分析与说明的方法，每一

种分析方法都有独特的观点和表示方法，但都适用下面的

基本原则。

1、能够表达和理解问题的信息域和功能域

对于计算机程序处理的数据，其信息域包括信息流（如

下图，即数据通过一个系统时的变化方式）、信息内容和

信息结构，而功能域反映上述三方面的控制信息。

结果数据

3.1.4需求分析原则

2、建立描述系统信息、功能和行为的模型

建立模型的过程是“逐步精化”的综合分析的过程。

通过对模型的不断深化认识，来达到对实际问题的深刻

认识。

3、能够对问题进行分解和不断细化，建立问题的层次

结构。

分解是为了降低问题的复杂性，增加问题的可解性和

可描述性。分解可以在同一个层次上进行（横向分解），

也可以在多层次上进行（纵向分解）。

3.1.4需求分析原则

4、需要给出系统的逻辑视图和物理视图

软件需求的逻辑视图给出的是软件要达到的功能和

要处理信息之间的关系，而不是实现的细节。

软件需求的物理视图给出的是处理功能和信息结构

的实际表现形式，这往往是由设备本身决定的。

请同学们特别注意：

需求分析只研究软件系统“做什么？”，而不考虑

“怎样做？”。

3.1.5需求分析方法

不同的开发方法，需求分析的方法也有所不同，常见的分

析方法有：

•功能分析方法

将系统看作若干功能模块的集合，每个功能又可以分

解为若干子功能，子功能还可继续分解，分解的结果已经

是系统的雏形。

•结构化分析方法

是一种以数据、数据的封闭性为基础，从问题空间到某

种表示的映射方法，由数据流图（DFD图）表示。

3.1.5需求分析方法

•信息建模法

是从数据的角度对现实世界建立模型的，基本工具是

E-R图。

•面向对象的分析方法

面向对象的分析方法（00A）的关键是识别问题域内

的对象，分析它们之间的关系，并建立起模型。

3.1.5需求分析工作流程

i■切

|口求知折民

报告.开发计划

BI*/■定系筑'

褥求补充；功卷，性食,少

।用户，有其至

坤埴介超度等*求，聂

已有的

类惘软

件

定

义

文

档

板方法

就再定义文档

，线麻&烟、

件定

3.2软件需求

3.2.1需求定义

＞权威的定义（IEEE软件工程标准词汇表中的定义）

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

♦系统或系统部件要满足合同、标准、规范或其他正式规定

文档所要具有的条件或权能

♦反映上面两条的文档说明

IEEE公布的需求定义分别从用户和开发者的角度阐明了什么是需求，需求

一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是

需求文档。

＞通俗的定义

♦需求是指明系统必须实现什么的规格说明，他描述了系统

的行为、特性或属性，是在开发过程中对系统的约束。

3.2.1需求分类

软件需求一般包括功能需求和非功能需求。

1、功能需求

包括对系统应该提供的服务、如何对输入做出反

映以及系统在特定条件下的行为的描述。在某些

情况下，功能需求可能还需要声明系统不应该做

布么。

3.2.1需求分类

2、非功能需求

＞非功能需求是对系统提供的服务或功能给出的约束。

包括时间约束、开发过程约束、标准等。

＞非功能需求比功能需求更关键

许多非功能需求关心的是系统的整体特性而不

是个别的系统特性。一个功能需求没有满足可能会

降低系统的能力，而一个非功能需求没有满足则可

能使整个系统无法使用

□例如：如果一个飞机系统不符合可靠性要求，它将不会被

批准飞行；如果一个实时控制系统无法满足其性能需求，

控制功能可能根本无法使用

3.2.1需求分类

2、非功能需求

＞性能需求

软件开发的技术性能指标，包括对存储容量、运行时间

的限制、安全保密性要求等。

□例如：系统的最大客户容量、运行的峰值速度、平均速率

、充分运行时最少需要多少内存、同步问题等

＞环境需求

对软件系统运行时所处环境的要求，包括硬件方面、软

件方面、使用方面等

＞可用性需求

人机界面友好、使用舒适、可理解性好、可修改性好

3.2.1需求分类

2、非功能需求

＞可移植性需求

»可靠性需求

在一定的环境下以用户能够接受的方式运行时所表现出

来的始终如一的能力。

»硬件方面：系统的平均失效时间、系统的平均故障间

隔时间、失效率

»软件方面：出错保障能力、健壮性、内部信息的一致

性、错误识别能力

＞资源使用需求：件运行时所需的数据、软件、内存空

间等资源

＞软件成本消耗与开发进度需求等

3.2.2高质量的软件需求应该具备的特征

□完整性

■不能遗漏任何必要的需求

■每一项需求要完成的任务必须要描述清楚，以便开发人

员明白实现这项需求的所有信息，用户能够审查这项需

求描述的正确性

3.2.2高质量的软件需求应该具备的特征

需求描述举例

“如果电话A呼叫电话B并且电话B空闲，那么电

话B应该响铃”

测试中出现问题：A呼叫空闲的B时，所有的铃都响了

改进1：“如果A呼叫B并且B空闲，那么除B响铃

夕卜，其他所有电话都不响铃

测试中又出现问题：与此同时，c也有正当的响铃理由

改进2：在需求规格说明书的开头加上，系统只

做需求规格说明书中要求做的事，而不做别的。

3.2.2高质量的软件需求应该具备的特征

□无二义性

■不同的人员对需求的理解应该是一致的。一般情况下，

描述需求都使用自然语言，因此容易引起需求理解的二

义性。

3.2.2高质量的软件需求应该具备的特征

□需求描述举例

“发现任何不友好且带有未知任务的或者有可

能在5分钟内飞入空中禁区的飞行物时,要拉响

上述需求描述的是：

说明针对军事系统中空中禁区受到入侵时的报警事件

讨论：以下情况是否拉警报

1.有明确任务的不友好飞行物

2.无明确任务的不友好飞行物

3.2.2高质量的软件需求应该具备的特征

□正确性

■每项需求都必须准确地反映用户要完成的任务

口可行性

■每一个成功的软件系统其解决方案都应该是可行的，可

行性体现在技术、经济、操作可行性

□必要性

■每项需求都应该是客户所需要的，开发人员不要自作主

张添加需求

□划分优先级

■为每项需求按重要程度分配一个优先级，有助于项目管

理者决冲突、安排阶段性交付，在必要时作出功能取舍

,以最小的费用获得产品最大的功能

3.2.2高质量的软件需求应该具备的特征

□可验证性

■例：系统目标：

”系统很好用，即使对于一个没有经验的用户，而

且应该使用户错误降到最少”

可验证的非功能需求：

“对一个没有经验的用户来说，经过2小时的培训应

该能够使用系统的所有功能。在这样的培训之后，一个

有经验的用户每天的出错平均数不应超过2次”

3.2.2高质量的软件需求应该具备的特征

■指定非功能需求的度量

理论上，非功能需求能够量化，从而使其验证更为可观。

在实际过程中，对需求描述的量化通常是很困难的

性质度量方法

速度每秒钟处理的事务，用户/事件响应时间，屏幕刷新时间

规模K字节，RAM芯片数

易用性培训时间，帮助国Hl数

可靠性失败平均时间，无效的概率，失败的发生率，有效性

鲁棒性失败之后的重启次数，事件引起失败的百分比，失败中

数据崩溃的可能性

可移植性依赖于目标的语句百分比，目标系统数

3.2.3获取需求的方法

＞访谈

访谈是最早开始使用的获取用户需求的技术，也是迄今

为止仍然广泛使用的需求分析技术。

访谈有两种基本形式，分别是正式的和非正式的访谈。

正式访谈时，系统分析员将提出一些事先准备好的具体

问题。

在非正式访谈中，分析员将提出一些用户可以自由回答

的开放性问题，以鼓励被访问人员说出自己的想法。

3.2.3获取需求的方法

＞面向数据流自顶向下求精

数据决定了需要的处理和算法，数据显然是需求分析的

出发点，结构化分析方法就是面向数据流自顶向下逐步

求精进行需求分析的方法。

把一个复杂的问题划分成若干小问题，然后再分别解

决，将问题的复杂性降低到人可以掌握的程度。分解的

方法可分层进行，方法原理是先考虑问题最本质的方面,

忽略细节，形成问题的高层概念。然后再逐层添加细节。

即在分层过程中采用不同程度的“抽象”级别，最高层

的问题最抽象，而低层的较为具体。

3.2.3获取需求的方法

＞面向数据流自顶向下求精

X顶层

3.2.3获取需求的方法

＞面向数据流自顶向下求精

当认为某一层比较复杂时到底应该划分为多少个子系

统，针对不同的系统的处理不同。划分的原则可以根据

业务工作的范围、功能性质、被处理数据对象的特点。

一般情况下上面一些层的划分往往按照业务类型划分的

比较多，下面一些层往往按照功能的划分比较多。

依照这个策略，对于任何复杂的系统，分析工作都可

以有计划、有步骤及有条不紊地进行。

（双方确定问题的综合需求。、

这些需求包括功能需求（最主

需求工程要的需求）、性能需求、环境

3.3需求和用户界面需求，另外还

3.3需求工程

需求和分析.问题识别

导出

需求描述

分析与综合

需求有效性

系统模型

验证编写文档

用户需求和分析评审

系统需求

:需求文挡

露写“需求说明书”，

双方共同的理解与分析结果

3.3需求工程用规范的方式描述出来；

⑵编写初步用户使用手册;

⑶编写确认测试计划；

需求和分析一()修改完善项目开发计划;问题识别

导出

需求描述

分析与综合

需求有效性

系统模型

验证编写文档

用户需求和

系统需求

需求文挡

3.3.1需求工程的定义

需求工程是指系统分析人员通过细致的调研分析，

准确地理解用户的需求，将不规范的需求陈述转化

成完整的需求定义，再将需求定义写成需求规格说

明书以及需求审查的过程。

3.3.2需求工程的重要性

□事实

■需求工程处于或接近于软件工程过程的开始阶段，它提

供了软件项目其余部分得以构建的根基。如果你在开发

的后期阶段出错，受到影响的仅仅是那些与后期阶段相

关的工作，而修正错误通常也是相对简单的事情。然而

,如果错误出现在接近开始的阶段，而且并未立即予以

纠正，那么所有后续阶段的工作都是在错误的基础上进

行的。修正错误的代价将飞速增加，通常情况下重新开

发也许更为经济。

需求问题是造成软件工程项目失败的主要原因，这已

经是一个不争的事实。

3.3.2需求工程的重要性

需求错误放大示意图

3.3.2需求工程的重要性

□有关软件错误的一些事实

■在软件生命周期中，一个错误发现的越晚，修复错误的

费用越高

■许多错误是潜伏的，并且在错误产生后很长一段时间才

被检查出来

■在需求过程中产生很多的错误

■在需求阶段，代表性的错误为疏忽、不一致和二义性

■需求错误是可以被检查出来

□规模的大小是问题的关键（拿建筑作类比）

■花园棚发生倾斜（塞几块砖即可扶正，几乎不需费用）

■房屋因地基不牢发生倾斜（打桩止陷，相当可观的费用）

■高层建筑发生倾斜（最好不要让它发生）

3.3.3需求工程的主要活动内容

软件需求工程的主要活动内容包括:

□需求获取

□需求分析

□编写需求规格说明书

口需求审查

还有需求管理：包括需求变更控制、需求跟踪等

需求获取

需求获取需要考虑的三个问题：

□应当收集什么信息；

能从什么来源中来收集；

可能通过什么机制或技术来收集

□问题1：需求获取的信息

■问题的描述

■要求解决问题的列表

■用户对系统的行为或结构施加的任何约束

需求获取

□问题2：信息的主要来源

■客户（实际的和潜在的）

■客户的规格说明书

■任何原有的系统及其文档

■原有系统的用户

■新系统的潜在用户

■原有产品（开发者的其他产品，执行与可能要开发的产

品相似的功能

■竞争对手的产品

■应用领域专家

■相关的技术标准和法规

需求获取

□问题3：需求获取的技术

■背景资料阅读

■面谈

■调查表

■文档检查

■任务观察

■讨论分析

■头脑风暴

■用例和场景

需求获取

系统分析人员应该在调研前做充分的准备,

针对具体项目的特点设计一些问题和表格。在

实际项目中应该根据项目的规模、涉及的业务

领域，有针对性的设计一些特别的问题。

下面给出一组比较通用的调研问题供参考:

需求获取

»调研的基本问题

□部门的名称、人员数量和结构

部门发展或变化简单介绍

□部门的主要任务

□业务处理流程

业务处理流程中涉及那些专业领域的知识

工作需要的审批流程是什么？

□主要算法描述

那些业务需要实时处理

那些业务需要交互操作

□部门各岗位的职责

需求获取

部门接收哪些部门或外界的信息？信息内容和格

式要求是什么？

部门产生哪叱信息？

□部门产生的宿W、荏到哪些其他部门？格式要求是

什么？

对信息的输入和输出方式有要求吗？输入输出设

备是什么

数据要求实时备份吗？备份的设备是什么？时间

策略？

业务处理有高峰期吗？高峰时间是什么时候？业

务量有多少？

现有的哪些设备要继续使用？

对产品的运行环境有要求吗？

需求获取

对界面风格和操作方式有要求吗？

在系统运行过程中允许停机吗？

操作方式要根据操作环境和使用人员素质分类吗

□需要的操作权限有哪些？

需要记录系统操作运行日志吗？

用户有能力进行系统维护吗？

□需要分布式处理吗？

需要什么方式的用户操作培训？

□需要制作联机帮助吗？

需求获取

»某出版社系统调查表

编号提出的问题

1您在哪个部门工作？

2出版业务的流程是什么？

3您每天都处理哪些文件、数据、报表？

4工作中手工处理特别麻烦的事情是什么？

5工作中手工处理什么问题解决不了？影响效率的问题有哪些？

6您认为提局工作效率，节省工作时间，减轻工作强度可米取哪些办法？

7您的部门需要成本核算和统计的内容有哪些？

8您的部门采用计算机管理工作情况如何？

9如何改进业务流程使之更合理？

10那些问题是目前传统手工方法根本无法解决的？

11出版社计算机管理信息系统需要解决什么问题？

需求分析

需求分析的任务就是借助于当前系统的逻辑模型导出目标

系统的逻辑模型，解决目标系统的“做什么”的问题。

需求分析的具体任务

＞获得当前系统的物理模型

＞抽象出当前系统的逻辑模型

＞建立目标系统的逻辑模型

理

怎么做

解

模型化:抽象化

导

需

出

枣

一

表

达

具体化；实例化

（物理模型）r--------（逻辑模里）需

求

需求分析建立模型的过程示意图

需求分析

■需求分析建立建模的过程（示例）

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

型，如下图是学生购买教材软件系统的实际建立

模型过程分析。

学生购买教材的实际处理流程——当前系统物理模型

需求分析

■需求分析建立建模的过程（示例）（续）

2.去掉具体模型中的非本质因素，抽取现实系统的

实质，抽象出当前系统的逻辑模型。

领

书

L、

书

单

学

开

领f

生

书

单

，

学生购买教材的逻辑模型

需求分析

■需求分析建立建模的过程（示例）（续）

3.分析当前系统与目标系统的差别，建立目标系统

的逻辑模型

4.对目标系统的逻辑模型进行改进与优化。

5.需求分析的验证。

无效书单

计算机教材管理系统的逻辑模型

需求分析

■需求分析建模方法

软件开发过程实质是：

人通过抽象、归纳把客

观系统变换到软件系统,

并保证软件系统的解等

价客观系统的解；由于

客观系统与软件系统差

异很大，所以变换过程

必须通过一个中间过渡

系统。不同的软件开发

模型采用不同的过渡系

统完成变换过程。

软件系统的本质示意图

需求分析

□结构化分析模型

结构分析方法也就是面向数据流的分析方法，它是最基本

的图形模型是数据流图和数据字典，在表示复杂数据模型时，

一般要求建立实体关系图（ER模型）。另外也可建立状态迁移

图，ER模型是对数据对象的说明，而数据流图是对加工说明，

也就是对数据对象的加工说明。状态变迁图是对控制信息的说

明。数据字典就是对系统的数据结构进行模型化的描述。

状态变迁图

（STD图）

控制说明

需求分析

□结构化分析模型

■结构化分析方法是抽象模型的概念，按照软

件内部数据传递、变换的关系，自顶向下逐

层分解，直到找到满足功能要求的所有可实

现的软件为止。

■抽象和分解是这个方法的主要手段，由于数

据传递与变换而形成的数据流，是这个方法

的主要依据。

D1库存清单

▼库存清单

12「

溥

溥

务

务

等

，1.12

新

仓库更库存信息1.3定货报表

接受产生

库

管理员存处理

事务清正贝报表

工

\J

定货信息

定货信息

D2定货信息

定货系统数据流图

需求分析

□面向对象分析模型

面向对象分析建模型方法是当前使用最多的方法。主要由

现在都是采用面向对象语言编程。目前采用UML模型来建立其

分析模型结构。UML综合其他几种面向对象分析模型，采用很

多种模型方法从不同视角也描述软件逻辑模型。比如，它包括

用例图、类图、顺序图，状态图、协作图。其分化为类模型、

行为模型、关系模型，还有协作等模型。所以它有很多模型方

法来描述软件结构。

支持需求分析的原型化方法

原型是指模拟某种产品的原始模型。在软件开发

中，原型是软件的一个早期可运行的版本，它反映最

终系统的部分重要特性。如果在获得一组基本需求说

明后，通过快速分析构造出一个小型的软件系统，满

足用户的基本要求。使得用户可在试用原型系统的过

程中得到亲身感受和受到启发，做出反应和评价。然

后开发者根据用户的意见对原型加以改进。随着不断

试验、纠错、使用、评价和修改，获得新的原型版本

,如此周而复始，逐步减少分析和通信中的误解，弥

补不足之处，进一步确定各种需求细节，适应需求的

变更，从而提高了最终产品的质量。

支持需求分析的原型化方法

1、开发原型系统原因

把建立原型系统作为一种可能采取的策略的主要理由

＞人类受认识能力局限，不能预先指定所有要求；

＞在用户和系统分析员之间存在固有的通信鸿沟；

＞用户需要“活的”系统模型，以便获得实践经验；

＞在开发过程中重复和反复是必要和不可避免的；

＞目前有快速建立原型系统的工具可供选用(

RationalRose)。

支持需求分析的原型化方法

1、开发原型系统原因

»在开发初期，要想得到一个完整准确的规格

说明不是一件容易的事。特别是对一些大型

的软件项目。

»用户往往对系统只有一个模糊的想法，很难

完全准确地表达对系统的全面要求。

＞软件开发者对于所要解决的应用问题认识更

是模糊不清

支持需求分析的原型化方法

1、开发原型系统原因

＞随着开发工作向前推进，用户可能会产生新的

要求，或因环境变化，要求系统也能随之变化

;开发者又可能在设计与实现的过程中遇到些

没有预料到的实际困难，需要以改变需求来解

脱困境。

＞因此规格说明难以完善、需求的变更、以及通

信中的模糊和误解，都会成为软件开发顺利推

进的障碍。

＞为解决这些问题，逐渐形成了软件系统的快速

原型的概念。

支持需求分析的原型化方法

2、原型的分类

□废弃型：先构造一个功能简单而且质量要求不高的模型系

统，针对这个模型系统反复进行分析修改，形成比较好的

设计思想，据此设计出更加完整、准确、一致、可靠的最

终系统。系统构造完成后，原来的模型系统就废弃不用。

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

探讨多种方案的可行性。它主要针对开发目标模糊，用户和开发者

对项目都缺乏经验的情况

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

明是否可靠

□追加型或演化型：先构造一个功能简单而且质量要求不高

的模型系统，作为最终系统的核心，然后通过不断地扩充

修改，逐步追加新要求，最后发展成为最终系统。

支持需求分析的原型化方法

3、原型类型的选择

□系统结构：联机事务处理系统，相互关联的应用

系统适合于用原型化方法，而批处理、批修改等

结构不适宜用原型化方法

逻辑结构：有结构的系统，如操作支持系统、管

理信息系统、记录管理系统等适合于用原型化方

法，而基于大量算法的系统不宜用原型化方法。

□用户特征：不满足于预先做系统定义说明，愿意

为定义和修改原型投资，不易肯定详细需求，愿

意承担决策的责任，准备积极参与的用户是适合

于使用原型的用户。

支持需求分析的原型化方法

3、原型类型的选择（续）

□应用约束：对已经运行系统的补充，不能用原型

化方法。

□项目管理：项目负责人愿意使用原型化方法，才

适合于用原型化的方法。

□项目环境：需求说明技术应当根据每个项目的实

际环境来选择。

当系统规模很大、要求复杂、系统服务不清晰的

时候，在需求分析阶段先开发一个系统原型是很

值得的。特别是当性能要求比较高时，在系统原

型上先做一些试验也是很必要的。

支持需求分析的原型化方法

4、原型化分析的好处

＞增进软件者和用户对系统服务需求的理

解，使比较含糊的具有不确定性的软件需

求（主要是功能）明确化。

＞软件原型化方法提供了一种有力的学习

手段。

支持需求分析的原型化方法

4、原型化分析的好处

＞使用原型化方法，可以容易地确定系统

的性能，确认各项主要系统服务的可应用

性，确认系统设计的可行性，确认系统作

为产品的结果。

＞软件原型的最终版本，有的可以原封不

动地成为产品，有的略加修改就可以成为

最终系统的一个组成部分，这样有利于建

成最终系统。

支持需求分析的原型化方法

5、原型开发技术

□可执行规格说明

基于场景的设计

□自动程序设计

专用语言

□软件复用技术

□简化假设

3.3,3.3编写需求规格说明书

■需求规格说明书

需求工程最大的成果是得到需求规格说明书。

□需求规格说明书是软件产品开发过程中唯一与用

户共同协商、共同起草的一个文件，它包含了用

户方和开发方两方面的意见，

需求规格说明书作为系统开发各方的共识，是对

系统进行设计、实现、测试和验收的基本依据

■项目经理根据它制定开发计划

■设计人员根据它进行系统设计

■测试人员根据它编写测试计划、设计测试用例

■维护人员根据它理解系统及其中的各个部分间的关系

■用户根据它进行系统的验收，检查系统是否符合要求

编写需求规格说明书

■制定软件需求规格说明的原则

□原则1：功能与实现分离，即描述要“做什么”而

不是“怎样实现”。

□原则2：要求使用面向处理的规格说明语言，讨论来

自环境的各种刺激可能导致系统做出什么样的功能性

反应，来定义一个行为模型，从而得到“做什么”的

规格说明。

□原则3：如果目标软件只是一个大系统中的一个元素

,那么整个大系统也包括在规格说明的描述之中。描

述该目标软件与系统的其他系统元素交互的方式。

□原则4：规格说明必须包括系统运行的环境。

□原则5：系统规格说明必须是一个认识的模型，而不

是设计或实现的模型。

编写需求规格说明书

■制定软件需求规格说明的原则

□原则6：规格说明必须是可操作的规格说明必须是

充分完全和形式的，以便能够利用它决定对于任意给

定的测试用例，已提出的实现方案是否都能满足规格

说明。

□原则7：规格说明必须容许不完备性并允许扩充。

□原则8：规格说明必须局部化和松散的耦合。它所包

括的信息必须局部化，这样当信息被修改时，只要修

改某个单个的段落（理想情况）。同时，规格说明应

被松散地构造（即耦合），以便能够很容易地加入和

删去一些段落。

3.3,3.3编写需求规格说明书

■需求规格说明书框架

1引言

2任务描述

3数据描述

4功能需求

5性能需求

6运行需求

7其他需求

3.3・3.4需求审查

■需求审查的主要内容

系统定义的目标是否与用户的要求一致

系统需求分析阶段提供的文档资料是否齐全

□文档中的所有描述是否完整、清晰、准确反映用

户要求

与所有其他系统成分的重要接口是否都已经描述

□被开发项目的数据流与数据结构是否足够，确定

□所有图表是否清楚，在不补充说明时能否理解

□主要功能是否已包括在规定的软件范围之内，是

否都已充分说明

软件的行为和它必须处理的信息、必须完成的功

能是否一致；

3.3・3.4需求审查

■需求审查的主要内容

设计的约束条件或限制条件是否符合实际

是否考虑了开发的技术风险

是否考虑过软件需求的其他方案

是否考虑过将来可能会提出的软件需求

是否详细制定了检验标准，它们能否对系统定义

是否成功进行确认

□有没有遗漏，重复或不一致的地方

用户是否审查了初步的用户手册或原型

□软件开发计划中的估算是否受到了影响。

3.4图形工具

＞在描绘复杂关系时，图形比文字叙述优越得多，它

形象直观。

＞本节简要介绍需求分析阶段可能用到的三种图形工

具。

3.4.1层次方框图

＞层次方框图用树形结构的一系列多层次的矩形框描

述数据的层次结构。

＞树形结构的顶层是一个单独的矩形框，它代表完整

的数据结构，下面的各层矩形框代表这个数据的子

集，最底层的各个框代表组成这个数据的实际数据

元素（不能再分割的元素）。

3.4.1层次方框图

＞随着结构的精细化，层次方框图对数据结构的描

绘也越来越详细，这种模式非常适合于需求分析

阶段的需要。

»系统分析员从对顶层信息的分类开始，沿图中每

条路径反复细化，直到确定了数据结构的全部细

节为止。

例如，描绘一家计算机公司全部产品的数据结构可

以用层次方框图表示。

3.4.1层次方框图

定货报表

零件

编号

定货报表的层次方框图

3.4.2Warnier图

＞法国计算机科学家Warnier提出了表示信息层次结构

的另一种图形工具，比层次方框图提供了更丰富的

手段。

＞用Warnier图可以表明信息的逻辑组织，也就是说,

它可以指出一类信息或一个信息量是重复出现的，

也可以表示特定信息在某一类信息中是有条件地出

现的。

3.4.2Warnier图

A花括号：区分数据结构的层次，在一个花括号内的

所有名字都属于同一类信息。

＞异或符号㊉：表明一类信息或一个数据元素在一定

条件下才出现，而且在这个符号上、下方的两个名

字所代表的数据只能出现一个。

＞圆括号：中间的数字指明了这个名字代表的信息类

（或元素）在这个数据结构中重复出现的次数。

零件编号一——字符(8)

零件名称一——字符(1,20)

定货数量一——整数。5)

目前价格一——实数

定货报表<厂供电商编号-------字符(8)

主要供应商<供及商名称----字符(1,20)

〔供应商地址-----字符(1,50)

「供应商编号-----字符(8)

,次要供应商

<供成商名称----字符(1,20)

〔供应商地址-----字符(1,50)

定货报表的Warnier图

3.4.3IPO图

＞IPO图是输入/处理/输出图的简称，它是美国

旧M公司发展完善起来的一种图形工具，能够方

便地描绘输入数据、数据处理和输出数据之间

的关系。

＞左框：列出输入数据。

＞中框：列出主要的处理（次序暗示了执行的顺

序）。

＞右框：列出输出数据

＞粗大箭头：指出数据通信的情况。

343IPO图

«A

图3.5IPO图的一个例子

343IPO图

图3.6改进的卬0图的形式

343IPO图

＞在需求分析阶段可以使用IPO图简略地描述系统的

主要算法（即数据流图中各个处理的基本算法）。

＞当然，在需求分析阶段，IPO图中的许多附加信息

暂时还不具备，但是在软件设计阶段可以进一步补

充修正这些图，作为设计阶段的文档。

3.5软件需求验证

3.5.1从哪些方面验证软件需求的正确性

软件系统中15%的错误起源于错误的需求，

因此，应该从下述4个方面进行验证：

(1)一致性，需求不能和其他需求互相矛盾。

(2)完整性，规格说明书应该包括用户需要

的每一个功能或性能。

(3)现实性，指定的需求应该是用现有的硬

件技术和软件技术基本上可以实现的。

(4)有效性，必须证明需求是正确有效的，

确实能解决用户面对的问题。

3.5.2软件需求验证方法

1.验证需求的一致性

自然语言书写的需求，除了靠人工技术审查验

证软件系统规格说明书的正确性之外，目前还没

有其他更好的“测试”方法。

由于人工审查的效果是没有保证的，冗余、遗

漏和不一致等问题可能没被发现而继续保留下来

,以致软件开发不能在正确的基础上顺利进行。

形式化的描述软件需求的方法较好地弥补了上

述缺点。

3.5.2软件需求验证方法

2.验证需求的现实性

为了验证需求的现实性，分析员应该参照以往

开发类似系统的经验，分析用现有的软、硬件技

术实现目标系统的可能性。必要的时候应该采用

仿真或性能模拟技术，辅助分析软件需求规格说

明书的现实性。

3.5.2软件需求验证方法

3.验证需求的完整性和有效性

只有目标系统的用户才真正知道软件需求规格

说明书是否完整、准确地描述了他们的需求。

然而许多用户只有当他们有某种工作着的软件

系统可以实际使用和评价时，才能完整确切地提

出他们的需要。

使用原型系统是一个比较现实的方法。

3.5.3需求评审

基线需求文档

附1需求管理

■需求管理是一组用于帮助项目组在项目进展中的

任何时候去标识、控制和跟踪需求的活动

■需求跟踪有两种方式，正向跟踪与逆向跟踪

□正向跟踪：以用户需求为切入点，检查《需求规约》

中的每个需求是否都能在后继工作产品中找到对应点

□逆向跟踪：检查设计文档、代码、测试用况等工作产

品是否都能在《需求规约》中找到出处

需求管理

需求管理

变更控制版本控制需求跟踪需求状态跟踪

•建议变更•确定需求文•定义对其它•定义需求状

•分析影响档的版本需求的链接态

•作出决策•确定需求文•定义对其它•跟踪需求的

•交流档的版本系统元素的每一个状态

•合并边接链

•测量需求的

稳定性

附2实体•联系图（E・R图）

1、两个实体型之间的联系

用图形来表示两个实体型之间的这三类联系

1:1联系l:n联系m:n联系

实体•联系图（E・R图）

■一对一联系（1:1）

□实例班级

一个班级只有一个正班长

一个班长只在一个班中任职

□定义：

如果对于实体集A中的每一个实体，实

体集B中至多有一个（也可以没有）实体班长

与之联系，反之亦然，则称实体集A与实

体集B具有一对一联系，记为1:1。1:1联系

实体■联系图（E・R图）

■，对多联系（1：n）

□实例

一个班级中有若干名学生，

每个学生只在一个班级中学习

□定义：

如果对于实体集A中的每一个实体，实

体集B中有n个实体（心0）与之联系，反之

,对于实体集B中的每一个实体，实体集A

中至多只有一个实体与之联系，则称实体集

A与实体集B有一对多联系，记为1:n。l:n联系

实体•联系图（E・R图）

■多对多联系（m:n）

□实例

课程与学生之间的联系：

一门课程同时有若干个学生选修

一个学生可以同时选修多门课程

□定义：

如果对于实体集A中的每一个实体，实体集B

中有n个实体（论0）与之联系，反之，对于实体集

B中的每一个实体，实体集A中也有m个实体（m?0

）与之联系，则称实体集A与实体B具有多对多联系

，记为m:n。

m:n联系

实体■联系图(E・R图)

2、两个以上实体型之间的联系

■两个以上实体型之间一对多联系

□若实体集E1，E2,En存在联系，对于实体集Ej

(j=1,2,i-1,i+1,n)中的给定实体，

最多只和Ej中的一个实体相联系，则我们说E1与

,E2,EM,Ei+1,En之间的联系是一对多

的。

实体•联系图（E・R图）

■实例

课程、教师与参考书三个实体型

一门课程可以有若干个教师讲

授，使用若干本参考书，每一个

教师只讲授一门课程，每一本参

考书只供一门课程使用。

两个以上实体型间

l:n联系

实体•联系图（E・R图）

■多个实体型间的一对一联系

一对夫妇一个孩供应商

■两个以上实体型间的多对多联系

m

供应商、项目、零件三个实体型-k

一个供应商可以供给多个项目多种/供应

零件，每个项目可以使用多个供应商/

供应的零件每种零件可由不同供应口/

商供给。/

项目零件

两个以上实体型间m:n联系

实体■联系图（E・R图）

3、ER图-概念模型的一种表示方法

■实体一联系方法（E-R方法）

□用E-R图来描述现实世界的概念模型

E-R方法也称为E-R模型

实体•联系图（E・R图）

■实体型

用矩形表示，矩形框内写明实体名。

学生教师

■属性

用椭圆形表示，并用无向边将其与相应的实体连

接起来

学生

实体■联系图（E・R图）

■联系

□联系本身：

用菱形表示，菱形框内写明联系名，并用无向边分

别与有关实体连接起来，同时在无向边旁标上联系的类

型（1:1、1:n或m:n）。

实体•联系图（E・R图）

■联系的表示方法

1:1联系l:n联系m:n联系

实体•联系图（E・R图）

■联系的表示方法示例

1:1联系l:n联系m:n联系

实体■联系图（E・R图）

♦:♦联系的属性：

课程

联系本身也是一种实体型，也

可以有属性。如果一个联系具有属

性，则这些属性也要用无向边与该

联系连接起来。

学生

实体•联系图（E・R图）

4、一个实例

用E-R图表示某个工厂物资管理的概念模型

■实体

仓库：仓库号、面积、电话号码

零件：零件号、名称、规格、单价、描述

□供应商：供应商号、姓名、地址、电话号码、帐号

□项目：项目号、预算、开工日期

□职工：职工号、姓名、年龄、职称

实体■联系图（E・R图）

■实体之间的联系如下：

（1）一个仓库可存放多种零件，一种零件可以存放在多个

仓库中。仓库和零件具有多对多的联系。用库存量来表示某

种零件在某个仓库中的数量。

（2）一个仓库有多个职工当仓库保管员，一个职工只能在

一个仓库工作，仓库和职工之间是一对多的联系。职工实体

型中具有一对多的联系。

实体■联系图(E・R图)

(3)职工之间具有领导-被领导关系。即仓库主任领导若

干保管员。

(4)供应商、项目和零件三者之间具有多对多的联系。

实体•联系图(E・R图)

(S)(电话号码)

侬应商吩3库而(ML)@话号码)瓢(w)

(W)

(c)完整的实体-联系图

面向数据流的分析过程

■任何信息处理系统的基本功能都是把输入数

据转变成需要的输出信息。

■数据决定了需要的处理和算法，看来数据显

然是分析的出发点。

■结构化分析方法（简称SA方法）就是面向数

据流自顶向下逐步求精进行需求分析的方法

面向数据流的分析过程

■通过可行性研究已经得出了目标系统的高层

数据流图，需求分析的目的之一就是把数据

流和数据存储定义到元素级。

■为了达到这个目的，通常从数据流图的输出

端着手分析，这是因为系统的目标是产生这

些输出，输出数据确定了系统必须具有的最

基本的组成元素。

1、沿数据流图回溯

■输出数据是由哪些元素组成的呢?

■每个输出数据元素又是从哪里来的呢？

■沿数据流图从输出端往输入端回溯，应该能

够确定每个数据元素的来源，与此同时也就

初步定义了有关的算法。

1、沿数据流图回溯

■沿数据流图回溯时常常遇到下述问题：

1.为了得到某个数据元素需要用到数据流图中

目前还没有的数据元素；

2.或者得出这个数据元素需要用的算法尚不完

全清楚。

1、沿数据流图回溯

■为了解决这些问题，往往需要向用户和其他

有关人员请教；

■他们的回答使分析员对目标系统的认识更深

入更具体了，系统中更多的数据元素被划分

出来了，更多的算法被搞清楚了。

1、沿数据流图回溯

■通常把分析过程中得到的有关数据元素的信

息记录在数据字典中，把对算法的简明描述

记录在IPO图中。

■通过分析而补充的数据流、数据存储和处理

,应该添加到数据流图的适当位置上。

2、用户复查

■从输入端开始，分析员借助数据流图以及数

据字典和简明的算法描述向用户解释输入数

据是怎样一步一步地转变成输出数据的。

■用户应该注意倾听分析员的报告，并及时纠

正和补充分析员的认识。复查过程验证了已

知的元素，补充了未知的元素，填补了文档

中的空白。

2、用户复查

■追踪数据流图和复查系统的逻辑模型这两个

步骤实质上构成一个循环。

■在分析员对目标系统的认识螺旋式上升的过

程中，用户及其他和系统有关的人员的参与

是必不可少的：分析过程中产生的问题依靠

他们来回答，分析员对系统的更深入的认识

必须经过他们的检验和确认。

3、细化数据流图

■通过功能分解可以完成数据流图的细化。

■在数据流图中选出一个功能比较复杂的处

理，并把它的功能分解成若干个子功能，

这些较低层的子功能成为一张新数据流图

上的处理，在这张新数据流图上还应该包

括自己的数据存储和数据流。

3、细化数据流图

■分层细化的两条原则：

1.第一，在分层细化时必须保持信息连续性，

也就是说细化前后对应功能的输入/输出数

据必须相同；

2.第二，当进一步细化将涉及如何具体地实现

一个功能时，就不应该再分解了。

3、细化数据流图

■下图粗略地概括了上述分析过程：

3/1、分层数据流图的画法

1.画系统的输入和输出

■把整个软件系统看作一个大的加工，然后根

据系统从外界的哪些源点接受哪些数据流，

以及系统的哪些数据流送到外界的哪些终点

,就可画出系统的输入和输出图。

■这张图称为顶层图。

3」、分层数据流图的画法

2.画系统的内部

■将顶层图中的加工分解成若干个加工，并用数据

流将这些加工连接起来，使得顶层图中的输入数

据流经一连串的加工处理后变换成顶层图的输出

数据流。

■这张图称为0层图。从一个加工画出一张数据流图

的过程实际上就是对这个加工的分解过程。

3/1、分层数据流图的画法

可用下述的方法来确定加工：

■在数据流的组成或值发生变化的地方应画一

个加工，这个加工的功能就是实现这一变化

■也可根据系统的功能确定加工。

3」、分层数据流图的画法

确定数据流的方法可以是：

■当用户把若干个数据看作一个单位来处理（

这些数据一起到达，一起加工）时，把这些

数据看成一个数据流。

■通常可以把实际工作中的单据（如报名单）

作为一个数据流。

■对于一些以后某个时间要使用的数据可组织

成一个数据（文件）存储。

3」、分层数据流图的画法

3.画加工的内部

■我们把每个加工看作一个小系统，该加工的