《第三讲 嵌入式系统需求定义嵌入式软件设计开发.ppt》由会员分享，可在线阅读，更多相关《第三讲 嵌入式系统需求定义嵌入式软件设计开发.ppt（68页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、嵌入式软件设计开发嵌入式软件设计开发BeiHangBeiHang College of Software College of Software康一梅康一梅 关于需求 需求就是关于系统应该“做什么”而不是“怎么做”的问题描述。需求通常分为需求定义和需求分析两个阶段。需求定义产生客户理解的系统规格说明书，需求分析产生开发人员可以清楚解释的分析模型。系统分析员素质 虽然许多传统的需求问题仍未解决，但是客户对系统的要求却在不断提高。这是因为客户本身面临着更激烈的竞争，他们需要以最快的速度调整业务以满足市场的需要。相应地，软件开发者对需求的定义与分析不仅要考虑当前的需求，还要考虑可能面临的需求变化。对
2、于软件开发者而言，现在已经进入随需应变的时代，这对系统分析员的要求也越来越高。一个合格的系统分析员应该具备以下素质：业务知识技术背景分析能力沟通技巧 基本原理是决策的依据。给定一个决基本原理是决策的依据。给定一个决策，它的基本原理包括它针对的问题、备策，它的基本原理包括它针对的问题、备选方案、评价备选方案的标准、开发人员选方案、评价备选方案的标准、开发人员的争论以及决策本身。的争论以及决策本身。基本原理基本原理需求分析系统规格说明：模型系统分析模型：模型 需求提出和分析仅仅集中在使用者对需求提出和分析仅仅集中在使用者对系统的观点上。系统的观点上。问题定义需求提出基本原理模型：模型需求模型的建模
3、步骤需求模型的建模步骤问题定义问题定义在正式的需求工程之前。在正式的需求工程之前。其目标是让项目经理和客户就所构建系统的其目标是让项目经理和客户就所构建系统的范围达成意见一致，产生一个问题定义文档，概范围达成意见一致，产生一个问题定义文档，概括系统的功能和领域，也包括非功能性需求。括系统的功能和领域，也包括非功能性需求。问题定义并不产生问题的完整描述，它只是问题定义并不产生问题的完整描述，它只是一个初步的需求活动。一个初步的需求活动。第三讲 嵌入式系统需求定义3.1 问题定义确定系统目标确定系统目标确定系统约束确定系统约束确定系统范围确定系统范围问题定义的活动问题定义的活动确定系统目标确定系统
4、目标 目标是用来指导项目的高层准则。目标常是相互冲突的。目标是用来指导项目的高层准则。目标常是相互冲突的。性能最好性能最好功能最多最强功能最多最强价格最便宜价格最便宜界面最美观界面最美观性价比最好性价比最好最快完成最快完成比竞争对手的要好比竞争对手的要好可复用可复用/一次性一次性可靠性可靠性。正确正确完整完整一致一致清晰清晰现实现实可验证可验证可追溯可追溯明确、量化明确、量化问题定义的活动问题定义的活动确定系统约束确定系统约束网络带宽、系统平台、接口、兼容旧系统等网络带宽、系统平台、接口、兼容旧系统等用户使用软件的能力与习惯用户使用软件的能力与习惯价格价格时间时间质量质量用户的配合度用户的配合
5、度公司现有状况公司现有状况(人力人力 资金资金 销售销售 开发平台开发平台 业务领域业务领域等等等等)非功能性需求非功能性需求问题定义的活动问题定义的活动确定系统范围确定系统范围确定应用域确定应用域-环境与系统的边界环境与系统的边界确定应用域的边界确定应用域的边界确定系统的边界确定系统的边界问题定义的活动问题定义的活动问题定义问题定义案例案例FRIEND,1994FRIEND,19941.1.当前紧急情况处理的缺陷当前紧急情况处理的缺陷基于电话线路，处理能力？基于电话线路，处理能力？一般不一般不用无线电传送。用无线电传送。防火、警察、紧急医疗服务、重大工防火、警察、紧急医疗服务、重大工程事故等
6、，纸制资料在紧急情况发生程事故等，纸制资料在紧急情况发生时用不上或不好用。时用不上或不好用。紧急情况发生时，关键信息不能快速紧急情况发生时，关键信息不能快速获得。如事件位置信息（危险品、煤获得。如事件位置信息（危险品、煤气管道等地点）不能得到或根本不存气管道等地点）不能得到或根本不存在。在。传送信息的方式传送信息的方式使用已有信息使用已有信息获取有用信息获取有用信息应急联动系统应急联动系统案例案例FRIEND,1994FRIEND,19942.2.功能性需求功能性需求在异常呼叫负载情况下能同时处理多个紧急事件。在异常呼叫负载情况下能同时处理多个紧急事件。对紧急情况的更坏状况有所准备对紧急情况的
7、更坏状况有所准备使用宽带，传输不能成为限制。使用宽带，传输不能成为限制。提供实时信息，如：提供实时信息，如：地理信息地理信息如城市地图，包括地上和地下公共设施如城市地图，包括地上和地下公共设施 危险品信息危险品信息 建筑物位置信息建筑物位置信息如煤气或供水管道、消防栓位置、楼层如煤气或供水管道、消防栓位置、楼层地图地图 可用的政府资源可用的政府资源如紧急情况操作方案（如紧急情况操作方案（Emergency Emergency Operation Plan,EOP)Operation Plan,EOP)问题定义问题定义应急联动系统应急联动系统案例案例FRIEND,1994FRIEND,19942
8、.2.功能性需求功能性需求遵照指导方针和遵照指导方针和EOPEOP，系统将自动通知适当部门的工作系统将自动通知适当部门的工作人员，创建任务列表、配置资源及其他一些在紧急情况人员，创建任务列表、配置资源及其他一些在紧急情况中节省时间的工作。中节省时间的工作。每一个与系统交互的现场指挥工具上都有一台移动电脑每一个与系统交互的现场指挥工具上都有一台移动电脑使用无线通信向总部调度员报告。目标是试图用一种更使用无线通信向总部调度员报告。目标是试图用一种更简单的输入手段、响应式的用户界面、语音识别、触摸简单的输入手段、响应式的用户界面、语音识别、触摸屏或手写笔式的系统，来替换第一响应者报告输入机制。屏或手
9、写笔式的系统，来替换第一响应者报告输入机制。系统事务都须归档，以便将来分析所需。系统事务都须归档，以便将来分析所需。问题定义问题定义应急联动系统应急联动系统案例案例FRIEND,1994FRIEND,19943.非功能性需求非功能性需求首先在公安警务部门使用。首先在公安警务部门使用。之后在医疗、消防、市政管理部门等使用，对本地信息之后在医疗、消防、市政管理部门等使用，对本地信息提供更高级的管理功能。提供更高级的管理功能。现场人员使用的设备应适合恶劣天气和艰苦工作。现场人员使用的设备应适合恶劣天气和艰苦工作。可移植到当地政府可用的现有硬件上。可移植到当地政府可用的现有硬件上。原型希望是可扩展的，
10、以便处理省级、国家级事件。原型希望是可扩展的，以便处理省级、国家级事件。问题定义问题定义医疗卫生部门使用医疗卫生部门使用警务警务应急联动系统应急联动系统案例案例FRIEND,1994FRIEND,19944.4.接受标准接受标准第一版不要求实现所有功能。第一版不要求实现所有功能。在需求工程阶段，客户与软件工程师协商一个可交付的在需求工程阶段，客户与软件工程师协商一个可交付的原型。原型。在协商阶段之后，用户验收测试的具体需求将被冻结。在协商阶段之后，用户验收测试的具体需求将被冻结。客户需求在客户需求在4-64-6周内开始正式交付。周内开始正式交付。最低限度，原型可扩展。最低限度，原型可扩展。最低
11、限度的验收测试，希望协商的原型能在有一个无线最低限度的验收测试，希望协商的原型能在有一个无线组件的系统上演示。组件的系统上演示。理想的演示，希望在警察的现场系统上演示。理想的演示，希望在警察的现场系统上演示。问题定义问题定义应急联动系统应急联动系统第三讲 嵌入式系统需求定义3.2 需求定义基本概念基本概念功能性需求功能性需求非功能性需求非功能性需求伪需求伪需求需求描述的要求需求描述的要求确定一致的术语确定一致的术语描述的层次描述的层次需求定义需求定义基本概念基本概念功能性需求功能性需求 功能性需求是系统功能的陈述，明确系功能性需求是系统功能的陈述，明确系统应该提供什么功能。如电梯控制系统统应该
12、提供什么功能。如电梯控制系统中的一个功能需求就是：当电梯求生系中的一个功能需求就是：当电梯求生系统开启时，电梯自动控制系统开启应急统开启时，电梯自动控制系统开启应急电灯。电灯。需求定义需求定义基本概念基本概念 非功能性需求非功能性需求:指与系统功能行为没有直接关系但用户可指与系统功能行为没有直接关系但用户可见的系统部分，是系统的特定特性，以保证功能的正常实现、优见的系统部分，是系统的特定特性，以保证功能的正常实现、优化产品的功能或者是限定产品应达到的目标值。非功能性需求为化产品的功能或者是限定产品应达到的目标值。非功能性需求为确定系统的结构和系统选用的技术等进行了约束，包括定量约束，确定系统的
13、结构和系统选用的技术等进行了约束，包括定量约束，如响应时间或精度等。如响应时间或精度等。最常见的非功能性需求有：最常见的非功能性需求有：系统处理速度；系统处理速度；可靠性；可靠性；可用性；可用性；安全性；安全性；耐用性；耐用性；产品的最终价格；产品的最终价格；系统的尺寸和质量；系统的尺寸和质量；系统的功耗。系统的功耗。需求定义需求定义基本概念基本概念伪需求伪需求 伪需求是客户强加的需求，它约束系统伪需求是客户强加的需求，它约束系统的实现。典型的伪需求是实现系统的编的实现。典型的伪需求是实现系统的编程语言和运行平台。程语言和运行平台。需求定义需求定义基本概念基本概念需求描述的要求需求描述的要求
14、需求定义的最终目的是要获得没有二需求定义的最终目的是要获得没有二义性的、全面的、详尽的目标需求。因义性的、全面的、详尽的目标需求。因此，需求规格说明要满足此，需求规格说明要满足正确性、完整正确性、完整性、一致性、清晰性、现实性、可修改性、一致性、清晰性、现实性、可修改性、可追踪性性、可追踪性等要求。等要求。需求定义需求定义m:模型r:现实r2:现实m:模型r:现实c1:概念p1:现象c2:概念p2:现象正确性：模型描述客户感兴趣的事实，而不是其他事实。完整性：模型中用概念描述了感兴趣的每个现象。需求描述的要求需求描述的要求:正确性、完整性、一致性、清晰性和现实性正确性、完整性、一致性、清晰性和
15、现实性需求定义需求定义m:模型r1:现实r2:现实一致性：模型中的所有概念都与同一现实的现象对应。清晰性：模型中的所有概念都只与一个现象对应。c1:概念p1:现象c2:概念p2:现象m:模型r1:现实r2:现实c1:概念p1:现象p2:现象需求描述的要求需求描述的要求:正确性、完整性、一致性、清晰性和现实性正确性、完整性、一致性、清晰性和现实性需求定义需求定义现实系统领域虚拟件领域m:模型r1:现实r2:现实现实性：模型描述了可以存在的事实。需求描述的要求需求描述的要求:正确性、完整性、一致性、清晰性和现实性正确性、完整性、一致性、清晰性和现实性需求定义需求定义可验证性可验证性：一旦系统建立，
16、如果可以设计一个可重复的：一旦系统建立，如果可以设计一个可重复的实验来演示系统满足了需求，那么说明是可验证的。实验来演示系统满足了需求，那么说明是可验证的。-产品应有一个好的用户界面。产品应有一个好的用户界面。-产品应是没有错误的（需要建立大量资源）产品应是没有错误的（需要建立大量资源）-对大多数情况，产品应在对大多数情况，产品应在1S1S内对用户给予响应。内对用户给予响应。可追溯性可追溯性：如果每个系统功能可以被追溯到相应的需求，：如果每个系统功能可以被追溯到相应的需求，那么系统规格说明是可追溯的。可追溯性不是对系统规那么系统规格说明是可追溯的。可追溯性不是对系统规格说明内容的约束，而是对它
17、的组织的约束。可追溯性格说明内容的约束，而是对它的组织的约束。可追溯性有助于开展系统测试和需求设计的系统验证。有助于开展系统测试和需求设计的系统验证。需求描述的要求需求描述的要求:可验证性和可追溯性可验证性和可追溯性需求定义需求定义基本概念基本概念确定一致的术语确定一致的术语 开发人员和用户合作时遇到的第一个障碍就是术语不通。开发人员和用户合作时遇到的第一个障碍就是术语不通。为了与客户沟通，需要与客户确认一些不确定的词语，以及应用为了与客户沟通，需要与客户确认一些不确定的词语，以及应用域的专业术语。同一个术语在不同的上下文中的意思不一样，这域的专业术语。同一个术语在不同的上下文中的意思不一样，
18、这就导致了误解的产生。虽然最后开发人员学会了用户的术语，但就导致了误解的产生。虽然最后开发人员学会了用户的术语，但是当新的开发人员加入这个项目后，这个问题就会出现。因此，是当新的开发人员加入这个项目后，这个问题就会出现。因此，开发人员应确定、命名、并且明确的描述这些用词与术语，最后开发人员应确定、命名、并且明确的描述这些用词与术语，最后将它们编入一个术语表。将它们编入一个术语表。术语表包含在系统需求规格说明中，并且在最后放入用户术语表包含在系统需求规格说明中，并且在最后放入用户手册。开发人员使术语表与系统规格说明同步升级。术语表有很手册。开发人员使术语表与系统规格说明同步升级。术语表有很多好处
19、：新来的开发人员面对一系列一致的定义，每个术语用来多好处：新来的开发人员面对一系列一致的定义，每个术语用来表达一个概念（取代开发人员术语和用户术语），并且每个术语表达一个概念（取代开发人员术语和用户术语），并且每个术语有一个精确的、清楚的正式含义。有一个精确的、清楚的正式含义。需求定义需求定义描述的层次描述的层次可以用用例描述这一系列用例描述与系统相关的用户的工作过程。系统支持的那部分过程也被描述，但重点是定义用户与系统的边界。这一系列用例描述不直接与应用域相关的系统支持的功能，包括文件管理功能、分组功能、撤消功能等。当我们讨论已知的边界条件，如系统初始化、关闭和例外处理机制时，会在系统设计时
20、扩展这些用例。这一系列用例描述用户和系统用户界面之间的交互作用，重点是解决控制流程和规划。这一系列用例描述系统提供的与应用域有关的功能。基本概念基本概念需求定义需求定义系统边界系统边界系统的应用功能系统的应用功能系统的支持功能系统的支持功能人机交互界面人机交互界面Greenfield Greenfield 工程工程：开发从零开始，不是从已有的系统：开发从零开始，不是从已有的系统开始，需求来自用户和客户。开始，需求来自用户和客户。Greenfield Greenfield 工程的项目工程的项目是由用户需要或新市场产生引发的。是由用户需要或新市场产生引发的。再工程再工程：由新技术或新信息流引发的对
21、已有系统的重新：由新技术或新信息流引发的对已有系统的重新设计和重新实现。有时扩展系统的功能，但系统的基本设计和重新实现。有时扩展系统的功能，但系统的基本目的没有变。新系统的需求直接从已有的系统上获取。目的没有变。新系统的需求直接从已有的系统上获取。界面工程界面工程：对已有系统用户界面的重新设计。除了界面：对已有系统用户界面的重新设计。除了界面被重新设计和实现之外，原有系统不做其他改动。这种被重新设计和实现之外，原有系统不做其他改动。这种项目是低费用的、不放弃原有系统的再工程项目。项目是低费用的、不放弃原有系统的再工程项目。基本概念基本概念:GreenfieldGreenfield工程、再工程、
22、界面工程工程、再工程、界面工程需求定义需求定义与客户协商系统规格说明书：联合应用设计（与客户协商系统规格说明书：联合应用设计（JADJAD）联合应用程序设计是一套面向结果的,大脑风暴式的,有一个共同的商业目的信息集合/分享会议。该方法是IBM公司在1970年开发的，由固定的，结构化的过程组成，并在一个有经验的实施者的领导下进行。简化方法是90年代的术语,简化方法去掉了一些结构,然而,仍要求所有各方都必须参加所有的会议和一个有建模技术的记录员作记录。参加者们包括项目团队,管理(与用户)和行政官员。为会议的成功，每个人必须理解和同意目的并且尽快解决他们的任务。需求定义需求定义与客户协商系统规格说明
23、书：联合应用设计（与客户协商系统规格说明书：联合应用设计（JADJAD）JDA主要有五个活动：-项目定义-调查-预备-会议-最终文件需求定义需求定义与客户协商系统规格说明书：联合应用设计（与客户协商系统规格说明书：联合应用设计（JADJAD）Figure 4-12.Activities of JAD(UML activity diagram).The heart of JAD is the Session activity during which all stakeholders design and agree to a system specification.The activitie
24、s prior to the Session maximizes its efficiency.The production of the Final document ensures that the decisions made during the Session are captured.Managementdefinition guideProjectdefinitionResearchPreparationSessionSession agendaPreliminary specificationWorking documentSession scriptScribe formsF
25、inal documentpreparationFinal document常见的问题常见的问题-系统用于什么任务？-什么时间交付？-希望系统具有哪些功能，它能完成哪些任务？-系统从用户或其它源接收什么输入？-系统向用户或其它源输出什么？-用户想要如何同系统打交道？即进行什么样的人机交互，如在小键盘输入和显示屏输出？显示屏显示什么内容有及如何规定显示方法？-系统的质量和体积如何？-系统连接何种外部设备？-系统是否需要运行某些现存组件？-系统处理哪种类型的数据？-系统是否要与别的系统通讯？-系统是单机还是网络系统？-系统的响应时间是多少？-需要什么样的安全措施？需求定义需求定义常见的问题常见的问
26、题-系统在什么样的环境下运行？如操作温湿度和环境参数说明。-外部存储媒介和内存需要多大？-系统的可折装性、可靠性和牢固性的期望值是什么？-如何给系统供电？-如何给系统供电？-系统负载如何？系统负载是一项重要内容。系统在过载的情况下可能导致失效。系统负载越大，需要的功耗就越大。-是否使用传感器？传感器的灵敏度、精度、分辩率和精确度的要求？-系统如何向用户通报故障？-是否需要任何手动或机械代用装置？-系统是否将具有远程诊断或更正问题的功能？-系统的最大可承受成本？-其它问题。需求定义需求定义面向对象的概念面向对象的概念:模块化的程序要优于庞大的、整模块化的程序要优于庞大的、整体式的计算机程序。体式
27、的计算机程序。易于理解易于理解扩展性强扩展性强利于维护利于维护运行效率？运行效率？面向对象需求定义面向对象需求定义功能分解家功能分解家：用函数实现模块：用函数实现模块每个每个模块做且仅做一件事。模块做且仅做一件事。数据公爵数据公爵：每个模块都应容纳一个数据：每个模块都应容纳一个数据结构。结构。实时系统开发者实时系统开发者：每个模块都应该能识：每个模块都应该能识别并对一个事件作出反应，且这个事件别并对一个事件作出反应，且这个事件是唯一的。是唯一的。每个模块都对应着且唯一对应着现每个模块都对应着且唯一对应着现实世界中的某一件事。实世界中的某一件事。面向对象需求定义面向对象需求定义面向对象的概念面向
28、对象的概念 对象对象是指一个是指一个独立的独立的、异步的异步的、并并发的实体发的实体。它能。它能知道一些事情知道一些事情（即存储即存储数据数据），），做一些工作做一些工作（即封装服务），（即封装服务），并并与其他对象协同与其他对象协同（通过交换消息），（通过交换消息），从而完成（模块化）系统的所有功能。从而完成（模块化）系统的所有功能。面向对象需求定义面向对象需求定义面向对象的概念面向对象的概念 复用性复用性:通过面向对象技术，软件工程通过面向对象技术，软件工程生存期中的每个部分都可以封装成可复生存期中的每个部分都可以封装成可复用的对象。用的对象。需求需求分析分析设计设计测试计划测试计划用户界
29、面用户界面体系结构体系结构面向对象需求定义面向对象需求定义面向对象的概念面向对象的概念需求提出需求分析系统规格说明：模型系统分析模型：模型 需求提出和分析仅仅集中在使用者对需求提出和分析仅仅集中在使用者对系统的观点上。系统的观点上。面向对象需求定义面向对象需求定义OOAOOA模型的建模步骤模型的建模步骤（B.BrueggeB.Bruegge&A.H.DutoitA.H.Dutoit 2002)2002)面向对象需求定义包括以下活动面向对象需求定义包括以下活动确定执行者确定执行者确定场景确定场景确定用例确定用例改进用例改进用例确定用例之间的关系确定用例之间的关系确定非功能性需求确定非功能性需求问
30、题描述-系统规格说明书-模型 场景 用例用什么形式描述？面向对象需求定义面向对象需求定义确定执行者确定执行者执行者描述与系统交互的外部实体。执行者可以是人执行者描述与系统交互的外部实体。执行者可以是人员也可以是外部系统。执行者具有唯一的名字与描述。员也可以是外部系统。执行者具有唯一的名字与描述。执行者是角色抽象，不一定直接对应到人。执行者是角色抽象，不一定直接对应到人。当确定执行者时，分析人员可以提出以下问题：当确定执行者时，分析人员可以提出以下问题：系统支持哪个用户群完成他们的工作？系统支持哪个用户群完成他们的工作？哪个用户群执行系统的主要功能？哪个用户群执行系统的主要功能？哪个用户群执行辅
31、助功能，如维护和管理？哪个用户群执行辅助功能，如维护和管理？系统与外部硬件或软件交互吗？系统与外部硬件或软件交互吗？需求定义的活动需求定义的活动消防员消防员医生医生传染病控制中心工作人员传染病控制中心工作人员警察警察防汛指挥中心工作人员防汛指挥中心工作人员调度员调度员市长市长省长省长部长部长危险品数据库危险品数据库在逃刑事犯罪分子数据库在逃刑事犯罪分子数据库传染病数据库传染病数据库系统管理员系统管理员。案例案例FRIEND,1994FRIEND,1994应急联动系统应急联动系统涉及现场某一单独事件时，可以共享同样的系统接口管理多个并发事件并访问大量信息不可能直接与系统交互，但会利用操作员提供的
32、服务，操作员与调度员可用相同的系统接口。为系统提供数据系统维护、管理等。需求定义的活动需求定义的活动确定执行者确定执行者应急联动系统应急联动系统现场工作人员现场工作人员业务数据库系统业务数据库系统应急联应急联动系统动系统系统管理员系统管理员调度员调度员案例案例FRIEND,1994FRIEND,1994需求定义的活动需求定义的活动确定执行者确定执行者 一旦执行者被确定，就需要决定每个执行者可以一旦执行者被确定，就需要决定每个执行者可以访问的功能。使用场景可以获得这些信息，而用例则访问的功能。使用场景可以获得这些信息，而用例则可形式化这些信息。可形式化这些信息。场景是未来所用系统的具体示例，是解
33、释单个案场景是未来所用系统的具体示例，是解释单个案例的具体例子。例的具体例子。场景是没有限制和非正式的。场景是没有限制和非正式的。场景应该用应用域的术语编写。场景应该用应用域的术语编写。需求定义的活动需求定义的活动确定场景确定场景案例案例FRIEND,1994FRIEND,1994应急联动系统应急联动系统应急联动系统是一个事件响应信息系统。应急联动系统是一个事件响应信息系统。在下面的场景中，警察报告火灾，调度员启动事件响在下面的场景中，警察报告火灾，调度员启动事件响应。应。注意：这个场景描述的是个别情况，并非描述火灾事注意：这个场景描述的是个别情况，并非描述火灾事件的所有情况。件的所有情况。需
34、求定义的活动需求定义的活动确定场景确定场景案例案例FRIEND,1994FRIEND,1994应急联动系统应急联动系统报告紧急情况用例：仓库着火报告紧急情况用例：仓库着火场景名称仓库着火参与执行者实例Bob,Alice：现场工作人员John：调度员事件流程Bob驾驶着巡逻车在主要街道巡逻，发现一个仓库有烟冒出。他的搭档Alice从自己的FRIEND掌上电脑进入“紧急事件报告”功能。Alice输入事件地点及紧急程度。考虑到这个地区较热闹，除了消防队她还要求几个医务人员前来。她确定了输入，等候答复。John通过工作站发出的嘟嘟声察觉到了紧急事件。他查看了Alice发来信息并做了回复。他指派了一个消
35、防队和两个医疗队到达事故地点，同时将他们的预计到达时间（ETA）传给Alice。Alice收到回复和预计到达时间。需求定义的活动需求定义的活动确定场景确定场景 在需求提出和生命周期的其他活动中，场景还有在需求提出和生命周期的其他活动中，场景还有许多其他的用处。如：许多其他的用处。如：实际场景实际场景：描述当前的工作情况。：描述当前的工作情况。想象场景想象场景：描述从零设计的或重建的未来系统。想象：描述从零设计的或重建的未来系统。想象场景可看作一个造价不高的原型。场景可看作一个造价不高的原型。评价场景评价场景：描述用户任务，根据它评价系统。：描述用户任务，根据它评价系统。培训场景培训场景：向新用
36、户介绍系统的示例。帮助用户掌握：向新用户介绍系统的示例。帮助用户掌握系统的指导材料。系统的指导材料。需求定义的活动需求定义的活动确定场景确定场景确定场景的问题确定场景的问题执行者希望系统执行的任务是什么？执行者希望系统执行的任务是什么？执行者访问什么信息？谁生成数据？数据是可修改和执行者访问什么信息？谁生成数据？数据是可修改和可移动的吗？被谁修改移动？可移动的吗？被谁修改移动？执行者需要通知哪些外部变化？多长时间一次？什么执行者需要通知哪些外部变化？多长时间一次？什么时间通知？时间通知？系统需要通知执行者什么事件？延时是多少？系统需要通知执行者什么事件？延时是多少？需求定义的活动需求定义的活动
37、确定场景确定场景 用例是对所有可能案例的抽象。详细说明了给定用例是对所有可能案例的抽象。详细说明了给定功能的所有场景。功能的所有场景。需求定义的活动需求定义的活动确定用例确定用例案例案例FRIEND,1994FRIEND,1994应急联动系统应急联动系统报告紧急情况用例报告紧急情况用例用例名称报告紧急情况参与执行者由现场工作人员初始化，与调度员联络。入口条件事件流程现场工作人员进入其终端上的报告紧急情况功能。FRIEND做出响应：提交一份表格给工作人员。现场工作人员填好表格：选择紧急等级、类型、位置和简单情况描述。现场工作人员还需描述紧急事件的可能后果。现场工作人员一旦填完就提交表格，此时调度
38、员被通知。调度员查看提交的表格，通过调用打开事件用例在数据库产生一个事件。调度员选择响应并且确认收到紧急情况报告。退出条件现场工作人员收到答复并选择响应。特殊需求现场工作人员的报告要在30S内答复。选择的响应要在调度员发送后30S内到达。需求定义的活动需求定义的活动确定用例确定用例改进用例改进用例 场景与用例用于创建用户在早期确认的需求。为场景与用例用于创建用户在早期确认的需求。为了尽可能减少需求变更，在需求提出阶段需要做许多了尽可能减少需求变更，在需求提出阶段需要做许多变更与实验。许多用例被重写几次，另外一些得到充变更与实验。许多用例被重写几次，另外一些得到充分改进，还有一些被完全放弃。为了
39、节省时间，许多分改进，还有一些被完全放弃。为了节省时间，许多探索工作可利用场景和用户界面模型来完成。探索工作可利用场景和用户界面模型来完成。改进用例的活动的重点是完整性和正确性。改进用例的活动的重点是完整性和正确性。-增加遗漏的新的用例增加遗漏的新的用例 -增加执行者不常看到的情况和例外控制增加执行者不常看到的情况和例外控制 -增加系统支持用例增加系统支持用例需求定义的活动需求定义的活动确定用例确定用例改进用例改进用例编写场景与用例的试探法编写场景与用例的试探法利用场景与用户交流，确定功能。利用场景与用户交流，确定功能。首先，改进一个元素的所有属性（如一个场景）来理解用户喜爱首先，改进一个元素
40、的所有属性（如一个场景）来理解用户喜爱的交互模式。的交互模式。然后，利用所有元素的某一属性（如不够细致的场景）来定义系然后，利用所有元素的某一属性（如不够细致的场景）来定义系统范围，与用户共同确定。统范围，与用户共同确定。用户界面模型仅仅作为可视化支持，一旦功能足够稳定，则把用用户界面模型仅仅作为可视化支持，一旦功能足够稳定，则把用户界面设计作为一项独立任务来做。户界面设计作为一项独立任务来做。给用户多种可选择方案（反对从用户提取一个单独的方案）给用户多种可选择方案（反对从用户提取一个单独的方案）当理解了系统范围和用户爱好后，详述元素的所有属性，与用户当理解了系统范围和用户爱好后，详述元素的所
41、有属性，与用户共同确定。共同确定。需求定义的活动需求定义的活动确定用例确定用例案例案例FRIEND,1994FRIEND,1994应急联动系统应急联动系统报告紧急情况用例改进版本报告紧急情况用例改进版本位置用例描述现场工作站由现场工作人员初始化，与调度员联络。入口条件事件流程现场工作人员进入其终端上的报告紧急情况功能。FRIEND做出响应：提交一份表格给工作人员。表格包括一个紧急情况类型菜单（普通、火灾、交通）、紧急等级、事件发生位置、事件描述、资源要求、危险原料所处场所、紧急事件的可能后果。现场工作人员填好表格：选择类型、位置和简单情况描述。现场工作人员还需描述。至少要填紧急情况类型和描述，
42、也可以描述对紧急情况的可能响应和特殊救援要求。一旦填完表格，现场工作人员按下“发送报告”按钮提交表格，此时调度员被通知。调度站调度员通过弹出的对话框注意到新的事件报告。查看提交的信息，通过调用打开事件用例在数据库产生一个事件。事件里包含了表格里的所有信息。调度员选择响应，并且确认收到紧急情况报告。现场工作人员收到答复并选择响应。分配救援资源给事件（用分配资源用例），通过发送短信息给现场工作人员表明收到报告。现场工作站现场工作人员收到答复和已选择的响应。特殊需求现场工作人员的报告要在30S内答复。选择的响应要在调度员发送后30S内到达。需求定义的活动需求定义的活动确定用例确定用例执行者与用例之间
43、的交流关系执行者与用例之间的交流关系 描述用例过程中的信息流，在功能层次上描述系统。描述用例过程中的信息流，在功能层次上描述系统。用例之间的扩展关系用例之间的扩展关系 区分事件的例外和事件的共有流程。区分事件的例外和事件的共有流程。用例之间的包含关系用例之间的包含关系 减少用例之间的冗余。减少用例之间的冗余。需求定义的活动需求定义的活动确定执行者与用例之间关系确定执行者与用例之间关系用例之间的扩展关系用例之间的扩展关系把基本用例与异常和任选的事件流区分开来有两个好处：把基本用例与异常和任选的事件流区分开来有两个好处：基本用例变得更短并容易理解。基本用例变得更短并容易理解。把普通用例与异常用例分
44、开，可以使开发人员分别处把普通用例与异常用例分开，可以使开发人员分别处理每种功能。理每种功能。注：普通用例与异常用例都是完整的用例，它们必须有一注：普通用例与异常用例都是完整的用例，它们必须有一个个入口和结束条件入口和结束条件。需求定义的活动需求定义的活动确定执行者与用例之间关系确定执行者与用例之间关系建立用例之间的扩展关系建立用例之间的扩展关系如果用例包括几个行为段，这些段具有可选特性或者异常特性，并如果用例包括几个行为段，这些段具有可选特性或者异常特性，并且它们不会增加对用例主要目的理解程度，则可以将这些行为分离且它们不会增加对用例主要目的理解程度，则可以将这些行为分离出来作为新的扩展用例
45、。而原始的用例则成为基本用例，扩展用例出来作为新的扩展用例。而原始的用例则成为基本用例，扩展用例与之就形成了扩展关系。与之就形成了扩展关系。在基本用例中需要声明扩展点，这些扩展点定义在基本用例中可能在基本用例中需要声明扩展点，这些扩展点定义在基本用例中可能进行扩展的位置。进行扩展的位置。对于复杂分支流和可选行为，最好将它们划分出来，形成扩展用例。对于复杂分支流和可选行为，最好将它们划分出来，形成扩展用例。通常此行为相当复杂，并且难以描述：将其包含在事件流中将更加通常此行为相当复杂，并且难以描述：将其包含在事件流中将更加难以看到难以看到“正常正常”行为。提取该行为将有助于提高对用例模型的理行为。
46、提取该行为将有助于提高对用例模型的理解。解。确保在无须引用扩展用例时，基本用例的事件流仍然保持完整而且确保在无须引用扩展用例时，基本用例的事件流仍然保持完整而且可以让人理解。可以让人理解。只有扩展用例知道它和基本用例之间的关系。基本用例只知道它具只有扩展用例知道它和基本用例之间的关系。基本用例只知道它具有扩展点，而并不清楚什么样的扩展用例在使用这些扩展点。有扩展点，而并不清楚什么样的扩展用例在使用这些扩展点。需求定义的活动需求定义的活动确定执行者与用例之间关系确定执行者与用例之间关系建立用例之间的扩展关系建立用例之间的扩展关系(续续)简要描述所定义的每一个扩展关系。定义产生扩展必须简要描述所定
47、义的每一个扩展关系。定义产生扩展必须满足的条件。确保在基本用例中定义了应插入扩展的扩满足的条件。确保在基本用例中定义了应插入扩展的扩展点。展点。如果未定义任何条件，这意味着扩展始终在执行。如果未定义任何条件，这意味着扩展始终在执行。如果扩展用例包含几个行为段，这些段从不同的扩展点如果扩展用例包含几个行为段，这些段从不同的扩展点插入到基本用例中，则确保对这些行为段以及基本用例插入到基本用例中，则确保对这些行为段以及基本用例中每一个行为段的扩展点都作了定义。中每一个行为段的扩展点都作了定义。需求定义的活动需求定义的活动确定执行者与用例之间关系确定执行者与用例之间关系用例之间的扩展关系用例之间的扩展
48、关系Figure 4-9.Example of use of extend relationship(UML use case diagram).ConnectionDown extends the ReportEmergency use case.The ReportEmergency use case becomes shorter and solely focused on emergency reporting.报告紧急情况用例简化并且只集中在紧急情况报告上。ReportEmergencyFieldOfficerConnectionDown案例案例FRIEND,1994FRIEND,1
49、994应急联动系统应急联动系统需求定义的活动需求定义的活动确定执行者与用例之间关系确定执行者与用例之间关系建立用例之间的包含交流关系建立用例之间的包含交流关系 如果用例包括一个行为段，该段对于此用例其他部分的重要性完全在于它产生的结果，而不在于得到结果的方法，则可以将此行为分离出来作为新的包含用例包含用例。而初始的用例则成为与此包含用例有包含关系的基本用基本用例例。两个用例间的包含关系是指用例实例为保持其完整性，不仅要符合基本用例的说明，同时还应当遵循包含用例的说明。包含关系可以通过以下方式帮助阐明用例：-隔离和封装复杂的细节，使之不会模糊用例的实际含义。-包含涉及到几个基本用例的行为，提高用
50、例的一致性。通常，有不止一个用例必须包含某个包含用例，这样维护一个额外用例和包含关系才有价值。只有基本用例清楚它和包含用例的关系；而包含用例并不知道自己被其他什么用例所包含。通过略述包含的目的以及包含用例插入基本用例的位置，说明它们之间的包含关系。说明基本用例的事件流时，应当引用在插入位置上的包含用例。需求定义的活动需求定义的活动确定执行者与用例之间关系确定执行者与用例之间关系用例之间的包含交流关系用例之间的包含交流关系Figure 4-10.Example of include relationships among use cases.查地图（ViewMap）用例描述了查看城市地图的事件流