PPT《软件工程 Software Engineering》

软件工程 Software Engineering 国防科技大学计算机学院 2004.

07

第四章 需求分析基础 软件需求 用户对目标软件系统在功能、行为、性能、设计约束等方面的期望.软件需求分析阶段的任务,通过对问题及环境的理解、分析,将用户需求精确化、完全化,最终形成需求规格说明,描述系统信息、功能和行为. ? 需求分析基础 主要内容三个主要阶段:问题分析、需求描述、需求评审技术和方法 初步需求获取技术 需求建模技术 快速原型技术 问题抽象、问题分解与多视点分析例 家庭保安系统 展示部分方法的使用过程.需求建模方法和CASE工具的进一步研究 面向数据流的分析 面向数据的分析 面向对象的分析

第四章 需求分析基础 软件需求的产品和过程 软件需求分析产品用户需求 (系统分析的产品) 系统需求软件需求规格说明(软件设计描述)需求规格说明是软件设计、实现、测试、维护的基础.

第四章 需求分析基础

第四章 需求分析基础 用户需求、系统需求和软件设计描述 用户需求用自然语言和

图表描述说明系统必须提供哪些服务、系统运行要受哪些约束系统需求详细说明系统将要提供的服务以及系统受到的约束精确的描述软件的功能系统买方和软件开发者签订合同的重要内容软件设计描述在系统需求的基础上,加入更详细的内容,构成软件设计活动的概要描述,是软件设计和实现的基础

第四章 需求分析基础 4.1 分析的任务与原则 任务 问题分析 需求描述 需求评审

第四章 需求分析基础

1 问题分析 分析人员应了解问题及环境,应与用户合作清除用户需求的模糊性、岐义性和不一致性,并对相互冲突的需求进行折衷.分析人员与用户合作对问题进行分析、综合,结合软件的特点及开发经验,寻求软件需求. 4.1分析的任务与原则 问题分析 系统模型 为用户的问题及准备开发的软件建立模型,从不同的角度、不同的抽象级别精确地说明对问题的理解、对目标软件的需求. 4.1分析的任务与原则 问题分析 系统模型 模型应帮助用户和分析人员发现、排除用户需求不一致,不合理的部分,挖掘潜在的用户需求.模型是分析人员根据问题创建的软件系统结构,包括与问题和环境相关的信息流、处理功能、用户界面、行为及设计约束.模型是形成需求规格说明、进行软件设计的基础.需求建模方法 面向数据流的分析方法、面向数据的分析方法、面向对象的分析方法. 4.1分析的任务与原则

2 需求描述 任务以需求模型为基础,考虑到软件问题的可解性,生成需求规格说明和初步的用户手册.需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准以及用户在性能、质量、可维护性等方面的要求.用户手册包括用户界面描述以及有关目标软件使用方法的初步构想. 4.1分析的任务与原则 需求描述 文档 遵循规范,内容全面、结构清晰、措辞准确、格式严谨.将初步用户手册作为分析文档,有助于分析人员从用户角度考虑软件需求,并鼓励用户尽早参予软件开发活动. 4.1分析的任务与原则

3 需求评审 分析人员在用户和软件设计人员的配合下,对自己生成的需求规格说明和初步的用户手册进行评审,确保软件需求的完全性、精确性和一致性,并使用户和软件设计人员对需求规格说明及用户手册的理解达成一致.需求规格说明得到用户和软件开发方的确认后,应成为用户方与软件开发方合同的一部分. 4.1分析的任务与原则 需求评审 分析活动 对于大型软件项目,分析人员可以先对问题的某些子系统进行需求分析、描述与评审,子系统完成后,再对其它子系统进行分析,进而构筑整个系统的需求模型. 4.1分析的任务与原则 4.2 初步需求获取技术 访谈与会议 深入调查研究 开发原型

第四章 需求分析基础 4.2.1 访谈与会议 个别访谈或小组会议 分析人员应精心准备问题,通过用户对问题的回答,逐步理解用户对目标软件的要求. (1) 循序渐进 首先关心一般性、整体性问题,然后再讨论细节问题. (2)客观、公正 不应限制用户在回答问题过程中自由发挥. (3) 总结 问题汇总后应能反映软件或其子系统的全貌,能覆盖用户对目标软件或其子系统在功能、行为、性能诸方面的要求. 细节问题留待以后解决.? 4.2初步需求获取技术 4.2.2 考察用户软件或其子系统业务流程 ? 调查研究 学习用户的有关业务知识,在用户帮助下了解用户的软件或子系统业务流程,结合软件开发和应用的经验提出新的用户需求. 4.2初步需求获取技术 4.2.3 联合小组 建立软件开发方和用户方共同组成的联合小组,小组成员对分析负有相同的责任.联合小组要制定自己的工作制度和计划,确定专门的记录员,另设专人负责会议的议程和资料的综合、整理.选择易于理解、比较简洁、精确的表示机制作为描述语言,如辅以文字说明的流程图.? 4.2初步需求获取技术 4.2.4 例 家庭保安系统 问题描述:家庭保安市场正以每年40%的速度增长.希望建立一种基于微处理器的家庭保安系统,它能够识别异常事件并采取相应的防护措施.这些异常事件包括:非法侵入、火灾、水淹等.一旦异常情况被传感器探测出来,系统应自动通过电话向监控中心报警.此外,应允许户主对系统行为进行程序控制.? 4.2初步需求获取技术 家庭保安系统 分析初期联合小组的工作程序 联合小组首先制定工作制度:每次会议开始前必须有确定的议程,参加者必须针对各项议程进行充分的准备,并用文字表示. 4.2初步需求获取技术 例 家庭保安系统 经过会议讨论,明确问题的范围、问题与环境的关系,并就开发软件产品的必要性达成共识.小组负责人要求每位参加者列出问题及环境中的有关对象,对这些对象施行的操作以及对象间的相互作用.列出的操作和对象尽可能完全,如,控制面板、电话机、监控中心、烟雾传感器、门窗监视器、警报器等对象,以及用户编程控制、电话拔号、报警等操作. 4.2初步需求获取技术 例 家庭保安系统 负责人应要求小组成员对接收传感器事件、用户编程控制、电话报警等操作进行更详细的描述,必要时可用流程

图表示.用户可能提出一些条件,如造价不能超过3,000元,对传感器事件必须在1秒内作出响应,事件必须按优先级进行处理等.会后小组负责人对这些信息进行综合、整理,形成文档,该文档应能反映 家庭保安系统 的全貌. 4.2初步需求获取技术 例 家庭保安系统 联合小组分成两个小组,分别处理用户编程控制和传感器监测两个子系统.目的是对子系统的软件需求进行细化.对出现的新对象、新操作、新约束应及时添加到相应的子系统.确定子系统需求并形成文档联合小组讨论子系统的集成及需求验证标准.子系统集成包括子系统接口的一致性检查、系统功能和行为的完整性检查.需求验证标准应该是可测试的,以便开发人员在代码生成后能够通过测试结果向用户表明软件系统已完整地实现了用户需求.初步分析活动应形成结论性文档,该文档将作为后续分析活动的基础. 4.2初步需求获取技术 例 家庭保安系统 初步分析生成的 家庭保安系统 部分需求文档 (不包括约束条件和测试标准) 家庭保安系统 的软件允许用户在安装时进行系统配置,实施对传感器的监控并通过控制面板与用户进行信息交互.配置操作(1)指定每一传感器的种类和编号;

(2)设置开、关机密码;

(3)指定报警电话号码;

(4)指定报警延迟和电话重拔延迟时间(以秒为单位). 4.2初步需求获取技术 例 家庭保安系统 当软件系统接收到传感器发出的数据后,判别是否出现异常事件.如果是,则在指定的延迟时间内拔报警电话号码,拔号操作将按照重拔延迟反复进行,直至电话接通.然后软件系统负责报告时间、地点和异常事件的性质.开机后软件系统负责显示当前工作状态,接收并处理用户指令. 4.2初步需求获取技术 4.3 需求建模 建立软件模型是分析活动的关键.目标软件系统的模型用来刻划系统所涉及的信息、处理功能及系统运行时的外部行为.模型不应涉及软件实现细节,这样会分散分析人员的注意力,限制软件设计人员的聪明才智.分析人员应以简洁、准确、清晰的方式,系统地描述软件需求模型,如,选择图形符号表示信息流、处理功能及系统行为,利用受限的自然语言给出用户需求描述.为了处理大型问题,模型表示机制应具备良好的结构化能力.

第四章 需求分析基础 4.4 问题的抽象、分解与多视点分析 抽象 关注一般问题的解决途径,以此指导特殊问题的求解.分析人员应该注意用户描述的抽象级别,统一规划系统行为避免不一致性,减少分析的工作量.

第四章 需求分析基础 问题的抽象、分解与多视点分析 分解 根据问题的规模和复杂性进行分解,并对子问题展开进一步的分析.逐级分解,直至子问题的规模降至合适程度.在问题分解过程中,要建立子问题之间的相互联系.必须遵循子问题内部紧藕合,子问题之间松藕合的原则. 4.4问题抽象、问题分解与多视点分析 问题的抽象、分解与多视点分析 视点分解法 在分析的初期,整体地把握一个大型问题的软件需求是困难的.需要从各个角度分别对问题进行理解和分析,然后再综合,达到全面理解的目需求分析视点 系统观点 用户观点 信息观点 功能观点 行为观点等.整理、综合用户描述,应注意用户视点的变化,避免遗漏. 4.4问题抽象、问题分解与多视点分析

4 .5 支持需求分析的快速原型技术 按照传统的软件开发方法,目标软件要等到木已成舟才能交用户认可.分析、设计及编码积累的各种问题,导致用户对目标软件提出诸多修改,甚至全盘否决,造成人力、物力的巨大浪费.软件开发早期,快速建立目标软件系统原型,让用户对原型进行评估并提出意见.原型几经改进最终确定........