《软件需求工程概述幻灯片.ppt》由会员分享，可在线阅读，更多相关《软件需求工程概述幻灯片.ppt（71页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件需求工程概述软件需求工程概述第1页，共71页，编辑于2022年，星期三2Software Requirements Engineering软件需求工程概述软件需求工程概述第2页，共71页，编辑于2022年，星期三3第3页，共71页，编辑于2022年，星期三4本章内容本章内容工程与软件工程工程与软件工程软件需求工程软件需求工程需求工程师需求工程师需求工程需求工程vs.系统分析系统分析软件生命周期中的需求活动软件生命周期中的需求活动关于需求的基本观点关于需求的基本观点第4页，共71页，编辑于2022年，星期三5Engineering VS.Software Engineering 工程与软件工
2、程工程与软件工程第5页，共71页，编辑于2022年，星期三6工程工程 人工的科学人工的科学(Sciences of Artificial)自然科学是揭示自然界的本质和现象的科学。自然科学是揭示自然界的本质和现象的科学。“工程工程”则可以诠释为则可以诠释为“人工人工”（artificial）的科学，的科学，或设计的，制造的科学。或设计的，制造的科学。原始森林原始森林/林业工程林业工程天然水晶天然水晶/宝石加工工艺宝石加工工艺计算机工程，软件工程，企业营销计划，医药治疗方案计算机工程，软件工程，企业营销计划，医药治疗方案一切工程活动都是服务于某种预期的目的的，同时一切一切工程活动都是服务于某种预期
3、的目的的，同时一切的人造物都的人造物都”应该应该”具有某种预期的功用。具有某种预期的功用。建筑，商业，教育，法律，医学，建筑，商业，教育，法律，医学，Herbert Simon,1969第6页，共71页，编辑于2022年，星期三7什么是工程什么是工程?工程的定义:工程就是运用科学知识，对现实问题提供性工程就是运用科学知识，对现实问题提供性能价格比合理的解决方案。能价格比合理的解决方案。性价比合理：涉及性能价格的权衡，尤其是在涉及性能价格的权衡，尤其是在资源的使用方面。资源的使用方面。解决方案：工程是有创造性和实效性的。工程是有创造性和实效性的。现实问题：问题是受人们关注的。问题是受人们关注的。
4、科学知识：用到应用科学中的分析方法。用到应用科学中的分析方法。第7页，共71页，编辑于2022年，星期三8什么是工程什么是工程?普通设计与开创性设计普通设计与开创性设计普通设计：解决已有问题，解决方案已广为人知。普通设计：解决已有问题，解决方案已广为人知。工程实践依照规范化的标准解决方案工程实践依照规范化的标准解决方案由工程师选择合适的方法和技术由工程师选择合适的方法和技术运用广为人知的设备进行设计运用广为人知的设备进行设计开创性设计：从未有人作过，或已有解决方案失效。开创性设计：从未有人作过，或已有解决方案失效。通常要面临解决复杂问题的困难挑战通常要面临解决复杂问题的困难挑战对若干设备进行复
5、杂装配形成新的系统对若干设备进行复杂装配形成新的系统系统工程更为强调和关注开创性的设计系统工程更为强调和关注开创性的设计第8页，共71页，编辑于2022年，星期三9软件工程的特殊性软件工程的特殊性软件的特殊性软件的特殊性软件具有抽象性软件具有抽象性软件是不能独立存在的，其作用在于驱动硬件进行软件是不能独立存在的，其作用在于驱动硬件进行某种操作某种操作软件行为不受物理定律约束软件行为不受物理定律约束软件复杂性不受物理限制软件复杂性不受物理限制软件无磨损软件无磨损传统的可靠性度量方法不再适用传统的可靠性度量方法不再适用软件复制无损耗软件复制无损耗复制品与原件无区别复制品与原件无区别第9页，共71页
6、，编辑于2022年，星期三10软件工程的特殊性软件工程的特殊性Think about these:Think about these:软件成本低于物理设备成本软件成本低于物理设备成本 软件易修改软件易修改 计算机比物理设备可靠性高计算机比物理设备可靠性高 软件的正确性可形式化的证明软件的正确性可形式化的证明 软件重用提高安全性和可靠性软件重用提高安全性和可靠性 计算机系统同机械系统相比风险更低计算机系统同机械系统相比风险更低关于软件的荒谬说法关于软件的荒谬说法(Myths)(Myths)：第10页，共71页，编辑于2022年，星期三11本章内容本章内容工程与软件工程工程与软件工程软件需求工程软
7、件需求工程需求工程师需求工程师需求工程需求工程vs.系统分析系统分析软件生命周期中的需求活动软件生命周期中的需求活动关于需求的基本观点关于需求的基本观点第11页，共71页，编辑于2022年，星期三12Software Requirements Engineering 软件需求工程软件需求工程第12页，共71页，编辑于2022年，星期三13什么是需求工程？什么是需求工程？需求工程是系统工程及软件工程的重要分支。需求工程是系统工程及软件工程的重要分支。需求工程旨在了解软件系统设计的真实意图，需求工程旨在了解软件系统设计的真实意图，具体功用及限制条件。并精确定义上述因素与具体功用及限制条件。并精确定
8、义上述因素与系统行为的关系及系统随时间和产品线变化而系统行为的关系及系统随时间和产品线变化而发生的各种演化。发生的各种演化。第13页，共71页，编辑于2022年，星期三14什么是需求工程？什么是需求工程？需求工程是指应用已证实有效的技术、方需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不
9、和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。断变化的需求演进给予支持。注意，和所有工程学科一样，需求工程并不是以零星偶发的、随机注意，和所有工程学科一样，需求工程并不是以零星偶发的、随机的或无计划的方式进行，而是代之以已证明方法的系统化应用。的或无计划的方式进行，而是代之以已证明方法的系统化应用。第14页，共71页，编辑于2022年，星期三15需求工程的重要意义需求工程的重要意义对大多数人来说，若要建一幢对大多数人来说，若要建一幢20万美元的房万美元的房子，他一定会与建房者详细讨论各种细节，子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以他们都明白
10、完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开及变更细节的危害性。然而，涉及到软件开发，人们却变得发，人们却变得“大大咧咧大大咧咧”起来。软件项起来。软件项目中百分之四十至百分之六十的问题都是在目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的需求分析阶段埋下的“祸根祸根”。（Le ffingwell 1997）第15页，共71页，编辑于2022年，星期三16需求工程的重要意义需求工程的重要意义问题的严重性：问题的严重性：对软件的依赖不断增加：对软件的依赖不断增加：汽车，手机，Web Services，软件成本的比重加大：软件成本的比重加大：Boeing777软件项目
11、失败带来巨大浪费：软件项目失败带来巨大浪费：1997 GAO 报告-6年内烂尾软件项目耗资1470亿美元 General Accounting Office(美国)总审计局第16页，共71页，编辑于2022年，星期三17需求工程的重要意义需求工程的重要意义问题的严重性：问题的严重性：软件失败的严重后果：软件失败的严重后果：Ariane 5:3.7亿美元的损失；第17页，共71页，编辑于2022年，星期三18需求工程的重要意义需求工程的重要意义问题的成因：问题的成因：软件质量认证的高成本：软件质量认证的高成本：Boeing 777 40%的软件成本用于测试的软件成本用于测试以修正软件缺陷为目的的
12、软件重写：以修正软件缺陷为目的的软件重写：Motorola:曾将曾将60%-80%的软件费用用于重写的软件费用用于重写需求的频繁变化：需求的频繁变化：Capers Jones（1994）在报告中称扩展需求对百）在报告中称扩展需求对百分之八十的管理信息系统项目和百分之七十的军事分之八十的管理信息系统项目和百分之七十的军事软件项目造成风险。软件项目造成风险。第18页，共71页，编辑于2022年，星期三19解决方案？解决方案？没有没有“银弹银弹”！No Silver Bullet!（Fred Brooks，1987）n软件的规模决定它的复杂性软件的规模决定它的复杂性n软件具有抽象性和不可视性软件具有
13、抽象性和不可视性n软件没有规范的装配步骤，因此极易修改！软件没有规范的装配步骤，因此极易修改！“No Silver Bullet”的原文是：的原文是：“没有任何技术或管理上的没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。量级上的进步。”在软件开发过程里是没有万能的终杀性武器的，只有各种方在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。法综合运用，才是解决之道。第19页，共71页，编辑于2022年，星期三20解决方案？解决方案？然而，早期的建模和分析是非常重要的然而
14、，早期的建模和分析是非常重要的可以节省纠错成本：晚期修改可能会使成本高出可以节省纠错成本：晚期修改可能会使成本高出200倍倍当然，仅仅有早期的建模和分析是不够的当然，仅仅有早期的建模和分析是不够的所有项目参加者均需了解系统需求所有项目参加者均需了解系统需求所有风险承担者均需对需求达成共识所有风险承担者均需对需求达成共识需透彻了解系统运作的背景需透彻了解系统运作的背景需透彻了解系统设计过程及其背景需透彻了解系统设计过程及其背景当需求发生演变时，要及时更新当需求发生演变时，要及时更新第20页，共71页，编辑于2022年，星期三21需求工程指南需求工程指南(Roadmap:Bashar Nuseib
15、eh&Steve Easterbrook,2000)(Roadmap:Bashar Nuseibeh&Steve Easterbrook,2000)如何如何获取获取需求信息？需求信息？识别：风险承担者，目标，分析角度，系统边识别：风险承担者，目标，分析角度，系统边界，应用实例，界，应用实例，核心技术：核心技术：座谈，问卷，代表会议座谈，问卷，代表会议 采用人种学（采用人种学（Ethnographic）方法（社交嵌入系）方法（社交嵌入系统）统）采用原型法，或参与设计法（缺乏了解的系统）采用原型法，或参与设计法（缺乏了解的系统）如何如何分析分析需求信息？需求信息？概念建模概念建模第21页，共71页
16、，编辑于2022年，星期三22需求工程指南需求工程指南(Roadmap:Bashar Nuseibeh&Steve Easterbrook,2000)(Roadmap:Bashar Nuseibeh&Steve Easterbrook,2000)如何就需求如何就需求达成共识达成共识？进行经验主义的模型验证进行经验主义的模型验证当出现矛盾和分歧时，提供磋商的方法和手段当出现矛盾和分歧时，提供磋商的方法和手段如何如何表达表达需求？需求？自然语言与形式化语言的合理搭配自然语言与形式化语言的合理搭配如何保持需求的如何保持需求的现时性现时性？需求发生变化时，及时更新需求发生变化时，及时更新产品线的维护产
17、品线的维护第22页，共71页，编辑于2022年，星期三23需求工程的理论基础需求工程的理论基础 RE FoundationsRE Foundations系统理论系统理论什么是系统什么是系统系统的控制和演化系统的控制和演化系统工程系统工程工程生命周期工程生命周期数学与逻辑数学与逻辑一阶逻辑一阶逻辑模态逻辑，时序逻辑，及模态逻辑，时序逻辑，及其他非经典逻辑其他非经典逻辑代数和关系模型代数和关系模型计算机科学计算机科学自动机理论自动机理论抽象，分解，和面向对象抽象，分解，和面向对象软件体系结构和设计模式软件体系结构和设计模式社会科学人类学与民族方法学组织行为学社会心理学政治学认知科学认知心理学语言学
18、知识表示（人工智能）哲学经验主义和科学哲学现象学，认识论和本体符号语言学 第23页，共71页，编辑于2022年，星期三24需求工程的领域划分需求工程的领域划分软件需求工程划分为需求开发和需求管理软件需求工程划分为需求开发和需求管理第24页，共71页，编辑于2022年，星期三25需求工程的领域划分需求工程的领域划分需求开发需求开发 问题获取问题获取分析分析编写规格说明编写规格说明验证验证需求管理需求管理 建立并维护在软件工程中同客户达成的契约建立并维护在软件工程中同客户达成的契约第25页，共71页，编辑于2022年，星期三26需求需求开发开发需求开发活动包括以下几个方面：需求开发活动包括以下几个
19、方面：确定产品所期望的用户类。确定产品所期望的用户类。获取每个用户类的需求。获取每个用户类的需求。了解实际用户任务和目标以及这些任务所支持的业务了解实际用户任务和目标以及这些任务所支持的业务需求。需求。分析源于用户的信息以区别用户任务需求、功能需求、分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。业务规则、质量属性、建议解决方法和附加信息。第26页，共71页，编辑于2022年，星期三27需求需求开发开发需求开发活动包括以下几个方面：需求开发活动包括以下几个方面：将系统级的需求分为几个子系统，并将需求中的将系统级的需求分为几个子系统，并将需求中的一部份
20、分配给软件组件。一部份分配给软件组件。了解相关质量属性的重要性。了解相关质量属性的重要性。商讨实施优先级的划分。商讨实施优先级的划分。将所收集的用户需求编写成规格说明和模型。将所收集的用户需求编写成规格说明和模型。评审需求规格说明，确保对用户需求达到共同的理评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题解与认识，并在整个开发小组接受说明之前将问题都要弄清楚。都要弄清楚。第27页，共71页，编辑于2022年，星期三28需求需求管理管理 通常的需求管理活动包括通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）。定义需求基线（迅速制定需求文档的主
21、体）。评审提出的需求变更、评估每项变更的可能影响从而决定是否评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。实施它。以一种可控制的方式将需求变更融入到项目中。以一种可控制的方式将需求变更融入到项目中。使当前的项目计划与需求一致。使当前的项目计划与需求一致。基于估计变更需求所产生影响的基础上，协商新的承基于估计变更需求所产生影响的基础上，协商新的承诺（约定）。诺（约定）。让每项需求都能与其对应的设计、源代码和测试用例联让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。系起来以实现跟踪。在整个项目过程中跟踪需求状态及其变更情况。在整个项目过程中跟踪需求状态及其变更情况
22、。第28页，共71页，编辑于2022年，星期三29需求需求管理管理 需求管理活动需求管理活动第29页，共71页，编辑于2022年，星期三30需求开发和需求管理之间的界限需求开发和需求管理之间的界限第30页，共71页，编辑于2022年，星期三31本章内容本章内容工程与软件工程工程与软件工程软件需求工程软件需求工程需求工程师需求工程师需求工程需求工程vs.系统分析系统分析软件生命周期中的需求活动软件生命周期中的需求活动关于需求的基本观点关于需求的基本观点第31页，共71页，编辑于2022年，星期三32SRE Engineer 需求工程师需求工程师第32页，共71页，编辑于2022年，星期三33Re
23、quirements Engineer 需求工程师需求工程师1.分析问题和解决问题的能力分析问题和解决问题的能力2.人际沟通及交流能力人际沟通及交流能力3.软件工程知识和技能软件工程知识和技能4.应用领域有关知识应用领域有关知识5.书面语言组织和表达能力书面语言组织和表达能力6.第33页，共71页，编辑于2022年，星期三34需求工程师做什么需求工程师做什么着手点是有待解决的着手点是有待解决的“问题问题”出现出现例如：例如：对系统现状不满；对系统现状不满；有新的商机出现；有新的商机出现；有可能节能、降耗、省时等。有可能节能、降耗、省时等。第34页，共71页，编辑于2022年，星期三35需求工程
24、师做什么需求工程师做什么需求工程师促进变化的发生，要完成以下工作：需求工程师促进变化的发生，要完成以下工作：确定确定“问题问题”及及“机会机会”要解决的问题是什么要解决的问题是什么?(问题的界定问题的界定)问题出在何处问题出在何处?(了解问题的领域及上下文了解问题的领域及上下文)问题与谁相关问题与谁相关?(确定干系人确定干系人-Stakeholder)为什么解决该问题为什么解决该问题?(确定干系人的目标确定干系人的目标)软件系统如何促进问题的解决软件系统如何促进问题的解决?(搜集情景实例搜集情景实例)解决问题的期限解决问题的期限?(确定开发活动的约束和限制确定开发活动的约束和限制)影响问题解决
25、的因素有哪些影响问题解决的因素有哪些?(确定可行性和风险确定可行性和风险)成为问题领域的专家成为问题领域的专家拥有更多的机会和解决问题的方案拥有更多的机会和解决问题的方案第35页，共71页，编辑于2022年，星期三36ACM/IEEE 职业道德规范职业道德规范:PUBLIC 保护保护公众公众利益。利益。CLIENT AND EMPLOYER 在保护公众利益的前提下，为在保护公众利益的前提下，为客户及雇主客户及雇主的最高利益服务。的最高利益服务。PRODUCT 尽可能令你的尽可能令你的产品产品符合行业的最高标准。符合行业的最高标准。JUDGEMENT 在进行职业在进行职业判断判断时，保持正直及独
26、立性。时，保持正直及独立性。MANAGEMENT 对软件开发和维护的对软件开发和维护的管理管理应遵循和提倡符合应遵循和提倡符合职业道德。职业道德。PROFESSION 在符合公众利益的前提下，推进在符合公众利益的前提下，推进职业职业的正的正直性和声誉。直性和声誉。COLLEAGUES 对对同事同事要持公正和支持的态度。要持公正和支持的态度。SELF 毕生坚持学习并在职业生涯中提倡职业道德。毕生坚持学习并在职业生涯中提倡职业道德。职业责任职业责任 (Code of Ethics)第36页，共71页，编辑于2022年，星期三37职业责任职业责任 (Code of Ethics)与需求工程相关的职业
27、规范与需求工程相关的职业规范:Competence 永不对你的工作永不对你的工作能力能力说谎。说谎。Confidentiality 坚持为你的客户及合作者坚持为你的客户及合作者保保密密。Intellectual property rights 保护他人的新保护他人的新观点及设计，即观点及设计，即知识产权知识产权。Data Protection 在处理个人信息时注意遵在处理个人信息时注意遵守相关法令守相关法令保护数据保护数据。第37页，共71页，编辑于2022年，星期三38需求工程过程、方法、技术需求工程过程、方法、技术符号表示符号表示(notation)是一种表示策略、框架或语言。是一种表示策
28、略、框架或语言。一阶逻辑一阶逻辑,数据流图数据流图,UML技术技术(technique)指出如何完成某项活动，以及如何用符号描述该项活动的产品。指出如何完成某项活动，以及如何用符号描述该项活动的产品。画用例图的技术画用例图的技术方法方法(method)给出关于如何完成系列活动的描述，重点是技术的集成和使用。给出关于如何完成系列活动的描述，重点是技术的集成和使用。CORE,SADT,SREM,JAD过程模型过程模型(Process model)给出关于如何完成系列活动的抽象描述，重点是活动间的依赖关系和给出关于如何完成系列活动的抽象描述，重点是活动间的依赖关系和资源的使用情况。资源的使用情况。过
29、程过程(Process)是对过程模型的实际运行，描述一两个代理的行为及其对资源的管理。是对过程模型的实际运行，描述一两个代理的行为及其对资源的管理。第38页，共71页，编辑于2022年，星期三39需求工程过程、方法、技术需求工程过程、方法、技术需求工程方法是如何嵌入需求工程过程的？需求工程方法是如何嵌入需求工程过程的？每种方法均适用于某一类问题领域每种方法均适用于某一类问题领域通常对他们的适用性的定义不够明确通常对他们的适用性的定义不够明确各种方法对需求工程活动的覆盖程度和侧重点各种方法对需求工程活动的覆盖程度和侧重点有所不同有所不同例如：例如：覆盖的活动包括：需求获取，建模，分析等覆盖的活动
30、包括：需求获取，建模，分析等侧重点包括：目标，行为，视角等。侧重点包括：目标，行为，视角等。第39页，共71页，编辑于2022年，星期三40需求工程师的素质要求需求工程师的素质要求 1.倾听的能力倾听的能力2.访问能力访问能力3.分析能力分析能力4.协调能力协调能力5.观察能力观察能力6.书写能力书写能力7.组织能力组织能力8.建模能力建模能力9.交际能力交际能力10.创新能力创新能力11.领域知识领域知识第40页，共71页，编辑于2022年，星期三41本章内容本章内容工程与软件工程工程与软件工程软件需求工程软件需求工程需求工程师需求工程师需求工程需求工程vs.系统分析系统分析软件生命周期中的
31、需求活动软件生命周期中的需求活动关于需求的基本观点关于需求的基本观点第41页，共71页，编辑于2022年，星期三42RE vs.Systems Analysis 需求工程需求工程vs.系统分析系统分析第42页，共71页，编辑于2022年，星期三43需求工程需求工程vs.系统分析系统分析RE vs.Systems Analysis需求工程由需求工程由系统分析系统分析发展而来发展而来系统分析关注企业内部的信息系统系统分析关注企业内部的信息系统主要采用非形式化的需求描述，工具和方法主要采用非形式化的需求描述，工具和方法,例如：例如：DFD,E-R,OO,80年代中期形成，年代中期形成，90年代以来成
32、为研究热点。年代以来成为研究热点。多见于管理学院，工程学科，和计算机科学的多见于管理学院，工程学科，和计算机科学的本科生和研究生教学本科生和研究生教学第43页，共71页，编辑于2022年，星期三44需求工程需求工程vs.系统分析系统分析RE vs.Systems Analysis需求工程需求工程超出超出系统分析的范围系统分析的范围涵盖整个形式化问题涵盖整个形式化问题从从“企业需求企业需求”到到“精确描述精确描述”不仅限于信息系统不仅限于信息系统实时系统实时系统嵌入系统嵌入系统交互系统交互系统基于组件的系统基于组件的系统web services相对较少关注企业管理问题和企业业务流程相对较少关注企
33、业管理问题和企业业务流程第44页，共71页，编辑于2022年，星期三45But,what is a requirement?每一个每一个“人造物人造物”都是一个都是一个内部环境内部环境与与外部环境外部环境的的“接接口口”。这里内部环境指人造物本身的设计组成。外部。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。环境指人造物的周遭及其作用环境。对这个接口的描对这个接口的描述述即是即是需求需求。Herbert Simon,1969需求需求,即是人们要解决的某个即是人们要解决的某个问题问题或达到某种或达到某种目的目的的需的需要。是系统或其组成部分为满足某种要。是系统或其组成部
34、分为满足某种书面规定书面规定（合同，标（合同，标准，规范等）所要具备的能力。需求将作为准，规范等）所要具备的能力。需求将作为系统开发，系统开发，测试，验收，提交的依据测试，验收，提交的依据。IEEE 610.12,1990第45页，共71页，编辑于2022年，星期三46将问题与解决方案分开将问题与解决方案分开理解问题理解问题需求获取需求获取问题的形式化表示问题的形式化表示形式规约，形式建模形式规约，形式建模就问题性质达成共识就问题性质达成共识验证验证,冲突及矛盾消解冲突及矛盾消解,磋商磋商需求管理需求管理 维护双方的共识维护双方的共识第46页，共71页，编辑于2022年，星期三47设计活动改变
35、客观世界状态设计活动改变客观世界状态第47页，共71页，编辑于2022年，星期三48什么是需求？什么是需求？（Jackson,1995Jackson,1995）领域性质领域性质(Domain Property)：无论系统存在与否均存在的应用领域的性质。：无论系统存在与否均存在的应用领域的性质。需求需求(Requirements)：由系统的存在而产生的应用领域性质。：由系统的存在而产生的应用领域性质。规约描述规约描述(Specification)：描述系统为满足需求而应具有的行为。：描述系统为满足需求而应具有的行为。需求证明的标准需求证明的标准(Verification Criteria)：1、
36、运行在某台机器上的程序满足规约描、运行在某台机器上的程序满足规约描述；述；2、针对给定的领域性质，规约描述满足需求。、针对给定的领域性质，规约描述满足需求。需求验证的标准（需求验证的标准（Validation Criteria）：）：1、是否已发现所有重要需求？、是否已发现所有重要需求？2、是否已发现所有有关的领域性质？、是否已发现所有有关的领域性质？第48页，共71页，编辑于2022年，星期三49实例实例Requirement R需求:只有被授权者能够访问数据库。Domain Properties D领域性质:授权者持有密码。密码不会分享给未授权者。Specification S 规约描述:
37、用户输入密码后，将被准许访问数据库。S+D imply R当领域模型出错时，会有什么后果第49页，共71页，编辑于2022年，星期三50需求：关于为什么？做什么？需求：关于为什么？做什么？不包括怎么做？不包括怎么做？（why,what,how）需求描述必须给出需求描述必须给出为什么为什么需要这样一个系统。需要这样一个系统。Ross,1977通常，需求描述系统要通常，需求描述系统要做什么做什么，而不是，而不是怎么做怎么做。但是，二。但是，二者不太容易区分，上一个抽象层次的者不太容易区分，上一个抽象层次的“怎么做怎么做”经常在经常在下一个抽象层次上转化为下一个抽象层次上转化为“做什么做什么”。Ja
38、ckson给出的稍为清楚的解释：给出的稍为清楚的解释：“为什么为什么”和和“做什么做什么”是指系统的设计目的，是置身系统外部，对是指系统的设计目的，是置身系统外部，对应用领域性质的描述。应用领域性质的描述。“怎么做怎么做”是指系统的内部结构和行为。是指系统的内部结构和行为。Jackson,1995第50页，共71页，编辑于2022年，星期三51“描述描述”是需求工程的核心是需求工程的核心（Jackson,1995）用非形式化的语言指出感兴趣的主题现象，并命名(designation)。例如：Parent(x,p)：p是x的父母。Female(x):x是女性。术语的形式化定义(definitio
39、n)和使用。例如：Mother(x,m)Parent(x,m)and Female(m)Sister(x,y)Female(y)and mother(x,m)and mother(y,m)and father(x,f)and father(y,f)第51页，共71页，编辑于2022年，星期三52“描述描述”是需求工程的核心是需求工程的核心（Jackson,1995,p58-59）关于领域性质的无可驳的描述(refutable description)。无可驳性依赖于与主题现象的一致性。例如：对所有的m和x，Parent(x，m)蕴含not(parent(m,x)开发过程中的带有假设性质的概略描
40、述(rough sketch)。例如：“人与人之间总是通过某种方式相互联系”“每个人实际上只能有一个家”第52页，共71页，编辑于2022年，星期三53存在问题的需求描述实例存在问题的需求描述实例含糊的需求描述：含糊的需求描述：“工资总额由上一条记录获得工资总额由上一条记录获得”“所有客户都具有同一控制域所有客户都具有同一控制域“错误的需求描述：错误的需求描述：“所有系统将九月作为财政年度的起始时间所有系统将九月作为财政年度的起始时间”不完整的需求描述：不完整的需求描述：“出错信息显示在屏幕的第出错信息显示在屏幕的第24行行“矛盾或不一致的需求描述：矛盾或不一致的需求描述：“C=A+B”；“C
41、=A-B”无法测试的需求：无法测试的需求：“系统应具有友好的界面系统应具有友好的界面“第53页，共71页，编辑于2022年，星期三54需求的层次需求的层次软件需求包括三个不同的层次软件需求包括三个不同的层次业务需求（业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。们在项目视图与范围文档中予以说明。用户需求用户需求(user requirement)描述了用户使用产品必须要完成的任务，这在使用实例（描述了用户使用产品必须要完成的任务，这在使用实例（use
42、case）文档或方案脚本（）文档或方案脚本（scenario）说明中予以说明。）说明中予以说明。功能需求功能需求(functional requirement)（包括非功能需求）（包括非功能需求）定义了开发人员必须实现的软件功能，使得用户能完成他们定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。的任务，从而满足了业务需求。第54页，共71页，编辑于2022年，星期三55软件需求各组成部分之间的关系软件需求各组成部分之间的关系 对一个复杂产品来说，软件功能对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，需求也许只是系统需求的一个子集，另外一些可能属于软
43、件部件。另外一些可能属于软件部件。管理人员或市场分析人员确定管理人员或市场分析人员确定软件的软件的业务需求业务需求，使公司运作更，使公司运作更加高效（对信息系统而言）或具加高效（对信息系统而言）或具有很强的市场竞争力（对商业软有很强的市场竞争力（对商业软件产品而言）。件产品而言）。所有的所有的用户需求用户需求必须与必须与业业务需求务需求一致。用户需求使需求一致。用户需求使需求分析者能从中总结出分析者能从中总结出功能需求功能需求以以满足用户对产品的要求从而完成满足用户对产品的要求从而完成其任务，而开发人员则根据其任务，而开发人员则根据功能功能需求需求来设计软件以实现必须的功来设计软件以实现必须的
44、功能。能。第55页，共71页，编辑于2022年，星期三56非功能性需求：非功能性需求：作为功能需求的补充，软件需求规格说明还应包作为功能需求的补充，软件需求规格说明还应包括括非功能需求非功能需求，它描述了系统展现给用户的行为，它描述了系统展现给用户的行为和执行的操作等。和执行的操作等。它包括产品必须遵从的标准、它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性设计或实现的约束条件及质量属性。所谓约束是。所谓约束是指对开发人员在软件产品设计和构造上的限制。指对开发人员在软件产品设计和构造上的限制。质量属性是
45、通过多种角度对产品的特点进行描述，质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。发人员都极为重要。第56页，共71页，编辑于2022年，星期三57需求工程需求工程第57页，共71页，编辑于2022年，星期三58本章内容本章内容工程与软件工程工程与软件工程软件需求工程软件需求工程需求工程师需求工程师需求工程需求工程vs.系统分析系统分析软件生命周期中的需求活动软件生命周期中的需求活动关于需求的基本观点关于需求的基本观点第58页，共71页，编辑于2022年，星期三59Requirement acti
46、vities in the SE lifecycle 软件生命周期中的需求活动软件生命周期中的需求活动第59页，共71页，编辑于2022年，星期三60瀑布模型（Waterfall/Baseline）核心思想：核心思想：系统开发是逐步求精的过程系统开发是逐步求精的过程各步骤相对独立，便于管理各步骤相对独立，便于管理存在的问题：存在的问题：忽略了需求的动态性忽略了需求的动态性需求完成后，用户对项目的参与需求完成后，用户对项目的参与即停止即停止需求描述与设计分开需求描述与设计分开不支持原型的使用和软件重用不支持原型的使用和软件重用（Loucopoulos&Karakostas,1995）第60页，共
47、71页，编辑于2022年，星期三61原型法原型法（Prototype）适用范围：适用范围：用于获取关于系统用户界面的需求用于获取关于系统用户界面的需求用于检验设计方案的可行性，或探讨系统性能问题用于检验设计方案的可行性，或探讨系统性能问题存在的问题：存在的问题：用户将原型误认为最终系统用户将原型误认为最终系统原型所反映的系统是不全面的原型所反映的系统是不全面的（Loucopoulos&Karakostas,1995,p30）第61页，共71页，编辑于2022年，星期三62增量式开发与演化式开发增量式开发与演化式开发Incremental vs.Evolutionary(Thayer&Dorfm
48、an,1997,p10)Incremental vs.Evolutionary(Thayer&Dorfman,1997,p10)第62页，共71页，编辑于2022年，星期三63螺旋模型螺旋模型(Spiral Model)螺旋模型主要用于风险分析螺旋模型主要用于风险分析每一轮开发活动具体包括每一轮开发活动具体包括:制定下一轮计划制定下一轮计划决定设计目标和限制条件决定设计目标和限制条件评估候选方案评估候选方案,风险降解风险降解产品开发产品开发需求工程有关步骤为：需求工程有关步骤为：需求风险分析需求风险分析规划设计规划设计可以减少可以减少需求变更需求变更所带来的风险所带来的风险存在的问题：存在的问
49、题：无法应付无法应付不可预见的需求变化不可预见的需求变化第63页，共71页，编辑于2022年，星期三64V型模型型模型（V-Model）(Macaulay,1996(Macaulay,1996）第64页，共71页，编辑于2022年，星期三65关于敏捷模型关于敏捷模型（Agile Models）基本原则：基本原则：减少沟通障碍减少沟通障碍程序员与客户直接交流程序员与客户直接交流减低繁重的文档负担减低繁重的文档负担文档代价昂贵但用途有限文档代价昂贵但用途有限对开发人员给予充分信任对开发人员给予充分信任无需运用花样翻新的过程模无需运用花样翻新的过程模型给与提示型给与提示响应客户要求响应客户要求而非严
50、格遵循合同条文而非严格遵循合同条文缺点：依赖程序员的记忆力源代码是难于维护的依赖口头交流易发生误解假定只有唯一的客户代表不可能反映多视角制作短期计划无长期及前瞻性规划第65页，共71页，编辑于2022年，星期三66本章内容本章内容工程与软件工程工程与软件工程软件需求工程软件需求工程需求工程师需求工程师需求工程需求工程vs.系统分析系统分析软件生命周期中的需求活动软件生命周期中的需求活动关于需求的基本观点关于需求的基本观点第66页，共71页，编辑于2022年，星期三67Viewpoints 关于需求的基本观点关于需求的基本观点第67页，共71页，编辑于2022年，星期三68关于需求的基本观点关于