软件工程第三章-3(需求分析)
合集下载
软件工程 第三课 需求分析
活动表的语法格式如下：
事件名（参数表）/动作表达式
其中，事迹名可以是任何事件的名称，在活动 表中常使用3种标准事件：entry\exit\do,而entry 事件表示进入该状态的动作， exit事件表示退出 该状态的动作，do事件表示在该状态下的动作， 需要时可以为事迹指定参数表，活动表中的动 作表达式描述做的具体动作。它是一个过程表 达式，当状态转换开始时执行该表达式。
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外，还应该 写出软件需求规格说明书，它是需求分析阶段 得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统 的数据要求、功能需求、性能需求、可靠性和 可用性要求、出错处理需求、接口需求、约束、 逆向需求以及将来可能提出的要求。自然语言 的规格说明具有容易书写、容易理解的优点， 为大多数人所欢迎和采用。
3.1 需求分析的任务 进一步了解确定用户需求。准确地回答 “系统必 须做什么？” 的问题。对目标系统提出完整、准 确、清晰、具体的要求。获得需求规格说明书。 需求分析的具体任务:
需求分析阶段的任务：在可行性分析的基础上，
1、确定系统的综合要求
系统功能要求—这是最主要的需求，确定系 统必须完成的所有功能。
约束—描述在设计或实现应用系统时应遵守的 限制条件，常见的约束有精度 、工具和语言约 束、使用的标准、使用的硬件平台。 逆向需求—逆向需求说明软件系统不应该做什么 需求。 将来可能提出的要求—对将来可能提出的扩充及 修改作预准备。
2、分析系统的数据要求 软件系统本质上是信息处理系统，因此， 必须分析系统的数据要求，这是软件需求分析的 一个重要任务。分析系统的数据要求通常采用建 立数据模型的方法。必须考虑： 数据 （需要哪些数据、数据间联系、数据性 质、结构） 数据处理 （处理的类型、处理的逻辑功能）
自考软件工程第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中数据流的定义，通常列出该数 据流的各组成数据项。
软件工程-需求分析
软件工程-需求分析软件工程-需求分析1. 引言2. 需求分析的重要性需求分析是软件工程开发过程中的第一步，其重要性体现在以下几个方面：2.1 确定项目目标与范围在需求分析阶段，通过与用户和相关利益相关方的沟通和交流，可以明确项目的目标与范围。
这有助于开发团队理解用户的需求，明确系统的功能和约束，确保项目的成功实施。
2.2 识别和定义系统需求通过需求分析，可以识别和定义系统的需求。
这包括功能需求、非功能需求以及性能需求等。
明确系统需求有助于后续的设计和开发工作，避免后期的返工和调整。
2.3 提高开发效率通过需求分析，可以避免需求方面的误解和偏差，减少开发过程中的不必要的沟通和调整。
这有助于提高开发效率，减少项目的开发周期和成本。
3. 需求分析的过程需求分析的过程包括以下几个步骤：3.1 需求获取需求获取是需求分析的第一步，主要是通过与用户和相关利益相关方的沟通和交流来收集和获取需求。
常用的需求获取方法包括面对面访谈、问卷调查、用户观察等。
3.2 需求分析与整理在需求获取的基础上，需求分析人员将获取到的需求进行分析与整理，辨识出主要和次要需求，并对其进行详细描述和分类。
3.3 需求验证需求验证是确认需求的正确性和可行性。
这可以通过与用户和相关利益相关方进一步的讨论和确认来完成。
验证需求的过程中，需求分析人员需要与开发人员密切合作，确保需求的准确理解和实现。
3.4 需求文档编写在需求验证完成后，需求分析人员需要将需求整理成文档的形式，以便于记录和交流。
需求文档应该包括需求的详细描述、功能需求、非功能需求、系统界面设计等内容。
4. 需求分析方法和工具需求分析方法和工具可以帮助分析人员更好地完成需求分析工作。
以下是一些常用的需求分析方法和工具：4.1 UML建模UML（Unified Modeling Language）是一种常用的建模语言，可以通过用例图、活动图、类图等来描述系统需求，辅助需求分析和系统设计工作。
软件工程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
需求分析的任务和步骤
软件工程导论-第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 表 )，
《软件工程》第3章 软件需求分析
【本章重点】 本章重点】
需求分析的方法 ； 需求分析的任务和原则 ；
【教学目标】 教学目标】
掌握需求分析的基本概念； 掌握需求分析的基本概念； 掌握如何使用需求获取技术来进行数据采集； 掌握如何使用需求获取技术来进行数据采集； 掌握结构化分析的思想与过程； 掌握结构化分析的思想与过程； 掌握数据流建模技术。 掌握数据流建模技术。
3.2 面向数据流的分析方法
3.2.2 数据流图
1．数据流图中的主要图形元素
3.2 面向数据流的分析方法
2．分层的数据流图
在多层数据流图中，可以把顶层数据流图、 在多层数据流图中，可以把顶层数据流图、底层数 据流图和中间层数据流图区分开来。顶层数据流图仅 据流图和中间层数据流图区分开来。 包含一个加工，它代表被开发系统。 包含一个加工，它代表被开发系统。它的输入流是该 系统的输入数据，输出流是系统的输出数据。顶层数 系统的输入数据，输出流是系统的输出数据。 据流图的作用在于表明被开发系统的范围， 据流图的作用在于表明被开发系统的范围，以及它和 周围环境的数据交换关系。 周围环境的数据交换关系。底层数据流图是指其加工 不须再做分解的数据流图，其加工称为“原子加工” 不须再做分解的数据流图，其加工称为“原子加工”。 中间层数据流图则表示对其上层父图的细化。 中间层数据流图则表示对其上层父图的细化。它的每 一个加工可以继续细化，形成子图。 一个加工可以继续细化，形成子图。中间层次的多少 视系统的复杂程度而定。 视系统的复杂程度而定。
3.2 面向数据流的分析方法
4．数据流图的优缺点
总体概念强，每一层都明确强调“干什么” 总体概念强，每一层都明确强调“干什么”，“需要 什么” 给出什么” 什么”，“给出什么”; 可以反映出数据的流向和处理过程; 可以反映出数据的流向和处理过程; 由于自顶向下分析， 由于自顶向下分析，容易及早发现系统各部分的逻辑 错误，也容易修正; 错误，也容易修正; 容易与计算机处理相对应; 容易与计算机处理相对应; 不直观，一般都要在作业流程分析的基础上加以概括、 不直观，一般都要在作业流程分析的基础上加以概括、 抽象、 抽象、修正来得到
第3章 需求分析
6
软 件 工 程
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到 从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这 类错误并不是由该应用系统本身造成的。 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一 个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。 我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖 自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键 部分，而且应该尽可能少。 3.7.6 故障处理 a. 内部故障处理 在开发阶段可以随即修改数据库里的相应内容。 b. 外部故障处理 对编辑的程序进行重装载时，第一次装载认为错，修改。第二次运 行，在需求调用时出错，有错误提示，重试。
(1)必须理解并描述问题的信息域，根据这条准则应该建 立数据模型。 (2)必须定义软件应完成的功能，这条准则要求建立功能 模型。 (3)必须描述作为外部事件结果的软件行为，这条准则要 求建立行为模型。 (4)必须对描述信息、功能和行为的模型进行分解，用层 次的方式展示细节。
12
第 3 章 需 求 分 析
据存储（可行性研究得到的高层数据流图）定义到元素级。
沿数据流图从输出端往输入端回溯着手分析。
第 3 章 需 求 分 析
图3.1 面向数据流自顶向下求精过程
15
3.2.3 简易的应用规格说明技术 软 件 工 简易的应用规格说明技术（面向团队的而求收集法）提倡用户 程 与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同
18
软 件 工 程
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外，还应该写出软件 需求规格说明书，它是需求分析阶段得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统的数据要 求、功能需求、性能需求、可靠性和可用性要求、出错处理 需求、接口需求、约束、逆向需求以及将来可能提出的要求。 自然语言的规格说明具有容易书写、容易理解的优点，为大 多数人所欢迎和采用。 为了消除用自然语言书写的软件需求规格说明书中可能 存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题， 有些人主张用形式化方法描述用户对软件系统的需求，第4章 将简要地介绍形式化说明技术。
软 件 工 程
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到 从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这 类错误并不是由该应用系统本身造成的。 在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一 个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。 我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖 自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键 部分，而且应该尽可能少。 3.7.6 故障处理 a. 内部故障处理 在开发阶段可以随即修改数据库里的相应内容。 b. 外部故障处理 对编辑的程序进行重装载时，第一次装载认为错，修改。第二次运 行，在需求调用时出错，有错误提示，重试。
(1)必须理解并描述问题的信息域，根据这条准则应该建 立数据模型。 (2)必须定义软件应完成的功能，这条准则要求建立功能 模型。 (3)必须描述作为外部事件结果的软件行为，这条准则要 求建立行为模型。 (4)必须对描述信息、功能和行为的模型进行分解，用层 次的方式展示细节。
12
第 3 章 需 求 分 析
据存储（可行性研究得到的高层数据流图）定义到元素级。
沿数据流图从输出端往输入端回溯着手分析。
第 3 章 需 求 分 析
图3.1 面向数据流自顶向下求精过程
15
3.2.3 简易的应用规格说明技术 软 件 工 简易的应用规格说明技术（面向团队的而求收集法）提倡用户 程 与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同
18
软 件 工 程
3.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
目标系统
物理模型
实例化
逻辑模型
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• •
状态迁移图
时序图 Petri网
•
状态迁移图
图形符号
初态
终态
中间状态
状态转换
图形符号
5、例子
3.8 验证软件需求
需求分析阶段的工作结果是开发软件系 统的重要基础，大量统计数字表明，软 件系统中15%的错误起源于错误的需求 。为了提高软件质量，确保软件开发成 功，降低软件开发成本，一旦对目标系 统提出一组要求之后，必须严格验证这 些需求的正确性。
3-4 为方便旅客，某航空公司拟开发一个机 票预订系统。旅行社把预订机票的旅客信息 (姓名、性别、工作单位、身份证号码、旅 行时间、旅行目的地等)输入进该系统，系 统为旅客安排航班，印出取票通知和账单， 旅客在飞机起飞的前一天凭取票通知和账单 交款取票，系统校对无误即印出机票给旅客 分析所述的机票预订系统。请用实体-联系图 描绘本系统中的数据对象并用数据流图描绘 本系统的功能
数据对象彼此间是有关联的，例如，教 师“教”课程，学生“学”课程，教或 学的关系表示教师和课程或学生和课程 之间的一种特定的连接。
二、属性
属性定义了数据对象的性质。必须把一 个或多个属性定义为“标识符”，也就 是说，当我们希望找到数据对象的一个 实例时，用标识符属性作为“关键字 ”(通常简称为“键”)。
IPO图使用的基本符号既少又简单。它 的基本形式是在左边的框中列出有关的 输入数据，在中间的框内列出主要的处 理，在右边的框内列出产生的输出数据 。处理框中列出处理的次序暗示了执行 的顺序，
图3.7 IPO图的一个例子图
图3.8 改进的IPO图的形式
3.7 系统行为描述
采用动态分析方法，直观地 分析系统的动作。 最常用的动态分析方法：
三、联系
数据对象彼此之间相互连接的方式称为联系 ，也称为关系。联系可分为以下3种类型： (1) 一对一联系(1∶1) 例如，一个部门有一个经理，而每个经理只 在一个部门任职，则部门与经理的联系是一 对一的。 (2) 一对多联系(1∶N) 例如，某校教师与课程之间存在一对多的联 系“教”，即每位教师可以教多门课程，但 是每门课程只能由一位教师来教
3-5 目前住院病人主要由护士护理，这样做不仅需 要大量护士，而且由于不能随时观察危重病人的病 情变化，还会延误抢救时机。某医院打算开发一个 以计算机为中心的患者监护系统，请写出问题定义 ，并且分析开发这个系统的可行性。 医院对患者监护系统的基本要求是随时接收每个病 人的生理信号(脉搏、体温、血压、心电图等)，定 时记录病人情况以形成患者日志，当某个病人的生 理信号超出医生规定的安全范围时向值班护士发出 警告信息，此外，护士在需要时还可以要求系统印 出某个指定病人的病情报告。
从四个方面验证： 一致性、完整性、现实性、有效性
习题
3-1 为什么要进行需求分析?通常对软件系统有哪些 需求? 3-2 怎样与用户有效地沟通以获取用户的真实需求? 3-3 银行计算机储蓄系统的工作过程大致如下：储 户填写的存款单或取款单由业务员键入系统，如果 是存款则系统记录存款人姓名、住址(或电话号码) 、身份证号码、存款类型、存款日期、到期日期、 利率及密码(可选)等信息，并印出存单给储户；如 果是取款而且存款时留有密码，则系统首先核对储 户密码，若密码正确或存款时未留密码，则系统计 算利息并印出利息清单给储户。请用数据流图描绘 本系统的功能，并用实体-联系图描绘系统中的数 据对象。
某校教学管理ER图
某校教学管理ER图
3.6 其他图形工具
一、层次方框图
层次方框图用树形结构的一系列多层次的矩 形框描绘数据的层次结构。树形结构的顶层 是一个单独的矩形框，它代表完整的数据结 构，下面的各层矩形框代表这个数据的子集 ，最底层的各个框代表组成这个数据的实际 数据元素(不能再分割的元素)。
例如，描绘一家计算机公司全部产品的层次方框图。
图3.5 层次方框图的一个例子
二、Warnier图
表示信息层次结构的另外一种图形工具。但 是这种图形工具比层次方框图提供了更丰富 的描绘手段。
图3.6 Warnier图的一个例子
三、IPO图
IPO图是输入、处理、输出图的简称，它是 美国IBM公司发展完善起来的一种图形工具 ，能够方便地描绘输入数据、对数据的处理 和输出数据之间的关系。
3.5 实体-联系图
数据模型中包含3种相互关联的信息 数据对象、数据对象的属性及数据 对象彼此间相互连接的关系。
一、数据对象 数据对象可以是外部实体即产生或 使用信息的任何事物、行为、事件 、角色、单位、地点或结构。总之 ，可以由一组属性来定义的实体都 可以被认为是数据对象
事物(例如，报表)、行为(例如，打电话)、事 件(例如，响警报)、角色(例如，教师、学生) 、单位(例如，会计科)、地点(例如，仓库)或 结构(例如，文件)等。
(3) 多对多联系(M∶N) 例如，图表示学生与课程间的联系(“学”)是 多对多的，即一个学生可以学多门课程，而 每门课程可以有多个学生来学。
四、实体-联系图的符号
实体-联系图简称为ER图，把ER图描绘的数 据模型称为ER模型。 ER图中包含了实体(即数据对象)、关系和属 性等3种基本成分，通常用矩形框代表实体 ，用连接相关实体的菱形框表示关系，用椭 圆形或圆角矩形表示实体(或关系)的属性， 并用直线把实体(或关系)与其属性连接起来 。
分析所述的患者监护系统。请用实体-联系 图描绘本系统中的数据对象并用数据流图描 绘本系统的功能，画出本系统的顶层IPO图 。并生成本系统的数据字典