需求分析概述_9

1、软件学院软件学院代飞代飞2013.2013.春春需求分析的根本任务建立分析模型建立解决方案需求分析技术需求分析方法前期需求阶段的建模与分析需求分析的活动业务需求业务需求项目前景文档项目前景文档项目范围文档项目范围文档1 1、需求获取的信息只是描述了涉众对软件系统的期望，、需求获取的信息只是描述了涉众对软件系统的期望，软件开发者无法轻易将这些期望转换为软件解决方案。软件开发者无法轻易将这些期望转换为软件解决方案。2 2、需求获取的各种文档中存在错误、遗漏、不一致性。、需求获取的各种文档中存在错误、遗漏、不一致性。用户需求及用户需求及问题域特性问题域特性建立分析模型将复杂的系统分解成为简单的部分以

2、及它们之间的联系，确定本质特征和用户达成对信息内容的共同理解分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息创建解决方案将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找解决方案创建解决方案的过程是创造性的帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关系这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案的正确性。“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解” 集中关注问题的计算特性（数据、功能、规则等等） 建模是对系统进行抽象的一种方式。其目标是建立系统的一个表示，便于更深刻的理解系统，更好地与用户进行交流。建模方

3、法抽象分解投影抽象（Abstraction）一方面要求人们只关注重要的信息，忽略次要的内容通过强调本质的特征，就减少了问题的复杂性另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节在问题的各元素之间推断出更广泛和更普遍的关系，帮助人们寻找解决方案分解（Decomposition / Partitioning）“分而治之”将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系分解的方案往往还能提供问题的解决思路投影（Projection）多视点方法：只关注事物的某一个方面抽象客观存在模型计算机理论模型：图灵机模型是从客观存在中“切”下来的相对完整的一部分。进行

4、建模时，首先要弄清楚应该对哪些方面进行建模，而哪些方面不应该建模。抽象物理模型模型是对复杂系统的简化和抽象模型是对复杂系统的简化和抽象它关注于特定的组元和组元之间的关系，同时它关注于特定的组元和组元之间的关系，同时忽略与组元无关的次要信息忽略与组元无关的次要信息在需求分析中的模型应该关注什么样的在需求分析中的模型应该关注什么样的组元呢？组元呢？计算世界与计算模型使用软件的构成单位作为模型的组元软件构建单位之间的关系作为模型组元之间的关系计算世界基于计算科学建立的，具有形式化的特征信息的描述具有明确化、准确化和确定化的特征需求分析阶段不适宜建立形式化的计算模型（用户无法理解）重点是软件系统需要解

5、决的问题描述软件系统的解决方案，而不是软件系统的构建方式和实现方式问题世界与业务模型使用问题域中的重要概念作为模型的组元使用概念之间的业务联系作为组元之间的关系使用了业务描述的方式，具有非形式化特征可以抽取出需求信息中最重要和最本质的内容可以达成用户和开发者的共同理解非形式化特征使得它不适合于进行需求建模业务模型元素（即业务概念和业务联系）的选取和定义上具有不准确、不确定和模糊化不足以用于描述一个有效的软件解决方案软件分析模型介于计算模型和业务模型二者之间的模型形式使用了计算模型的组元形式：以对象、类、函数、过程、属性鞥作为模型的基本元素；在组元的表现上采用了业务模型的表现方式，使用业务概念、

6、业务联系和问题域语言来表现组元的语义。半形式化的不像计算模型那么严谨，适合需求分析的根本任务比业务模型更严格，适合描述软件解决方案在实际的软件开发中，业务模型是并不存在的。在实际的软件开发中，业务模型是并不存在的。常见的情况是，需求分析人员直接根据常见的情况是，需求分析人员直接根据需求获取的信息建立分析模型。需求获取的信息建立分析模型。模型是对重要知识的描述，这种描述通过模型语言实现。它具有三个要素：语法：使用规则怎样使用模型的元素，并且以什么方式组织、连接或关联这些元素；语义：模型元素所具有的固有含义；语用：使用模型元素语境相关的含义；分析模型采用半形式化语言语用复杂语义丰富语法严格同时又不

7、太复杂曾经有很多的研究者尝试建立一种能够描述软件开发中各种情景的形式化或半形式化模型语言，但最后都失败了非形式化语言：自然语言是一种具有复杂规则非形式化语言：自然语言是一种具有复杂规则和多样化表达方式的语言，表达能力最强。和多样化表达方式的语言，表达能力最强。缺点：松散、模糊、歧义、凌乱缺点：松散、模糊、歧义、凌乱形式化语言是基于数学方法的语言，具有数学形式化语言是基于数学方法的语言，具有数学的表示特性：的表示特性：1 1、可以进行逻辑一致性推导和、可以进行逻辑一致性推导和证明，保证信息的正确性；证明，保证信息的正确性；2 2、所描述的信息、所描述的信息可以准确地映射为机器行为；可以准确地映射

8、为机器行为；缺点：要求使用者具有相关的数学知识缺点：要求使用者具有相关的数学知识半形式化语言是介于自然语言和形式化语言之间的半形式化语言是介于自然语言和形式化语言之间的描述语言。一方面，具有严格的语言，比自然语言描述语言。一方面，具有严格的语言，比自然语言更加严格；另一方面，具有比形式化方法更强的表更加严格；另一方面，具有比形式化方法更强的表达能力。达能力。关注内容观察视角视点（Viewpoints）：从不同的观察角度出发，将系统中既交织共存又相对独立的不同内容拆解成不同的部分，然后分别为每一个子部分建模。软件分析模型的复杂性使得需要使用多视点对其进行模型描述！常见的软件分析模型：过程模型、实

9、体联系模型、对象模型、状态机模型、行为模型。需求分析的目标问题域特性：E；用户的期望：R描述解系统行为：SE, SR，简单的推理过程（软件测试）E, RS，创造性的过程一方面，设计行为带有实用性、独创性、一方面，设计行为带有实用性、独创性、意会性意会性另一方面，设计行为带有客观性、合理性、中立性另一方面，设计行为带有客观性、合理性、中立性需求分析的根本任务需求分析技术常用的需求分析技术需求分析技术的综合运用需求分析技术的发展过程需求分析技术的应用特征需求分析方法前期需求阶段的建模与分析需求分析的活动结构化技术数据建模实体关系图Entity Relationship Diagram过程建模数据流

10、图Data Flow Diagram上下文图Context Diagram微规格说明Mini-Specification数据字典Data Dictionary行为建模状态(转换)图/矩阵State (Transition) Diagram/Matrix过程/数据关系建模功能实体矩阵Function/Entity Matrix信息工程方法功能分解图Function Decomposition Diagram过程依赖图Process Dependency Diagramn面向对象技术qUMLn用例图Use-Case Diagramn类图Class Diagramn交互图（顺序图）Interacti

11、on（Sequence /）Diagramn活动图Activity Diagramn对象约束语言Object Constraint Languagen状态图State Chart Diagram需求分析的技术多种多样，如何综合运用才是需求分析人员最大的困难如何为各个视角选择需求分析技术？每一种需求分析技术都有自己的特点，都用自己适合的应用和不适合的应用。如何实现它们之间的配合？只有通过多种需求分析技术的有机结合与集成才能充分的描述复杂应用1 1、需求分析方法。、需求分析方法。方法是技术的组合，方法所方法是技术的组合，方法所包含的思想，可以指导需求分析技术的选择。包含的思想，可以指导需求分析技术

12、的选择。2 2、技术的发展历程。、技术的发展历程。技术都应一定的实际需要技术都应一定的实际需要而产生，了解技术产生的发展历程，可以指导而产生，了解技术产生的发展历程，可以指导需求分析技术的选择。需求分析技术的选择。3 3、技术的应用特征。、技术的应用特征。每种技术都有自己的特点每种技术都有自己的特点和应用特征，尤其适合的应用场景。和应用特征，尤其适合的应用场景。系统对外交互系统内部交互功能式描述通信式描述行为式描述对交互的有用性的描述对交互中发生的信息交流情况的描述更小的交互相互之间形成的先后衔接与协作关系交互所涉及的系统或者系统部分的分解关系分解可以使得系统的对外交互转换为系统的内部交互形式

13、Wieringa框架结构化信息工程面向对象通用其他外部功能功能分解图用例图状态（转移）图/矩阵外部通信上下文图用例图交互图外部行为过程依赖图交互图概念组元数据流图DFD实体关系图ERD功能实体矩阵实体生命历史事件实体矩阵类图数据字典对象角色模型组元功能对象约束语言微规格说明组元通信数据流图DFD功能实体矩阵事件实体矩阵过程依赖图交互图组元行为实体生命历史活动图状态（转移）图/矩阵业务过程模型Petri网Zachman矩阵的行目标/范围（规划者视图）关心软件系统的成本和效益，对最终系统的规模、形式、位置空间以及基本目标的粗略描述规划者视图规定了项目的前景和范围。企业模型（所有者视图）：关心软件系

14、统会如何参与和帮助实际工作对业务实体、业务过程以及它们与系统之间交互的描述利用业务概念限定了系统的解决方案分析模型。系统模型（设计师视图）：关注软件系统应该的需要以及设计方法的选择限制对软件系统的基本功能和设计空间的描述体系结构。Zachman矩阵的行技术模型（构建者视图）：关注程序对软件系统当中控制逻辑、算法、I/O控制以及其他各种具体技术细节的描述描述详细设计的设计模型组件模型（集成者视图）：关注组装对软件系统的组件、接口以及编码程序等内容的描述实际运行的系统：描述系统投入使用后的实际状况和在运行中的实际表现。Zachman矩阵的列：数据：对企业有重要意义的事物以及企业对这些事物的理解功能

15、：企业在业务中执行的任务以及企业对任务的理解。位置：组织活动和软件系统的地理分布，以及它们与组织的其他方面的关联。人：在软件系统被引入后会涉及的人员和组织时间：系统内的事件-事件关联之间的时间因素，表现为业务的规划调度、系统的事件响应和控制结构。动机：该列针对的是企业建立目标系统的动机，揭示了企业的目标、目的、业务规划、知识架构、思想路线和决策基础。结构化信息工程面向对象通用其他数据数据流图DFD实体关系图ERD数据流图DFD实体关系图ERD类图数据字典对象角色模型功能上下文图数据流图DFD功能实体矩阵上下文图数据流图DFD功能实体矩阵功能分解图过程依赖图用例图交互图活动图对象约束语言微规格说

16、明状态（转移）图/矩阵业务过程模型网络Map人员层次模型矩阵模型网状模型时间实体生命历史事件实体矩阵实体生命历史事件实体矩阵状态（转移）图/矩阵Petri网动机对象约束语言微规格说明对象角色模型需求分析的根本任务需求分析技术需求分析方法前期需求阶段的建模与分析需求分析的活动传统分析 没有方法 (1950s)依赖个体才智,依据个人习惯缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构等等结构化分析 （1970s）:从功能角度，把现实世界描述为数据在信息系统中的流动传统结构化分析 (late 1960s), 现代结构化分析 (late 1970s)以数据流动为中心，以DFD为核心技术，辅助ER

17、D，STD信息工程 (late 1980s) ：是对结构化分析方法的改进，从信息角度描述系统以数据为基础，ERD为核心技术，辅助DFD，STD, FDD, PD面向对象分析 （1990s）以对象为基础，以UML（类图）为核心技术需求分析的根本任务需求分析技术需求分析方法前期需求阶段的建模与分析需求分析的活动使用面向问题的技术对问题世界的建模使用面向解系统的技术对软件解决方案的建模面向目标的分析（Goal Oriented Analysis）面向问题域的分析（Problem Domain Oriented Analysis）领域分析（Domain Analysis）企业建模（Enterprise

18、 Modeling） 前期需求分析阶段的重点是理解问题世界，注重于系系统的环境、开发组织的业务背景、涉众的特征以及目标等等，软件系统只是整个背景下的一个要素。后期需求分析阶段关注的是解系统解决方案的建立，以软件系统为核心，注重于分析系统的内部功能以及它与环境的互动，是对系统功能的详细信息的分析。问题框架特性解决框架分解与组合基本思路研究所有可能的问题域，从中发现一些重复出现的简单问题类型分析每一种问题框架的特性，确定问题的理解和解决方法将问题框架的建立和分类系统化，以简单的问题框架为基本单位，进行复杂问题的分解主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等等。企业建模利用企业的目标、任务、策略、资源等来