软件工程导论第3章需求分析.docx

软件工程导论第3章需求分析.docx

《软件工程导论第3章需求分析.docx》由会员分享，可在线阅读，更多相关《软件工程导论第3章需求分析.docx（8页珍藏版）》请在冰豆网上搜索。

软件工程导论第3章需求分析

第三章软件需求分析

虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一些可行的方案，但是可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法。

因此许多细节被忽略了。

然而在员终的系统中却不能遗漏任何一个微小的细节，所以可行性研究并不能代替需求分析，它实际上并没有准确地回答“系统必须做什么？

”这个问题。

需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

软件需求分析是一个不断进行揭示和判断的过程。

3.1需求分析的任务

3.1.1确定系统的综合要求

1功能需要

划分出系统必须完成的所有功能

2性能需要

系统必须满足的定时约束或容量约束

速度（系统的响应时间）

信息速率

主存容量

磁盘容量

安全性

3.1.2分析系统的数据要求

任何一个软件系统其本质上都是一个信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的概貌，同时也对软件设计有着深远的影响。

分析系统的数据要求，这是软件需求分析的一个重要任务。

分析系统的数据要求通常采用建立数据模型的方法

系统的数据来源和去处一般含如下几个方面：

（1）从系统以外来，再到系统以外去；

（2）从系统以外来，再到系统内部去；

（3）从系统内部来，再到系统内部去；

（4）从系统内部来，再到系统外部去。

3.1.3导出系统的逻辑模型

用数据流图、实体--关系图、状态转换图、数据字典、主要的处理算法描述逻辑模型。

3.1.4修止系统开发计划

准确地估计系统的成本及进度，修正以前我们所制定的开发计划。

3.2与用户沟通获取需求的方法

321访谈

情景分析技术就是分析对用户将来使用目标解决问题的方法

某个具体问题的方法和结果进行分析。

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

3.23简易的应用规格说明技术

3.24快速建立软件原型

3.3分析建模与规格说明

3.3.1分析建模

1建模：

是为了理解事物而对事物做出的一种抽象，是对事物

的一种无歧义的书面描述。

模型由一组图形符号和组织这些符号的

规则组成

2模型与工具

数据模型一实体-关系图

功能模型一数据流图

行为模型一状态转换图

3.3.2软件需求规格说明

用自然语言完整、准确、具体描述系统的数据需求、功能需求、

性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求、将来可能提出来的需求

3.4实体-关系图

3.4.1数据对象数据对象：

是对软件必须理解的复合信息的抽象。

复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物不是数据对象。

数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构

数据对象彼此间是有关联的，它只封装了数据，没有对数据的操作

3.4.2属性定义了数据对象的性质，属性用标识符表示

3.4.3联系数据对象彼此之间相互连接的方式称为联系，也称为关系。

联系分为3种类型。

（1）一对一联系（1:

1）例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。

（2）一对多联系（1:

N）例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。

（3）多对多联系（M:

N）

例如，表示学生与课程间的联系（“学”）是多对多的，即一个

学生可以学多门课程，而每门课程可以有多个学生来学。

3.4.4实体-关系图的符号

实体-关系图简称ER图

3.5数据规范化

为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。

通常用“范式”定义消除数据冗余的程度。

第一范式数据冗余

程度最大，第五范式数据冗余程度最小。

但是，范式的级别越高，存储同样数据就需要分解成更多张表，因此，‘存储自身'的过程也就越复杂。

第二，随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。

第三，范式级别提高则需要访问的表增多，因此性能（速度）将

下降。

从实用角度看来，在大多数场合选用第三范式都比较恰当。

下面给出第一、第二和第三范式的定义：

（1）第一范式:

每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。

（2）第二范式:

满足第一范式条件，而且每个非关键宇屑性都由

整个关键字决定（而不是由关键字的一部分来决定）。

（3）第三范式：

符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字局性的进一步描述（即一个非关镑字属性值不依赖于另一个非关键字属性值）。

3.6状态转换图

状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

此外，状态图还指明了作为特定事件的结果将做哪些动作。

因此，状态图满足了行为建模的机制

3.1状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。

状态规定了系统对事件的响应方式。

系统对事件的响应，既可以做一个（或一系列）动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态有改变动作。

状态图既可以表示系统循环运行过程，也可以表示单程生命期。

3.6.2事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换的另一个状态的外界事件的抽象。

事件就是引起系统做动作或转换状态的控制信息。

363符号

364例子

3.7其他图形工具

3.7.1层次方框图

层次方框图是用树形结构的一系列多层次的矩形框描绘数据

的层次结构。

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

数据结构。

下面各层的矩形框代表这个数据的子集，最低层的各个

框代表组成这个数据的实际数据元素（不可再分割）。

描绘一家计算

机公司全部产品的数据结构图如下口

3.7.2Warnier图

Warnier图是由法国计算机科学家J.D.Warnier提出的表示信

息层次结构的另外一种图形工具。

在Warnier图中花括号用来区分数据结构的层次，在一个花括

号内的所有名字都属于同一类信息；符号表示在其上、下方的名字

中的一个名字；名字右边圆括号中的符号表示这个名字在信息类中

重复出现的次数口

3.7.3IPO图

IPO图是输入/处理/输出图的简称，它是由美国IBM公司发展

完善起来的一种图形工具，可以方便地表示输入数据、数据处理和输出数拯三者之间的关系。

3.8验证软件需求

3.8.1验证软件需求的途径与方法

一致性：

在所有需求中，任何一条需求不能和其他需求互相矛

盾。

形式化描述

完整性：

软件规格说明书必须包括用户需求的每一个功能或性

能。

原型

现实性：

指定的需求应该是用现有的硬件技术和软件技术基本

上可以实现的。

仿真和模拟

有效性：

软件需求确实能解决用户所而对的问题口原型

3.8.3用于需求分析的软件工具

PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、

数据导出、系统规模、系统动态、系统性质和项目管理等八个方面描述信息系统。

一旦用PSL对系统做了完整描述，就可以调用PSA产生一组分

析报告，其中包括所有修改规格说明数据库的记录，用各种形式描述数据库信息的参照报告（包括图形形式的描述），关于项目管理信息的总结报告，以及评价数据库持性的分析报告。

借助PSL/PSA系统可以边对目标系统进行自顶向下的逐层分

解，边将需求分析过程中遇到的数据流、文件、处理等对象用PSL描述出来并输入到PSL/PSA系统中。

PSL将对输入信息作一致性和

完整性检查，并且保存这些描述信息

能保证文档具

PsL/P5A系统的主要优点是它改进了文档质量，

有完整性、一致性和无二义性，从而可以减少管理和维护的费用

图3.1面向数据流自顶向下求精过程

状态1

f、

状态2

初始事件

状态变量1

事件表达式

状态变量2结束事件

活动表1

活动表2

图3.3状态图中使用的主要符号

闲置

-拿起听筒

«口、好号曰

timer=0

超时

do/想拨

超时

do/响蜂鸣音

数字

号音且增

加timer

Y数字

号无效号码

存储的信息

do/播放信息

信息播完

-【通话丿

‘受话人挂断电话

■（、断线:

图3.4电话系统的状态图

图3.5层次方框图的一个例子

［操作系统（P1）

编译程序（P2）

£系统软*

「编译程序（P3）

I软件工｛测试驱动程序（P4）软件产品\㊉

I设计辅助工具（P5）

应用软

1.校验

有效的

旧的主文件

主纪录

》主纪录

事务文件

、

2.校验

有效的

A

事务纪录

事务纪录

3•更新

更新后的

主纪录

>>

主文件

图3.7IPO图的一个例子

IPO表

系统：

作者：

模块：

日期：

编号：

局部数据元素：

注释:

图3.8改进的IPO图的形式