中科院需求工程需求工程（第一讲）需求工程原理_.ppt

软件需求工程: 原理和方法,金芝 中国科学院数学与系统科学研究院 ,内容,教学安排 课程目的和背景 教学大纲和主要内容 参考书目,教学安排,每星期13小时的课（13周），其中： 2月20日:软件需求工程原理 2月27日:软件需求工程过程 3月6日:文献综述 3月13日:软件需求建模基础 3月20日:面向目标的方法 3月27日:面向主体和意图的方法 4月3日:基于情景的方法 4月10日:问题框架方法 4月24日:基于领域建模的方法 5月8日:文档驱动的方法 5月15日:课程设计 5月22日:面向方面的方法,需求工程展望(非功能性需求) 5月29日:课程总结和答疑,需求工程概述,代表性方法,课程作业,文献综述一篇 课程设计报告一份 含3-4个案例的案例分析,考试及评分标准,10%上课情况 15%文献综述报告 15%案例分析报告 60%期末考试(开卷课堂考试),课程的目的,了解需求工程研究和实践的现状,以及进行进一步研究的背景知识 需求工程在软件工程中的地位和角色 需求工程的本质 需求工程方法学 当前的代表性研究 获得对目前代表性需求工程方法和技术的一些实践经验,预备知识,软件工程 软件开发过程 基本的软件建模思想 基本的形式化建模手段 基于逻辑的方法 命题逻辑 谓词逻辑 简单的模态逻辑 基本状态变迁系统 应用软件开发的工程实践经验,参考书目和经典文献,davis, a., a taxonomy for the early stages of the software development life cycle, journal of systems and software, 8(4): 297-311. 1988 pohl, k., the three dimensions of requirements engineering. in: rolland, c.; bodart, f.; cauvet, c. (eds.) proceedings of the 5th conference on advanced information systems engineering. lecture notes in computer science 22: 275-292, springer verlag, 1993. davis, a. m., software requirements: objects, functions and states, prentice hall, 1993. flowers s., software failure: management failure, new york: wiley, 1996. grady, jeffrey o., system requirements analysis, mcgraw-hill, 1993 gunter, carl a., gunter, elsa l., jackson, m. and zave, p., a reference model for requirements and specifications. ieee software 17(3), 2000 jackson, m., software requirements and specifications, addison wesley/ acm press, 1995 loucopoulos, p., and karakostas, v., system requirements engineering, mcgraw-hill book company europe, 1995 jackson, m., the meaning of requirements, annals of software engineering 3: 5-21, 1997 zave, p., classification of research efforts in requirements engineering. acm computing surveys, 29(4): 315-321, 1997 zave, p., and jackson, m., four dark corners of requirements engineering, acm trans. softw. eng. methodol. 6(1): 1-30, 1997 ian sommerville and peter sawyer, requirements engineering: a good practice guide.chichester, england: john wiley&sons, 1997 kotonya, g., and sommerville, ian, requirements engineering: processes and techniques. john wiley & sons ltd, 1998. robertson, s., and robertson, j., mastering the requirements process, addison-wesley. 1999. nuseibeh b, and easterbrook s., requirements engineering: a roadmap. proc. of the 22nd intl conf. on software engineering, future of software engineering track: 35-46. acm press, 2000. bray, ian k., an introduction to requirements engineering, addison-wesley, reading, ma, 2002 davis, alan m., just enough requirements management: where software development meets marketing, dorset house publishing, 2005,第一讲：软件需求工程原理,为什么需要需求工程? 需求工程有用吗? 什么是软件需求工程?,为什么需要需求工程,从软件开发的困难看,软件项目失败的案例,（1992年） performing rights society（演出权益协会）proms项目，花费1100万英镑之后被放弃。其中糟糕的需求工程是项目失败的一个主要因素，包括未能以普通人能够理解和检查的形式表达软件需求。 （1990年） wessex regional information systems plan（地区信息系统）, risp项目，花费4300万英镑后被放弃。其主要原因包括缺乏对项目范围的清晰定义。,与客户沟 通的问题,需求的边 界问题,软件项目失败的案例,（1993年） london stock exchange（伦敦股票交易） taurus项目，花费7500万英镑后被取消。许多问题源于未能协调不一致的需求。 （1992年） london ambulance service despatch system（伦敦救护车服务派遣系统），在运行两天后被关闭，源于对社会服务领域的需求没有分析清楚。,不一致需 求的管理 问题,需求不清 晰的问题,软件项目失败的案例,swanick air traffic control（空中交通控制），计划在1998年完成，但2001年还未完成（额外开支1.8亿英镑）。主要原因包括：没有得到完整的需求规格说明就开始系统实现的工作。,需求没弄 清楚就匆 忙开始后 续工作,近期的软件失效案例,同时访问同一资源的计算机超出预定范围,开放软件面对各种病毒攻击,2008年6月30日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一 是对系统用户数的预测不足,2004年4月，东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消 一笔输错指令的交易，导致该公司蒙受了近2.5亿美元的损失；故障原因之一， 对操作人员的错误行为的预期不充分,1996 欧洲的调查结果,it产品和服务部门的软件开发者一致将需求规格说明和管理客户的需求列为他们所面对的最重要的问题 。 需求被认为比编写文档、测试、质量保证、标准、设计、配置管理和程序设计要明显更容易出问题的地方。,耸人听闻吗？,代价大，造成巨大的浪费 社会影响严重,美国standish group调查报告,调查时间：1995年 调查范围： 美国全国范围的软件项目 总投资： 平均每年要花多于2500亿的美元用于支持大约175,000个it应用项目的开发，其中, 大公司的平均投资是2,322,000美元， 中型公司的平均投资是1,331,000美元， 小型公司是434,000美元。,美国standish group调查结果,总体结果： 成功率（项目指按时并按照规定的预算完成了最初说明的所有系统特征和功能） ：16.2%， 有问题（超时完成、超过预算、或改变了最初约定的系统功能） ：52.7%， 完全失败（项目被彻底取消） ：31.1%。,美国standish group调查结果,分类结果 成功 大公司的项目成功率只有9%， 中型和小型公司的项目成功率分别为16.2%和28%。 有问题 大公司项目有61.5%是有问题的， 中型和小型公司的有问题的项目分别为46.7%和50.4%。 完全失败 29.5%的大公司项目被取消， 中型和小型公司中被取消的项目分别占37.1%和21.6%。,成功率为什么这么低？,项目成功/失败因素分析（95年）,项目成功/失败因素分析（95年）,十大成功因素中与需求相关的占了5项，排名前5大成功因素中有4项与需求相关。 有问题的十大原因中与需求相关的原因占5项，占36.9%。引起问题的原因中排名前3项都与需求相关。 失败项目的十大原因中与需求相关的原因占4项，占35.4%。排名前5项失败的原因中与需求相关的有3项。,其它一些调查结果,boehm(1981) 以后修正需求错误比在需求阶段修正它要多化200倍的代价。 brooks(1987) 构建软件最困难的阶段是精确地决定要构建什么（需求） esi(1996) 17个国家3800公司的调查 大多数 (50%) 被发现的问题是在需求规格说明和管理中,评述,项目需求无疑是在软件项目前期造成麻烦的一个最大问题，一个又一个的研究已经发现，当项目失败时，需求问题通常正是其核心问题。,（software runaways，glass，1998）,需求工程是“最关键性的和最易出问题的地方”。,（hooper and hsia，1982）,为什么是这样呢？,面对的问题,待开发的软件系统大部分是社会系统。涉及面广，需求相关者多 软件项目的成功除了技术因素外，还与社会因素（如政策）相关 规模大、交互复杂。可能超越人仅靠经验能够认识的问题的范围,需求阶段三要素,项目成败的因素：需求相关者,客户： 客户的需要被误解或没有被完全捕捉 客户需求变化得过于频繁 客户没有准备为项目提供足够的资源 客户不想与开发者合作 客户具有不现实的期望 系统不再对客户有利,开发人员： 不能胜任本项任务 开发者的技能和知识非常关键 杰出的设计来自杰出的设计者,项目成败的因素：过程,良定的过程模型 说明执行活动的次序 说明需要交出什么样的制品，以及什么时候交出 将活动和制品交给开发者 提供监控项目进程、评估产出和计划未来项目的准则 适当的个性化 每个组织都可以客户化一个通用过程模板得到自己的过程 良好的合作关系 任务安排的有组织性 任务分配的合理性 任务合作的协调性,项目成败的因素：建模,语言： 捕获系统需求，为系统建模，并用一种语言表达系统模型 支持在描述性语句中捕获过程性含义，说出什么需要做，而不是怎样去做 case工具： 支持模型的协同存取和开发者之间的合作 目前的uml及其工具： 支持面向对象风格 支持静态结构建模和动态行为建模,需求阶段,按主要活动看三要素： 抽取需求 参与者：客户和系统分析员 形式：结构化吗？有方法支撑吗？ 刻画需求 参与者：客户和系统分析员 形式：可理解吗？可解释吗？ 需求建模和分析 参与者：系统分析员 形式：形式化程度决定可分析程度，决定正确性验证的准确性 控制需求过程 参与者：系统分析员 形式：有可控的需求变更过程吗？有工具支持需求追踪吗？,需求工程有用吗？,从发展现状看,standish group报告（2000年）,数字的变化 成功率从1995年的16%增长到28% 面临问题的项目从1995年的53%减少到49% 项目的失败率从1995年的31%减少到23%,软件需求工程方法的引入改善了软件应用开发中的困难局面，在软件项目中引入适当的需求工程方法对提高软件开发的质量和软件项目的成功率具有明显的影响,standish group报告（2000年）,新的it项目成功的十大因素 与需求相关因素有5项： 用户参与（16%） 清楚的业务目标（12%） 尽可能小的问题范围（10%） 稳定的基本需求（6%） 形式化方法（6%）,需求工程方法的有效性、可行性以及实施的质量仍然直接决定和影响软件项目的质量,软件规模的扩大 社会/物理系统对软件越来越依赖 需求分析成为软件工程的关键,逐步与软件工程分离 成为一门专门的学科：需求工程,什么是软件需求工程,破 题,需求：构造任何人工制品之前，首先要弄清楚的是意图（为什么需要它？它将用在何处？） 工程：工程化方法，构造有用的人工制品，强调最终产品的实用性和目的性，需要规范化、标准化的生产过程，得到规范化、标准化的产品（而不是强调产品的创造性，与艺术比较而言）,软件需求工程,研究对象：软件加强型系统中的软件,泛指由计算机技术支持的互相联系 着的一组人类活动组成的系统 与物理设备相关 与人类社会的活动相关,软件加强型系统,比如：游戏软件与物理设备、用户 erp系统与组织运作过程,软件产品的种类,信息系统 嵌入式系统 通用的服务型系统,软件的类型（信息系统）,支持组织运作的软件 包含：文件/数据库、应用 70%以上的软件是这种类型 比如，职工工资、雇员记录、可银行帐户管理、客户记录、事务记录 需要业务分析,软件产品的种类,信息系统 嵌入式系统 通用的服务型系统,软件的类型（嵌入式系统）,嵌入物理设备，驱动某种硬件过程的软件 比如，电梯系统、信用卡机器，电信软件，飞行软件，等等 嵌入社会活动，驱动组织运作的软件（大量涉及人的活动） 比如，erp系统，车辆/航班调度系统，等 需要功能性的行为和非功能性的约束分析,软件产品的种类,信息系统 嵌入式系统 通用的服务型系统,软件的类型（通用服务系统）,提供某种形式的通用服务的系统 比如，传统意义上的科学计算系统，有经典的算法，不需要需求分析 比如，许多现代的internet应用，远程医疗咨询、远程学习，还没有标准的解决方案，需要需求分析,软件需求需要工程化方法吗？,大部分工业产品都不需要需求工程 有形的 可度量的 目的和产品形态有直接对应 为什么软件产品需要需求工程？,需求识别超出软件的范畴,软件的渗透性 需求从软件将运行的物理/社会系统中来 软件的目的来源于物理/社会系统赋予它的目的 这样的软件，其目的来自多个方面 具有多样非功能需求 软件的引入改变物理/社会系统，反过来影响对软件的需求,软件产品的特殊性,软件没有固定的形态: 配置通用的机器去实现特定的目的 但目标没有可直接对应的产品形态 人和软件交互的复杂性和持续性: 相比于不含软件的系统,含软件的系统会被高强度不间断的连续交互 交互过程中的相互控制性: 人控制软件系统,软件系统也需要控制人 多源交互的协调和软件的适应性: 一群人参与的活动,需要软件来协调,特殊性给产品开发带来困难,对与人紧密耦合的问题进行描述具有内在的复杂性，从而给理解软件的意图带来困难： 没有确定的问题构形 问题解决方案的构造过程没有硬性的终止规则 问题解决方案没有对错之分,只有好坏之分 不存在对问题解决方案的客观的检测手段 每个问题基本上都是全新的 一个问题的原因存在多种解释 ,三类问题和三种需求变化方式,三类问题和三种需求变化方式,s类型程序（可说明的） 问题能够被形式地和完全地陈述出来 接受：按照这个规格说明，这个程序是正确的吗？ 这种软件不会进化 对规格说明的改变定义一个新的问题，因而是新的程序 p类型程序（问题求解） 现实世界问题的不精确陈述 接受：对这个问题来说，这个程序是一个可接受的解决方案吗？ 这种软件很可能要连续地进化 因为这个方案是决不会完美的，并且是能够被改进的 因为现实世界要变化，所以这个程序也要变化 e类型程序（被嵌入的） 一个变成它建模的世界的一部分的系统 接受：完全依赖于观点和判断 这个软件是固有的进化的 软件和世界的变化相互影响,软件开发的不变量,软件是开发出来的，不是制造出来的 开发过程充满了各种不确定性 软件工程的进展已经为开发实践带来了很多确定因素： 算法、代码库、可复用类、软件构件：模块重用 商用成品软件：从零开始变成客户化软件 各种概念结构：支持从零开始的软件开发 但仍然不象传统工程那样成功 软件项目的成功仍然无法保证 任何组织都不可能找到一个软件包使它的核心业务活动可以自动生成,三个不同层次 上的解决方案,软件开发的本质困难,软件要解决的问题具有： 复杂性 不一致性 可变性 不可见性,软件工程固有的困难,软件开发的本质困难,软件：是作为一种创造性活动开发 出来的产品 是由工匠（而不是艺术家）创 作的工艺品或艺术品,软件不是重复性制造活动的产物 这样的人工制品需要需求工程,存在各种各样的不确定因素,一般工程化方法的动机,低成本高利润： 工程必须要考虑设计的消耗/产出平衡，特别是针对那些需要使用资源的问题。 解决方案： 工程强调解决方案的设计，通常是针对稳定的人工制品而言，即产品是有形的和度量的，其目的和产品形态有直接的对应关系。 解决实际问题： 工程师处理的问题常常是和人相关的，工程一般关注于通过技术的进步来提高人类生活的质量。 运用科学知识： 区别工程与其它设计的关键区别在于它要系统地使用分析技术，这些技术具有科学和数学的背景，工程使用这些技术分析问题，同时也对创建解决方案具有指导作用。,软件需求工程的任务,浅层理解：软件工程是要做出一个系统，其中，需求工程关注系统将要做什么，后续阶段关注系统将怎样被实现。 深层理解：软件工程的产品是用来解决问题的。其中，后续阶段是关于如何解决问题，而需求工程的目的是定义所需解决的问题。,软件需求工程任务特征,需求工程任务 定义不足的问题定义良好的问题 需求工程目的 找出解决方案 需求工程的结果得到的过程 创造：需求是创造出来的，几乎是从无到有的过程 需求工程的对错 单纯的创造没有对错，但需求却有上下两个方面的判断标准 保证是可实现的（需求模型的正确性） 保证实现的东西是用户想要的（需求模型的有效性）,软件需求工程的操作特征,大量的领域知识，成为问题领域的专家 需求分析过程需要融入问题领域的知识 信息沟通与知识传递，与人沟通 知识和信息需要从客户或其他人那里获得，传递存在的知识并不想想象得那么容易 输入是朴素和粗糙的，而输出要完全精确 需要大量细化、准确化、和求精的工作,什么是软件需求？,问题领域：问题所存在的现实世界中的某个部分 解系统：必须要用来在问题领域内产生某些效果，从而解决存在的问题,需求涉及问题领域中的私有现象,规格说明涉及问题领域与系统共享的现象,领域知识涉及问题领域中的私有现象和与系统共享的现象,领域知识涉及问题领域中的私有现象和与系统共享的现象,软件需求工程的任务,已知环境e（问题领域分析），已知需求r（需求抽取， 对环境的作用，客户希求的目标），构造规格说明s（可实现的） 使得：,期望引入目标系统后环境将满足的约束（需求r）,规格说明s,满足规格说明s的目标系统,环境说明e,软件需求和软件规格说明的分离,理解问题 抽取、需求获取、等 形式地描述问题 规格说明、建模、等 获得对问题本质的一致意见 证明有效、矛盾归结、协商 需求管理维护一个一致的意见,软件需求和规格说明的交织,客户需求,规格说明,软件需求工程,三个活动组成的系统化过程： 通过一个迭代合作的问题分析过程开发需求 用各种形式的表示格式将所得到的观察文档化 检查所获得的理解的准确性,可能遇到的问题,开发需求的系统化过程 在这个过程刚开始的时候存在很多未知因素的情况下，这个过程怎样才能是系统化的？当我们并不知道需要多少步或者当什么时候可以结束还不清楚的时候，我们怎么能采取步进的方法？,可能的问题所在,通过一个迭代合作的分析问题的过程 需要多少次迭代？ 我们怎么知道已经采集了足够多的需求？ 足够是什么意思？ 合作涉及人与人的合作，那谁将会被这个过程涉及呢？他们怎样相互沟通？他们将就这个过程达成什么样的协议？ 用户应该是主动参与者吗？他们应该被牵扯进决策过程中吗？还是他们仅仅只作为信息源？,可能的问题所在,用各种形式的表示形式将所得到的观察文档化 应该采用什么表示形式？ 结果应该怎样文档化？ 应该采用什么标准和哪种表示法？为什么？,可能的问题所在,检查所获得的理解的准确性 我们怎样才知道这个过程完成了？ 需求需要有多准确？在这个地方准确是什么意思？ 参与需求工程的每个人都将具有相同的理解吗？,区分客户需求和软件规格说明,两种常用的关于需求的定义 需求是客户希望在问题域内产生的效果。 需求是系统为解决问题或完成目标所必须满足的条件或能力。 实际案例中的两句陈述： 每当电梯停在某一楼层时，电梯门将在开启、等待、关闭3个状态中循环。 每当电梯停在某一楼层时，系统将使电梯门在开启、等待、关闭3个状态中循环。,需求的种类,需求的种类,功能需求： 由待开发的软件系统的适当行为（功能性）所满足的需求 功能可以分层次描述 性能需求： 安全性、速度、容量、可用性、可靠性 是一种特别不稳定的需求 设计约束： 完全属于非功能性需求 常见的约束： 直接约束系统的合成结构 约束用于开发系统的过程和技术，只能间接地影响系统的结构 商业约束： 开发时间、费用与最终的功能性、可靠性、可用性之间的关系,需求类型的定义和描述（一）,客户需要和期望 业务需求 用户需求 产品需求 环境需求 未知需求,需求类型的定义和描述（一）,客户需要和期望 业务需求 用户需求 产品需求 环境需求 未知需求,是开发系统和软件的原因 从业务目标中导出 可借助于业务情景理解业务需求 支持业务需求并辅助组织实现它们是系统成功的关键因素,需求类型的定义和描述（一）,客户需要和期望 业务需求 用户需求 产品需求 环境需求 未知需求,用户是使用系统或软件的个体或群体 用户需求是他们对系统或软件的需要,需求类型的定义和描述（一）,客户需要和期望 业务需求 用户需求 产品需求 环境需求 未知需求,由一个系统生产出的产品的需求,需求类型的定义和描述（一）,客户需要和期望 业务需求 用户需求 产品需求 环境需求 未知需求,从系统开发工作涉及的物理设备、社会和文化的条件，以及系统或软件将使用的设置中导出的需求,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,最主要的,抓住客户心理的,用于定义系统范围的,用于估计系统构建的代价和时间的需求. 举例: 连续的业务上的成功 高质量的产品或服务 满足客户的需要 缩减代价 客户和雇员的忠诚 改进的性能 减少失效 有效性 缩减周期时间 创新性解决方案 ,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,系统或软件必须要做什么 一个功能是由系统的一个或多个组件提供的能力 因为功能需求要说明对系统的输入,系统的输出,以及输入和输出之间的行为关系,有时称作为行为或操作需求 用来沟通客户、系统和软件工程师的文档，一般就是功能文档或者规格说明 功能文档提供了对系统要操作的数据的详细分析、系统接口的详细定义、以及系统对用户提供的能力,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,非功能需求说明系统的特性，比如：可靠性、安全性等,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,为什么要考虑设计约束？因为分离需求工程和设计活动有时很难： 新系统要安装在已经存在其他系统的环境之中，其他系统限制了新系统的设计 大型系统必须要进行体系结构上的划分，使各子系统的需求要分别并行考虑 出于预算、期限、质量等方面的原因，常希望重用一些已经存在的系统，这既约束了系统需求，也约束了系统设计 如果系统需要外部规定的批准，必须使用标准的设计,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,定义并满足性能需求（可依赖性需求），最困难的问题 定义功能的需求必须执行得有多好 可依赖性需求相当于对可用性、性能、可靠性、安全性等方面的系统级需求,需求类型的定义和描述（二）,被系统分析员用不同方式分析和描述的 高层（或系统层）需求 功能需求（系统必须要做的） 非功能需求 系统特性（比如：安全性） 专门工程需求 导出需求和设计约束 性能需求（比如：要多快） 接口需求（系统元素之间的关系）,识别系统元素之间，以及系统元素和系统环境之间的物理的