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