软件工程第三讲教案.docx

软件工程第三讲教案.docx

《软件工程第三讲教案.docx》由会员分享，可在线阅读，更多相关《软件工程第三讲教案.docx（30页珍藏版）》请在冰豆网上搜索。

软件工程第三讲教案

教案首页

周次日期课时序

课题

软件需求分析

教学目的

要求

理解需求分析阶段所要完成的工作目标；掌握需求分析的

分析方法

重点

理解需求分析的工作目标

难点

掌握分析方法

教学过程

设计

及

时间分配

第三章软件需求分析（2*45‘）

第一节需求分析的任务与步骤（30‘）

第二节需求分析的方法（30‘）

第三节图形工具（15‘）

第四节需求规格说明与评审（15‘）

教学场所

或教学方法

使用

教具

作业

课后记

授课教师

第三章软件需求分析

3.1需求分析的任务与步骤

软件需求分析是软件生存周期中重要的一步，也是最关键的一步。

只有通过软件需求分析，才能把软件功能和性能研究清楚，并将其描述为具体的软件需求规格说明，进而建立软件开发的基础。

软件需求分析是一个不断认识和逐步细化的过程。

在该过程中能将软件计划阶段所确定的软件范围逐步细化到可详细说明的程度。

制定软件的需求规格说明不仅是软件开发者的任务，而且用户也起着极其重要的作用。

首先用户必须对软件功能和性能提出初步的基本要求，并澄清一些模糊概念。

然后软件分析人员了解用户的要求，认真细致地进行调查研究与分析，把用户要做什么的要求最终转换成一个完全的、细致的软件需求规格说明，准确地表达用户的要求，进而为概要设计做好准备工作。

3.1.1需求分析的任务

需求分析是软件计划时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么”这个问题。

需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件与其它系统元素的接口细节，描述软件的其它有效性需求。

分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示，在软件完成后，制定的软件需求规格说明还要为评价软件质量提供依据。

需求分析阶段研究的对象是软件项目的用户需求。

虽然在可行性研究阶段已经粗略了解了用户的需求，甚至还提出了一些可行的方案，但是，忽略了许多细节。

所以可行性研究并不能代替需求分析。

需要注意的是，必须全面理解用户的各项要求，但又不能全盘接受用户所有的要求。

因为并非所有用户要求都是合理的。

对其中模糊的要求还需要澄清，然后才能决定是否可以采纳。

对于那些无法实现的要求应向用户做出充分的解释说明。

明确地表达所接受的用户要求，是需求分析的另一个重要方面。

只有经过确切描述的软件需求才能成为软件设计的基础。

　　软件开发项目是要求实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中。

这是软件实现的基础。

但是目标系统的具体物理模型是将其逻辑模型实例化，即具体到某个业务领域。

与物理模型不同，逻辑模型忽略具体实现机制与细节，只描述系统要完成的功能和要处理的数据。

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

其实现步骤的描述如图3-1所示。

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

可行性研究阶段产生的文档，特别是数据流图，是需求分析的出发点。

在数据流图中已经给出系统必须完成的许多基本功能，在需求分析阶段将仔细研究这些功能并进一步将它们具体化。

在这个阶段结束时交出的文档中应该包括详细的数据流图，数据字典和简明的算法描述。

需求分析的结果是系统开发的基础，是工程的成功和优秀软件产品的保证。

因此，除了对目标系统提出完整、准确、清晰、具体的要求描述外，必须加强对软件需求进行严格的审查验证。

一般说来，需求分析阶段的任务包括下述几方面。

1．确定对系统的综合需求

对系统的综合需求主要有：

系统功能需求、系统性能需求、运行需求、将来可能提出的需求。

系统分析人员与用户协商，澄清模糊需求，删除无法做到的需求，改正错误需求。

对于系统功能需求，应该划分出系统必须完成的所有功能。

而系统性能需求包括：

响应时间、精确度指标需求、安全性等。

运行需求集中表现为对系统运行时所处环境的需求。

如软硬件运行环境需求等。

最后，对于将来可能提出的需求，应该明确地列出那些虽然不属于当前系统开发范畴，但是根据分析将来很可能会提出来的需求。

这样做增强了被设计系统的可扩展性，在设计过程中对系统将来可能的扩充和修改做准备，以便于需要时能比较容易地进行这种扩充和修改，更有利于系统维护。

2．分析系统的数据需求

任何一个软件系统实际上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的结构。

分析系统的数据需求是由系统的信息流归纳抽象出数据元素组成，数据的逻辑关系，数据字典格式，数据模型。

并以输入/处理/输出的结构方式表示。

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

3．提出系统的逻辑模型

在理解当前已存在系统结构的基础上，抽取其做什么的本质。

需要对当前已存在系统的物理模型进行分析，区分本质和非本质因素，去掉那些非本质因素就可获得反映系统本质的逻辑模型。

在综合上述分析的结果和明确目标系统要做什么的基础上，可以提出要设计的软件系统的逻辑模型。

具体做法是：

首先确定目标系统与当前系统的逻辑差别；然后将变化部分看作是新的处理步骤,对功能图（一般为数据流图）及对象图进行调整；最后由外及里对变化的部分进行分析，推断其结构，获得目标系统的逻辑模型。

通常用数据流图、数据字典和主要的处理算法描述逻辑模型。

4．修正系统开发计划

在经过需求分析阶段的前述工作之后，分析员对目标系统有了更深入更具体的认识，因此可以对系统的成本和进度做出更准确的估计，在此基础上应该对开发计划进行修正。

5．开发原型系统

在第一章中已介绍了几种主要的软件开发模型，许多方法都涉及到了原型系统问题，这里就是指开发原型系统。

在许多工程产品的设计过程中经常使用样机。

建造样机的主要目的是：

检验关键设计方案的正确性及系统是否真正满足用户的需要。

对于软件系统的开发，使用原型系统的主要目的是，使用户通过实践获得未来的系统将怎样工作，从而可以更准确地确定他们的要求。

建立原型系统能够解决下述问题：

由于认识能力的局限而不能预先指定所有要求；在用户和系统分析员之间存在的通信鸿沟；用户需要一个现实的系统模型，以便获得实践经验；而且在开发过程中重复和反复是必要的和不可避免的；

采用原型系统策略也带来了的成本增加副作用。

但是，由于正确地提出用户需求是软件开发工程成功的基础，所以原型系统采用逐渐增多。

尤其是目前较好的软件开发工具的出现，为快速建立软件的原型系统建立了可实施的基础。

3.1.2需求分析的步骤

在前面已介绍了需求分析的主要任务，只有在需求分析中采取正确的步骤才能完成上述任务，需求分析的步骤如下。

1．调查研究

分析人员与程序员共同研究系统数据的流程、调查用户需求或查阅可行性报告、项目开发计划报告，访问现场，获得当前系统的具体模型，以IPO图或DFD图表示。

把从外面输入到系统中来的或者是通过计算由系统中产生出来的数据输出。

要确定输出数据的元素组成及其来源，并沿数据流图从输出端往输入端回溯，以确定每个数据元素的来源，定义有关的算法。

但是，由于高层数据流图不包括具体的细节，因此沿数据流图回溯时常遇到下述问题：

为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法不清楚。

为了解决这些问题，通过用户向其他相关人员研究，使分析员对目标系统的认识更深入更具体，系统中更多的数据元素被划分出来，算法更清楚。

把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中，把通过分析而补充的数据流、数据存储和处理，应添加到数据流图中。

还有许多问题存在，如数据字典准确性和完整性、算法的正确性和有没有遗漏必要的处理或数据元素等。

一个系统的详细信息只能来源于直接在这个系统上工作的系统的用户。

因此，用户对前一个分析步骤中得出的结果仔细地进行复查。

用户应该注意倾听分析员的报告，确定对目标系统的认识是否正确、有无遗漏，并及时纠正和补充分析员的认识。

复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。

追踪数据流图和复查系统的逻辑模型这两个步构成一个循环。

对数据流图的分析产生问题，这些问题也可能又引出新的问题，每经过一次循环都会了解到未来的逻辑系统的更多细节。

2．分析与综合

问题分析和方案的综合是需求分析的第二步工作。

分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制。

通过分析确定满足功能要求的程度，根据功能需求，性能需求，运行环境需求等，删除其不合理的部分，增加其需要部分，最终给出目标系统的详细逻辑模型。

在这个步中，分析和综合工作反复地进行。

在对现行问题期望的输入和输出信息进行分析的基础上，分析员开始综合出一个或多个解决方案，然后检查它的工作是否符合软件计划中规定的范围等等，再进行修改。

对分析和综合的过程将一直到分析员与用户都可正确地制定该软件的规格说明为止。

经过上述分析过程，分析员越来越深入地定义了系统中的数据和系统应完成的功能。

为了追踪更详细的数据流，分析员把数据流图扩展到更低的层次。

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

在数据流图中选出一个功能比较复杂的处理，并把它的功能分解成若干个子功能，较低层的子功能在一张新数据流图上的处理，在这张新数据流图上还包括数据存储和数据流。

应注意下述两条原则：

①在分层细化时必须保持信息连续性，也就是说细化前后对应功能的输入／输出数据必须相同；②当进一步细化将实现一个具体地功能时，也就是当把一个功能进一步分解成子功能后，为了完成这些子功能需要写出的程序代码时，就不应该再分解了。

3．书写文档

经过分析确定了系统必须具有的功能和性能，定义了系统中的数据并且简略地描述了处理数据的主要算法。

下一步应该把分析的结果用正式的文档记录下来，作为最终软件配置的一个组成成分。

根据需求分析阶段的基本任务，在这个阶段应该完成下述四份文档资料：

（1）系统规格说明。

主要描述目标系统的概述、功能要求、性能要求、运行要求和将来可能提出的要求。

在分析过程中得出的数据流图是这个文档的一个重要组成部分，用IPO图或其他工具简要描述的系统算法是文档的另一个重要组成部分。

此外，这个文档中还应包括用户需求和系统功能之间的参照关系以及设计约束等。

（2）数据要求。

主要包括在需求分析建立的数据字典以及描绘数据结构的层次方框图或Warnier图，还应该包括对存储信息（数据库或普通文件）分析的结果。

（3）用户系统描述。

这个文档从用户使用系统的角度描述系统，相当于一份初步的用户手册。

内容包括对系统功能和性能的扼要描述，使用系统的主要步骤和方法以及系统用户的责任等。

这个初步的用户手册使得未来的用户能从使用的角度检查该目标系统，因而比较易于判断这个系统十分符合他们的需要。

（4）修正的开发计划。

经过需求分析阶段的工作，分析员对目标系统有了更深入更具体的认识，因此可以对系统的成本和进度作出更准确的估计，在此基础上应该对开发计划进行修正。

包括修正后的成本计划、资源使用计划和进度计划等。

4．需求分析评审

作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性以及其他需求给予评价。

3.1.3需求分析的原则

目前已出现许多分析方法。

虽然各种分析方法都有独特的描述方法，但所有分析方法有共同的基本原则。

1．能够表达和理解问题的数据域和功能域

软件定义与开发的目的是实现数据处理，将一种形式的数据转换成另一种形式的数据。

其转换过程必经输入、加工数据和产生结果数据等步骤，其数据域应包