《软件需求第8课 软件需求分析概述ppt课件.ppt》由会员分享，可在线阅读，更多相关《软件需求第8课 软件需求分析概述ppt课件.ppt（79页珍藏版）》请在三一办公上搜索。
1、1,软 件 需 求,哈尔滨工程大学计算机科学与技术学院海量数据挖掘及网络数据集成研究组 王念滨 教授 博导,2,第 8 章 软件需求分析概述,3,本课主要讨论问题,2 需求分析技术,3 需求分析方法,4 前期需求分析阶段的建模与分析,1 需求分析的根本任务,5 需求分析活动,4,本课主要讨论问题,2 需求分析技术,3 需求分析方法,4 前期需求分析阶段的建模与分析,1 需求分析的根本任务,5 需求分析活动,5,1 需求分析的根本任务,需求分析是软件需求中最核心的工作，需求建模是需求分析的主要手段。 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。需求
2、分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。,6,软件的生存周期,问题定义,可行性研究,需求分析,软件设计,编码,测试,维护,计划时期,开发时期,运行时期,2 软件工程及软件需求概述,7,1 需求分析的根本任务,需求分析根本任务：建立分析模型，创建解决方案。,8,建立分析模型将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征和用户达成对信息内容的共同理解分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息,1 需求分析的根本任务,创建解决方案将一个问题分解成独立的、更简单
3、和易于管理的子问题来帮助寻找解决方案创建解决方案的过程是创造性的帮助开发者建立问题的定义，并确定被定义的事物之间的逻辑关系这些逻辑关系可以形成信息的推理，进而可以被用来验证解决方案的正确性。,9,1 需求分析的根本任务,从实践角度考虑，需求分析不是分析如何实现用户的需求。实际上，需求分析是以业务分析为导向，将用户零散的需求串联起来，形成一个体系完成、组织合理、内容清晰的框架，为今后的设计开发工作打下良好的基础。,What to do? Yes,How to do ? No,10,1 需求分析的根本任务,需求分析的任务：分解、提炼的过程，在此过程中消除需求矛盾,（1）分解 分解是人类控制复杂性，
4、认识复杂事物的基本策略方法。无论是采用结构化方法，还是采用面向对象方法，分解都是必须采用的手段。 传统方法一般采用系统导向的分解方法，而现代需求工程建议采用业务导向的方法。 实践中，分解的策略很多，主要要根据团队的应用实践和用户的要求选择适当的分解方法，主要包括以下几种： 1）业务流程为主线的分解策略； 2 ）程序结构为主线的分解策略； 3 ）基于场景的分解策略； 4 ）基于数据的分解策略等。,11,1 需求分析的根本任务,1）业务流程为主线的分解策略,系统级别,业务职责,岗位间,岗位级别,动作级别,目标系统,主题域1,主题域n,。,业务事件1,业务事件n,业务活动1,业务活动m,业务步骤1,
5、业务步骤w,目标决定范围,理清业务脉络,填充细节,细化和确认工作,12,1）业务流程为主线的分解策略,1 需求分析的根本任务,业务流程为主线的分解策略是目前比较流行的方法，主要按照“业务”的角度考虑分解方法。此方法特别适合联机事务处理系统、管理信息系统（MIS）。目标系统-主题域的分解依据是“目标决定范围”；主题域-业务事件所做的是理清业务脉络；业务事件-业务活动所做的是填充细节；业务活动-业务步骤所做的是细化和确认工作。,13,2）程序结构为主线的分解策略,1 需求分析的根本任务,目标系统,子系统1,子系统n,。,功能模块1,功能模块n,子模块1,子模块m,功能点1,功能点w,14,2）程序
6、结构为主线的分解策略,1 需求分析的根本任务,该方法是需求分析最常用的分解方法。当由于其过早进入程序结构，割裂了与问题域之间的联系，从而容易导致对问题域研究的不足，降低了需求的质量。目前认为此种方法仅适合于问题域比较清晰，问题不算复杂的情况，例如工具软件、嵌入式系统等。,15,3）基于场景的分解策略,1 需求分析的根本任务,目标系统,关注点1,关注点n,场景集合1,场景集合n,使用场景1,使用场景m,任务1,任务w,16,3）基于场景的分解策略,1 需求分析的根本任务,对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、使用场景是主要的线索。向上可以总结成一类相似的集合，再总结成一系列的关
7、注点或者功能域，向下可以分解成具体的步骤或者操作任务。,17,4）基于数据的分解策略,1 需求分析的根本任务,目标系统,主题域1,主题域n,。,主题类1,主题类n,逻辑数据1,逻辑数据m,物理数据1,物理数据w,18,4）基于数据的分解策略,1 需求分析的根本任务,上述分解策略都是从“业务”角度来组织。但对于类似数据仓库之类的数据类项目，业务线索并不是十分明显，或者并不重要这是就需要以数据为主的分解策略。其中主题域仍然与“业务流程为主的分解策略”类似。而主题类是企业中的高层实体，主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在实现时又会对应于多个物理数据类。,19,分解策略小结,1 需求
8、分析的根本任务,业务流程为主线的分解策略； 程序结构为主线的分解策略； 基于场景的分解策略； 基于数据的分解策略等。 上述几种分解策略的选择要根据实际应用展开。选择一个合适的分解策略后，就可以将需求分析规格说明书的大纲确定下来，知道应该获取什么信息，由此当信息获取完成后，需求分析的任务就是将获取的信息填充到相应的级别上，并不断地验证是否已经填充完成，验证获取需求的可用性和完整性，解决存在的矛盾。,20,1 需求分析的根本任务,需求分析的任务：分解、提炼的过程，在此过程中消除需求矛盾,(2) 提炼 分解是一种自顶向下的方法，当按照任何一种线索进行分解时。就会破坏其它线索的完整性。例如，如果以“业
9、务”为线索，就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。 此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行提炼。例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。,21,1 需求分析的根本任务,需求分析的任务：分解、提炼的过程，在此过程中消除需求矛盾,(3)消除矛盾 在分析过程中，显然可能会发现有些需求是相互矛盾的、冲突的，由于是将收集的信息放在一个预先定义的结构中发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也能够知道它影响那些层面。寻找相应的人员，通过进一步需求获取来消除矛盾。
10、,22,1 需求分析的根本任务,建立分析模型,建立分析模型将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征和用户达成对信息内容的共同理解分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息,23,1 需求分析的根本任务,建立分析模型,建模的目标与要点 建模是寻求分析的主要手段，它通过简化（化简）、强调来帮助需求分析人员理清思路，达成共识。因此需求建模的过程非常重要。建模的目的（为什么要建模？） 在平常工作和生活中，许多理工科的领域，几乎看不到那个领域是没有模型的。建筑工地需要施工图纸，电子工厂需要电路图，如果没有这些，我们会感到不可思议。因为这些模型
11、可以有效地帮助人们更好地认识、应用、设计复杂的事物。,24,1 需求分析的根本任务,建模的目的（为什么要建模？） 软件行业的复杂程度与例子中的行业比较，其复杂程度可以说是有过之而无不及。 为什么要建模？通过建模可以更好地理解正在开发的系统。 原先，由于计算机应用还不算普及，因此软件系统的规模和复杂度都相对较小。使用“数据结构+算法=程序”的模式就可以解决大部分问题。 现在，随着计算机应用的不断普及，业务模式、数据量都在发生迅速的变化。软件涉及的问题越来越广，早已超出了人们可以处理的复杂程度。 例子：以建筑行业作类比，早期的软件系统就像是构建一个小平房。即使没有建筑图纸，建筑工人也能够凭借经验和
12、已有的平房，安全，快捷地构建出可供使用的房屋。而现在的软件系统更像是高楼大厦，如果还采用传统的方式，就无法进行有效的规划和设计，最终必然导致失败。,建立分析模型,25,1 需求分析的根本任务,建立分析模型,建模的目的 通过软件建模，帮助我们按照实际情况或按照我们的需要的模式对系统进行可视化，提供一种详细说明系统的结构或者行为的方法，给出一个指导系统构造的模板。对所有做出的决定实施文档化。,26,1 需求分析的根本任务,模型 “模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解” 集中关注问题的计算特性（数据、功能、规则等等） “它是对系统进行思考和推理的一种方式。建模的目标是建立系
13、统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易” 建模方法抽象分解投影,建立分析模型,27,1 需求分析的根本任务,抽象（Abstraction）一方面要求人们只关注重要的信息，忽略次要的内容通过强调本质的特征，就减少了问题的复杂性（例如学生模型）另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节在问题的各元素之间推断出更广泛和更普遍的关系，帮助人们寻找解决方案分解（Decomposition / Partitioning）“分而治之”将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系分解的方案往往还能提供问题的解决思路投影（Pr
14、ojection）多视点方法,建立分析模型,28,1 需求分析的根本任务,建立分析模型-三种模型,29,1 需求分析的根本任务,问题世界与业务模型使用问题域中的重要概念作为模型的组元使用概念之间的业务联系作为组元之间的关系使用了业务描述的方式，具有非形式化特征业务模型元素（即业务概念和业务联系）的选取和定义上具有不准确、不确定和模糊化可以抽取出需求信息中最重要和最本质的内容可以达成用户和开发者的共同理解非形式化特征使得它不适合于进行需求建模不足以用于描述一个有效的软件解决方案不准确、不确定和模糊化,建立分析模型,30,1 需求分析的根本任务,建立分析模型,软件分析模型介于计算模型和业务模型二者
15、之间的模型形式使用了计算模型的组元形式在组元的表现上采用了业务模型的表现方式半形式化的不像计算模型那么严谨比业务模型更严格,31,1 需求分析的根本任务,计算世界与计算模型使用软件的构成单位作为模型的组元软件构建单位之间的关系作为模型组元之间的关系基于计算科学建立的，具有形式化的特征信息的描述具有明确化、准确化和确定化的特征需求分析阶段不适宜建立形式化的计算模型重点问题是缺乏和软件实现相关的技术细节用户无法理解,建立分析模型,32,1 需求分析的根本任务,建模的要点和原则 在建模时，要注意考虑到计划之外的变化：设计要文档化，只有这样，才能使不熟悉的新手也可以有效地利用设计的方案。用可视化的模型
16、表达现实世界，有助于理解变化所代表的含义。 在实际的建模过程中要遵循以下建模原则： 模型是用来沟通的； 选择创建什么模型对如何解决问题和如何形成解决方案具有深远的影响。 每种模型可以在不同的精度级别上表示； 最好的模型是与现实相联系的模型； 单个模型往往不够充分，对每个重要的系统最好用一组几乎独立的模型去处理。,建立分析模型,33,1 需求分析的根本任务,模型的描述三个要素之间互为依赖，每个要素都为下一个要素提供了一个必需的环境语法：使用规则怎样使用模型的元素，并且以什么方式组织、连接或关联这些元素；语义：特定模型元素所具有的含义；语用：模型元素的上下文，以及影响该模型元素意义的约束和假定分析
17、模型语用复杂语义丰富语法严格同时又不太复杂,建立分析模型,34,1 需求分析的根本任务,建立分析模型,模型的描述多视点方法,35,1 需求分析的根本任务,视点（Viewpoints）：将系统中既交织共存又相对独立的不同内容拆解成不同的部分每一个视点都是独立的模型存在，用独立的模型语言和表示法进行描述多视点：所有视点的模型描述集成起来，就是对原有复杂系统的模型描述依据系统内不同部分之间的关系，建立不同模型内元素之间的联系，从而将多个独立的模型描述在语义上连接起来,建立分析模型,36,1 需求分析的根本任务,建立分析模型-模型、模型语言与表示方法,37,1 需求分析的根本任务,需求建模通常的做法是
18、：先依据获取的问题域信息建立初步的模型。然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。,建立分析模型,需求建模流程,38,1 需求分析的根本任务,创建解决方案,39,1 需求分析的根本任务,创建解决方案,40,1 需求分析的根本任务,创建解决方案-创建解决方案的过程,41,本课主要讨论问题,2 需求分析技术,3 需求分析方法,4 前期需求分析阶段的建模与分析,1 需求分析的根本任务,5 需求分析活动,42,2 需求分析技术,常用的需求分析技术,结构化技术数据建模实体关系图Entity Re
19、lationship Diagram过程建模数据流图Data Flow Diagram上下文图Context Diagram微规格说明Mini-Specification数据字典Data Dictionary行为建模状态(转换)图/矩阵State (Transition) Diagram/Matrix过程/数据关系建模功能实体矩阵Function/Entity Matrix信息工程方法功能分解图Function Decomposition Diagram过程依赖图Process Dependency Diagram,面向对象技术UML用例图Use-Case Diagram类图Class Dia
20、gram交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram活动图Activity Diagram对象约束语言Object Constraint Language状态图State Chart Diagram,43,2 需求分析技术,需求分析技术的发展过程,44,2 需求分析技术,Wieringa框架,系统对外交互,系统内部交互,功能式描述,通信式描述,行为式描述,对交互的有用性的描述,对交互中发生的信息交流情况的描述,更小的交互相互之间形成的先后衔接与协作关系,交互所涉及的系统或者系统部分的分解关系,分解可以使得系统的对外交互转换为系
21、统的内部交互形式,45,2 需求分析技术,Wieringa框架,46,2 需求分析技术,Zachman 框架,47,2 需求分析技术,Zachman矩阵的行目标/范围（规划者视图）关心软件系统的成本和效益，对最终系统的规模、形式、位置空间以及基本目标的粗略描述规划者视图规定了项目的前景和范围。企业模型（所有者视图）：关心软件系统会如何参与和帮助实际工作对业务实体、业务过程以及它们与系统之间交互的描述利用业务概念限定了系统的解决方案分析模型。系统模型（设计师视图）：关注软件系统应该的需要以及设计方法的选择限制对软件系统的基本功能和设计空间的描述体系结构。,Zachman 框架,48,Zachma
22、n矩阵的行技术模型（构建者视图）：关注程序对软件系统当中控制逻辑、算法、I/O控制以及其他各种具体技术细节的描述描述详细设计的设计模型组件模型（集成者视图）：关注组装对软件系统的组件、接口以及编码程序等内容的描述实际运行的系统：描述系统投入使用后的实际状况和在运行中的实际表现。,2 需求分析技术,Zachman 框架,49,2 需求分析技术,Zachman矩阵的列：数据：对企业有重要意义的事物以及企业对这些事物的理解功能：企业在业务中执行的任务以及企业对任务的理解。位置：组织活动和软件系统的地理分布，以及它们与组织的其他方面的关联。人：在软件系统被引入后会涉及的人员和组织时间：系统内的事件-事
23、件关联之间的时间因素，表现为业务的规划调度、系统的事件响应和控制结构。动机：该列针对的是企业建立目标系统的动机，揭示了企业的目标、目的、业务规划、知识架构、思想路线和决策基础。,Zachman 框架,50,2 需求分析技术,Zachman 框架,51,2 需求分析技术,Zachman 框架,52,本课主要讨论问题,2 需求分析技术,3 需求分析方法,4 前期需求分析阶段的建模与分析,1 需求分析的根本任务,5 需求分析活动,53,3 需求分析方法,传统分析 没有方法 (1950s)依赖个体才智，依据个人习惯缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构等等结构化分析 传统结构化分析 (
24、late 1960s),现代结构化分析 (late 1970s)以数据流动为中心，以DFD为核心技术，辅助ERD信息工程 (late 1980s) 以数据知识结构为基础，ERD为核心技术，辅助DFD，PD面向对象分析 （1990s）以对象为中心，以UML（类图）为核心技术以全面思想革新为理想，以承继结构化技术为现实,Unified Modeling Language,54,3 需求分析方法,正确认识建模方法论,建模方法的产生和演变和时代背景有着紧密地联系，如下表所示,55,3 需求分析方法,结构化分析方法,56,3 需求分析方法,面向对象分析方法,57,3 需求分析方法,正确认识UML,(1)
25、 UML发展历程,面向对象编程（OOP）的出现，逐渐催生了面向对象设计（）和面向对象分析（）技术的出现。为了更好地开展和，在世纪年代，出现了面向对象建模语言，而在年代末开始进入快速发展阶段，截至年，发展到多种方法。由于每种语言、方法的创造者都极力推崇自己的成果，爆发了“面向对象技术的方法大战”,58,3 需求分析方法,(1) UML发展历程,正确认识UML,Class-Responsibility-Collaborator卡建模,Object Management Group,59,3 需求分析方法,(1) UML发展历程-UML三剑客,正确认识UML,James Rumbaugh、Ivar
26、Jacobson、Grady Booch 1991年由Rumbaugh等人提出了 （Object Modeling Technique ） 1992年由Jacobson等人提出 （Object-Oriented Software Engineering） 1993年由Booch等人提出了 Booths Method,60,3 需求分析方法,(1) UML发展历程-UML三剑客,正确认识UML,1994年Rumbaugh和Booch共同合作将他们的和ooch方法统一起来。到年成为“统一方法”（Unified Method）版本.8 随后，Jacobson加入，并采用了他的用例（Usecase）思
27、想最终由一个成立于年的被称为UML Partners国际联盟统一了他们的记号系统，产生了UML0.9版UML 于年初由UML Partners提交给OMG(Object Management Group)，年末，修改后的UML1.1版被采纳，成为面向对象建模标准语言年底，已稳定占领技术市场的份额,61,3 需求分析方法,(1) UML发展历程-UML发展现状,正确认识UML,成为全面应用阶段的事实标准：由于UML和面向对象的天生血缘关系，随着面向对象技术的深入普及，UML成为非常普及的建模技术。目前市场上的建模工具都是基于UML的。据统计，各种与建模有关的书籍都是与UML有关的。多数软件开发公
28、司基本以UML作为建模工具。应用领域逐渐扩展：新批准的UML2.0版本除了增强基础设施增加了新的建模能力，使模型交换更加简单有效外，还增加了许多可扩展能力目前不仅软件建模广泛应用，还逐渐推广到嵌入式系统建模、业务建模、流程建模等多种领域中。,62,3 需求分析方法,() UML的准确理解,正确认识UML,UML是一种语言（Language）实际上UML就是一种表示方法，它不是方法论。UML是一种建模语言（Modeling Language）它不是编程语言，而是建模语言。它不仅包含软件建模，而且可用于业务建模、流程建模等多种领域。UML是统一建模语言（Unified Modeling Langu
29、age ）它是一种标准化的、统一的建模语言，OMG认可的工业标准，也是如IBM、SUN等大型公司认可的事实标准。,63,3 需求分析方法,(3) 为什么要使用UML,正确认识UML,UML是一种统一的、标准化的建模语言，它为参与软件设计和开发的各类人员提供统一的语言，使开发人员能够基于共的模型来理解业务、需求，理解软件及其架构如何构造的。,64,3 需求分析方法,(4) 如何使用UML,正确认识UML,UML2.0标准中，共定义了13种不同的图，这些图的功能以及与UML1.0之间的关系如下表,65,3 需求分析方法,(4) 如何使用UML,正确认识UML,66,3 需求分析方法,(4) 如何使
30、用UML-需求阶段一般常采用的图,正确认识UML,涉及到的几种图稍微讲一下,67,2 需求分析技术,3 需求分析方法,4 前期需求分析阶段的建模与分析,1 需求分析的根本任务,5 需求分析活动,本课主要讨论问题,68,4 前期需求分析阶段的建模与分析,69,4 前期需求分析阶段的建模与分析,面向目标的分析（Goal Oriented Analysis）面向问题域的分析（Problem Domain Oriented Analysis）领域分析（Domain Analysis）企业建模（Enterprise Modeling）,适合前期需求分析阶段的分析技术包括：,70,4 前期需求分析阶段的建
31、模与分析,面向问题域的分析问题框架特性解决框架分解与组合基本思路研究所有可能的问题域，从中发现一些重复出现的简单问题类型分析每一种问题框架的特性，确定问题的理解和解决方法将问题框架的建立和分类系统化，以简单的问题框架为基本单位，进行复杂问题的分解,71,4 前期需求分析阶段的建模与分析,领域分析,图 产品线方法示意图,72,4 前期需求分析阶段的建模与分析,企业建模,主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等等。企业建模利用企业的目标、任务、策略、资源等来刻画组织的行为，并依此来发现组织开发系统的目的，建立系统的业务需求,图 企业多视角方法示意,73,2 需求分
32、析技术,3 需求分析方法,4 前期需求分析阶段的建模与分析,1 需求分析的根本任务,5 需求分析活动,本课主要讨论问题,74,5 需求分析活动,图 后期需求阶段的需求分析活动流程图,75,5 需求分析活动,需求细化,明确用户需求的隐含因素； 将从问题域和业务的角度表述的用户需求等价的转化为从软件 和技术的角度表述的系统需求； 非功能需求也需要从高层次的表述方式转化为一系列更加详细 和具体的需求表述； 需求细化也会发现新的细节需求； 需求已经得了充分的理解，并且开发者已经可以着手为其进行 方案设计时停止细化过程 细化后的需求应该被一一的标识和记录下来,76,5 需求分析活动,需求细化,需求的记录
33、标识符（ID），每一条需求都应该能够通过ID唯一的标识自己。源头（Source），要能够回溯到需求的源头，例如特定的涉众。理由（Rational），需求被提出的目的。优先级（Priority），详细情况见下一节。成本（Cost），预估的实现成本。风险（Risk），实现该需求的过程中可能带来的风险。可变性（Volatility），将来发生变化的可能性。,77,5 需求分析活动,确定需求优先级,累计投票 区域划分 重要性。需求的不可或缺程度。紧急性。需求的时间紧迫程度。惩罚性。忽略需求会导致的惩罚程度。成本。实现需求的代价。风险。需求实现中可能产生的风险程度。,78,Top-NN的取值是不受明确限制的，真正受限制的是Top-N个需求的实现代价总和数据量化,确定需求优先级,5 需求分析活动,79,需求协商,5 需求分析活动,明确冲突的因素，避免情绪上的冲突 明确冲突的解决空间 确定最佳解决方案,图 WinWin螺旋模型,
