《需求工程导论教学课件PPT》由会员分享，可在线阅读，更多相关《需求工程导论教学课件PPT（44页珍藏版）》请在金锄头文库上搜索。
1、课程介绍课程安排课程的目的和背景教学大纲和主要内容参考书目课程安排每周4*50分钟（8周）其中第一周 需求工程的基本知识一第二周 需求工程的基本知识二第三周 需求工程的获取技术第四周 需求工程的建模技术一第五周 需求建模技术二，课程设计指导第六周 需求管理技术第七周 主要的需求分析方法介绍第八周 复习考试另有8个学时的实验课课堂作业随堂练习课程设计报告一份考试和评分标准随堂练习20%课程设计案例分析报告30%课程结束考试50%课程的目的了解需求工程研究和实践的现状了解需求工程研究和实践的现状, ,以及进行以及进行进一步研究的背景知识进一步研究的背景知识需求工程在软件工程中的地位和角色需求工程的
2、本质需求工程方法学当前的代表性研究获得对目前代表性需求工程方法和技术的获得对目前代表性需求工程方法和技术的一些实践经验一些实践经验预备知识软件工程软件工程软件开发过程基本的软件建模思想基本的形式化建模手段基本的形式化建模手段基于逻辑的方法命题逻辑谓词逻辑简单的模态逻辑基本状态变迁系统应用软件开发的工程实践经验应用软件开发的工程实践经验参考书目参考书目软件需求工程原理和方法，金芝编写科学出版社需求分析与系统设计 LESZEK.A 马素霞 等译经典文献1.Davis, A., A Taxonomy for the Early Stages of the Software Development L
3、ife Cycle, Journal of Systems and Software, 8(4): 297-311. 19882.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, Sp
4、ringer Verlag, 1993.3.Davis, A. M., Software Requirements: Objects, Functions and States, Prentice Hall, 1993.4.Flowers S., Software Failure: Management Failure, New York: Wiley, 1996.5.Grady, Jeffrey O., System Requirements Analysis, Mcgraw-Hill, 19936.Gunter, Carl A., Gunter, Elsa L., Jackson, M.
5、and Zave, P., A Reference Model for Requirements and Specifications. IEEE Software 17(3), 20007.Jackson, M., Software Requirements and Specifications, Addison Wesley/ ACM Press, 19958.Loucopoulos, P., and Karakostas, V., System Requirements Engineering, McGraw-Hill Book Company Europe, 19959.Jackson
6、, M., The meaning of requirements, Annals of Software Engineering 3: 5-21, 199710.Zave, P., Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys, 29(4): 315-321, 199711.Zave, P., and Jackson, M., Four Dark Corners of Requirements Engineering, ACM Trans. Softw. Eng. M
7、ethodol. 6(1): 1-30, 199712.Ian Sommerville and Peter Sawyer, Requirements Engineering: A Good Practice Guide.Chichester, England: John Wiley&Sons, 199713.Kotonya, G., and Sommerville, Ian, Requirements Engineering: Processes and Techniques. John Wiley & Sons Ltd, 1998.14.Robertson, S., and Robertso
8、n, J., Mastering the Requirements Process, Addison-Wesley. 1999.15.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.16.Bray, Ian K., An Introduction to Requirements
9、Engineering, Addison-Wesley, Reading, MA, 200217.Davis, Alan M., Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House Publishing, 2005第一讲. 需求工程导论主要内容1.软件的需求问题1.软件的发展2.软件生产状况调查2.需求问题的原因分析3.需求工程4.需求工程师1.1软件的发展60年代的发展1.1软件的发展 软件危机1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术
10、会议上第一次提出了“软件危机”(software crisis)这个名词。软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题开发成本超出预算，实际进度比预定计划一再拖延。用户对“已完成”系统不满意的现象经常发生。软件产品的质量往往靠不住。Bug一大堆，Patch一个接一个。软件的可维护程度非常之低。软件通常没有适当的文档资料。软件的成本不断提高。软件开发生产率的提高赶不上硬件的发展和人们需求的增长1.1软件的发展 软件工程概括来说，软件危机包含两方面问题：一、如何开发软件，以满足不断增长，日趋复杂的需求；二、如何维护数量不断膨胀的软件产品。解决方案：软件工程IEEE ：（1）应
11、用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即，将工程应用到软件。（2）对（1）中各种方法的研究”1.1软件的发展90年代的发展EAI:企业应用集成，CBD:基于组件的开发1.2 90年代的软件生产状况调查Standish Group 1995365家公司的8380个项目成功项目Success：在预计的时间之内，在预算的成本之下，完成预期的所有功能问题项目Challenged：已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全失败项目Impaired：因无法进行而被中途撤销，或者最终产品无法提交使用1.2 90年代的软件生产状况调查 Standish
12、 Group 1995大公司开发项目的平均成本是232.2万美元，中等公司是133.1万美元，小型公司是43.4万美元大约31的项目在完成之前被取消，52.7的项目成本是原来预算的189%大公司9%按预算交付，小公司16%按预算交付1.2 90年代的软件生产状况调查 影响因素Standish Group 1995成功项目的影响要素成功项目的影响要素影响指数用户参与15.9高层管理支持13.9清晰的需求说明13.0正确的项目计划9.6切合实际的期望8.2细化的项目里程碑7.7员工能力7.2主人翁精神5.3清晰的目标和前景2.9努力工作2.4其他13.91.2 90年代的软件生产状况调查 影响因素
13、Standish Group 1995问题项目的影响要素问题项目的影响要素影响指数缺少用户输入12.8不完整的需求说明12.3需求变化11.8缺乏高层管理支持7.5技术能力不足7.0缺乏资源6.4不切实际的期望5.9目标不清晰5.3不现实的时间要求4.3新技术的影响3.7其他23.01.2 90年代的软件生产状况调查 影响因素Standish Group 1995失败项目的影响要素失败项目的影响要素影响指数不完整的需求说明13.1缺少用户输入12.4缺乏资源10.6不切实际的期望9.9缺乏高层管理支持9.3需求变化8.7缺乏计划8.1额外的无用功能7.5缺乏IT管理6.2技术能力不足4.3其他
14、9.91.2 90年代的软件生产状况调查 影响因素Standish Group 1995需求因素用户参与（用户输入）高层管理支持清晰的需求说明切合实际的期望清晰的目标和前景需求变化额外的无用功能综合来看，需求因素对成功项目的影响指数为53.9对问题项目的影响指数为55.6对失败项目的影响指数为60.9 1.2 90年代的软件生产状况调查ESPITI，1996欧洲软件协会ESI 欧洲软件过程改进培训计划项目ESPITI 17个国家的超过3800个组织 1.2 90年代的软件生产状况调查需求问题的典型案例Bray2002PROMS（演出权益协会）,11M,1992,未能以常人能理解和检查的形式表述
15、软件需求，软件规格说明也考虑不周（与客户沟通的问题）RISP（西萨克斯地区信息系统计划）, 43M ,1990,缺少清晰的项目范围定义（需求的边界问题）TAURUS(伦敦股票交易), 75M(1.4B), 1993,未能协调不一致的需求（不一致需求的管理问题）LASDS(伦敦救护车服务派遣系统), 1992,社会服务领域糟糕的需求分析（需求不清晰）ATC(空中交通控制系统), 1.8B,1998-2001,缺乏健壮的需求规格说明（需求没有搞清楚就匆忙开始工作)近期的软件失效案例近期的软件失效案例同时访问同一资源的计算机超出预定范围开放软件面对各种病毒攻击20082008年年年年6 6月月月月3
16、030日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一日，北京奥运门票系统在提交使用的当天即发生瘫痪；原因之一是对系统用户数的预测不足是对系统用户数的预测不足是对系统用户数的预测不足是对系统用户数的预测不足 20042004年年年年4 4月，东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消月，东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消月，东京证交所称其交易系统出现的故障使得某证券公司未能迅速取消月，东京证交所称其交易系统出现的故障使得某证券公司未能迅
17、速取消一笔输错指令的交易，导致该公司蒙受了近一笔输错指令的交易，导致该公司蒙受了近一笔输错指令的交易，导致该公司蒙受了近一笔输错指令的交易，导致该公司蒙受了近2.52.5亿美元的损失；故障原因之一，亿美元的损失；故障原因之一，亿美元的损失；故障原因之一，亿美元的损失；故障原因之一，对操作人员的错误行为的预期不充分对操作人员的错误行为的预期不充分对操作人员的错误行为的预期不充分对操作人员的错误行为的预期不充分 主要内容1.软件的需求问题2.需求问题的原因分析1.应用软件的模拟特性2.需求问题的技术原因分析3.需求工程4.需求工程师2.1 应用软件的模拟特性软件的三种类型软件类别纯工具型软件应用型
18、软件专业用户普通用户评判标准功能的复杂性使用的高效性技术的先进性功能的有用性使用的方便性技术的可行性功能的“模拟”性使用的方便性技术的可行性关注点创新性有效性模拟性示例系统编程环境DBMSOffice语言翻译MISEAI2.1 应用软件的模拟特性软件的分析活动2.1 应用软件的模拟特性软件模拟性的实践调查对应用型软件的“模拟”特性理解及应用问题Capers JonesCapers1996在调查了几百个公司之后发现超过75的企业在需求处理环节存在不足。2000年Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现Nikula2000：在以30分为标准线的情况下，75%的公司竟然在1
19、0分以下。Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程Hofmann2001。Juristo 等人在对欧洲的150多名RE实践者进行调查后发现，在需求处理的诸多技术当中，需求获取和冲突协商的技术没有得到充分的应用Juristo 2002。研究也发现当软件生产面临时间、市场等其他压力时，漠视“模拟”特性的情况就更为严重Lubars1993，Francisco2003 2.2 需求问题的技术原因分析非技术性和社会性因素组织机构文化、社会背景、商业目标、利益协商关注软件系统和现实之间的互动效应 软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件
20、内部的数据流与状态更应该得到重视解决方案和具体应用环境相关的 不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的 面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商 2.2 需求问题的技术原因分析结构化分析和面向对象分析具有一定的先天缺陷 编程 设计分析设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功 但是需求分析除了拥有构建高质量软件的目标之外
21、，还有一个更加重要的目标是理解现实 2.2 需求问题的技术原因分析以“企业”为中心的软件反映了软件规模日益扩大 一方面提高了需求处理中非技术性和社会性因素的影响比重另一方面也进一步放大了传统技术在需求处理阶段的不适应性 2.2 需求问题的技术原因分析需求错误的高代价性 主要内容1.软件的需求问题2.需求问题的原因分析3.需求工程1.简介2.基本活动3.需求工程与系统工程4.需求工程特性4.需求工程师3.1 需求工程是软件工程的一个分支它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束同时它也关注以上因素和准确的软件行为规格说明之间的联系关注以上因素与其随时间或跨产
22、品族而演化之后的相关因素之间的联系3.2 需求工程的基本活动3.3 需求工程与系统工程3.4 需求工程的特性必要性软件开发是这样一个工程问题利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的 计算机应用于现实世界的广泛性 新的问题和新的解决方案 定义问题就是需求工程的任务 3.4 需求工程的特性重要性Frederick BrooksBrooks1987 “开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困
23、难。”容易忽略需求工程重要性的地方问题广为人知 电梯调度、图书管理 问题小而简单 出错也无所谓 3.4 需求工程的特性复杂性处理范围广泛 现实世界和计算机世界 涉及诸多参与方 客户、用户、领域专家、需求工程师、软件开发者、系统维护者等 处理内容多样 功能需求、非功能需求 、环境及其约束 处理活动互相交织 需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的 处理结果要求苛刻 正确性、完整性和一致性 主要内容1.软件的需求问题2.需求问题的原因分析3.需求工程4.需求工程师1.知识要求2.技能要求4.1 需求工程师需要具备的知识软件技术尤其是软件建模与分析技
24、术认知学和社会学等方面的知识 认知心理学 人类学 社会学 语言学 哲学知识 掌握涉众的信仰与理念（认识论） 分析在现实中观察到的各种现象（现象学） 4.2 需求工程师需要具备的技能专业技能 需求工程的相关知识 分析技能 抽象能力 整合能力系统化思想交流技能 交谈和提问的技巧 倾听的技巧 4.2 需求工程师需要具备的技能观察技能 建模技能 写作技能 文档组织能力 语言驾驭能力 创新技能 发现连用户都没有意识到的潜在需求 协调能力 随堂作业是否参加过软件开发项目？如果参加过，请简单描述要开发的软件的功能。你认为这个软件系统需要进行软件需求工程吗？为什么？如果没有参加过，或者上述项目不需要进行软件需求工程。请设想一个需要使用软件需求工程的软件开发场景，并解释为什么需要进行软件需求工程？下节课提交文字材料，并要求做好ppt，下节课开始请每位同学讲他们的答案。本章小结从20世纪60年代末期软件工程产生起，需求分析就一直是软件开发的重要主题20世纪90年代的调查状况表明，单纯的需求分析已经不能很好的解决软件生产中的“需求”问题应用型软件的模拟性和一系列的技术原因表明软件生产需要进行一个比需求分析更加复杂和完整的需求工程需求工程是软件工程当中一项重要和复杂的活动，需求工程需要具备一定的知识和技能才可以很好的执行需求工程活动
