1、教案（第 1 页）章章节节名名称称5 5 软件需求分析软件需求分析授授课课安安排排授授 课课时时 数数2授授 课时课时间间第 5 次授授 课课方方 法法讲练结合授授 课课 教教具具机房教教学学目目的的掌握需求获取的方法和分析方法教教学学重重点点需求获取的方法和 UML 用例图教教学学难难点点需求获取的方法和 UML 用例图软件质量=系统所实现的需求/客户所期望的需求软件项目投标及签订合同的基础软件系统实现的基础系统确认移交的基础需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求分析的任务就是准确地回答“系统必须做什么?”这个问题，是通过系统分析员与用户一起商定，清晰、准确、具体
2、地描述软件产品必须具有的功能、性能、运行规格等要求。软件需求分析阶段的目的是澄清用户的要求，并把双方共同的理解明确地表达成一份书面文档软件需求规格说明书。装订线教案（附页）（第2页）在软件的整个生命周期中，首先是软件计划期，接着是软件开发期，软件需求分析是软件开发的第一个阶段，也是关系到软件开发成功与否的关键一步。软件在需求分析和设计阶段占用的工作量达到总工作量的 4050， 说明软件开发前期的活动多么重要。当然这也包括分阶段开发原型的开销。大家熟悉的编码工作只占全部工作量的 1020，而软件测试和调试的工作量占到总工作量的3040，甚至50%。需求获取：资料收集需求分析与协商：理解分析整理系
3、统建模：用模型描述(写下来)需求规约：完善需求文档并定稿需求验证：验证确认需求管理：整体规划及变更管理需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理。缺少用户参与是项目失败的主要原因之一良好的开端是成功的一半需求获取：通过客户调研等手段对需求进行收集、分析、细化、核实和组织两种项目(相对)的需求获取过程： 产品项目：一般是根据公司战略和市场需求研发，旨在进行批量出售或推广的项目 工程项目：一般是根据与用户签定的合同研发，旨在满足特定用户需求的项目教案（附页）（第3页）建立顺畅的通信途径深入客户方进行访谈与调查观察用户操作流程建立分析所需要的通信途径，以保证能顺利地对问题进行分析
4、访谈/调查计划：从初步的需求了解出发，制订需要了解或讨论的问题的顺序和范围等 有利于保证访谈的效率和全面性，但灵活性不足在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性用户提出某种需求： 水的质量信息必须立即能够显示出来。分析员更准确的描述： 水的质量记录必须在接到请求信号的 5 秒内显示出来。需求获取的三大挑战 1 问题空间的理解 2 人与人之间的沟通3 需求的不断变化教案（附页）（第4页）沟通问题需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理必须能够表示和理解问题的信息域(数据)必须能够定义软件将完成的功能必须能够表示软件的行为(作
5、为外部事件的结果)必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节分析过程应该在基本信息基础上不断细化协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素 不一致的目标教案（附页）（第5页） 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做目标软件的模型不应涉及软件实现细节常用的分析方法： 面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA)建模，一图胜过千言万语Unified Modeli
6、ng Language近十几年来 OOSE 最重要的成果贡献者：Grady Booch， James Rumbaugh,Ivar Jacobson于 1996 年 6 月推出中文网站 http:/www. http:/ http:/UML 是一种可视化的图形符号建模语言，利用它可以进行需求分析、概要设计、详细设计、编程实现、项目计划、测试、原型迭代、产品发布、产品维护等。目前在软件工程里主要用于系统分析与系统设计。Rational Rose 是 UML 的主要建模工具。Microsoft Visio 是 UML 常见的建模工具UML 是一种标准化的图形建模语言， 它是面向对象分析与设计的一种标
7、准表示。由:视图(views),教案（附页）（第6页）图(Diagrams),模型元素(Model elements)通用机制(general mechanism)等几个部分构成。是一种客户、系统分析师、设计人员、编程人员、测试人员和维护人员共同的语言，沟通的工具巴比伦通天图图像UML 借助图形符号展示和表达系统的概观 ，据此可以开发出表示系统各个方面的不同图示。有助于理解系统的行为和状态的典型图有：用例为一系列事务，其中的每个事务是从系统外部调用的，需要与内部对象合作，以便在对象与系统周围之间创建关联此图是系统的静态结构，也是类以及这些类表示的关系的集合时序图是通过展示系统与其环境之间的交互
8、，描述系统行为的简单而直观的方法协作图表示特定环境和交互中一系列关联的对象。活动图是状态机图的变更或特例。在状态机图中，状态是展示执行操作的活动，操作完成后将触发转换。状态图展示方法执行的状态和对象执行的活动。Design View描述系统设计特征，包括结构模型视图和行为模型视图，前者描述系统的静态结构(类图、对象图)，后者描述系统的动态行为(交互图、状态图、Process View表示系统内部的控制机制。常用类图描述过程结构，用交互图描述过程行为。Use case View 描述系统的外部特性、系统功能等。Implementation View表示系统的实现特征，常用构件图表示Deploym
9、ent View配置视图描述系统的物理配置特征。用配置图表示教案（附页）（第7页）(1) 统一标准UML 统一了 Booch、OMT 和 OOSE 等方法中的基本概念，已成为 OMG 的正式标准，提供了标准的面向对象的模型元素的定义和表示。(2) 面向对象UML 还吸取了面向对象技术领域中其他流派的长处。UML 符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、多余的和极少使用的符号,也添加了一些新符号。(3) 可视化、表示能力强系统的逻辑模型或实现模型都能用 UML 模型清晰的表示，可用于复杂软件系统的建模。(4) 独立于过程UML 是系统建模语言，独立于开发过程。(5) 易掌握、易
10、用由于 UML 的概念明确，建模表示法简洁明了，图形结构清晰，易于掌握使用。1992 年由 Jacobson 提出了 Use case 的概念及可视化的表示方法Use case 图，受到了 IT 界的欢迎，被广泛应用到了面向对象的系统分析中。用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计方法的主流。Jacobson 对用例的定义“对话中的参与者所执行的交互的动作序列，系统为参与者提供了一些可测量值。 ”用例的简单解释“系统的一组使用场景，每个场景描述了一个系统执行的动作序列。执行动作序列，产生特定参与者可看得见的结果值 。 ”用例图的元素 4-1教案（附页）（第8页）系统是用例图的
11、一个组成部分，它代表的是一个活动范围，而不是一个真正的软件系统。系统的边界用来说明构建的用例的应用范围。系统边界框定义系统的边界或限制，所以，系统的所有功能或过程会被限制在系统内，即此边界将系统的所有过程/功能与外界环境分隔。用例是系统执行的功能或过程，它可以由外部对象或系统内部另一个用例启动参与者是负责启动系统过程的外部实体，它可以是使用系统的人或为某些访问系统的外部过程。用例符号 3-1用例符号参与者用例将详细说明的需求表示为系统和一个或多个参与者之间的一系列交互这些交互有助于向用户描述所提出的系统功能就复杂系统来说，用例也以需要构建的内容提供系统分析的起点用例提供由系统提供的服务的源，并
12、且有助于确定系统必须实现的类用例的必要性步骤 1. 定义系统和系统边界步骤 2. 确定参与者及其目标步骤 3. 确定用例步骤 4. 确定参与者和用例之间的关系一 确定系统边界二、执行者(角色、Actor)执行者是指用户在系统中所扮演的角色。执行者在用例图中是用类似人的图教案（附页）（第9页）形来表示, 但执行者可以是人，也可以是一个外界系统。如何确定执行者：1、谁使用系统的主要功能(主执行者)?2、谁需要从系统获得对日常工作的支持和服务？3、需要谁维护管理系统的日常运行（副执行者）？4、系统需要控制哪些硬件设备？5、系统需要与其它哪些系统交互？6、谁需要使用系统产生的结果（值）？三、用例(us
13、e case)从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在 UML 中,用例被定义成系统执行的一系列动作。用例有以下特点:用例捕获某些用户可见的需求,实现一个具体的用户目标。用例由执行者激活,并将结果值反馈给执行者。用例必须具有功能上的完整描述。如何确定用例：1、与系统实现有关的主要问题是什么？2、系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？3、执行者需要系统提供哪些功能？4、执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？用例之间的关系扩展关系包含关系例 1：用例图实例教案（附页）（第10页）现有一医院病房监护系统，病症监视器安置在每个病房，将病人的
14、病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情报告，立及更新病历。要求根据现场情景，对医院病房监护系统进行需求分析， 建立系统的用例模型。提供提供标准标准病历病历管理管理病人病人医生医生值班护值班护病症病症监护监护病病情情中央中央监护监护使使使使使使情景分析系统名称：医院病房监护系统根据分析系统主要实现以下功能：1、病症监视器可以将采集到的病症信号（组合） ，格式化后实时的传送到中央监护系统。2、中央监护系统将病人的病症信号
15、开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。3、当病症信号异常时，系统自动更新病历并打印病情报告。4、值班护士可以查看病情报告并进行打印。5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。6、系统定期自动更新病历。教案（附页）（第11页）1、通过以下六个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。角色描述模板通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：2、识别出系统的用例通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：详细用例说明的结构需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理
