需求分析概述.pptx

《需求分析概述.pptx》由会员分享，可在线阅读，更多相关《需求分析概述.pptx（50页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、主要内容1.需求分析的根本任务1.建立分析模型2.建立解决方案2.需求分析技术3.需求分析方法4.前期需求阶段的建模与分析5.需求分析的活动第1页/共50页1.需求分析的根本任务第2页/共50页1.需求分析的根本任务建立分析模型将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征和用户达成对信息内容的共同理解分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息第3页/共50页1.需求分析的根本任务创建解决方案将一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找解决方案创建解决方案的过程是创造性的帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑

2、关系这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案的正确性。第4页/共50页1.1建立分析模型模型“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解”集中关注问题的计算特性（数据、功能、规则等等）“它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易”建模方法抽象分解投影第5页/共50页1.1建立分析模型抽象（Abstraction）一方面要求人们只关注重要的信息，忽略次要的内容通过强调本质的特征，就减少了问题的复杂性另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节在问题的各元素之间推

3、断出更广泛和更普遍的关系，帮助人们寻找解决方案分解（Decomposition/Partitioning）“分而治之”将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系分解的方案往往还能提供问题的解决思路投影（Projection）多视点方法第6页/共50页1.1建立分析模型计算世界与计算模型使用软件的构成单位作为模型的组元软件构建单位之间的关系作为模型组元之间的关系基于计算科学建立的，具有形式化的特征信息的描述具有明确化、准确化和确定化的特征需求分析阶段不适宜建立形式化的计算模型重点是问题，缺乏和软件实现相关的技术细节用户无法理解第7页/共50页1.1建立分析模

4、型问题世界与业务模型使用问题域中的重要概念作为模型的组元使用概念之间的业务联系作为组元之间的关系使用了业务描述的方式，具有非形式化特征业务模型元素（即业务概念和业务联系）的选取和定义上具有不准确、不确定和模糊化可以抽取出需求信息中最重要和最本质的内容可以达成用户和开发者的共同理解非形式化特征使得它不适合于进行需求建模不足以用于描述一个有效的软件解决方案不准确、不确定和模糊化第8页/共50页1.1建立分析模型软件分析模型介于计算模型和业务模型二者之间的模型形式使用了计算模型的组元形式在组元的表现上采用了业务模型的表现方式半形式化的不像计算模型那么严谨比业务模型更严格第9页/共50页1.1建立分析

5、模型三种模型第10页/共50页1.1建立分析模型模型的描述三个要素之间互为依赖，每个要素都为下一个要素提供了一个必需的环境语法：使用规则怎样使用模型的元素，并且以什么方式组织、连接或关联这些元素；语义：特定模型元素所具有的含义；语用：模型元素的上下文，以及影响该模型元素意义的约束和假定分析模型语用复杂语义丰富语法严格同时又不太复杂曾经有很多的研究者尝试建立一种能够描述软件开发中各种情景的形式化或半形式化模型语言，但最后都失败了第11页/共50页1.1建立分析模型模型的描述多视点方法第12页/共50页1.1建立分析模型视点（Viewpoints）：将系统中既交织共存又相对独立的不同内容拆解成不同

6、的部分每一个视点都是独立的模型存在，用独立的模型语言和表示法进行描述多视点：所有视点的模型描述集成起来，就是对原有复杂系统的模型描述依据系统内不同部分之间的关系，建立不同模型内元素之间的联系，从而将多个独立的模型描述在语义上连接起来第13页/共50页1.1建立分析模型模型、模型语言与表示法 第14页/共50页1.1建立分析模型需求建模通常的做法是：先依据获取的问题域信息建立初步的模型。然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。第15页/共50页1.2 建立解决方案需求分析的目标第16页

7、/共50页1.2 建立解决方案建立解决方案的过程第17页/共50页主要内容1.需求分析的根本任务2.需求分析技术1.常用需求分析技术2.需求分析技术的发展过程3.Wieringa框架4.Zachman 框架3.需求分析方法4.前期需求阶段的建模与分析5.需求分析的活动第18页/共50页2.1 常用需求分析技术结构化技术数据建模实体关系图Entity Relationship Diagram过程建模数据流图Data Flow Diagram上下文图Context Diagram微规格说明Mini-Specification数据字典Data Dictionary行为建模状态(转换)图/矩阵Stat

8、e(Transition)Diagram/Matrix过程/数据关系建模功能实体矩阵Function/Entity Matrix信息工程方法功能分解图Function Decomposition Diagram过程依赖图Process Dependency Diagramn面向对象技术qUMLn用例图Use-Case Diagramn类图Class Diagramn交互图（顺序图/通信图）Interaction（Sequence/Communication）Diagramn活动图Activity Diagramn对象约束语言Object Constraint Languagen状态图State

9、 Chart DiagramNext第19页/共50页2.1 常用需求分析技术技术的综合运用如何为各个视角选择需求分析技术？每一种需求分析技术都有自己的特点，具有在应用上的独特性如何实现它们之间的配合？只有通过多种需求分析技术的有机结合与集成才能充分的描述复杂应用第20页/共50页2.2需求分析技术的发展过程第21页/共50页2.3 Wieringa框架系统对外交互系统内部交互功能式描述通信式描述行为式描述对交互的有用性的描述对交互中发生的信息交流情况的描述更小的交互相互之间形成的先后衔接与协作关系交互所涉及的系统或者系统部分的分解关系分解可以使得系统的对外交互转换为系统的内部交互形式第22页

10、/共50页2.3 Wieringa框架结构化信息工程面向对象通用其他外部功能功能分解图用例图状态（转移）图/矩阵外部通信上下文图用例图交互图外部行为过程依赖图交互图概念组元数据流图DFD实体关系图ERD功能实体矩阵实体生命历史事件实体矩阵类图数据字典对象角色模型组元功能对象约束语言微规格说明组元通信数据流图DFD功能实体矩阵事件实体矩阵过程依赖图交互图组元行为实体生命历史活动图状态（转移）图/矩阵业务过程模型Petri网第23页/共50页2.4 Zachman 框架第24页/共50页2.4 Zachman 框架Zachman矩阵的行目标/范围（规划者视图）关心软件系统的成本和效益，对最终系统的

11、规模、形式、位置空间以及基本目标的粗略描述规划者视图规定了项目的前景和范围。企业模型（所有者视图）：关心软件系统会如何参与和帮助实际工作对业务实体、业务过程以及它们与系统之间交互的描述利用业务概念限定了系统的解决方案分析模型。系统模型（设计师视图）：关注软件系统应该的需要以及设计方法的选择限制对软件系统的基本功能和设计空间的描述体系结构。第25页/共50页2.4 Zachman 框架Zachman矩阵的行技术模型（构建者视图）：关注程序对软件系统当中控制逻辑、算法、I/O控制以及其他各种具体技术细节的描述描述详细设计的设计模型组件模型（集成者视图）：关注组装对软件系统的组件、接口以及编码程序等

12、内容的描述实际运行的系统：描述系统投入使用后的实际状况和在运行中的实际表现。第26页/共50页2.4 Zachman 框架Zachman矩阵的列：数据：对企业有重要意义的事物以及企业对这些事物的理解功能：企业在业务中执行的任务以及企业对任务的理解。位置：组织活动和软件系统的地理分布，以及它们与组织的其他方面的关联。人：在软件系统被引入后会涉及的人员和组织时间：系统内的事件-事件关联之间的时间因素，表现为业务的规划调度、系统的事件响应和控制结构。动机：该列针对的是企业建立目标系统的动机，揭示了企业的目标、目的、业务规划、知识架构、思想路线和决策基础。第27页/共50页2.4 Zachman 框架

13、ContextualConceptualLogicalPhysicalAs BuiltFunctioningContextualConceptualLogicalPhysicalAs BuiltFunctioningWhyWhyWhoWhoWhenWhenWhereWhereWhatWhatHowHowProject scopeAnalysis modelDesign modelCoded programApplication SystemPlaning*AnalysisDesignImplementationIntegrationData ModelingBehavior ModelingE

14、vent ModelingBusiness RulesNetwork topologiesOrganizational structure modelingBusiness Model第28页/共50页2.4 Zachman 框架第29页/共50页2.4 Zachman 框架结构化信息工程面向对象通用其他数据数据流图DFD实体关系图ERD数据流图DFD实体关系图ERD类图数据字典对象角色模型功能上下文图数据流图DFD功能实体矩阵上下文图数据流图DFD功能实体矩阵功能分解图过程依赖图用例图交互图活动图对象约束语言微规格说明状态（转移）图/矩阵业务过程模型网络Map人员层次模型矩阵模型网状模型时间

15、实体生命历史事件实体矩阵实体生命历史事件实体矩阵状态（转移）图/矩阵Petri网动机对象约束语言微规格说明对象角色模型第30页/共50页主要内容1.需求分析的根本任务2.需求分析技术3.需求分析方法4.前期需求阶段的建模与分析5.需求分析的活动第31页/共50页3.需求分析方法传统分析 没有方法(1950s)依赖个体才智,依据个人习惯缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构等等结构化分析 传统结构化分析(late 1960s),现代结构化分析(late 1970s)以数据流动为中心，以DFD为核心技术，辅助ERD,STD信息工程(late 1980s)以数据知识结构为基础，ERD

16、为核心技术，辅助DFD，STD,FDD,PD面向对象分析（1990s）以对象为中心，以UML（类图）为核心技术以全面思想革新为理想，以承继结构化技术为现实第32页/共50页3.需求分析方法结构化分析第33页/共50页3.需求分析方法面向对象分析第34页/共50页主要内容1.需求分析的根本任务2.需求分析技术3.需求分析方法4.前期需求阶段的建模与分析5.需求分析的活动第35页/共50页4.前期需求阶段的建模与分析第36页/共50页4.前期需求阶段的建模与分析面向目标的分析（Goal Oriented Analysis）面向问题域的分析（Problem Domain Oriented Analy

17、sis）领域分析（Domain Analysis）企业建模（Enterprise Modeling）第37页/共50页4.前期需求阶段的建模与分析面向问题域的分析问题框架特性解决框架分解与组合基本思路研究所有可能的问题域，从中发现一些重复出现的简单问题类型分析每一种问题框架的特性，确定问题的理解和解决方法将问题框架的建立和分类系统化，以简单的问题框架为基本单位，进行复杂问题的分解第38页/共50页4.前期需求阶段的建模与分析领域分析第39页/共50页4.前期需求阶段的建模与分析企业建模主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等等。企业建模利用企业的目标、任务、策

18、略、资源等来刻画组织的行为，并依此来发现组织开发系统的目的，建立系统的业务需求第40页/共50页主要内容1.需求分析的根本任务2.需求分析技术3.需求分析方法4.前期需求阶段的建模与分析5.需求分析的活动第41页/共50页5.需求分析的活动第42页/共50页5.需求分析的活动需求细化明确用户需求的隐含因素 将从问题域和业务的角度表述的用户需求等价的转化为从软件和技术的角度表述的系统需求 非功能需求也需要从高层次的表述方式转化为一系列更加详细和具体的需求表述 需求细化也会发现新的细节需求需求已经得了充分的理解，并且开发者已经可以着手为其进行方案设计时停止细化过程 细化后的需求应该被一一的标识和记

19、录下来 第43页/共50页5.需求分析的活动需求细化需求的记录标识符（ID），每一条需求都应该能够通过ID唯一的标识自己。源头（Source），要能够回溯到需求的源头，例如特定的涉众。理由（Rational），需求被提出的目的。优先级（Priority），详细情况见下一节。成本（Cost），预估的实现成本。风险（Risk），实现该需求的过程中可能带来的风险。可变性（Volatility），将来发生变化的可能性。第44页/共50页5.需求分析的活动确定需求优先级累计投票 区域划分 重要性。需求的不可或缺程度。紧急性。需求的时间紧迫程度。惩罚性。忽略需求会导致的惩罚程度。成本。实现需求的代价。风险

20、。需求实现中可能产生的风险程度。第45页/共50页5.需求分析的活动确定需求优先级Top-NN的取值是不受明确限制的，真正受限制的是Top-N个需求的实现代价总和数据量化 第46页/共50页5.需求分析的活动需求协商明确冲突的因素，避免情绪上的冲突 明确冲突的解决空间 确定最佳解决方案 第47页/共50页本章小结需求分析是需求工程中最为重要和核心的活动，它对信息的建模是理解问题的关键，也是创建正确解决方案的关键需求分析涉及很多的技术和方法，需求分析活动的有效执行需要分析人员能够掌握并判定这些方法的选择与使用需求分析过程当中会执行很多的重要子活动，它们的有效整合确保了整个需求分析工作的成功第48页/共50页思考题1.分析“结构化分析”和“面向对象分析”的过程，说明它们为什么都开始于系统的边界定义？2.“事件”和“事物”一直是进行需求分析的一个重要思路，你对此如何评价？3.列举面向对象分析的各种技术，说明它们是对结构化分析技术的继承和借鉴吗？如果是，那么说明它们借鉴了哪些结构化分析技术，如果不是，那么说明它们的数学基础是什么？4.Wieringa框架和Zachman框架给了你什么启示？5.结合实践调查情况，评价一下各种建模技术在实践中的重要性.第49页/共50页感谢您的观看！第50页/共50页