第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中数据流的定义，通常列出该数 据流的各组成数据项。
软件工程中的需求分析与建模
● 03
第3章 需求建模技术
需求建模概述
需求建模是软件工程中的一个重要环节，通过对需求 进行建模，可以更清晰地理解和定义系统需求。需求 建模的目的是为了准确地捕获用户需求，确保软件开 发过程中不会遗漏任何重要需求。同时，需求建模还 可以帮助团队更好地沟通和协作，提高项目的成功率。
用例建模
用例是描述系统功能的一种有效方式。通过用 例建模，可以清晰地定义系统的功能和用户与 系统之间的交互。用例图可以直观地展示系统 的功能和不同用户角色之间的交互关系。用例 描述则详细描述了每个用例的具体行为和步骤。
意度。
需求变更频繁
导致开发过程混乱
需求不明确
影响产品质量
沟通不畅
导致需求误解
面临的挑战
可能的改进方向
采用敏捷开发模式
迭代开发 持续集成 快速反馈
加强需求管理
建立需求数据库 制定明确需求文档 实施变更控制
提高沟通效率
定期沟通会议 使用协同工具 建立需求反馈渠道
展望未来
未来在软件工程领域，人工智能技术的发展将为需求 分析带来更多可能性，大数据技术的应用将提升需求 建模的精度，需求管理工具的不断创新将提高团队效 率。
测试
单元测试 集成测试
软件工程发展历程
软件工程的发展经历了多个阶段，从最初的混沌时期 到逐渐建立起规范的软件开发流程和方法。随着科技 的不断进步，软件工程也在不断演变和完善。
● 02
第二章 需求分析基础
需求分析概述
需求分析是软件工程中至关重要的一部分，它 涉及定义、识别和规范软件开发项目中的需求。 通过需求分析，可以确保开发团队在项目开始 阶段清晰了解客户的需求，明确目标和方向。 需要对需求进行系统性的分析，以确保最终的
软件工程导论-第3章_需求分析_(第五版)(张海藩编著)_a_百度文库
求互相矛盾。
(2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的
每一个功能或性能。
(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本
上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步 则很难做出预测，只能从现有技术水平出发判断需求的现实性。
(4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的
成功来之不易
31%
（取消）
16.2%
（成功地完成）
53.8%
（受到挑战） Source: Standish Group
2
软件项目失败的原因
软件项目失败的最重要的五个主要原因：
需求不完整 缺少客户的参与 缺少资源 期望值过高 缺少高层的支持
0% 5% 10% 15%
3
需求错误的成本
4
软件需求的重要性： •软件需求分析是决定软件成功开发的一个关键因素
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体 的了解，可以比较准确地估计系统的成本和进度，修 正以前制定的开发计划。
补充：与用户沟通获取需求的方法
3.2 与用户沟通获取需求的方法
需求获取的困难：
－用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求，开发人员缺乏相关 的领域知识和经验，难以准确理解这些需求 －不同的用户提出不同的需求，可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 －由于经济和业务环境的动态性，需求经常发生变更
图3.7 IPO图的一个例子图
模块编号:c.5.5.8
图3.7 IPO图的一个例子图
图3.8 改进的IPO图的形式
本书建 议使用 一种改 进的 IPO图 (也称 为IPO 表 )，
(2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的
每一个功能或性能。
(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本
上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步 则很难做出预测，只能从现有技术水平出发判断需求的现实性。
(4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的
成功来之不易
31%
（取消）
16.2%
（成功地完成）
53.8%
（受到挑战） Source: Standish Group
2
软件项目失败的原因
软件项目失败的最重要的五个主要原因：
需求不完整 缺少客户的参与 缺少资源 期望值过高 缺少高层的支持
0% 5% 10% 15%
3
需求错误的成本
4
软件需求的重要性： •软件需求分析是决定软件成功开发的一个关键因素
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体 的了解，可以比较准确地估计系统的成本和进度，修 正以前制定的开发计划。
补充：与用户沟通获取需求的方法
3.2 与用户沟通获取需求的方法
需求获取的困难：
－用户通常并不真正知道自己希望计算机系统做什么 用户通常使用业务语言表达需求，开发人员缺乏相关 的领域知识和经验，难以准确理解这些需求 －不同的用户提出不同的需求，可能存在矛盾和冲突 管理者可能出于增加影响力的原因而提出特别的需求 －由于经济和业务环境的动态性，需求经常发生变更
图3.7 IPO图的一个例子图
模块编号:c.5.5.8
图3.7 IPO图的一个例子图
图3.8 改进的IPO图的形式
本书建 议使用 一种改 进的 IPO图 (也称 为IPO 表 )，
软件工程PPT课件第3章 软件需求分析
5
理
D5 订单表
订单49
1. 数据流图的四个基本成分
2
或
2
数据处理(加工) 数据流（数据对象）
或
II
数据存储 (文件或数据库）
2
或
位于被建模系统之外的信息生 产者或消费者,称为外部项。 说明数据输入的源点(数据源) 或数据输出的汇点(数据池)
50
2. DFD各成分的作用和 命名注意事项
数据流
表示数据和数据流向
抽象出当前系统的逻辑模型
购 书 申 学请
购
生
审查 有效性
书 单
开发票
发 票
开领 书单
领 书 单 发书
书
学 生
学生购买教材的逻辑模型
35
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
36
计算机售书系统的逻辑模型
28
(10) 软件成本消耗 与开发进度需求
开发有规定的时间表吗？
软硬件投资有无限制？
29
(11) 质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？
规定系统平均出错时间？
出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
4
需求分析的任务和步骤
需求分析的任务
建立分析模型 编写需求说明
需求分析的步骤
问题分析
需求描述
需求验证（评审）
5
需求获取的常用方法
第3章 需求分析-软件工程案例教程(第2版)-李军国-清华大学出版社
6
可行性研究的任务和目的
➢ 用最小的代价在尽可能短的时间内确 定问题是否能够解决。
➢ 确定问题是否能够解决和值得解决。 ➢ 分析可能的利弊关系。
➢ 对行动方针提出建议（是否可行）。
7
可行性研究的时间与成本
➢ 可行性研究实质上是在较高层次上以抽 象方式进行系统分析和设计的过程。
➢ 可行性研究需要的时间长短取决于工程 的规模。
仔细阅读和分析有关的材料，改正含糊或不正确的叙述， 清晰的描述目标系统。
➢ 识别用户的真正要求?（访问关键人员） ➢技术现状如何？ （系统调研） ➢系统配置如何？ （分析有关的材料） ➢系统维护能力如何？ （系统调研） ➢ 系统配置与外部环境的接口什么样？（限制和约束） ➢ 技术上的风险有哪些？ ➢ 是否具备技术资源？ ➢ 开发人员是否得到培训？ ➢ 是否存在法律责任和政治风险？
21
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解业务活动状况，特别是活动要点的分析。 ➢ 明确这些要点间什么在流动，如何流动。 ➢ 对物理流量进行分析。 ➢ 模型化，得到实际业务系统的物理模型。
22
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解系统应解决的问题是什么？ ➢ 这些问题是如何提出的？ ➢ 了解问题的结构。 ➢ 这些问题如何解决才能满足用户的要求？
17
案例： （库存管理）
找出问题
➢不能及时获得库存信息 ➢库存信息不够准确 ➢无法及时了解车间对库存商品的需求情况
18
系统分析过程
① 分析现实世界，充分理解当前系统，并用一个具体模 型描述，获得当前系统的物理模型。
可行性研究的任务和目的
➢ 用最小的代价在尽可能短的时间内确 定问题是否能够解决。
➢ 确定问题是否能够解决和值得解决。 ➢ 分析可能的利弊关系。
➢ 对行动方针提出建议（是否可行）。
7
可行性研究的时间与成本
➢ 可行性研究实质上是在较高层次上以抽 象方式进行系统分析和设计的过程。
➢ 可行性研究需要的时间长短取决于工程 的规模。
仔细阅读和分析有关的材料，改正含糊或不正确的叙述， 清晰的描述目标系统。
➢ 识别用户的真正要求?（访问关键人员） ➢技术现状如何？ （系统调研） ➢系统配置如何？ （分析有关的材料） ➢系统维护能力如何？ （系统调研） ➢ 系统配置与外部环境的接口什么样？（限制和约束） ➢ 技术上的风险有哪些？ ➢ 是否具备技术资源？ ➢ 开发人员是否得到培训？ ➢ 是否存在法律责任和政治风险？
21
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解业务活动状况，特别是活动要点的分析。 ➢ 明确这些要点间什么在流动，如何流动。 ➢ 对物理流量进行分析。 ➢ 模型化，得到实际业务系统的物理模型。
22
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解系统应解决的问题是什么？ ➢ 这些问题是如何提出的？ ➢ 了解问题的结构。 ➢ 这些问题如何解决才能满足用户的要求？
17
案例： （库存管理）
找出问题
➢不能及时获得库存信息 ➢库存信息不够准确 ➢无法及时了解车间对库存商品的需求情况
18
系统分析过程
① 分析现实世界，充分理解当前系统，并用一个具体模 型描述，获得当前系统的物理模型。
软件工程导论第讲义3章需求分析
- 后台处理流程： 建模！解释后台处理的逻辑。 模型是用户方面的技术人员。好的模型对于系 统的扩展和改变至关重要。
2 原型法处理界面设计问题
在不少项目中，一旦用户对界面挑剔起来将会花 费大量时间。因此，在原型阶段，就应包括界面 设计的原则。从界面风格，易用性，友好化，用 户习惯等多方面达成一定规定，会对程序员在界 面设计上节省大量时间。
1 界面处理流程和后台业务处理流程是否正确。
- 界面处理流程： 界面是指用户面对的界面。 用户只有看到具体的软件界面，才会形成感性 的知识，才能对开发的系统提出具体要求，和 进一步的改进需求。才能理解我们推荐的解决 方案。另一方面，这也是检验PM对用户需求的 理解是否正确，能否做出符合要求的产品。
例如：大多数的动态网站，都是在客户初步的 需求基础上，先制作一个大体上能表现功能的 静态网站出来，然后客户根据这个静态网站提 出进一步的详细需求，开发便按照这个详细需 求来进行。
为了快速地构建和修改原型，通常使用下述3 种方法和工具：
(1) 第四代技术
第四代技术包括众多数据库查询和报表语言、 程序和应用系统生成器以及其他非常高级的 非过程语言。第四代技术使得软件工程师能 够快速地生成可执行的代码，它们是较理想 的快速原型工具。
3.1.3 软件需求分析的任务
一、综合需求
需求分类
功能需求 性能需求 环境需求
(1) 功能需求
• 系统做什么？ • 系统何时做什么？ • 系统何时及如何修改或升级？
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
(3) 环境需求
• 硬件设备：机型、外设、接口、
优点：经济、易于管理；
可以快速将结果制表并分析
2 原型法处理界面设计问题
在不少项目中，一旦用户对界面挑剔起来将会花 费大量时间。因此，在原型阶段，就应包括界面 设计的原则。从界面风格，易用性，友好化，用 户习惯等多方面达成一定规定，会对程序员在界 面设计上节省大量时间。
1 界面处理流程和后台业务处理流程是否正确。
- 界面处理流程： 界面是指用户面对的界面。 用户只有看到具体的软件界面，才会形成感性 的知识，才能对开发的系统提出具体要求，和 进一步的改进需求。才能理解我们推荐的解决 方案。另一方面，这也是检验PM对用户需求的 理解是否正确，能否做出符合要求的产品。
例如：大多数的动态网站，都是在客户初步的 需求基础上，先制作一个大体上能表现功能的 静态网站出来，然后客户根据这个静态网站提 出进一步的详细需求，开发便按照这个详细需 求来进行。
为了快速地构建和修改原型，通常使用下述3 种方法和工具：
(1) 第四代技术
第四代技术包括众多数据库查询和报表语言、 程序和应用系统生成器以及其他非常高级的 非过程语言。第四代技术使得软件工程师能 够快速地生成可执行的代码，它们是较理想 的快速原型工具。
3.1.3 软件需求分析的任务
一、综合需求
需求分类
功能需求 性能需求 环境需求
(1) 功能需求
• 系统做什么？ • 系统何时做什么？ • 系统何时及如何修改或升级？
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
(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 数据对象
• 它的范畴很大，可以是外部实体(例如，产生 或使用信息的任何事物)、事物(例如，报表)、 行为(例如，打电话)、事件(例如，响警报)、 角色(例如，教师、学生)、单位(例如，会计 科)、地点(例如，仓库)或结构(例如，文件) 等。 • 总之，可以由一组属性来定义的实体都可以 被认为是数据对象。
第3章 需求分析及功能建模方法
第3章需求分析及功能建模方法3.1 需求分析概述3.1.1 需求分析概念1、所谓需求分折：就是对待开发的系统要做什么，完成什么功能的全面描述。
2、需求分析的工作：通过对需求的调查、了解、观察和分析，通过对原始数据的收集、分类和抽象，并采用有效的技术、工具，对原始资料进行加工整理，描述开发目标、实现的功能及其相互关系等活动的集合;3、需求的定义：客户对一个待开发的系统在实现目标、完成功能、应达到的性能、安全性、可靠性等方面的期望和要求的集合;4、需求获取的困难：(1) 软件功能复杂;(2) 需求的可变性;5、需求分析阶段的主要任务：分析当前的业务流程，包括体系结构，各职能部门完成的主要任务、关系及其交流的信息。
6、需求分析的结果通常以模型等建模工具和方法描述系统的信息流、功能结构及完成各功能需要的数据。
7、功能模型和软件需求规格说明书是软件开发的依据，将指导后续的开发工作。
8、需求分析工作是系统分析员与用户不断交互的过程中完成的。
3.1.2 系统分析员的职能1、系统分析员的主要要任务：是确定应用信息系统及软件产品应该达到的各项功能性要求和非功能性要求，即用户要做什么。
2、系统分析员应该具备的素质：(1) 获取需求的能力;(2) 管理及沟通能力;(3) 技术素养;3.1.3 需求获取的方法常用的几种获取需求的方法：(1)面谈;(2)实地观察;(3)问卷调查;(4)查阅资源;3.1.4 需求分析过程1、标识问题：(1) 需求分析的第一步，通过对问题的识别和标识获得所求解问题及其运行环境的理解;(2) 标识问题从现行系统的业务流程做起，理解现行系统的业务流程;(3) 在标识理解需求的同时，还要注意确定系统的人机界面;2、建立需求模型：(1) 模型是对现实原形所作的一种抽象，其本质是只关心与研究内容有关的因素，而忽略无关的因素，其目的是把复杂的事物变得简单，便于认识和分析;(2) 目前常用的模型方法主要有DFD数据流图和IDEFO，都属于结构化分析方法，其特征是抽象和分解;(3) 首先对应用领域进行全面的分析，发现并找出同类事物的本质，用抽象方法把这类事物的非主要方面剔除，把握住事物的内部规律或本质，就可以找到解决办法;然后采用自上而下逐步求精的方法对复杂的问题进行分解;(4) 结构化分析及建模方法的主要优点：(A) 不过早陷入具体的细节;(B) 从整体或宏观入手分析问题;(C) 通过图形化的模型对象直观地表示系统要做什么，完成什么功能;(D) 图形化建模方法方便系统分析员理解和描述系统;(E) 模型对象不涉及太多的技术术语，便于用户理解;3、描述需求：(1) 需求描述的目标：对软件项目功能性和非功能性的需求全面描述;(2) 功能性需求：指需要计算机实际解决的问题或实现的具体功能，明确描述系统必须做什么，实现什么功能以及输入输出等;(3) 非功能性需求：软件项目对实际运行环境的要求;(4) 需求描述主要由需求模型和需求说明书组成，说明书侧重文字说明，内容如下：需求概述;功能需求;信息需求;性能需求;环境需求;其他需求;(5) 在对需求进行分析过程中，系统分析员要经常考虑的问题：(A) 描述的需求是完全的吗?(B) 需求描述是正确的和一致的吗?(C) 描述的这些需求是可行的、实际可操作的吗?(D) 描述中的每一条需求都是客户需要的吗?4、确认需求：1、评审委员会审核下列内容：功能需求;数据需求;性能;数据管理;其他需求。
需求分析与用例模型
什么是需求？
第3章 需求分析与用例模型
在统一过程（UP）中，需求按照“FURPS”模型进行分类。
➢ 功能性（Functional）：特性、功能、安全性；
➢ 可用性（Usability）：人性化因素、帮助、文档；
非
➢ 可靠性（Reliability）：故障频率、可恢复性、可预测
功 能
性；
性
➢ 性能（Performance）：响应时间、吞吐量、准确性、有
用例之间的各种关系
3.包含关系 ➢包含关系描述的是一个用例需要某种功能，而该功能被另外一个 用例定义，那么在用例的执行过程中，就可以调用已经定义好的用 例。 ➢在UML中，用例之间的包含关系含有关键字<<include>>的带有箭 头的虚线表示。
3.包含关系
3.包含关系
3.包含关系
3.包含关系
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
事件流
➢ 说明用例如何开始和结束。只说明属于该用例的事件， 而不是发生在其他用例中或系统外部的事件。
➢ 避免不明确的术语，如“例如”、“等等”和“信息”
事件流
➢ 在事件流里要对事件流进行结构化说明 基本事件流 • 描述每个情节的行为者:目标语句对的顺序 • 假设之前的每一步都是成功的 备选事件流 • 异常情况
第3章 需求分析与用例模型
在统一过程（UP）中，需求按照“FURPS”模型进行分类。
➢ 功能性（Functional）：特性、功能、安全性；
➢ 可用性（Usability）：人性化因素、帮助、文档；
非
➢ 可靠性（Reliability）：故障频率、可恢复性、可预测
功 能
性；
性
➢ 性能（Performance）：响应时间、吞吐量、准确性、有
用例之间的各种关系
3.包含关系 ➢包含关系描述的是一个用例需要某种功能，而该功能被另外一个 用例定义，那么在用例的执行过程中，就可以调用已经定义好的用 例。 ➢在UML中，用例之间的包含关系含有关键字<<include>>的带有箭 头的虚线表示。
3.包含关系
3.包含关系
3.包含关系
3.包含关系
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
事件流
➢ 说明用例如何开始和结束。只说明属于该用例的事件， 而不是发生在其他用例中或系统外部的事件。
➢ 避免不明确的术语，如“例如”、“等等”和“信息”
事件流
➢ 在事件流里要对事件流进行结构化说明 基本事件流 • 描述每个情节的行为者:目标语句对的顺序 • 假设之前的每一步都是成功的 备选事件流 • 异常情况
L-第三章-软件工程课件需求分析
6
教学要求
教学目的：了解需求分析的任务和步骤、评 审标准和过程；掌握基本技术，理解需求规 格说明书的作用与组成。 教学重点：基本技术、需求规格说明书的作 用与组成。 教学难点：基本技术。
7
需求分折简介
软件需求指用户对所开发的软件在功能、 性能、环境、可靠性等各方面的要求。
需求分析主要回答待开发的系统必须 “做什么”，并用 《 需求规格说明书 》 的 形式准确、详细、规范地表达出来。
8
注意
①需求分析阶段，系统分析员的主要关注点 是“做什么（ what ) ” ，不是“怎样做 （ how）”； ②需求分析阶段，系统分析员应该给出软件 求规格书。
9
§3.1需求分析的任务
四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
34
一、基本概念(2)
联系：客观事物之间的联系。联系分为三种： 一对一（ 1 : 1 ) ．班级和班长 一对多联系（ 1 : N ) ．班级和学生，系与教师，学生与宿舍 多对多联系（ M : N ) 课程与学生，教师和课程，学生和学会 二、 E 一 R 图的结构 三种基本元素：
35
例:教学E-R图
46
注意的原则 ( 1 )
数据流图上所有图形符号只限于前述四种基本图 形元素； 数据流图的主图必须包括前述四种基本元素，缺 一不可； 数据流图的主图上的数据流必须封闭在外部实体 之间； 每个数据处理至少有一个输入数据流和一个输出 数据流； 在数据流图中，需按层给数据处理框编号。编号 表明该处理所处层次及上下层的亲子关系；
36
例
仓库，职工，零件和供应商的ER图
37
三、如何建立实体一联系图？
教学要求
教学目的：了解需求分析的任务和步骤、评 审标准和过程；掌握基本技术，理解需求规 格说明书的作用与组成。 教学重点：基本技术、需求规格说明书的作 用与组成。 教学难点：基本技术。
7
需求分折简介
软件需求指用户对所开发的软件在功能、 性能、环境、可靠性等各方面的要求。
需求分析主要回答待开发的系统必须 “做什么”，并用 《 需求规格说明书 》 的 形式准确、详细、规范地表达出来。
8
注意
①需求分析阶段，系统分析员的主要关注点 是“做什么（ what ) ” ，不是“怎样做 （ how）”； ②需求分析阶段，系统分析员应该给出软件 求规格书。
9
§3.1需求分析的任务
四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
34
一、基本概念(2)
联系：客观事物之间的联系。联系分为三种： 一对一（ 1 : 1 ) ．班级和班长 一对多联系（ 1 : N ) ．班级和学生，系与教师，学生与宿舍 多对多联系（ M : N ) 课程与学生，教师和课程，学生和学会 二、 E 一 R 图的结构 三种基本元素：
35
例:教学E-R图
46
注意的原则 ( 1 )
数据流图上所有图形符号只限于前述四种基本图 形元素； 数据流图的主图必须包括前述四种基本元素，缺 一不可； 数据流图的主图上的数据流必须封闭在外部实体 之间； 每个数据处理至少有一个输入数据流和一个输出 数据流； 在数据流图中，需按层给数据处理框编号。编号 表明该处理所处层次及上下层的亲子关系；
36
例
仓库，职工，零件和供应商的ER图
37
三、如何建立实体一联系图？
软件需求分析第三章
需求分析的任务
需求分析是对问题进一步发现、求精、建模、 规格说明和复审的过程。
➢准确地定义未来系统的目标，确定为了满
足用户的需求，系统必须“做什么”。
➢用 <需求规格说明书> 规范的形式准确地
描述用户的需求。
做什么（what） 怎么做（how）
2024/1/14
任务：
➢描述软件的功能和性能 ➢确定软件设计的约束、软件同其它
2➢024/通1/14信途径：访谈、调查、情景分析
某图书馆系统调查表
编号
问
题
1 您在哪个部门工作？ 2 您每天必须做哪些事？顺序是什么？
3 您每天要处理那些文件、数据、报表？
4 您感到工作中特别麻烦的事情是什么？
5 工作中什么问题用手工方法解决不了？影响效 率的问题有哪些？
6 您认为提高工作效率，节省工作时间，减轻工 2024/1/14 作强度可采取哪些办法？
➢描述内容所使用的符号
操作符
含义描述
＝
等价于（定义为）
＋
和(连接两个分量)
〔..｜..〕 或(选择结构)
｛...｝
重复(循环结构)
( ... ) 任选
m..n
界域
＊＊
注释符
2024/1/14
➢例如：电话系统中的数据字典 电话号码=[当地分机号|外地号码] 当地分机=[2001|2002……|2999] 外地号码=9+[当地号码|长途号码] 长途号码=（1）+区号+当地号码 只可访问4个
分支交换机
前缀=[795|799|874|877] 访问的号码=*任意四位串号码*
2024/1/14
➢限制重复次数说明
｛｝ 1｛ ｝
需求分析是对问题进一步发现、求精、建模、 规格说明和复审的过程。
➢准确地定义未来系统的目标，确定为了满
足用户的需求，系统必须“做什么”。
➢用 <需求规格说明书> 规范的形式准确地
描述用户的需求。
做什么（what） 怎么做（how）
2024/1/14
任务：
➢描述软件的功能和性能 ➢确定软件设计的约束、软件同其它
2➢024/通1/14信途径：访谈、调查、情景分析
某图书馆系统调查表
编号
问
题
1 您在哪个部门工作？ 2 您每天必须做哪些事？顺序是什么？
3 您每天要处理那些文件、数据、报表？
4 您感到工作中特别麻烦的事情是什么？
5 工作中什么问题用手工方法解决不了？影响效 率的问题有哪些？
6 您认为提高工作效率，节省工作时间，减轻工 2024/1/14 作强度可采取哪些办法？
➢描述内容所使用的符号
操作符
含义描述
＝
等价于（定义为）
＋
和(连接两个分量)
〔..｜..〕 或(选择结构)
｛...｝
重复(循环结构)
( ... ) 任选
m..n
界域
＊＊
注释符
2024/1/14
➢例如：电话系统中的数据字典 电话号码=[当地分机号|外地号码] 当地分机=[2001|2002……|2999] 外地号码=9+[当地号码|长途号码] 长途号码=（1）+区号+当地号码 只可访问4个
分支交换机
前缀=[795|799|874|877] 访问的号码=*任意四位串号码*
2024/1/14
➢限制重复次数说明
｛｝ 1｛ ｝
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
应如何实施。
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
基础
运行的原型 运行原型
修正和改进原型
2020/3/7第3章软件需求分析与建模
改进的原型
软件工程教研室
23
3.2 结构化分析方法
3.2.1基本思想和分析过程
结构化分析方法的基本思想是“分解”和“抽象”。 分解是指对于一个比较复杂的系统，为了将其复杂 性降低到可以掌握的程度，从而把大问题分解成若 干个小问题，然后分别求解，这是一种分治策略。 如图3-3是一幅自顶向下逐层分解的示意图。顶层抽 象地描述了整个系统，底层具体地刻画了系统的每 一个细节，而中间层是从抽象到具体的逐层过渡。
2020/3/7第3章软件需求分析与建模
软件工程教研室
8
3.1.2 获取需求的方法
需求获取可能是软件开发中最需要与用户交流的方面。进 行需求分析要脚踏实地地围绕两个核心问题来开展：应该 了解什么？通过什么方式去了解？ 这两个问题也就是：目标、方法、处理三个部分。 1、目标 用书面的方式记录和归整用户的需求报告。 （1）首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分 析信息流程做准备。 （2）然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这 些数据，输出什么信息，输出到什么部门，输出结果的格 式是什么。
21
分析阶段的原型化生命周期
运行/ 维护
转换
基本 业务
系统 分析
系统 分析
基本 需求
构造 原型
使用 原型
补充
详细 设计
初步 设计
Y 满意否？ N
修改、 扩充
2020/3/7第3章软件需求分析与建模
软件工程教研室
22
确定基本信息需求 ·基本需求 ·估计成本 ·确定数据
开发初始原型
初始原型
使用原型系统 并澄清需求
的载体，实质上是进一步落实现行系统的数据收集、整理、
输入、存储、处理、输出等各个环节，从而得到完整的信
息流程。
2020/3/7第3章软件需求分析与建模
软件工程教研室
7
需求分析的原则：
1、详细了解用户的业务及目标,充分理解用户对功能和质量 的要求。 2、运用合适的方法、模型和工具，正确的、完整的、清晰 的表示可理解的问题信息域、定义软件将完成的功能和软 件的主要行为。 3、能够对问题进行分解和不断细化，建立问题的层次结构。 作为一个整体来看，可能很大、很复杂、很难理解。但可 以通过把问题以某种方式分解为几个较易理解的部分，并 确定各部分间的接口，从而实现整体功能。 4、尽量重用已有的软件组件，以便开发人员能够降低新系 统的开发成本和节省时间。 5、准确、规范、详细地编写需求分析文档和认真细致地评 审需求分析文档。
2) 面向对象的分析方法 (OOA)
2020/3/7第3章软件需求分析与建模
软件工程教研室
17
3.1.4 需求分析的主要过程
需求分析过程主要有以下5个步骤构成（见图3-1）。
2020/3/7第3章软件需求分析与建模
软件工程教研室
18
需求分析过程示意 (1) 通过对现实环境的调查，获得当前系统的物理模型
2020/3/7第3章软件需求分析与建模
软件工程教研室
11
（4）设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于 为用户接受的。 （5）查阅档案记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、 报表等。 3、处理 通过调查了解了用户需求后，还需要进一步分析和表达 用户的需求，并建立快速原型，以便于进行技术评审。
2020/3/7第3章软件需求分析与建模
软件工程教研室
3
3.1.1 需求分析的任务和原则
需求分析的具体任务在于：确定对系统的综合需求，提
出系统的逻辑模型，修正系统开发计划，快速建立软件原
型。
通过对用户进行访谈和调研，获取和确定用户需求，并 将
需求分为功能需求、非功能需求两类需求。 (1) 功能性需求:
的数据、用户程序与其它程序间的处理、系统隔离与系统
备份要求；
(10)软件成本消耗与开发进度：开发的时间规定、软硬件投资
有无限制；
(11)质量保证：系统的可靠性要求、系统是否要监测和隔离错
误、规定系统平均出错时间、出错后重启系统允许的时间、
维护是否包括对系统的改进、系统的可移植性。
(12)各种计划、单据和报表的处理：计划单据和报表都是信息
定义了系统做什么（描述系统必须支持的功能和过程） (2) 非功能性需求（技术需求）:
定义了系统工作时的特性（描述操作环境和性能目标, 如： 响应时间、平均无故障工作时间、自动恢复时间等）。
2020/3/7第3章软件需求分析与建模
软件工程教研室
4
项目案例：基于本体知识库的循环经 济系统决策技术研究的功能需求
性； (6)文档：文档类型和种类、使用对象； (7)数据：输入/输出数据的格式、数据的准确性和精度、数
据量、数据需保持的时间；
2020/3/7第3章软件需求分析与建模
软件工程教研室
6
(8)资源：软件运行时所需的数据、软件、内存空间等，软件
开发、维护所需的人力、支撑软件、开发设备等。
(9)安全保密：对访问系统或系统信息的控制、隔离用户之间
2020/3/7第3章软件需求分析与建模
软件工程教研室
14
需求分析过程应该建立3种模型，它们分别是数据模型、 功能模型和行为模型。
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现行 描述重要的业务功能，不考 描述现实系统是如何在物理
系统 虑系统是如何实施的。
上实现的。
目标 描述新系统的主要业务功能 描述新系统是如何实施的 系统 和用户新的需求，无论系统 （包括技术）。
数据输入及编辑
项目经济和技术指标的输入、添加、修改和删除功能
查询及监测
以行政级别、经济类型和经济名称、图形斑块等为单位的查 询和分析比较；
评价及决策
经济状况评价、环境状况评价、综合效益评价、质量评价等
系统维护
数据库管理、网页管理、目录管理、用户管理、事件监视等
2020/3/7第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
12
3.1.3 需求分析的模型和方法
提出目标系统的数据模型、功能模型和行为模型是需 求分析的核心任务。
所谓模型就是系统的一种书面描述，通过抽象、概括 和一般化，把研究的对象或问题转化为本质相同的另一对 象或问题，以便解决的方法。模型不一定必须用某种数学 公式表示，可以是图形，甚至可以是文字叙述。
第3章 软件需求分析与建模
教学内容：
1. 需求分析的任务和步骤 2. 结构化分析与建模（数据流建模、实体-关系建模、功能建
模、行为建模） 3. 验证软件需求
基本要求：
1. 了解：需求分析的任务和步骤
2. 理解：结构化分析方法的指导原则；
3. 掌握：结构化分析与建模的方法
2020/3/7第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
16
2、需求分析方法 需求分析方法由对软件问题的信息域和功能域的系 统分析过程及其表示方法组成; 大多数的需求分析方法是由信息驱动的 信息域具有三种属性: 信息流、信息内容和信息结构。 常用的分析方法有：
1) 面向数据流的结构化分析方法 (SA)
2020/3/7第3章软件需求分析与建模
软件工程教研室
26
2020/3/7第3章软件需求分析与建模
软件工程教研室
27
总之，结构化分析是一种建模活动, 主要是根据软件内 部的数据传递、变换关系，自顶向下逐层分解，描绘出 满足功能要求的软件模型。 使用的手段主要有系统流程图、数据流图、数据字典、 实体-关系图和状态转换图等。
软件工程教研室
2
3.1 需求分析
系统工程
需求分析是软件设计的基础，需
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
基础
运行的原型 运行原型
修正和改进原型
2020/3/7第3章软件需求分析与建模
改进的原型
软件工程教研室
23
3.2 结构化分析方法
3.2.1基本思想和分析过程
结构化分析方法的基本思想是“分解”和“抽象”。 分解是指对于一个比较复杂的系统，为了将其复杂 性降低到可以掌握的程度，从而把大问题分解成若 干个小问题，然后分别求解，这是一种分治策略。 如图3-3是一幅自顶向下逐层分解的示意图。顶层抽 象地描述了整个系统，底层具体地刻画了系统的每 一个细节，而中间层是从抽象到具体的逐层过渡。
2020/3/7第3章软件需求分析与建模
软件工程教研室
8
3.1.2 获取需求的方法
需求获取可能是软件开发中最需要与用户交流的方面。进 行需求分析要脚踏实地地围绕两个核心问题来开展：应该 了解什么？通过什么方式去了解？ 这两个问题也就是：目标、方法、处理三个部分。 1、目标 用书面的方式记录和归整用户的需求报告。 （1）首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分 析信息流程做准备。 （2）然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这 些数据，输出什么信息，输出到什么部门，输出结果的格 式是什么。
21
分析阶段的原型化生命周期
运行/ 维护
转换
基本 业务
系统 分析
系统 分析
基本 需求
构造 原型
使用 原型
补充
详细 设计
初步 设计
Y 满意否？ N
修改、 扩充
2020/3/7第3章软件需求分析与建模
软件工程教研室
22
确定基本信息需求 ·基本需求 ·估计成本 ·确定数据
开发初始原型
初始原型
使用原型系统 并澄清需求
的载体，实质上是进一步落实现行系统的数据收集、整理、
输入、存储、处理、输出等各个环节，从而得到完整的信
息流程。
2020/3/7第3章软件需求分析与建模
软件工程教研室
7
需求分析的原则：
1、详细了解用户的业务及目标,充分理解用户对功能和质量 的要求。 2、运用合适的方法、模型和工具，正确的、完整的、清晰 的表示可理解的问题信息域、定义软件将完成的功能和软 件的主要行为。 3、能够对问题进行分解和不断细化，建立问题的层次结构。 作为一个整体来看，可能很大、很复杂、很难理解。但可 以通过把问题以某种方式分解为几个较易理解的部分，并 确定各部分间的接口，从而实现整体功能。 4、尽量重用已有的软件组件，以便开发人员能够降低新系 统的开发成本和节省时间。 5、准确、规范、详细地编写需求分析文档和认真细致地评 审需求分析文档。
2) 面向对象的分析方法 (OOA)
2020/3/7第3章软件需求分析与建模
软件工程教研室
17
3.1.4 需求分析的主要过程
需求分析过程主要有以下5个步骤构成（见图3-1）。
2020/3/7第3章软件需求分析与建模
软件工程教研室
18
需求分析过程示意 (1) 通过对现实环境的调查，获得当前系统的物理模型
2020/3/7第3章软件需求分析与建模
软件工程教研室
11
（4）设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于 为用户接受的。 （5）查阅档案记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、 报表等。 3、处理 通过调查了解了用户需求后，还需要进一步分析和表达 用户的需求，并建立快速原型，以便于进行技术评审。
2020/3/7第3章软件需求分析与建模
软件工程教研室
3
3.1.1 需求分析的任务和原则
需求分析的具体任务在于：确定对系统的综合需求，提
出系统的逻辑模型，修正系统开发计划，快速建立软件原
型。
通过对用户进行访谈和调研，获取和确定用户需求，并 将
需求分为功能需求、非功能需求两类需求。 (1) 功能性需求:
的数据、用户程序与其它程序间的处理、系统隔离与系统
备份要求；
(10)软件成本消耗与开发进度：开发的时间规定、软硬件投资
有无限制；
(11)质量保证：系统的可靠性要求、系统是否要监测和隔离错
误、规定系统平均出错时间、出错后重启系统允许的时间、
维护是否包括对系统的改进、系统的可移植性。
(12)各种计划、单据和报表的处理：计划单据和报表都是信息
定义了系统做什么（描述系统必须支持的功能和过程） (2) 非功能性需求（技术需求）:
定义了系统工作时的特性（描述操作环境和性能目标, 如： 响应时间、平均无故障工作时间、自动恢复时间等）。
2020/3/7第3章软件需求分析与建模
软件工程教研室
4
项目案例：基于本体知识库的循环经 济系统决策技术研究的功能需求
性； (6)文档：文档类型和种类、使用对象； (7)数据：输入/输出数据的格式、数据的准确性和精度、数
据量、数据需保持的时间；
2020/3/7第3章软件需求分析与建模
软件工程教研室
6
(8)资源：软件运行时所需的数据、软件、内存空间等，软件
开发、维护所需的人力、支撑软件、开发设备等。
(9)安全保密：对访问系统或系统信息的控制、隔离用户之间
2020/3/7第3章软件需求分析与建模
软件工程教研室
14
需求分析过程应该建立3种模型，它们分别是数据模型、 功能模型和行为模型。
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现行 描述重要的业务功能，不考 描述现实系统是如何在物理
系统 虑系统是如何实施的。
上实现的。
目标 描述新系统的主要业务功能 描述新系统是如何实施的 系统 和用户新的需求，无论系统 （包括技术）。
数据输入及编辑
项目经济和技术指标的输入、添加、修改和删除功能
查询及监测
以行政级别、经济类型和经济名称、图形斑块等为单位的查 询和分析比较；
评价及决策
经济状况评价、环境状况评价、综合效益评价、质量评价等
系统维护
数据库管理、网页管理、目录管理、用户管理、事件监视等
2020/3/7第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
12
3.1.3 需求分析的模型和方法
提出目标系统的数据模型、功能模型和行为模型是需 求分析的核心任务。
所谓模型就是系统的一种书面描述，通过抽象、概括 和一般化，把研究的对象或问题转化为本质相同的另一对 象或问题，以便解决的方法。模型不一定必须用某种数学 公式表示，可以是图形，甚至可以是文字叙述。
第3章 软件需求分析与建模
教学内容：
1. 需求分析的任务和步骤 2. 结构化分析与建模（数据流建模、实体-关系建模、功能建
模、行为建模） 3. 验证软件需求
基本要求：
1. 了解：需求分析的任务和步骤
2. 理解：结构化分析方法的指导原则；
3. 掌握：结构化分析与建模的方法
2020/3/7第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
16
2、需求分析方法 需求分析方法由对软件问题的信息域和功能域的系 统分析过程及其表示方法组成; 大多数的需求分析方法是由信息驱动的 信息域具有三种属性: 信息流、信息内容和信息结构。 常用的分析方法有：
1) 面向数据流的结构化分析方法 (SA)
2020/3/7第3章软件需求分析与建模
软件工程教研室
26
2020/3/7第3章软件需求分析与建模
软件工程教研室
27
总之，结构化分析是一种建模活动, 主要是根据软件内 部的数据传递、变换关系，自顶向下逐层分解，描绘出 满足功能要求的软件模型。 使用的手段主要有系统流程图、数据流图、数据字典、 实体-关系图和状态转换图等。
软件工程教研室
2
3.1 需求分析
系统工程
需求分析是软件设计的基础，需