软件工程第三章

合集下载

自考软件工程第3章知识点总结

自考软件工程第3章知识点总结

2
第3章 软件需求分析
需求分析在软件开发中所处的地位愈加突出,从而也愈加 困难,它的难点主要体现在以下几个方面:
(1) 问题的复杂性。 (2) 交流障碍。 (3) 不完备性和不一致性。 (4) 需求易变性。
软件需求分析与说明的方法的基本原则:
(1) 必须能够表达和理解问题的数据域和功能域。 (2) 可以把一个复杂问题按功能进行分解并可逐层细化。 (3) 建模。
结构化分析(Structured Analysis,简称SA),是面向数 据流进行需求分析的方法。根据软件内部数据传递、变换的关 系,自顶向下逐层分解,描绘出满足功能要求的软件模型。
3.2.1自项向下逐层分解的分析策略
面对一个复杂的问题,采取分解的策略,把一个复杂的问
题划分成若干小问题,然后再分别解决。分解可分层进行,在
(3) 环境需求。 (4) 用户界面需求。
4
第3章 软件需求分析
2. 分析与综合, 导出软件的逻辑模型 分析人员对获取的需求,进行一致性的分析检查,在 分析、 综合中逐步细分软件功能,划分成各个子功能。 3. 编写文档 编写文档的步骤如下: (1) 编写“需求说明书。 (2) 编写初步用户使用手册。 (3) 编写确认测试计划。 (4) 修改完善项目开发计划。
3. 数据项条目 数据项条目是不可再分解的最小数据单位, 其定义格 式及举例如下: 数据项名称: 货物编号 别名: G-No, G-num, Goods-No 简述: 本公司的所有货物的编号 类型: 字符串 长度: 10
取值范围及含义: 第1位: 进口/国产
第2~4位: 类别 第5~7位: 规格
第8~10位: 品名编号
1. 数据流条目
数据流条目给出了DFD中数据流的定义,通常列出该数 据流的各组成数据项。

软件工程PPT课件第3章 软件需求分析

软件工程PPT课件第3章 软件需求分析

–多个来回
6
软件需求分析的通信途径
7
分析建模
结构化分析模型 面向对象分析模型 分析模型描述工具

DFD、DD和PSPEC(加工规约)
CFD、CSPEC(控制规约)和STD E-R图 用例图,对象-关系图,对象-行为图
8
结构化分析模型
数据对象 说明 E-R图 加工说明 DFD图
44
数据流图
数据流图(DFD)是一种图形化技术,它描绘信息
流和数据从输入移动到输出的过程中所经受的变换 。 在数据流图中没有任何具体的物理部件,它只是 描绘数据在软件中流动和被处理的逻辑过程。 数据流图是系统逻辑功能的图形表示,即使不是 专业的计算机技术人员也容易理解它,因此是分析 员与用户之间极好的通信工具。 此外,设计数据流图时只需考虑系统必须完成的 基本逻辑功能,完全不需要考虑怎样具体地实现这 些功能。
2
需求分析的结构化分析方法准则
(1) 必须理解并描述问题的信息域,根 据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能,这条 准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件 行为,这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模 型进行分解,用层次的方式展示细节。
40
分析模型的元素
数据字典(DD):模型核心(中心库) E-R图(ERD): 数据流图(DFD)
指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能;
DFD中每个功能的描述包含在加工规约 (小说明)。
状态变迁图(STD)
指明作为外部事件的结果,系统将如何 动作。
41
3.4.2 数据建模
4
需求分析的任务和步骤

软件工程--第三章 生命周期方法学

软件工程--第三章 生命周期方法学
《软件工程导论》讲义 2015 版:第三章 生命周期方法学
Hale Waihona Puke 第三章 生命周期方法学一、 生命周期方法学的阶段划分
生命周期方法学是最传统也是最经典的软件开发方法学, 它严格按照软件生 命周期的阶段划分将软件开发过程划分为多个阶段:软件定义划分为问题定义、 可行性研究、需求分析三个阶段,软件开发划分为总体设计、详细设计、编码实 现、综合测试四个阶段,再加上软件维护阶段。 用图表表示即为: 问题定义 软件定义 可行性研究 需求分析 软件开发
P
F ,F 是 n 年后的收入,P 是折算为当前收入 (1 i ) n
有了对投入成本和效益的估算,就可以评价投资的价值了。一般来说,投资 收益主要的评价指标有以下几项: 投资回收期 投资回收期是指所开发的软件投入运行或者进行销售后,多长时间 能够全部收回投资。一旦收回投资,以后的收入就是纯收入;而在收回 投资之前的时间,对项目本身来说都是负债经营的。 任何一个应用软件项目都有一定的预期寿命,软件运行一定时间之 后,必然会因为跟不上技术的进步和应用的要求而被淘汰,被废弃。由 于激烈的市场竞争,商品软件的寿命会更短。因此,投资回收期是一个 软件项目投资的重要经济指标, 越早收回投资, 也就越早能够开始盈利, 在整个软件的生命周期中也能够获得越多的效益。如果投资回收期超过 了软件的预期寿命,那就是一个失败的投资。 纯收入 纯收入是软件在整个生命周期中得到的收益(注意:收益应当是考 虑了货币的时间价值后折合成现值的收益) 与开发这个软件的投入之差。 如果没有纯收入,因为投入开发是有风险的,因此也不应该实施这个项 目。纯收入首先必需能够对投资者的风险进行补偿。为了比较不同投资 项目之间的收益情况,还应该使用投资收益率,即纯收入与投入之比来 表示单位投入能够产生的效益。 投资回收率 投资回收率表示的是单位时间内单位投入能够产生的效益,它能够 更准确地体现出投资于一个项目的效益,并且可以与同样的资金进行别 的投资的收益进行比较。对于投资回收率,可以按照投资利息的方式来 理解。也就是说,投资回收率相当于我们将资金投入软件项目后,单位 时间(一般是年)可以得到的利率。计算投资回收率可以使用以下的方 程。

《软件工程》第3章 软件需求分析

《软件工程》第3章 软件需求分析

【本章重点】 本章重点】
需求分析的方法 ; 需求分析的任务和原则 ;
【教学目标】 教学目标】
掌握需求分析的基本概念; 掌握需求分析的基本概念; 掌握如何使用需求获取技术来进行数据采集; 掌握如何使用需求获取技术来进行数据采集; 掌握结构化分析的思想与过程; 掌握结构化分析的思想与过程; 掌握数据流建模技术。 掌握数据流建模技术。
3.2 面向数据流的分析方法
3.2.2 数据流图
1.数据流图中的主要图形元素
3.2 面向数据流的分析方法
2.分层的数据流图
在多层数据流图中,可以把顶层数据流图、 在多层数据流图中,可以把顶层数据流图、底层数 据流图和中间层数据流图区分开来。顶层数据流图仅 据流图和中间层数据流图区分开来。 包含一个加工,它代表被开发系统。 包含一个加工,它代表被开发系统。它的输入流是该 系统的输入数据,输出流是系统的输出数据。顶层数 系统的输入数据,输出流是系统的输出数据。 据流图的作用在于表明被开发系统的范围, 据流图的作用在于表明被开发系统的范围,以及它和 周围环境的数据交换关系。 周围环境的数据交换关系。底层数据流图是指其加工 不须再做分解的数据流图,其加工称为“原子加工” 不须再做分解的数据流图,其加工称为“原子加工”。 中间层数据流图则表示对其上层父图的细化。 中间层数据流图则表示对其上层父图的细化。它的每 一个加工可以继续细化,形成子图。 一个加工可以继续细化,形成子图。中间层次的多少 视系统的复杂程度而定。 视系统的复杂程度而定。
3.2 面向数据流的分析方法
4.数据流图的优缺点
总体概念强,每一层都明确强调“干什么” 总体概念强,每一层都明确强调“干什么”,“需要 什么” 给出什么” 什么”,“给出什么”; 可以反映出数据的流向和处理过程; 可以反映出数据的流向和处理过程; 由于自顶向下分析, 由于自顶向下分析,容易及早发现系统各部分的逻辑 错误,也容易修正; 错误,也容易修正; 容易与计算机处理相对应; 容易与计算机处理相对应; 不直观,一般都要在作业流程分析的基础上加以概括、 不直观,一般都要在作业流程分析的基础上加以概括、 抽象、 抽象、修正来得到

第三章 软件工程 需求分析-基础部分

第三章 软件工程 需求分析-基础部分
7
3.1.4 需求分析的过程
分析与综合 从信息流和信息结构出发,逐步细化所有的软件功能, 从信息流和信息结构出发,逐步细化所有的软件功能,找 出系统各元素之间的关联,接口特性和设计上的约束, 出系统各元素之间的关联,接口特性和设计上的约束,分 析它们是否满足功能要求,是否合理. 析它们是否满足功能要求,是否合理.剔除其不合理的部 增加其需要部分.最终综合成系统的解决方案, 分,增加其需要部分.最终综合成系统的解决方案,给出 目标系统的详细逻辑模型. 目标系统的详细逻辑模型. 常用的分析方法 面向数据流的结构化分析方法 面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对象的分析方法 面向对象的分析方法 (OOA) 等
16
3.2.1 需求获取技术
需求调查对象 对组织的高层管理者, 对组织的高层管理者,进行组织管理目标或经营方针等 组织战略问题的调查 对中层的管理者, 对中层的管理者,进行全部业务流的调查 对业务工作人员, 对业务工作人员,进行详细业务信息的调查 市场调查 了解市场对待开发软件有什么样的要求; 了解市场对待开发软件有什么样的要求;了解市场上有 无与待开发软件类似的系统 考察现场 了解用户实际的操作环境,操作过程和操作要求. 了解用户实际的操作环境,操作过程和操作要求.对照用 户提交的问题陈述,对用户需求可以有更全面, 户提交的问题陈述,对用户需求可以有更全面,更细致的 认识. 认识. 观察用户工作流程 用户和开发人员共同组成联合小组
具体化 表 达 需 求
3
目标系统
物理模型
实例化
逻辑模型

软件工程 第3章需求分析

软件工程 第3章需求分析
名字:定货报表 别名:定货信息 描述:每天一次送给采购员的 逐一确定 需要定货的零件表 元素的来 定义:定货报表 = 零件编号 +零件名称+ 源 定货数量+目前价格+主要供应 商+次要供应商
位置:定货报告 定货信息 库存清单
面向数据流方法的分析的应用
6 D1 库存清单 事务 1 包含零件编 号、名称、 目前价格
深入调查
外部输入或系 统生成
3.2.2 面向数据流的自顶向下求精
• 回溯时常遇到的问题:为了得到某个数据元素需要 用到数据流图中还没有的数据元素,或者得出这个 数据元素要用的算法尚不完全清楚。 • 因此,需要向用户等有关人员请教,他们的回答使 分析员对目标系统的认识更深入具体,系统中更多 的数据元素被划分出来,更多的算法搞清楚了。 • 把分析过程中得到的有关数据元素的信息记录在数 据字典中,把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理,应该 添加到数据流图的适当位置上。
• 主要目标:把数据流和数据存储定义到元 素级别(不可分解为止)
数据的来源、去 向、数据结构定 义等
可行性 分析忽 略了细 节
3.2.2 面向数据流的自顶向下求精
自顶向下,逐 层细化的方法
• 结构化分析方法是一种什么方法呢? • 从数据流图的输出端着手分析,这是因为系 统的基本功能是产生这些输出的关键原因。 • 输出数据决定了系统必须具有的最基本的组 成元素(包括功能和数据结构组成)。
3.4.1 数据对象
• 它的范畴很大,可以是外部实体(例如,产生 或使用信息的任何事物)、事物(例如,报表)、 行为(例如,打电话)、事件(例如,响警报)、 角色(例如,教师、学生)、单位(例如,会计 科)、地点(例如,仓库)或结构(例如,文件) 等。 • 总之,可以由一组属性来定义的实体都可以 被认为是数据对象。

软件工程课件 第三章

软件工程课件 第三章

软件工程课件第三章在软件工程的领域中,第三章通常聚焦于软件设计的核心概念与方法。

软件设计是软件开发过程中的关键环节,它将需求分析阶段所确定的功能和性能要求转化为具体的软件架构和模块结构,为后续的编码和测试工作奠定坚实的基础。

软件设计的目标是创建一个高效、可靠、可维护且易于理解的软件系统。

这需要综合考虑诸多因素,如系统的功能需求、性能要求、安全性要求、用户体验等。

同时,还要考虑软件的可扩展性,以适应未来可能的变化和升级。

在软件设计中,架构设计是至关重要的一环。

架构设计就像是为一座大楼绘制蓝图,它决定了软件系统的整体结构和组织方式。

一个良好的软件架构应该具有清晰的层次结构,各个模块之间的职责明确,并且能够有效地支持系统的功能和性能需求。

例如,常见的分层架构将软件系统分为表示层、业务逻辑层和数据访问层。

表示层负责与用户进行交互,业务逻辑层处理核心的业务逻辑,数据访问层则负责与数据库进行交互。

这种分层架构使得各个层次之间的职责清晰,便于开发和维护。

模块设计也是软件设计的重要组成部分。

模块是软件系统中的基本单元,具有相对独立的功能。

在进行模块设计时,需要遵循高内聚、低耦合的原则。

高内聚意味着模块内部的各个元素紧密相关,共同完成一个特定的功能;低耦合则表示模块之间的依赖关系尽量少,使得一个模块的修改对其他模块的影响最小化。

例如,一个负责用户登录的模块,应该只专注于处理登录相关的功能,而不涉及其他诸如用户信息管理等功能。

接口设计在软件设计中也不容忽视。

接口是模块之间进行交互的桥梁,定义了模块之间的通信方式和数据格式。

良好的接口设计能够提高模块之间的协作效率,降低系统的复杂性。

例如,在设计一个数据存储接口时,需要明确规定数据的读写方法、参数类型和返回值类型等。

数据结构的选择也是软件设计中的一个关键决策。

不同的数据结构适用于不同的场景,选择合适的数据结构能够提高软件的性能和效率。

例如,对于频繁插入和删除操作的场景,链表可能是一个更好的选择;而对于快速查找操作,二叉搜索树或者哈希表可能更为合适。

软件工程第三章需求应用全面分析

软件工程第三章需求应用全面分析

结构化英语、判定树、判定表用于描述数据流 图中的处理逻辑说明。
• SA方法的实质*:是采用一组分层数据流图及数据
字典作为系统的模型,从总体来看,是一种依赖数
据流图的自顶向下的建模方法。
2020/11/25
5
数据流图:分层扩展的功能模

数据流图(DFD)是SA方法中用于建立系统逻辑模型 的一种工具,它以图形的方式描绘数据在系统中处理的流 动过程。由于它只反映系统需要完成的逻辑功能,所以它 是一种功能模型。*
配件库存
顾客
订货单 发货单
1
处理 业务Biblioteka 订货单 发货单供应 商
2020/11/25
15
数据流图: DFD绘制步骤(续)
* (2)再绘制二层DFD:是顶图的分解,表明子系统划分及其 边界。 • 系统划分几个子系统,一个子系统在二层图中只有一个处理逻辑(需
求来源是业务子系统或用例图中的用例); • 每一子系统析取所有的外部项、输入输出数据流和主要数据存储; • 各子系统之间的依赖关系(数据流直接依赖,数据存储缓存依赖)。
软件工程 Software Engineering
第三章 需求应用全面分析
2020/11/25
1
本章主要内容
• 3.1 软件需求概念
-软件需求的问题、定义、层次、来源、依据、目标
• 3.2 需求工程过程
- 需求开发:需求获取、需求分析、规格说明、需求验证 - 需求管理:覆盖需求开发全过程
• 3.3 需求获取技术
数据存储可以是一个文件,也可以是文件的一部分或 数据库记录的一部分。数据可以存储在磁盘、磁带、存储 器等任何介质上。指向数据存储的箭头可以是单向的,也 可以是双向的。

《软件工程》第3章用例图及其应用

《软件工程》第3章用例图及其应用
《软件工程建模工具,能够帮助我们更好地理解系统需求 和功能。本章介绍用例图的概念、基本元素、符号表示方法以及应用场景。
用例图的概念和作用
用例图是一种描述系统功能和用户行为的图形化工具。它帮助开发人员和利 益相关者理解系统的需求,并作为沟通和验证的工具。用例图能够直观地展 示系统功能,帮助识别系统的边界和行为。
用例图的基本元素
用例图包含参与者、用例和关系三个基本元素。参与者代表系统的外部角色, 用例代表系统的功能或服务,而关系则表示参与者和用例之间的交互和依赖 关系。
用例图的符号和表示方法
用例图使用参与者图标、椭圆形表示的用例以及连接线表示关系。参与者图标通常表示为人的图 标,用例图标则是一个椭圆形,并用文字描述用例的名称。
用例图在软件工程中的重要性
用例图在软件工程中起到了至关重要的作用。它不仅帮助开发人员了解系统 需求和功能,还能够引导需求分析和测试的工作,并作为可视化的沟通工具, 促进不同角色之间的合作交流。
结论
用例图作为软件工程中常用的建模工具,具有直观、易理解的特点。通过用例图,我们能够更好 地理解和沟通系统需求,提高系统开发的质量和效率。
用例图的绘制步骤
绘制用例图的步骤包括:确定系统的边界和参与者、识别系统的用例、绘制参与者和用例的图标、 添加关系和标注信息、进行审查和验证。
用例图的应用场景
用例图在软件工程中有广泛的应用场景,例如需求分析、系统设计、测试规 划等。通过用例图,开发人员和利益相关者能够共同理解系统功能和用户需 求,从而有效地进行软件开发。

软件工程第三章

软件工程第三章

SIT
3)着重强调的是数据流程而不是控制流程。
数据流程图中的基本符号有: 1、数据流
数据流是有名字有流向的数据,在数据流程图中,数据 流用标有名字的箭头来表示。
3.5 需求分析方法
2、加工 加工又称处理逻辑,表示数据所进行的加工或变换,以 标有名字的圆圈代表加工。指向加工的数据流是该加工的输 入数据,离开加工的数据流是该加工的输出数据。 3、文件
SIT
3.1 概述
目标系统的逻辑模型:分析当前系统与目标系统逻辑上 的差别,明确目标系统要“做什么”的实质工作,从当前系 统的逻辑模型导出目标系统的逻辑模型。 目标系统的物理模型:确定待开发系统的系统元素,将 功能和数据结构分配到系统元素中。它的具体物理模型则是 由它的逻辑模型经实例化后,具体到某个业务领域得到的。
3.3.2用户需求
用户需求是从用户角度来描述系统功能和非功能需求, 以便让不具备专业技术方面知识的用户能看懂。这样的需求 描述只描述系统的外部行为,要尽量避免对系统设计特性的 描述。
3.3 软件需求分析类型
3.3.3系统需求
系统需求是比用户需求更详细的需求描述,是系统实现 的基本依据,因此,是一个完全的和一致的系统描述,是软 件工程人员系统设计的起点。 自然语言时常被用来书写系统需求描述,但被用来做更 详细的描述时,深层次的问题就暴露出来,主要有:
3.5 需求分析方法
3.建立行为模型 分析建模是实现真实世界模型向计算机模型转换的核心 环节,也是一种处理软件复杂性的有效手段。在需求开发阶 段,分析建模的关键是针对用户需求建立抽象的分析模型, 从而有助于开发人员理解用户需求,同时增强自然语言的需 求规格说明。分析模型往往采用一些图形化的表示方式,从 数据、功能和行为等不同角度表达用户需求。

《软件工程》第3章用例图及其应用

《软件工程》第3章用例图及其应用
用例与参与者之间存在关联关系,表示参与者可以参与用例的执行。这种关系有助于明确系统的边界和 交互方式。
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一,它能 够帮助开发团队更好地理解用户需求,明确系统 的功能范围。
2
通过用例图,开发团队可以对系统的交互方式进 行模拟和验证,从而发现潜在的问题和缺陷,提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中,保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率,确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例,可以找出未被测 试到的功能和业务流程,从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率,降低 漏测的风险。
02
针对每个测试场景,细化出具体的测试用例,包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求,从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程,为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系, 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物,它描 述了用户期望的系统功能和行为。
02 在系统设计完成后,可以通过与原始用例图进行 对比,验证设计是否满足原始需求。
03 如果设计不符合原始需求,则需要重新调整设计, 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03

软件工程第三章需求工程

软件工程第三章需求工程

软件工程第三章需求工程在软件工程中,需求工程是至关重要的一环。

它就像是一座建筑的蓝图,为后续的设计、开发、测试等工作指明了方向。

如果需求工程做得不好,就好比在没有清晰规划的情况下盲目施工,结果必然是混乱和低效的。

需求工程主要包括需求获取、需求分析、需求规格说明和需求验证这几个关键步骤。

需求获取是需求工程的起点。

这可不是一件简单的事情,它需要与各种利益相关者进行有效的沟通和交流。

这些利益相关者可能包括客户、用户、业务经理、技术专家等等。

他们对于软件系统的期望和需求各不相同,因此获取到全面、准确的需求信息是一个挑战。

在与利益相关者交流时,我们需要运用各种技巧。

比如,倾听是非常重要的。

要让他们能够畅所欲言,表达出自己的真实想法和需求。

同时,提问也是必不可少的。

通过有针对性的问题,可以引导他们深入思考,挖掘出一些潜在的需求。

此外,观察他们的工作流程和操作习惯,也能为获取需求提供有价值的线索。

需求分析是对获取到的需求进行深入理解和梳理的过程。

这就像是把一堆杂乱无章的拼图碎片整理成一幅完整的画面。

我们需要识别出需求中的关键元素,理解它们之间的关系,并且找出可能存在的冲突和不一致。

为了进行有效的需求分析,我们常常会使用一些工具和技术。

比如,用例图可以帮助我们清晰地描述系统的功能和用户与系统之间的交互。

数据流图则能够展示数据在系统中的流动和处理过程。

状态转换图可以用于描述系统中对象的状态变化。

通过这些工具,我们能够更直观地理解需求,发现潜在的问题。

需求规格说明是将分析后的需求以一种清晰、准确、无歧义的方式记录下来。

它就像是一份合同,明确了软件系统应该具备的功能和性能。

需求规格说明通常包括功能需求、非功能需求、约束条件等内容。

功能需求描述了系统应该完成的具体任务和操作。

非功能需求则关注系统的性能、可靠性、可维护性、安全性等方面的要求。

约束条件可能包括技术限制、预算限制、时间限制等。

在编写需求规格说明时,语言要简洁明了,避免使用模糊不清的词汇和语句。

软件工程第三章习题及参考答案

软件工程第三章习题及参考答案

第三章习题及参考答案1、用逐步求精方法解决下述得更新顺序主文件得问题。

美国某杂志社需要一个软件,以更新存有该杂志订户姓名、地址等数据得顺序主文件。

共有插入、修改与删除等3种类型得事务,分别对应于事务代码1、2与3。

也就就是说,事务类型如下:类型1:INSERT(插入一个新订户到主文件中)类型2:MODIFY(修改一个已有得订户记录)类型3:DELETE(删除一个已有得订户记录)事务就是按订户名字得字母顺序排序得。

如果对一个订户既有修改事务又有删除事务,则已对那个订户得事务排好次序了,以便使修改发生在删除之前。

2.分析图3、1所示得层次图,确定每个模块得内聚类型。

3.分析图3、2,确定模块之间得耦合类型。

在图3、2中已经给模块之间得接口编了号码,表3、1描述了模块间得接口。

4、假设您在一所职业高中工作,负责该校信息系统得建设与维护。

财务科长请您研究用学校拥有得微型计算机生成工资明细表与各种财务报表得可能性。

请详细描述您用结构化分析方法分析上述问题得过程。

用面向数据流方法设计工资支付系统得软件结构。

5.用3种方法计算图3、3所示流图得环形复杂度。

6、图3、4就是用程序流程图描绘得程序算法,请把它改画为等价得盒图。

7、某交易所规定给经纪人得手续费计算方法如下:总手续费等于基本手续费加上与交易中得每股价格与股数有关得附加手续费。

如果交易总金额少于1000元,则基本手续费为交易金额得8、4%;如果交易总金额在1000元到10000元之间,则基本手续费为交易金额得5%,再加34元;如果交易总金额超过10000元,则基本手续费为交易金额得4%加上134元。

当每股售价低于14元时,附加手续费为基本手续费得5%,除非买进、卖出得股数不就是100得倍数,在这种情况下附加手续费为基本手续费得9%。

当每股售价在14元到25元之间时,附加手续费为基本手续费得2%,除非交易得股数不就是100得倍数,在这种情况下附加手续费为基本手续费得6%。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
36
§4. 实体-联系图
所谓复合信息是指具有 一系列不同性质或属性 的事物,因此,仅有单 个值的事物(例如宽度) 不是数据对象。
1. 数据对象:是对软件必须理解的复合信息的表 示。在ER图中用矩形框代表实体。
2. 联系:数据对象彼此之间相互连接的方式称为联 系,也称为关系。联系可分为以下三类: (1)一对一联系(1∶1) (2)一对多联系(1∶N) (3)多对多联系(M∶N)
情景分析的用处:
● 它能在某种程度上演示产品的行为,从而便于用 户理解,而且还可能进一步揭示出一些系统分析员 目前还不知道的需求。
● 由于情景分析较易为用户所理解,因此,使用这 种技术能保证用户在需求分析过程中始终扮演一个 积极主动的角色。
24
§ 2 与用户沟通的方法
2. 面向数据流自顶向下求精
(1)沿数据流图回溯:数据流图的输出端是系 统的最终目的。向回确定每个数据元素的来 源,可加细数据流图及数据字典,并将相关 算法记录在IPO图中。
4、修正系统开发计划
根据在分析过程中获得的对系统的更深 入更具体的了解,可以比较准确地估计系统 的成本和进度,修正以前制定的开发计划。
§ 2 与用户沟通的方法
1.访谈
正式访谈:系统分析员将提出一些事先准备好的 具体问题。 非正式访谈:分析员将提出一些用户可以自由回 答的开放性问题,以鼓励被访问人员说出自己的 想法。 调查表:当需要调查大量人员的意见时,向被调 查人员分发调查表是一个十分有效的做法。经过 仔细考虑写出的书面回答可能比被访问者对问题 的口头回答更准确。
编号
提出问题
7 您的部门需要成本核算和统计的内容有哪些?
8 您的部门采用计算机管理工作情况如何?
9 如何改进业务流程使之更合理?
10 哪些问题是目前传统手工方法根本无法解决的?
11 出版社计算机管理信息系统需要解决什么问题?
§ 2 与用户沟通的方法
情景分析技术—就是对用户运用目标系统 解决某个具体问题的方法和结果进行分析。
2.1 软件需求的概念
个人能力或经验不足 软件组织的能力不足
需求分析
需求分析
困难:
片面性, 不完全
模糊性, 不准确 不一致性, 易于发生变动等等 应用系统复杂,庞大
因此必须使用系统的方法、借助于一系列行之 有效的技术和工具进行需求分析。
13
准 则:
(1) 必须理解并描述问题的信息域,根据这条准则 应该建立数据模型。
快速原型就是快速建立起来的旨在演示 目标系统主要功能的可运行的程序。构建原 型的要点是,它应该实现用户看得见的功能 (例如,屏幕显示或打印报表),省略目标系 统的“隐含”功能(例如,修改文件)。
30
§ 2. 与用户沟通的方法
为了快速地构建和修改原型,通常使用下述3 种方法和工具:
(1) 第四代技术 (2) 可重用的软件构件 (3) 形式化规格说明和原型环境
通常用自然语言完整、准确、具体地描述系统的数 据要求、功能需求、性能需求、可靠性和可用性要 求、出错处理需求、接口需求、约束、逆向需求以 及将来可能提出的要求。自然语言的规格说明具有 容易书写、容易理解的优点,为大多数人所欢迎和 采用。
SRS的作用:开发者与用户间事实上的技术合同书;开发者 下一步设计和编码的基础;测试验收目标系统的依据。
13.1% 不完整的产品要求; 12.4% 缺乏用户的参与; 10.6% 缺少资源(人力、财力); 9.9% 不现实的期望; 9.3% 高层领导支持不足; 8.7% 产品要求与指标的改变; 8.1% 没有订计划; 7.5% 不再需耍该开发中的系统。 其中,与产品需求有关的(1,2,4和6项)占了44.1%。这些数5 据突出地显示了软件产品需求在软件开发中的重要性。
28
面向团队的需求收集法: (用户与开发者配合) 1)初步访谈; 2)开发者和用户分别写出“产品需求”; 3)开会讨论,各自展示需求列表; 4)得出一致意见,为需求列表制定小型规格说明; 5)根据会议成果,起草完整的软件需求规格说明。
29
§ 2. 与用户沟通的方法
特性1:快速
4. 快速建立软件原型 特性2:容易修改
等需求。 (3)可靠性和可用性需求:系统的可靠性以及用户可以
使用系统的程度。 (4)出错处理需求:说明系统对环境错误应该怎样响应。
15
§1. 需求分析的任务
§1. 需求分析的任务
(5)接口需求:描述应用系统与它的环境通信的格式。 如:用户接口需求,硬件接口需求,软件接口需 求,通信接口需求。
(6)约束:描述设计或实现应用系统时应遵守的限制条 件。
6
需求分析的重要性
– 需求错误是可以被检查出来的
7
参与需求分析的人有哪些,场所在哪
• 参与需求分析的人
– 系统分析师、需求阐释者、客户代表、用户代表、 开发方领导、项目经理、架构设计师、领域专家、 财务人员、市场人员、软件质量保证(SQA, Software Quality Assure)人员、程序员、测试人 员、部署人员、技术文档编写人员、培训人员等。
(7)逆向需求:说明软件系统不应该做什么。
(8)将来可能提出的要求:列出根据分析得到的将来可 能会提出的要求,易于后期进行扩充和修改。
16
2、分析系统的数据要求
任何一个软件系统本质上都是信息处理 系统,系统必须处理的信息和系统应该产 生的信息在很大程度上决定了系统的面貌 ,对软件设计有深远影响,因此,必须分 析系统的数据要求,这是软件需求分析的 一个重要任务。分析系统的数据要求通常 采用建立数据模型的方法(见3.4节)。
§4. 实体-联系图
为了把用户的数据要求清晰明确地表达出来, 系统分析员通常建立一个概念性的数据模型(也 称为信息模型)。概念性数据模型是一种面向问 题的数据模型,是按照用户的观点来对数据和信 息建模。它描述了从用户角度看到的数据,它反 映了用户的现实环境,且与在软件系统中的实现 方法无关。
最常用的表示概念性数据模型的方法,是实体联系方法(Entity-Relationship Approach)。
26
有补充 修正
需要 分解
分析追踪 数据流图
用户复查
无补充修正
细 化 不需分解 数据流图
27
§ 2. 与用户沟通的方法
3. 简易的应用规格说明技术
传统访谈技术用户和开发者往往会区分“我们和他
们”
面向团队的需求收集法
这种方法提倡用户与开发者密切合作, 共同标识问题,提出解决方案的要素,商讨 不同的方法并指定基本的需求。
软件系统经常使用各种长期保存的信息,这些信 息通常以一定方式组织并存储在数据库或文件中, 为减少数据冗余,避免出现插入异常或删除异常, 简化修改数据的过程,通常需要把数据结构规范化 (见3.5节)。
3、导出系统的逻辑模型
综合上述两项分析的结果可以导出系统的 详细的逻辑模型,通常用数据流图、实体-联 系图、状态转换图、数据字典和主要的处理 算法描述这个逻辑模型。
实体关系图(ER):数据建模的基础,描 述数据对象及其关系;
数据流图(DF):功能建模的基础,描述 数据怎样转换以及转换的功能;
状态转换图(ST):行为建模的基础,表
示系统的各种行为状态以及状态间的转换方
式。
34
软件需求规格说明书(SRS)
软件需求规格说明书(Software Requirement Specification)是需求分析阶段得出的最主要的文 档。是软件开发、软件验收和管理的根据。
需求分析的重要性
– 在需求过程中会产生很多错误 • DeMarco在一份研究报告中指出,被检查出 来的错误的56%产生的根源可以追溯到需求 阶段。 • AIRMICS所进行的一项调查发现,在一份美 国军方大型管理信息系统的需求规格说明书 (SRS)中存在着500多个错误,当然这仅仅是 一个软件项目中的一次调查。
(2) 必须定义软件应完成的功能,这条准则要求建 立功能模型。
(3) 必须描述作为外部事件结果的软件行为,这条 准则要求建立行为模型。
(4) 必须对描述信息、功能和行为的模型进行分解 ,用层次的方式展示细节。
§1. 需求分析的任务
§1. 需求分析的任务
1、确定对系统的综合要求
(1)功能需求:系统必须完成的功能 (2)性能需求:通常包括响应时间,磁盘容量,安全性
• 需求分析的场所
– 调研时,在客户现场
– 编写软件需求文档时,可以在开发单位
– 复审相关的需求文档时,根据需要来安排
2.1 软件需求的概念
软件需求分析的困难
(1)客户说不清楚需求 • 有些客户对需求只有朦胧的感觉,当然说不清楚具
体的需求。
• 有些客户心里非常清楚想要什么,但却说不明白。
• “不懂装懂”或者“半懂充内行”的客户令人恐惧 。
2.1 软件需求的概念
软件需求的复杂性
(2)需求自身经常变动
需求变更原因--客户方: 对信息系统的了解不够 对业务需求表达不清 对自身业务抽象程度不够
对需求重视程度不够 与开发人员配合不够
业务范围不断拓展 业务流程不断变更 管理模式不断创新
客户的能力不足,可以进行适 当的培训,可改善一点。
属于态度问题,需要高层领导 协调。
某出版社系统调查表
编号
提出问题
1 您在哪个部门工作?
2 出版业务流程是什么?
3 您每日都处理那些文件、数据、报表?
4 工作中手工处理特别麻烦的事情是什么?
5 工作中手工处理什么问题解决不了?影响效率的问题有哪 些?
6 您认为提高工作效率,节省工作时间,减轻工作强度可采 取哪些办法?
某出版社系统调查表
软件工程
---第3章 需求分析
1
软件需求分析:“做什么?”
◆基本任务:系统必须做什么? ◆确定系统必须完成哪些工作,也就是对 目标系统提出完整、准确、清晰、具体的 要求。 ◆写软件需求规格说明书,以书面形式准 确地描述软件需求。
相关文档
最新文档