软件工程第三讲教案Word格式.docx
《软件工程第三讲教案Word格式.docx》由会员分享，可在线阅读，更多相关《软件工程第三讲教案Word格式.docx（30页珍藏版）》请在冰豆网上搜索。
软件需求分析是软件生存周期中重要的一步，也是最关键的一步。
只有通过软件需求分析，才能把软件功能和性能研究清楚，并将其描述为具体的软件需求规格说明，进而建立软件开发的基础。
软件需求分析是一个不断认识和逐步细化的过程。
在该过程中能将软件计划阶段所确定的软件范围逐步细化到可详细说明的程度。
制定软件的需求规格说明不仅是软件开发者的任务，而且用户也起着极其重要的作用。
首先用户必须对软件功能和性能提出初步的基本要求，并澄清一些模糊概念。
然后软件分析人员了解用户的要求，认真细致地进行调查研究与分析，把用户要做什么的要求最终转换成一个完全的、细致的软件需求规格说明，准确地表达用户的要求，进而为概要设计做好准备工作。
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．能够表达和理解问题的数据域和功能域
软件定义与开发的目的是实现数据处理，将一种形式的数据转换成另一种形式的数据。
其转换过程必经输入、加工数据和产生结果数据等步骤，其数据域应包括数据流、数据内容和数据结构。
数据流是数据通过一个系统时的变化方式。
输入数据首先转换成中间数据，然后转换成输出结果数据。
在此期间可以从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。
对数据进行转换是程序中应有的功能或子功能。
两个转换功能之间的数据传递就确定了功能间的接口。
数据内容即数据项。
2．按自顶向下、逐层分解问题
系统太大太复杂很难理解。
可以把问题以某种方式分解为多个较易理解的部分，并确定各部分间的接口，从而实现整体功能。
在需求分析阶段，软件的功能域和信息域都能进一步的分解。
这种分解可以是同一层次上的，称为横向分解；
也可以是多层次的纵向分解。
把一个功能分解成几个子功能，并确定这些子功能与父功能的接口，就属于横向分解。
但如果继续分解，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的子功能，这就属于纵向分解了。
3．给出系统的逻辑视图和物理视图
给出系统的逻辑表示又称系统的逻辑视图，物理表示又称系统的物理视图。
这两种视图满足处理需求所提出的逻辑限制条件和提出的物理限制条件必不可少。
进而确定做怎样的实现形式限制，功能限制及算法与数据限制。
如数据字典，就对数据流的条目、文件条目、数据项条目及加工条目进行了具体的规定和限制。
软件需求的逻辑视图给出软件要达到的功能和要处理数据之间的关系，而不是实现的细节。
例如，一个商店的销售处理系统要从顾客那里获取订单，系统读取订单的功能并不关心订单数据的物理形式和用什么设备读入，也就是说无需关心输入的机制，只是获取顾客的订单而已。
类似的，系统中检查库存的功能只关心库存文件的数据结构，而不关心在计算机中的具体存储方式。
软件需求的逻辑描述是软件设计的基础。
软件需求的物理视图给出处理功能和数据结构的实际表示形式，这是由设备决定的。
如一些软件靠终端键盘输入数据，另一些软件靠参数转换设备提供数据。
分析员必须弄清系统元素对软件的限制，并考虑功能和信息结构的物理表示。
3.2需求分析的方法
在这里，讨论一下需求分析方法。
需求分析方法包括对软件的数据域和功能域的系统分析过程及其表示方法，并定义了系统逻辑视图和物理视图的表示方式。
由于需求分析方法是由数据驱动的，所以提供了一种表示数据域的机制。
分析员根据这种表示，确定软件功能及其他特性，建立目标系统的逻辑模型。
数据域具有三种属性：
数据流、数据内容和数据结构。
通常，一种需求分析方法总要利用其中的一种或几种属性。
归纳起来，需求分析方法具有以下的性质。
（1）支持数据域分析的机制
虽然每种分析方法进行数据域分析的方式不同，但它们有共同特点，即都直接或间接地与数据流、数据内容或数据结构等属性有关。
在一般情况下，数据流特征是将输入转换成输出的变换功能过程来描述，数据内容可以用数据字典表示，或者通过描述数据或数据对象的层次结构隐含地表示。
（2）功能表示的方法
功能用数据变换或加工来表示。
每项功能可用规定的记号标识。
说明功能可以用自然语言文本，也可以用形式化的规格说明语言，还可以用上述两种方式的混合方式（结构化语言）。
（3）接口的定义
接口的说明是数据表示和功能表示的结果。
某个功能的流进和流出数据流应是其他相关功能的流出或流入数据流。
因此，通过数据流分析可以确定功能间的接口。
（4）问题分解的机制
问题分解和抽象主要依靠分析员在不同抽象层次上表示数据域和功能域，以逐层细化的手段建立分层结构来实现。
即不仅都能表示这些功能，而且能在这个抽象层次上操纵这个功能。
另外，所有的分析方法都提供一种逐层分解的机制，把总的功能划分成一些子功能，每项子功能还可以在更低的一级抽象层次上表示。
（5）逻辑视图和物理视图
大多数方法允许分析员在提出问题的逻辑解决方案之前先分析物理视图，同一种表示法既可用来表示逻辑视图，也可用来表示物理视图。
（6）系统抽象模型
为了比较精确地定义软件需求，可建立待开发软件的一个抽象的模型。
用基于抽象模型描述软件系统的功能和性能，形成软件需求规格说明。
这种抽象的模型是从外部现实世界的问题领域抽象而来，在高级层次上描述和定义系统的服务。
比较简单的问题，不必建立抽象系统模型。
系统模型可在分析员头脑中形成，直接由分析员写成规格说明。
但对于较复杂的问题，必须建立形式化的抽象系统模型，才能准确全面地反映问题领域中各种复杂的要求。
不同类型的问题有不同的需要解决的中心问题，因而需建立不同类型的系统模型。
如数学软件，设计的中心问题是算法，软件人员的主要力量要用在数学模型算法的考虑上。
而对于数据通信软件，中心问题是数据传送和过程控制，实现算法简单，采用数据流模型比较合适。
对于涉及大量数据的数据处理软件，中心问题是数据处理，包括数据的采集、数据的传送、存储、变换、输出等，一旦明确了数据结构，与它相关的算法就很简单了，因此可以采用面向数据结构的模型。
系统模型的建立过程是对现实世界中存在的有关实体和活动的抽象和精化，如图3-2所示，包括观察分析、模型表示和模型检查三个阶段。
第一阶段分析员和用户合作，从各方面观察现实世界中的有关实体和活动，建立理解的共同基准。
第二阶段分析员和用户在共同理解的基础上建立系统模型，包括系统提供的各种系统服务，模型表示的细节：
系统输入、系统输出、系统数据处理、系统控制等。
第三阶段进行模型检查。
除了静态检查之外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界观察得到的系统跟踪信息进行对照，检查模型是否达到要求。
3.2.1面向数据流的需求分析方法
结构化分析方法是面向数据流进行需求分析的方法。
于20世纪70年代末由E.Yourdon等人提出，至今已得到广泛应用，结构化分析方法的一些重要概念也应用到其他方法中。
结构化分析方法使用数据流图DFD与数据字典DD来描述，面向数据流问题的需求分析适合于数据处理类型软件的需求描述。
其核心思想是分解化简问题，将物理与逻辑表示分开，对系统进行数据与逻辑的抽象。
具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的可实现的软件为止。
由于这种方法利用图形来表达需求，显得清晰、层次分明，易于学习和掌握。
但其不能表达复合逻辑的需求分析问题，也不能详细表达加工。
3.2.2数据流图
数据流图也简称为DFD（Data
Flow
Diagram的英文缩写）,它是描述数据处理过程的工具。
1．数据流图的定义
数据流图从数据传递和加工的角度，以图形的方式描述数据流从输入到输出的传输变换过程。
数据流图是结构化系统分析的主要工具，它表示了系统内部信息的流向，并表示了系统的逻辑处理的功能。
2．数据流图的特性
（1）抽象性
在数据流图中，具体的组织机构、工作场所、物质流等都去掉，仅剩下信息和数据存储、流动、使用以及加工的情况。
这有助于抽象地总结出信息处理的内部规律。
（2）概括性
数据流图把系统对各种业务的处理过程联系起来考虑，形成一个总体，具有概括性。
数据流图描述的主体是抽象出来的数据。
（3）层次性
数据流图具有层次性，一个系统将用多层次的数据流图描述。
3.数据流图基本符号
（1）数据流图中的主要图形元素
数据流图的基本图形元素有4种，有时为了使数据流图便于在计算机上输入和输出，免去画曲线、斜线和圆的困难，常使用对应的另一套符号，这两套符号完全等价。
如图3-3所示。
图3-3数据流图基本图形符号
在数据流图中，数据流是沿箭头方向传送数据的通道，它们是在加工之间传输被加工数据的命名通道。
也有连接数据存储文件和加工没有命名的数据通道。
这些数据流虽然没有命名，但因联接的是有名加工和有名文件，所以其含义也是清楚的。
同一数据流图上不能有同名的数据流。
多个数据流可以指向同一个加工，也可以从一个加工发出许多数据流。
加工是以数据结构或数据内容作为加工对象。
加工的名字通常是一个动词短语，简明地表明完成的是什么加工。
文件在数据流图中起保存数据的作用，因而称为数据存储，它也可以是数据库。
指向文件的数据流可理解为写入文件或查询文件，从文件中引出的数据流可理解为从文件读取数据或得到查询结果。
数据流图中第1种元素是数据源点或汇点，它表示图中要处理数据的输入来源或处理结果要送往何处。
由于它在图中的出现仅仅是一个符号，并不需要以软件的形式进行设计和实现，因而，它只是数据流图的外围环境中的实体，故称外部实体。
在实际问题中它可能是人员、计算机外围设备或是传感装置。
（2）数据流与加工之间的关系
图3-4数据流图加工关系
在数据流图中，如果有两个以上数据流指向一个加工，或从一个加工中引出两个以上的数据流，这些数据流之间存在一定的关系。
在图3—4中给出描述这些关系所用符号及其含义。
其中星号“*”表示相邻的一对数据流同时出现，⊕则表示相邻的两数据流只取其一。
（3）分层的数据流图
为了表达数据处理过程的数据加工情况，用一层数据流图是不够的，需要按照问题的层次结构进行逐步分解，并以多层的数据流图反映这种结构关系。
先把整个数据处理过程暂且看成一个加工，它的输入数据和输出数据实际上反映了系统与外界环境的接口，这就是分层数据流图的顶层。
但仅此一层并未表明数据的加工要求，需要进一步细化。
如果一个数据处理包括3个子系统，就可以画出表示这3个子系统1、2、3的加工及其相关的数据流。
这是顶层下面的第一层数据流图,继续分解这3个子系统，可得到第二层数据流图，它们分别是子系统1、2和3的细化。
这样得到的多层数据流图可十分清晰地表达整个数据加工系统的真实情况。
对任何一层数据流图来说，称它的上层图为父图，在它下一层的图则称为子图。
在多层数据流图中，可以把顶层流图、底层流图和中间层流图区分开来。
顶层流图仅包含一个加工，它表示被开发系统。
它的输入流是该系统的输入数据，输出流是系统的输出数据。
顶层流图的作用在于表明被开发系统的范围，以及它和周围环境的数据交换关系。
底层流图是指其加工不须再做分解的数据流图，其加工称为“原子加工”。
中间层流图则表示对其上层父图的细化。
它的每一加工可以继续细化，形成子图。
中间层次的多少视系统的复杂程度而定。
4．数据流图的用途
利用数据流图把对现有系统的认识或目标系统的设想描绘出来，供有关人员审查确认。
由于在数据流图中通常仅使用四种基本符号，而且不包含任何有关物理实现的细节，因此，绝大多数用户都可以理解和评价它。
数据流图的作用主要有以下几条：
（1）系统分析员用这种工具可以自顶向下分析系统信息流程。
（2）可在图上画出需要计算机处理的部分。
（3）根据数据存贮，进一步作数据分析，向数据库设计过渡。
（4）根据数据流向，定出存取方式。
（5）对应一个处理过程，用相应的语言、判定表等工具表达处理方法。
5．数据流图的特点
（1）总体概念强，每一层都明确强调干什么，需要什么，给出什么。
（2）可以反映出数据的流向和处理过程。
（3）由于自顶向下分析，容易及早发现系统各部分的逻辑错误，也容易修正。
（4）容易与计算机处理相对照。
（5）不直观，一般都要在作业流程分析的基础上加以概括、抽象、修正来得到。
如果没有计算机系统帮助的话，人工绘制太麻烦，工作量较大。
6．数据流图画法
（1）画数据流图的一般原则
画数据流图的基本原则是:
就是自外向内，自顶向下，逐层细化，完善求精。
具体步骤如下。
①先找系统的数据源点与汇点。
它们是外部实体，由它们确定系统与外界的接口。
②找出外部实体的输出数据流与输入数据流。
③在图的边上画出系统的外部实体。
④从
升级会员 