软件工程-需求分析课件

《软件工程-需求分析课件》由会员分享，可在线阅读，更多相关《软件工程-需求分析课件（35页珍藏版）》请在金锄头文库上搜索。

1、第三章 需求分析(Requirements Analysis),需求分析,需求分析是软件定义时期的最后一个阶段 准确回答“系统必须做什么？”的问题 可行性分析阶段已经粗略了解了用户的需求，甚至已经提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的方案。因此许多细节被忽略。 在系统开发前，还需要进一步确定系统必须完成哪些工作。不是“how”，而是“what”。,真的很重要吗？ 例： 一个很好的例子：用在欧洲航天局太空火箭Ariane-5上的嵌入式软件。1996年6月4日，该火箭第一次飞行投入使用，刚工作约40秒，飞行便开始偏离其轨道。沿着Ariane地

2、面控制器的方向飞行，火箭最终被摧毁。火箭摧毁，损失的不仅是火箭本身，还有它携带的四个人造卫星。总损失达到500 million美元。 最后查明原因：在Ariane-5飞行轨道的需求文档中，没有分析其飞行路线，认为和Ariane-4一样。,第三章 需求分析,统计资料： 1994年 ，一个Standish公司，对350多个公司的大约8000个软件项目进行调查，目的是发现它们进展的如何？结果很让人震惊：31%的软件项目在完成前被取消；此外，在大公司里，只有9%的项目能及时交付并且花费不超过其预算；小公司里16% 的项目遇到各种问题。 (Standish 1994). 为了搞清楚上述原因，Standi

3、sh要求他调查的对象解释他们项目失败的原因，总结如下： 需求不完整（13.1%） 缺乏和用户交流（12.4%） 缺少资源（10.6%） 需求不现实（9.9%） 管理不善（9.3%） 改变需求和规格说明（8.7%） 缺少计划（8.1%） 系统取消（7.5%）,需求分析的重要性,5点事实: 软件生命周期中，一个错误发现得越晚，修复错误的费用越高,需求分析的重要性,许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 DeMarco在一份研究报告中指出，被检查出来的错误的56产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信

4、息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。 在需求阶段，代表性的错误为疏忽、不一致和二义性 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A7E它机上的”宅行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A7E项目中77的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是： 49不正确的事实，31疏忽，l 3不一致，5二义性,需求错误是可以被检查出来的,需求分析的重要性,需求管理的困难性,需求工程,需求是什么? 需求就是用一种清晰、简洁、一致且无二义性的

5、方式，对一个待开发系统中各个有意义方面的陈述的一个集合。 需求工程 一般指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述出待开发系统及其行为特征和相关约束；通常是一些过程的集合：需求获取(需求引出)、需求分析和编写软件规格说明书(SRS)及验证(包括鉴定和证实)。,需求工程涉及人员,需求分析现状,误解 交流障碍 缺乏共同语言 “完整性”问题 需求永远不会稳定 用户意见不统一 错误要求 认识混淆,3.1 需求分析的任务,仍然回答“What”，而不是“How”， 但更细致、精确,Final stage of Definition phase,1. 需求分析的任务,1、确定对系统的综合

6、要求 功能要求(functional requirements):系统必须做什么？ 性能要求(performance requirements)：做得怎样？ 例：response time , memory , back-up memory , security , 运行要求(operational requirements) ：运行环境、软硬件配置等。 未来可能的扩充要求(possible evolution) 明确列出那些不属于当前系统的开发范畴,但是据分析将来可能会提出的要求.,3.1 需求分析的任务,2、分析数据要求 建立概念模型(conceptual models): E-R Dia

7、gram 形象描绘数据结构: Warnier Diagram, IPO 数据结构规范化(Normalization),3、导出逻辑模型：抽取其“做什么”的本质 DFD + DD + IPO,4、修正计划：重估成本、进度等,3.1 需求分析的任务,5、开发原型系统(Prototyping),“样机 试用”,C,D,G,3.2获取用户需求的方法,一、访谈 最早使用、并且目前仍然广泛使用的需求分析技术。 1、正式访谈 系统分析员提出一些事先准备好的具体问题 eg:客户销售的商品种类、销售人员数目等 2、非正式访谈 分析员提出一些用户可自由回答的开放性问题，鼓励被访者说出自己的想法 eg：对目前正使用

8、的系统有哪些不满意等,二、面向数据流自顶向下求精 软件系统本质上是信息处理系统，任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息 数据是分析的出发点，在可行性研究阶段许多实际的数据元素被忽略了，需求分析阶段将定义这些数据元素 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法 具体步骤如下：,3.2 获取用户需求的方法,1、沿DFD回溯 （1）DFD的输出端是系统的最终目的 （2）向回确定每个数据元素的来源 （3）为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出某个数据元素需要用的算法尚不清楚，可加细DFD及DD，并将相关算法记录在IPO图中。,2、

9、用户复查 数据字典准确完整吗？ 算法正确吗？ 有没有遗漏必要的处理或数据元素？ 某些数据元素是从哪里来的？ 构成一个循环，认识螺旋式上升,3.2 获取用户需求的方法,3、细化DFD： 加细前后的IO须相同。 分解到须考虑具体实现的代码时即可仃止,面向数据流自顶向下求精过程,3.2 获取用户需求的方法,三、简易的应用规格说明技术 传统的获取需求的方法,用户处于被动地位，不能像同一个团队的人那样齐心协力地识别和精化需求,效果并不理想(发生误解、遗漏重要信息等)。 为解决上述问题，提出一种面向团队的需求收集法（简易的应用规格说明技术）:提倡用户与开发者密切合作，共同标识问题，提出解决方案要素、商讨不

10、同方案并指定基本需求。,3.2 获取用户需求的方法,四、快速建立软件原型 最准确、最有效、最强大的需求分析技术 1、快速 尽快提供给用户一个可运行的目标系统的原型，以便使用户和开发者就系统“做什么”达成共识。 2、容易修改 原型功能不能满足用户，则根据用户意见迅速修改，以更好地满足用户需求。 重复“修改试用反馈”过程。,3.2 获取用户需求的方法,3.3分析建模与规格说明,结构化分析方法准则: 理解并描述问题的信息域，建立数据模型 定义软件功能，建立功能模型 描述软件行为，建立行为模型 对上述模型进行分解，用层次的方式展示细节,数据模型、功能模型、行为模型 2.4节讲的数据流图，描绘当数据在软

11、件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础； 3.4节将介绍的实体-联系图，描绘数据对象及对象之间的关系，用于建立数据模型； 3.6节将介绍状态转换图，指明了作为外部事件结果的系统行为，该图描绘了系统的各种行为状态和在不同状态间转换的方式，是行为建模的基础。,软件规格说明书： 通过需求分析除了建立分析模型外，还应写出软件需求规格说明书，需求分析阶段得出的最主要的文档。 软件规格说明书内容及格式如下：,3.3 分析建模与规格说明,封面：,3.3 分析建模与规格说明,内容：,系统规格说明： 系统概貌 功能要求 性能要求 运行要求 可能增加的要求

12、 DFD IPO, 数据要求： DD Hierarchy 或 Warnier Diagram, 用户系统描述 初步用户手册：从用户的观点考虑系统 系统功能、性能 使用与步骤 等,修正的开发计划： 成本估计 资源使用计划 进度计划,3.3 分析建模与规格说明,3.4概念模型和规范化 对数据的分析(3.4实体-联系图和3.5数据规范化),1、概念模型：描述从用户角度看到的数据 实体 -联系图(Entity - Relationship Diagram),3.4概念模型和规范化,2、范式(Normal Forms)：消除数据冗余的程度 IBM E. F. Godd (1970) 例：,*Keywor

13、d:可唯一地标识一个元组的属性,1 - NF：所有属性都是原子值，即不出现“表中有表”,2 - NF：在 1-NF 基础上，每个non-key-word都由整个key word 决定（而非依赖于key word 的一部分）。例：“Major”实际上由“ID”的第6、7位决定，可省去。,3 - NF：在 2-NF基础上，non-key-word之间无从属关系。,3.4概念模型和规范化,3.6状态转换图（状态图）,状态图:通过描绘系统的状态和引起系统状态转换的事 件，来表示系统的行为。 状态:可被观察到的系统行为模式,一个状态代表系统的一种行为模式. 初态、终态、中间状态，一张状态图中只能有一个初

14、态，可有0个或多个终态。 事件：某个特定时刻发生的事情，它引起系统做动作或从一个状态转换到另一个状态。 符号：, 初态 中间状态,终态 ,电话系统的状态图,3.7其它图形工具,1、层次方框图 (Hierarchy) 描绘数据的结构 用树型结构的一系列多层次的矩形框描绘数据的层次结构； 树型结构顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割）。,例：,3.7其它图形工具,2、Warnier Diagram：,例：P.46 图 3.4,3.7其它图形工具,3、IPO图(Input / Process / Output)： 简要的算法描述,1. 校验 主记录 2. 校验 事务记录 3. 更新 主记录,旧的主文件 事务文件,有效的 主记录 有效的 事务记录 更新后的 主文件,3.7其它图形工具,3. 8验证要求(Requirements Validation),方法： 人工审查 初步用户手册 使用软件工具 完整性、一致性,