第3章需求分析a.pptVIP

第3章 需求分析 需求分析要求详细、准确地分析清楚系统必须“做什么”，有时又称为软件系统分析，它处于软件工程的开始部分，提供了构建软件项目其余部分的根基，关系到软件开发的成败。同时，随着面向对象（OO）、可视化编程（VP）、计算机辅助软件工程（Computer Aided Software Engineering，简称为CASE）等软件开发技术的发展和应用， 软件设计、编码、测试等环节的技术日益成熟和稳定，需求工程却由于没有可现成套用的方法成为一个困难的课题，因此目前软件工程学科的焦点和重心正呈现出逐渐转移到前期需求阶段的趋势。只有通过软件需求分析，才能把用户对软件功能和性能的总体要求描述为具体的软件需求规格说明，从而奠定软件开发的基础。  3.1 需求分析的目标与原则 软件需求是指用户对目标系统在功能、行为、性能等方面的期望。需求分析是发现、求精、建模和产生规格说明的过程，软件开发人员需要对应用问题及环境进行理解和分析，为问题涉及的信息、功能及行为建立模型。需求分析实际上是对系统的理解与表达的过程，是一种软件工程的活动。 3.1.1 需求分析的目标 A4：决定系统应该做什么。A5：决定系统不应该做什么。A6：确认系统将能够满足用户的需要，并且定义相应的验收标准。A7：为系统开发提供一个基础。 3.1.2 需求分析的原则 近年来已提出了大量的分析建模方法，虽然各种方法都有独特的描述方法，但在进行软件的需求分析时，都应该遵循一些基本的原则 1）必须能够表达和理解问题的数据域和功能域 理解和表示问题的信息域，可用数据模型描述；定义软件将完成的功能，可用功能模型描述；表示软件的行为（服务、操作），可用行为模型描述。 软件定义与开发工作的最终目的是解决数据处理问题，就是将一种形式的数据转换成另一种形式的数据。其转换过程必须经历数据输入、加工和产生结果等步骤。对于计算机程序处理的数据，其数据域应包括数据流、数据内容和数据结构。 2）必须自顶向下、逐层分解和细化问题对描述的信息、功能和行为模型必须被划分，使分析模型可以用层次的方法展示细节。划分就是把系统进行分解。一个庞大而又复杂的问题在整体上往往很难被完全理解，为此，人们常常把一个复杂问题分解成若干个子问题，如果问题被分解后，还不足以被理解，又把子问题再进一步分解，直到问题能被完全理解为止。分析过程应该从要素信息移到实现细节。可以采用逐步求精的技术。如图3-2所示，问题的分解包括横向分解和纵向分解。 3）必须给出系统的逻辑视图和物理视图给出系统的逻辑视图（逻辑模型）和物理视图（物理模型），对满足处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制条件是必不可少的。 3.2 需求分析的过程及方法 3.2.1 需求分析的过程 为了确保分析结果的一致性、全面性、精确性，软件 需求分析过程要有用户的参与和积极的协助。就需求分析而言，一个系统的成功与否，开发者与用户双方的合作是非常重要的。需求开发是分析人员对问题及环境的理解、分析与综合，建立目标系统的模型，最后形成软件需求规格说明 。需求分析过程如图3-3所示。 需求分析工作可以分成以下4个过程1 . 问题获取2.　需求分析3.　需求规格说明4.　需求评审 3.2.2 需求分析方法 需求分析的方法虽然种类繁多，但根据目标系统被分解的方式不同，基本上可以分辨出它们是属于哪一类广泛应用的方法。20世纪70年代，开发和推出了各种冠以“结构化分析（Structured Analysis，简称SA）”头衔但各具特色的方法。直到20世纪90年代初，结构化分析方法才面临严峻的挑战，同时，面向对象分析方法（Object Oriented Analysis，简称OOA）已悄然成型，而且同样也是随之出现了大批派生的方法。 如今，对于面向对象分析方法的批评已经开始出现，一类所谓的第三种方法（尚未命名但却是基于问题框架的）正发展成形，我们称之为面向问题域的分析方法（Problem Domain Oriented Analysis，简称PDOA）。 1.结构化分析 综合性的结构化分析方法正是通过开发各种“模型”而利用了这一点。结构化分析，使用数据流建模方法，主要工具是数据流图（Data Flow Diagram，简称DFD），来对问题进行分析。结构化分析一般包括下列工具： 数据流图（data flow diagram，简称DFD） 数据字典（data dictionary，简称DD） 结构化语言 判定树 判定表 DFD模型也可以看作是一种行为模型。从理论上讲，这是可能的，并且假如只是涉及那些“