第三章 需求分析.docx

第三章 需求分析.docx

《第三章 需求分析.docx》由会员分享，可在线阅读，更多相关《第三章 需求分析.docx（11页珍藏版）》请在冰豆网上搜索。

第三章需求分析

第三章需求分析

3.1需求分析的任务

3．1．1目的

精确地定义系统必须做什么，也就是对目标系统提出完整、准确、清晰、具体的要求。

——为目标系统提出精确的逻辑模型。

[注]可行性研究的目的：

确定用户的问题是否存在值得去做的解——提出了解，但可以尽可能的抽象——提出抽象的解，不必提出具体的解。

解=做什么+怎么做

3．1．2主要内容

3．1．2．1确定对系统的综合要求

1.功能需求：

应划分出系统必须完成的所有功能——列举出被开发软件在职能上应做什么，直至“功能单元”。

2.性能需求：

给出被开发软件工作时的技术性能指标，包括：

实时性（联机响应的时间），可靠性（校验码、批量的控制；其度量可用：

平均故障间隔时间/平均修复时间），易用性，安全性（文件存取的限制、功能使用限制、运行日志、异地备份），精确性，存储容量（包括后援存储），资源利用（比如提高处理能力：

减少中间文件的数量、减少文件传输的次数、减少外存访问的次数、减少程序调用和其它系统开销；比如开辟尽可能大的内存空间）等等

3.运行要求：

确定系统运行所处环境的要求，包括：

系统软件，DBMS，硬件，操作员，物理限制等等。

4.将来可能提出的要求：

以便系统今后的扩充和修改。

3．1．2．2分析系统的数据要求

重点：

必须处理的数据、应该产生的信息、数据存储

1．建立完备一致的数据字典

DD主要用于描述数据流和数据存储的详细内容，同时也描述了外部项和处理逻辑的某些数据特征。

DD把数据的最小组成单位看作是数据元素（DataElement）,若干个数据元素组成一个数据结构（DataStructure）,DD就是通过对数据元素和数据结构的定义，来描述数据流和数据存储的逻辑内容的。

[注]DD管理的对象是元数据（MetaData）,元数据是有关系统的各种信息的描述，它表达了系统的全貌，是一部系统的“百科全书”。

元数据类型有：

（1）数据实体类型；

（2）处理实体类型；（3）应用实体类型。

[“二级视图下的数据字典系统”]

2．数据存储结构的规范化

重点：

概念结构设计（E-R图）、逻辑结构设计（E-R图向数据模型转换并规范化）

[注]1970年IBM公司的科德（E.F.Codd）首先提出了规范化理论（NormalizationTheory）：

第一范式（1NF）—2NF—3NF（ThirdNormalForm）—BCNF（Boyce-CoddNormalForm）—4NF—5NF。

3NF基本可以满足应用的要求。

3．数据存取要求分析：

1）可预测性：

可预先定义的存取要求；

2）立即存取要求：

需要立即响应的存取要求；

3）更新程度：

数据的“新鲜”程度。

3．1．2．3导出新系统的逻辑模型

直至所有“功能单元”

3．1．2．4修改项目开发计划

3．2需求分析的过程

（图：

参考当前系统建立目标系统）

【作业】一、画出银行对个人存款、取款业务的DFD；

二、画出图书馆对读者借书、还书服务的DFD；

三、画出一家汽车配件连锁销售公司的DFD。

【实例】开发某种“优化处理”软件，要求：

1．画出该“优化处理”的DFD，其功能至少包括：

（1）检验原始数据；

（2）计算最优解；

（3）编辑最优解；

（4）打印最优结果。

2．将该“优化处理”的DFD变换成软件结构图。

[注]教材2.4例子

图2.5定货系统的基本系统模型（DFD1）

图2.6定货系统的功能级数据流图（DFD2）

图2.7把处理事务的功能进一步分解后的数据流图（DFD3）

3．3结构化分析

结构化分析（StructuredAnalysis，简称SA）

结构化设计（StructuredDesign,简称SD）

结构化分析设计技术（StructuredAnalysisandDsignTechnique,

简称SADT）

SADT是70年代中期由E.Yourdon和L.Constantine等人提出来的一种面向数据流的方法；并在全面分析总结的基础上，形成了一个完整的工程化体系。

该方法要求系统的开发工作按照规定的步骤，遵循特定的规范，使用一定的图表等工具，在结构化和模块化的基础上进行，它系统的运用了描述模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找出满足要求的可实现的软件。

（“结构”的含义是指用一组标准的准则和工具从事某项工作）

在这个方法里，“抽象”，“分解”，“模块化”，“结构化”是它的主要手段；而由数据传递、变换所形成的数据流（Dataflow）和数据流程图（DFD）是它的主要依据。

这个方法最显著的优点是：

直观，自然，易学，易用；它的关键工作是：

画分层的DFD和确定数据定义与加工策略。

[注]SADT方法并没有真正解决“需求定义”，“逻辑模型”的完整性问题！

3．4Yourdon方法的缺陷

其实Yourdon方法是建立在三个假设之上的：

假设1：

所有的需求都是可以预先定义的；

假设2：

需求在较长一段时间内是不变的（相对稳定的）；

假设3：

运用所提供的工具可以做到项目参与者之间清晰、准确、有效的沟通。

这三个假设往往是很难成立的：

（1）完备、一致和正确的需求难以预先定义

a）需求模糊：

即使在用户心目中，需求也常常是模糊的，一个人显然无法完整地说出自己的一切需求；特别是一些处理过程中的经验性的东西，他难以表达，也许也不会想到应该表达出来。

而Yourdon方法却在开始阶段硬要一个只有初步想法的人对需求做出精确的说明，这不是强人所吗？

b）客观多变：

一个组织每时每刻都会发生变化，为了适应新的形势发展，用户的需求也会随之变化。

很显然，客观问题的多变性是信息系统的固有特性，Yourdon方法所依赖的假设恰恰难以容纳这种多变性。

（2）精确的逻辑模型难以构造

因为开发人员不熟悉用户的业务，在一开始就要求构造出精确的逻辑

模型几乎是天方夜谭。

（3）工具“模棱两可”：

工具缺乏精确技术语言的“严密性”、“行业感”

（4）规范、标准难以严格执行

（5）开发周期长，开发效率低

（6）方法上出现“死锁”现象

“逻辑模型”的精确描述依赖于“自顶向下的求精过程”，而“自顶向下的求精过程”的顺利进行又依赖于精确的“逻辑模型”，这二个问题互相缠绕依赖而构成方法学上的“死锁”。

林林总总的现实告诫人们：

Yourdon方法难以适合信息系统的开发！

在上世纪八十年代初人们提出了所谓的系统开发的“原型方法”。

原型法在思想上就突破了传统“瀑布模型”思想中的阶段划分，给软件工程方法学注入了新鲜的血液。

3．5原型法（PrototypingMethodology）

3．5．1基本原理

原型法的基本原理类似于工程设计中广泛应用的制造模型法。

例如，你要修建一座大桥，可先做一个大桥的模型，对此模型进行反复的测试，大量的实验和修改，直至得到一个大家都能接受的、满意的方案为止，再建造大桥。

在这里，我们可以看到：

原型就是模型的意思（原型=模型），它指的是模拟某种产品的原始模型。

但是系统开发的“原型”和大桥的“原型”却有根本的不同，大桥的原型当然不会成为实际的大桥，软件系统的原型却有可能演变成为所需要的最终系统。

这牵涉到我们运用原型的策略。

由于运用原型的目的和方式不同，在使用系统开发的原型时就应采取不同的策略。

3．5．2运用原型的策略

[注]所谓的探索型原型法（ExploratoryPrototyping）、实验型原型法（ExperimentalPrototyping）、演化型原型法（EvolutionaryPrototyping）等等均是无稽之谈。

3．5．3基本过程

在你获得一组基本的需求之后，就快速地加以实现，然后用户和开发人员面对演示着的原型，不断地对系统要求进行补充和细化，逐步地加深了对系统的理解，这意味着这个对原型的逐步求精过程是一个迭代过程。

各种活动往往交融在一起，或合而为一或交叉进行。

对系统的定义、对需求的建立、对设计的完善等等，是在系统的开发过程中逐步迭代完成的，而决非一开始就能预见一切的。

系统开发过程中的所谓各个“阶段”完全交织在一起。

相对于Yourdon方法来说原型法是一个非线性的系统开发方法。

为了更清楚地表述原型法的运用过程，我们给出如下示意图。

3．5．4螺旋模型和渐增模型

基于原型法人们提出了若干种软件开发模型：

（1）Boehm的螺旋模型

分析，建原型，评价与修改

设计，建原型，评价与修改

实现，建原型，评价与修改

[注]沿螺线自内向外每旋转一圈便开发出一个更为完善的软件版本。

（2）Gilb的增量模型

完成一部份分析工作

完成一部份设计工作

完成一部份实现工作

建原型并评价

重复上述过程

[注]原型运用条件：

1）人员融为一体；

2）用户自始至终参加；

3）支撑工具：

最低4GL；

4）不再强调高质量的阶段性文档。

[注]Yourdon方法适合于“预先指定的系统”；

原型法适合于“用户驱动的系统”。