{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a

上传人:精****库 文档编号:140967967 上传时间:2020-08-03 格式:PPTX 页数:36 大小:776.93KB
返回 下载 相关 举报
{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a_第1页
第1页 / 共36页
{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a_第2页
第2页 / 共36页
{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a_第3页
第3页 / 共36页
{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a_第4页
第4页 / 共36页
{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a_第5页
第5页 / 共36页
点击查看更多>>
资源描述

《{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a》由会员分享,可在线阅读,更多相关《{行业分析报告}软件工程导论第3章需求分析第五版张海藩编著a(36页珍藏版)》请在金锄头文库上搜索。

1、第3章 软件需求分析,教学目的与要求: 深刻理解需求分析阶段的概念及任务,熟练掌握ER图,HIOP图的画法。 教学重点:需求分析阶段的任务、方法、具体任务。 教学难点:写出需求规格说明书,第3章 软件需求分析,3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图(数据建模) 3.5 (存储)数据的规范化 3.6 状态转换图(行为建模) 3.7 其他图形工具(数据建模:层次图、Warnier,IPO: 描述数据处理的算法) 3.8 验证软件需求 3.9 小结 习题,成功来之不易,31%,(取消),16.2%,(成功地完成),53.8%,(受到

2、挑战),Source: Standish Group,2,软件项目失败的原因,软件项目失败的最重要的五个主要原因:,需求不完整,缺少客户的参与 缺少资源,期望值过高,缺少高层的支持,0%,5%,10%,15%,3,需求错误的成本,4,软件需求的重要性: 软件需求分析是决定软件成功开发的一个关键因素 -帮助分析员真正理解业务问题 -是估算成本和进度的基础 -避免建造错误的系统,从而减少不必要的浪费 -软件规格说明有助于分析员与用户在系统需求问题上达成 正式契约 -有助于管理软件的演化和变更 -是软件质量的基础,为系统验收测试提供了标准,5,软件需求分析的基本任务是准确地回答“系统必须做什么?”,

3、3.1.1 确定对系统的综合要求,1.功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。 2.性能需求 性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、等方面的需求。 3.可靠性、可用性、安全性、保密性等需求 要求定量地指定系统的可靠性、可用性、安全性、保密性等。,3.1 需求分析的任务,4. 出错处理需求 在某些情况下,“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是,应该有选择地提出这类出错处理需求。对应用系统本身错误的检测应该仅限于系统的关键部分,而且应该尽可能少。 5

4、. 接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。 6. 约束 常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。,7、用户界面需求,系统环境 软件界面,多少台机器、机型等接口。 8、逆向需求 软件不应该有的功能及性能。 9. 将来可能提出的要求,这是软件需求分析的一个重要任务。通常采用建立数据流图、数据字典、数据模型的方法。 常用的图形工具有层次方框图HIPO和Warnier图,在本章第3.7节中将简要地介绍这两种图形工具。 软件系统经常使用各种长期保存的信息,为减少数据冗余,避免

5、出现插入异常或删除异常,简化修改数据的过程,通常需要把数据结构规范化(见3.5节)。 3.1.3 导出系统的逻辑模型 在分析综合中逐步细化软件功能划分各子功能,对系统数据域进行分析,建立新系统的逻辑模型(系统流程图、数据流图、数据字典、E-R图、UML模型图表示)。 常用方法有:面对结构化分析方法(SA)、面向数据结构(JSP)方法、面向对象OOA方法。,3.1.2 分析系统的数据要求,3.1.4 修正系统开发计划,3.1.4 修正系统开发计划 根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。,补充:与用户沟通获取需求的方法,3.2

6、 与用户沟通获取需求的方法 需求获取的困难: 用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求,开发人员缺乏相关的领域知识和经验,难以准确理解这些需求 不同的用户提出不同的需求,可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 由于经济和业务环境的动态性,需求经常发生变更,补充:与用户沟通获取需求的方法,3.2 与用户沟通获取需求的方法,需求获取的关键在于通过与用户的沟通和交流,收集和理解用户的各项要求。 3.2.1 访谈-访问用户和用户领域的专家 形式:分别交流 需求讨论会 问卷调查 现场考察 3.2.2 对数据流图自顶向下逐步细化求精 根据数据字

7、典,用IPO图描绘出输入的数据怎样加工成输出的数据。 3.2.3 简易的应用规格说明技术 分析员与用户开会,共同完善需求规格说明书。 3.2.4 快速建立软件原型 -通过用户试用原型,反馈需求,收集需求 建立原型的三种方法及工具: 1、第四代技术:数据库语言、程序生成器、非过程的高级语言 2、形式化规格说明、自动翻译软件、原型,3.3.1 根据需求分析结果建立模型 模型:用于描述客观事物的图形。 根据需求分析过程中获取的用户需求,建立三种模型: 数据模型:E-R图,层次图,Warnier图 功能模型:数据流图 行为模型:状态转换图 3.3.2 书写软件需求规格说明书,3.3 建立模型、书写规格

8、说明,2、分析和综合导出软件的逻辑模型,应该包括在SRS(需求规格说明)中的内容 -功能:软件应该提供什么功能? 外部接口:软件如何与人、系统硬件和其他系统等进行相互作用? 性能:在运行速度、可用性、响应时间、恢复时间等方面有什么要求? 特性:软件系统在可移植性、可维护性、安全性等方面有什么考虑? 设计约束:是否存在必要的标准、开发语言、数据库、资源 限制、运行环境等因素的影响和策略? 不应该包括在SRS 中的内容 - 项目开发计划:如成本、人员、进度、工具、方法等 - 产品保证计划:如配置管理、验证与测试、 质量保证等 - 软件设计细节:需求通常用于表达“做什么”,而不描述“如何做”。,编写

9、需求规格说明的原则,原则 1:只描述“做什么”而无须描述“怎么做” 原则 2:必须说明运行环境 原则 3:考虑用户、分析员和实现者的交流 -对形式化和自然语言之间作出恰当的选择 - 明确的理解最重要,不存在十全十美的软件规格说明书,编写需求规格说明的原则,原则 4:力求寻找到恰如其分的需求详细程度 - 一个有益的原则就是编写单个的可测试需求文档 - 建议将可测试的需求作为衡量软件产品规模大小的尺度 原则 5:文档段落不宜太长 简短 - 记住:不要在需求说明中使用“和/或”、“等等”之类的词 原则 6:避免使用模糊的、主观的术语 - 如用户友好、容易、简单、迅速、有效、许多、最新技术、 优越的、

10、可接受的、最大化、最小化、提高等 - 不可验证 建议:采用一种标准的SRS 模板,为了把用户的数据要求清楚、准确地描述出来,系统分析员通常建立一个概念性的数据模型(也称为信息模型)。数据模型中包含3种相互关联的信息:数据对象、数据对象的属性及数据对象彼此间相互连接的关系。 3.4.1 数据对象(实体):是指具有多个特征的复合信息。 3.4.2 联系:数据对象之间的关系(1:1,1:n,m:n)。 3.4.3 属性:数据对象的、联系的特征。 3.4.4 表示符号(矩形,菱形,圆角矩形或椭圆) 通常,使用实体-联系图(entity-relationship diagram)来建立数据模型。可以把实

11、体-联系图简称为ER图,相应地可把用ER图描绘的数据模型称为ER模型。,3.4 实体-联系图(E-R图),ER信息模型的设计,三个例子,软件系统经常使用各种长期保存的信息,这些信息通常以一定方式组织并存储在数据库或文件中,为减少数据冗余,避免出现插入异常或删除异常,简化修改数据的过程,通常需要把数据结构规范化。 下面给出第一、第二和第三范式的定义: (1) 第一范式在同一表中没有重复项出现,如果有则应将重复项去掉。 每个属性值都必须是原子值,即仅仅是一个简单值而不含内部结构。,3.5 数据规范化,(2) 第二范式满足第一范式条件,(2) 第二范式满足第一范式条件,而且每个非关键字属性都由整个关

12、键字决定(而不是由关键字的一部分来决定)。 每个表必须有一个(而且仅一个)数据元素为主关键字,其它元素与主关键字一一对应。 (3) 第三范式符合第二范式的条件,每个非关键字属性都仅由关键字决定,而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述(即一个非关键字属性值不依赖于另一个非关键字属性值)。 表中的所有数据元素,不但要能够唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其它的函数关系。,3.6 状态转换图,根据本章开头讲的结构化分析的第3条准则,在需求分析过程中应该建立起软件系统的行为模型。 状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件,来表

13、示系统的行为。 状态图还指明了作为特定事件的结果系统将做哪些动作(例如,处理数据)。 (面向对象模型中介绍),3.6 状态转换图(略),3.7 其他图形工具,3.7 其他图形工具 3.7.1 层次方框图(H图) 层次方框图是用树形结构的一系列多层次的矩形框描绘数据的层次结构。 树形结构的顶层是一个单独的矩形框,它代表完整的数据结构,下面的各层矩形框代表这个数据的子集,最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。,3.7.2 Warnier图,图3.5 层次方框图的一个例子,法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似,Warni

14、er图也用树形结构描绘信息,但是这种图形工具比层次方框图提供了更丰富的描绘手段。,3.7.2 Warnier图,HIPO图,图3.6 Warnier图的一个例子,3.7.3 HIPO图 HIPO(Hierarchy Plus InputProcessOutput,输入、处理、输出)图,是IBM公司于70年代中期在层次结构图的基础上,做出的一种描述系统结构和模块内部处理功能的工具。 HIPO图,有H图和IPO图两部分组成。 H图描述整个系统的设计结构合格模块之间的关系,H图画n层,每层根据经验一般为310个模块,层次(n层)按具体情况定。 IPO图描述某一特定模块内部的处理过程和输入输出关系。

15、HIPO图一般有1张H图,多张 IPO图组成,层次模块结构图,H图特点,层次模块结构图(H图),1、H图基本做法:是将系统划分为若干子系统,子系统下再划分为若干的模块,大模块内再分子模块。 2、H图特点:主要关心模块的外部属性,不关心模块的内部,即只关心它是什么能够做什么,不关心它怎么做。(怎么做IPO图解决) 3、模块的定义(什么是模块):具有输入输出、逻辑功能、运行程序和内部数据这四种属性的一个程序。,图3.7 IPO图的一个例子图,图3.7 IPO图的一个例子图,模块编号:c.5.5.8,图3.8 改进的IPO图的形式,图3.8 改进的IPO图的形式,本书建议使用一种改进的IPO图(也称

16、为IPO表),,3.8 验证软件需求,(1) 一致性:所有需求必须是一致的,任何一条需求不能和其他需求互相矛盾。 (2) 完整性:需求必须是完整的,规格说明书应该包括用户需要的每一个功能或性能。 (3) 现实性:指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测,对软件技术的进步则很难做出预测,只能从现有技术水平出发判断需求的现实性。 (4) 有效性:必须证明需求是正确有效的,确实能解决用户面对的问题。,3.8.2 验证软件需求的方法,3.8 验证软件需求 3.8.1 从哪些方面验证软件需求的正确性,需求验证是检验需求能否满足客户的意愿。 需求验证的技术: 需求评审:若需求说明书用自然语言表达,则由不同代表( 如分析员、客户、设计人员、测试 人员)组成 的评审小组以会议形式对需求进行系统性分析 ;若用形式化方法表达,则用软件工具。 原型评价:客户和用户在一个可运行的系统模型上实际检验 系统是否符合他

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 商业/管理/HR > 企业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号