软件工程第三章
合集下载
自考软件工程第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章 软件需求分析
–多个来回
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
有了对投入成本和效益的估算，就可以评价投资的价值了。一般来说，投资 收益主要的评价指标有以下几项： 投资回收期 投资回收期是指所开发的软件投入运行或者进行销售后，多长时间 能够全部收回投资。一旦收回投资，以后的收入就是纯收入；而在收回 投资之前的时间，对项目本身来说都是负债经营的。 任何一个应用软件项目都有一定的预期寿命，软件运行一定时间之 后，必然会因为跟不上技术的进步和应用的要求而被淘汰，被废弃。由 于激烈的市场竞争，商品软件的寿命会更短。因此，投资回收期是一个 软件项目投资的重要经济指标， 越早收回投资， 也就越早能够开始盈利， 在整个软件的生命周期中也能够获得越多的效益。如果投资回收期超过 了软件的预期寿命，那就是一个失败的投资。 纯收入 纯收入是软件在整个生命周期中得到的收益（注意：收益应当是考 虑了货币的时间价值后折合成现值的收益） 与开发这个软件的投入之差。 如果没有纯收入，因为投入开发是有风险的，因此也不应该实施这个项 目。纯收入首先必需能够对投资者的风险进行补偿。为了比较不同投资 项目之间的收益情况，还应该使用投资收益率，即纯收入与投入之比来 表示单位投入能够产生的效益。 投资回收率 投资回收率表示的是单位时间内单位投入能够产生的效益，它能够 更准确地体现出投资于一个项目的效益，并且可以与同样的资金进行别 的投资的收益进行比较。对于投资回收率，可以按照投资利息的方式来 理解。也就是说，投资回收率相当于我们将资金投入软件项目后，单位 时间（一般是年）可以得到的利率。计算投资回收率可以使用以下的方 程。
Hale Waihona Puke 第三章 生命周期方法学一、 生命周期方法学的阶段划分
生命周期方法学是最传统也是最经典的软件开发方法学， 它严格按照软件生 命周期的阶段划分将软件开发过程划分为多个阶段：软件定义划分为问题定义、 可行性研究、需求分析三个阶段，软件开发划分为总体设计、详细设计、编码实 现、综合测试四个阶段，再加上软件维护阶段。 用图表表示即为： 问题定义 软件定义 可行性研究 需求分析 软件开发
P
F ，F 是 n 年后的收入，P 是折算为当前收入 (1 i ) n
有了对投入成本和效益的估算，就可以评价投资的价值了。一般来说，投资 收益主要的评价指标有以下几项： 投资回收期 投资回收期是指所开发的软件投入运行或者进行销售后，多长时间 能够全部收回投资。一旦收回投资，以后的收入就是纯收入；而在收回 投资之前的时间，对项目本身来说都是负债经营的。 任何一个应用软件项目都有一定的预期寿命，软件运行一定时间之 后，必然会因为跟不上技术的进步和应用的要求而被淘汰，被废弃。由 于激烈的市场竞争，商品软件的寿命会更短。因此，投资回收期是一个 软件项目投资的重要经济指标， 越早收回投资， 也就越早能够开始盈利， 在整个软件的生命周期中也能够获得越多的效益。如果投资回收期超过 了软件的预期寿命，那就是一个失败的投资。 纯收入 纯收入是软件在整个生命周期中得到的收益（注意：收益应当是考 虑了货币的时间价值后折合成现值的收益） 与开发这个软件的投入之差。 如果没有纯收入，因为投入开发是有风险的，因此也不应该实施这个项 目。纯收入首先必需能够对投资者的风险进行补偿。为了比较不同投资 项目之间的收益情况，还应该使用投资收益率，即纯收入与投入之比来 表示单位投入能够产生的效益。 投资回收率 投资回收率表示的是单位时间内单位投入能够产生的效益，它能够 更准确地体现出投资于一个项目的效益，并且可以与同样的资金进行别 的投资的收益进行比较。对于投资回收率，可以按照投资利息的方式来 理解。也就是说，投资回收率相当于我们将资金投入软件项目后，单位 时间（一般是年）可以得到的利率。计算投资回收率可以使用以下的方 程。
《软件工程》第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.1.4 需求分析的过程
分析与综合 从信息流和信息结构出发,逐步细化所有的软件功能, 从信息流和信息结构出发,逐步细化所有的软件功能,找 出系统各元素之间的关联,接口特性和设计上的约束, 出系统各元素之间的关联,接口特性和设计上的约束,分 析它们是否满足功能要求,是否合理. 析它们是否满足功能要求,是否合理.剔除其不合理的部 增加其需要部分.最终综合成系统的解决方案, 分,增加其需要部分.最终综合成系统的解决方案,给出 目标系统的详细逻辑模型. 目标系统的详细逻辑模型. 常用的分析方法 面向数据流的结构化分析方法 面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对象的分析方法 面向对象的分析方法 (OOA) 等
16
3.2.1 需求获取技术
需求调查对象 对组织的高层管理者, 对组织的高层管理者,进行组织管理目标或经营方针等 组织战略问题的调查 对中层的管理者, 对中层的管理者,进行全部业务流的调查 对业务工作人员, 对业务工作人员,进行详细业务信息的调查 市场调查 了解市场对待开发软件有什么样的要求; 了解市场对待开发软件有什么样的要求;了解市场上有 无与待开发软件类似的系统 考察现场 了解用户实际的操作环境,操作过程和操作要求. 了解用户实际的操作环境,操作过程和操作要求.对照用 户提交的问题陈述,对用户需求可以有更全面, 户提交的问题陈述,对用户需求可以有更全面,更细致的 认识. 认识. 观察用户工作流程 用户和开发人员共同组成联合小组
具体化 表 达 需 求
3
目标系统
物理模型
实例化
逻辑模型
软件工程 第3章需求分析
名字：定货报表 别名：定货信息 描述：每天一次送给采购员的 逐一确定 需要定货的零件表 元素的来 定义：定货报表 = 零件编号 +零件名称+ 源 定货数量+目前价格+主要供应 商+次要供应商
位置：定货报告 定货信息 库存清单
面向数据流方法的分析的应用
6 D1 库存清单 事务 1 包含零件编 号、名称、 目前价格
深入调查
外部输入或系 统生成
3.2.2 面向数据流的自顶向下求精
• 回溯时常遇到的问题：为了得到某个数据元素需要 用到数据流图中还没有的数据元素，或者得出这个 数据元素要用的算法尚不完全清楚。 • 因此，需要向用户等有关人员请教，他们的回答使 分析员对目标系统的认识更深入具体，系统中更多 的数据元素被划分出来，更多的算法搞清楚了。 • 把分析过程中得到的有关数据元素的信息记录在数 据字典中，把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位置上。
• 主要目标：把数据流和数据存储定义到元 素级别（不可分解为止）
数据的来源、去 向、数据结构定 义等
可行性 分析忽 略了细 节
3.2.2 面向数据流的自顶向下求精
自顶向下，逐 层细化的方法
• 结构化分析方法是一种什么方法呢？ • 从数据流图的输出端着手分析，这是因为系 统的基本功能是产生这些输出的关键原因。 • 输出数据决定了系统必须具有的最基本的组 成元素（包括功能和数据结构组成）。
3.4.1 数据对象
• 它的范畴很大，可以是外部实体(例如，产生 或使用信息的任何事物)、事物(例如，报表)、 行为(例如，打电话)、事件(例如，响警报)、 角色(例如，教师、学生)、单位(例如，会计 科)、地点(例如，仓库)或结构(例如，文件) 等。 • 总之，可以由一组属性来定义的实体都可以 被认为是数据对象。
位置：定货报告 定货信息 库存清单
面向数据流方法的分析的应用
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 需求获取技术
数据存储可以是一个文件，也可以是文件的一部分或 数据库记录的一部分。数据可以存储在磁盘、磁带、存储 器等任何介质上。指向数据存储的箭头可以是单向的，也 可以是双向的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 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
软件需求分析：“做什么？”
◆基本任务：系统必须做什么? ◆确定系统必须完成哪些工作，也就是对 目标系统提出完整、准确、清晰、具体的 要求。 ◆写软件需求规格说明书，以书面形式准 确地描述软件需求。
§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
软件需求分析：“做什么？”
◆基本任务：系统必须做什么? ◆确定系统必须完成哪些工作，也就是对 目标系统提出完整、准确、清晰、具体的 要求。 ◆写软件需求规格说明书，以书面形式准 确地描述软件需求。