状态转换图
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 满足第一范式条件，而且每个非关键字属性 都由整个关键字决定(而不是由关键字的一 部分来决定)。 如：
选课 ( 学号，课程号，听课出勤率，作业完成率，分数 )
教课 ( 职工号，课程号，授课效果 )
第三范式
• 符合第二范式的条件，每个非关键字属性都仅由 关键字决定，而且一个非关键字属性不能仅仅是 对另一个非关键字属性的进一步描述(即一个非关 键字属性值不依赖于另一个非关键字属性值)。 如：
行为模型 ----状态转换图
3.3 分析建模与规格说明
2). 软件需求规格说明(SRS)
Software Requirement Specification
通常用自然语言+模型，完整、准确、 具体地描述系统的数据要求、功能需求、 性能需求、可靠性和可用性要求、出错 处理需求、接口需求、约束、逆向需求 以及将来可能提出的要求。
所以，从实用角度看来，在大多数 场合选用第三范式都比较恰当。
第一范式
• 每个属性值都必须是原子值，即仅仅是一个 简单值而不含内部结构。 如：
学生(学号，姓名，性别，年龄，年级，专业，籍贯) 教师(职工号，姓名，年龄，职称，职务，工资级别，工资) 课程(课程号，课程名，学分，学时，课程类型)
第二范式
(4). 实体-联系图的符号
• ER图中包含了实体(即数据对象)、关 系和属性等3种基本成分。
• 通常用矩形框代表实体； • 用连接相关实体的菱形框表示关系； • 用椭圆形或圆角矩形表示实体(或关系)
的属性； • 并用直线把实体(或关系)与其属性连
接起来。
举例
教 师 属 性
学
生
属
对象
性
联
系
属
关系
4 修正系统开发计划
3.2 与用户沟通获取需求的方法
• 访谈
• 面向数据流自顶向下求精 • 简易的应用规格说明技术 • 快速建立软件原型
(1). 访 谈
• 正式的访谈 --- 系统分析员将提出一些事先准备好的具体问题。
• 非正式的访谈 --- 分析员将提出一些用户可以自由回答的开放性问
题，以鼓励被访问人员说出自己的想法。
准则要求建立行为模型。
(4) 必须对描述信息、功能和行为的模型进行分 解，用层次的方式展示细节。
软件的需求包括：
• 功能需求 • 性能需求 • 环境需求 • 可靠性需求 • 安全保密要求 • 用户界面需求
• 资源使用需求 • 成本消耗需求 • 开发进度需求 • 预先估计以后系统
可能达到的目标
3.1 需求分析的任务
• 当需要调查大量人员的意见时，向被调查人分发 调查表是一个十分有效的做法。
• 在访问用户的过程中使用情景分析技术往往非常 有效。
所谓情景分析就是对用户将来使用目标系统解
决某个具体问题的方法和结果进行分析。
情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便
照用户的观点对数据建立的模型。它描述了从用 户角度看到的数据，反映了用户的现实环境，而 且与在软件系统中的实现方法无关。 • 数据模型中包含3种相互关联的信息：数据对象 （实体）、数据对象的属性及数据对象彼此间相 互连接的关系。
(1). 数据对象
• 数据对象: 是对软件必须理解的复合信息的 抽象。
教师(职工号，姓名，年龄，职称，职务，工资)
----- 工资依赖于职称或职务
教师(职工号，姓名，年龄，职称，职务，工资级别，工资)
3.6 状态转换图
• 状态转换图(简称为状态图)
通过描绘系统的状态及引起系统状态转换的 事件，来表示系统的行为。此外，状态图还 指明了作为特定事件的结果系统将做哪些动 作(例如，处理数据)。
软件需求规格说明书，是需求分析阶段 得出的最主要的文档。
软件需求说明书的编写提示 （GB856T—88）
软件需求说明书的编写提示
1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示
3 需求规定 3.1 对功能的规定 3.2 对性能的规定 3.2.1 精度 3.2.2 时间特性要求 3.2.3 灵活性 3.3 输人输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求
1、范式级别越高，存储同样数据就需要分解成更多张 表，因此，“存储自身”的过程也就越复杂。
2、随着范式级别的提高，数据的存储结构与基于问题 域的结构间的匹配程度也随之下降，因此，在需求变 化时数据的稳定性较差。
3、范式级别提高则需要访问的表增多，因此性能(速度) 将下降。从实用角度看来，在大多数场合选用第三范 式都比较恰当。
---- 准确地回答“系统必须做什么?”。
• 在分析软件需求和书写软件需求规格说明 书的过程中，分析员和用户都起着关键的、
必不可少的作用。
需求分析的结构化方法都遵守下述准则：
(1) 必须理解并描述问题的信息域，根据这条 准则应该建立数据模型。
(2) 必须定义软件应完成的功能，这条准则要求 建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条
性
课
程
属
图3.2 某校教学管理ER图
性
3.5 数据规范化
规范化的目的是： • 消除数据冗余，即消除表格中数据的重复； • 消除多义性，使关系中的属性含义清楚、
单一；
• 使关系的“概念”单一化，让每个数据项 只是一个简单的数或字符串，而不是一个 组项或重复组；
• 方便操作。使数据的插入、删除与修改操 作可行并方便；
(4). 快速建立软件原型
• 正如第1章已经讲过的，快速原型就是 快速建立起来的旨在演示目标系统主 要功能的可运行的程序。
• 快速建立软件原型是最准确、最有效、 最强大的需求分析技术。
• 快速原型应具备的特性是“快速”、 “容易修改”。
快速构建和修改原型， 通常使用下述3种方法和工具：
(1) 第四代技术 (2) 可重用的软件构件
(3) 形式化规格说明和原型环境
3.3 分析建模与规格说明
1). 分析建模
模型----就是为了理解事物而对事物做出的一 种抽象，是对事物的一种无歧义的书面描述。 通常，由一组图形符号和组织这些符号的规 则组成。
需求分析过程应该建立3种模型: 数据模型 ---- 实体-联系图
功能模型 ---- 数据流图
c. 多对多联系(M∶N)
如：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每 门课程可以有多个学生来学。
• 联系也可能有属性。
如：学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由 于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课 程之间的联系“学”的属性。
说，当我们希望找到数据对象的一个实例时，用标 识符属性作为“关键字”(通常简称为“键”)。 • 应该根据对所要解决的问题的理解，来确定特定数 据对象的一组合适的属性。
如：学生具有学号、姓名、性别、年龄、专业（其它 略）等属性； 课程具有课程号、课程名、学分、学时数等属性； 教师具有职工号、姓名、年龄、职称等属性。
• 使关系模式更灵活，易于实现接近自然语 言的查询方式。
如 何 规 范 化？
• 规范化 --- 将数据的逻辑结构归结为满足一定条件 的二维表（关系）。即：
1. 表格中每个信息项必须是一个不可分割的数据 项，不可是组项。
2. 表格中每一列 (列表示属性)中所有信息项必须 是同一类型，各列的名字 (属性名) 互异，列的次 序任意。
• 需求分析的任务就是借助于当前系统的逻辑模 型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
3.1 需求分析的具体任务
1 确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性 需求、出错处理需求、接口需求、约束、 逆向需求、将来可能提出的要求。
2 分析系统的数据要求
3 导出系统的逻辑模型
(3). 简易的应用规格说明技术
--- 一种面向团队的需求收集法
这种方法提倡用户与开发者密切合作， 共同标识问题，提出解决方案要素，商 讨不同方案并指定基本需求。
使用简易的应用规格说明技术 分析需求的典型过程
1. 初步的访谈，通过用户对基本问题的回答，初步确 定待解决的问题的范围和解决方案。
2. 开发者和用户分别写出“产品需求”。
• 复合信息: 是指具有一系列不同性质或属性 的事物，仅有单个值的事物(例如，宽度)不 是数据对象。
• 可以由一组属性来定义的实体都可以被认为 是数据对象。
如：外部实体、事物、行为、事件、角色、单位、 地点或结构等。
• 数据Βιβλιοθήκη Baidu象彼此间是有关联的。
(2). 属 性
• 属性定义了数据对象的性质。 • 必须把一个或多个属性定义为“标识符”，也就是
(3). 联 系
• 数据对象彼此之间相互连接的方式称为联系，也称为关系。 • 联系可分为以下3种类型：
a. 一对一联系(1∶1)
如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是 一对一的。
b. 一对多联系(1∶N)
如：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程， 但是每门课程只能由一位教师来教。
3. 开发者和用户开会讨论，共同创建一张意见一致的 组合列表。
4. 把与会者分成更小的小组，每个小组的工作目标是 为每张列表中的项目制定小型规格说明。小型规格 说明是对列表中包含的单词或短语的准确说明。
5. 每个小组向全体与会者展示他们制定的小型规格说 明，讨论，以创建出意见一致的确认标准。
6. 由一名或多名与会者根据会议成果起草完整的软件 需求规格说明书。
• 为表示实体型之间的联系，又建立两个 关系：
选课 (学号，课程号，听课出勤率， 作业完成率，分数)
教课 (职工号，课程号，授课效果) • 这五个关系，组成了数据库的模型。 • 在每个关系中，属性名下加下划线）指
明关键字。并规定关键字能唯一地标识 一个元组。
• 通常用“范式(Normal Forms)”定义消除数据冗余的 程度。第一范式(1 NF)数据冗余程度最大，第五范 式(5 NF)数据冗余程度最小。但是：
4 运行环境规定 4.1 设备 4.2 支持软件 4.3 接口 4.4 控制
软件工程思想(林锐 P38—P48)
• 需求分析为什么困难？ • 如何进行需求分析？
3.4 实体-联系图(ER)
Entity Relationship Diagram
• ER图 ---- 是用来建立数据模型的工具。 • 数据模型 ---- 是一种面向问题的数据模型，是按
需求分析
第3章 需求分析
意义： • 软件需求的深入理解是软件开发工作获
得成功的前提条件，不论我们把设计和 编码做得如何出色，不能真正满足用户 需求的程序只会令用户失望，给开发带 来烦恼。
需求分析是软件定义时期的最后一个阶段， 它的基本任务不是确定系统怎样完成它的工 作，而是确定系统必须完成哪些工作，也就 是对目标系统提出完整、准确、清晰、具体 的要求。并在在需求分析阶段结束之前，由 系统分析员写出软件需求规格说明书，以书 面形式准确地描述软件需求。即：
3. 表格中各行 (行表示元组) 互不相同，行的次序 任意。
教工号 001 002
姓名 张毅坤 李林
性别 男 女
职称 教授 讲师
职务 院长
用教学管理例说明如何规范化
• 有三个实体型，即课程、学生和教师， 用三个关系保存它们的信息： 学生(学号，姓名，性别，年龄， 年级，专业，籍贯) 教师(职工号，姓名，年龄，职称， 职务，工资级别，工资) 课程(课程号，课程名，学分，学 时，课程类型)
(2). 面向数据流自顶向下求精
• 数据决定了需要的处理和算法，它是需求分析的出发点。 • 可行性研究阶段产生的是高层数据流图，许多具体的细节
没有包括，许多实际的数据元素被忽略，当时分析员还不 需要考虑这些细节，现在是定义这些数据元素的时候了。
自 顶 向 下 求 精 过 程
问题：
• 使用传统的访谈或面向数据流自顶向下求精 方法定义需求时，用户处于被动地位而且往 往有意无意地与开发者区分“彼此”。由于 不能像同一个团队的人那样齐心协力地识别 和精化需求，这两种方法的效果有时并不理 想。
于用户理解，而且还可能进一步揭示出一些分析员 目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术 能保证用户在需求分析过程中始终扮演一个积极主 动的角色。需求分析的目标是获知用户的真实需求， 而这一信息的惟一来源是用户，因此，让用户起积 极主动的作用对需求分析工作获得成功是至关重要 的。
选课 ( 学号，课程号，听课出勤率，作业完成率，分数 )
教课 ( 职工号，课程号，授课效果 )
第三范式
• 符合第二范式的条件，每个非关键字属性都仅由 关键字决定，而且一个非关键字属性不能仅仅是 对另一个非关键字属性的进一步描述(即一个非关 键字属性值不依赖于另一个非关键字属性值)。 如：
行为模型 ----状态转换图
3.3 分析建模与规格说明
2). 软件需求规格说明(SRS)
Software Requirement Specification
通常用自然语言+模型，完整、准确、 具体地描述系统的数据要求、功能需求、 性能需求、可靠性和可用性要求、出错 处理需求、接口需求、约束、逆向需求 以及将来可能提出的要求。
所以，从实用角度看来，在大多数 场合选用第三范式都比较恰当。
第一范式
• 每个属性值都必须是原子值，即仅仅是一个 简单值而不含内部结构。 如：
学生(学号，姓名，性别，年龄，年级，专业，籍贯) 教师(职工号，姓名，年龄，职称，职务，工资级别，工资) 课程(课程号，课程名，学分，学时，课程类型)
第二范式
(4). 实体-联系图的符号
• ER图中包含了实体(即数据对象)、关 系和属性等3种基本成分。
• 通常用矩形框代表实体； • 用连接相关实体的菱形框表示关系； • 用椭圆形或圆角矩形表示实体(或关系)
的属性； • 并用直线把实体(或关系)与其属性连
接起来。
举例
教 师 属 性
学
生
属
对象
性
联
系
属
关系
4 修正系统开发计划
3.2 与用户沟通获取需求的方法
• 访谈
• 面向数据流自顶向下求精 • 简易的应用规格说明技术 • 快速建立软件原型
(1). 访 谈
• 正式的访谈 --- 系统分析员将提出一些事先准备好的具体问题。
• 非正式的访谈 --- 分析员将提出一些用户可以自由回答的开放性问
题，以鼓励被访问人员说出自己的想法。
准则要求建立行为模型。
(4) 必须对描述信息、功能和行为的模型进行分 解，用层次的方式展示细节。
软件的需求包括：
• 功能需求 • 性能需求 • 环境需求 • 可靠性需求 • 安全保密要求 • 用户界面需求
• 资源使用需求 • 成本消耗需求 • 开发进度需求 • 预先估计以后系统
可能达到的目标
3.1 需求分析的任务
• 当需要调查大量人员的意见时，向被调查人分发 调查表是一个十分有效的做法。
• 在访问用户的过程中使用情景分析技术往往非常 有效。
所谓情景分析就是对用户将来使用目标系统解
决某个具体问题的方法和结果进行分析。
情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便
照用户的观点对数据建立的模型。它描述了从用 户角度看到的数据，反映了用户的现实环境，而 且与在软件系统中的实现方法无关。 • 数据模型中包含3种相互关联的信息：数据对象 （实体）、数据对象的属性及数据对象彼此间相 互连接的关系。
(1). 数据对象
• 数据对象: 是对软件必须理解的复合信息的 抽象。
教师(职工号，姓名，年龄，职称，职务，工资)
----- 工资依赖于职称或职务
教师(职工号，姓名，年龄，职称，职务，工资级别，工资)
3.6 状态转换图
• 状态转换图(简称为状态图)
通过描绘系统的状态及引起系统状态转换的 事件，来表示系统的行为。此外，状态图还 指明了作为特定事件的结果系统将做哪些动 作(例如，处理数据)。
软件需求规格说明书，是需求分析阶段 得出的最主要的文档。
软件需求说明书的编写提示 （GB856T—88）
软件需求说明书的编写提示
1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示
3 需求规定 3.1 对功能的规定 3.2 对性能的规定 3.2.1 精度 3.2.2 时间特性要求 3.2.3 灵活性 3.3 输人输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求
1、范式级别越高，存储同样数据就需要分解成更多张 表，因此，“存储自身”的过程也就越复杂。
2、随着范式级别的提高，数据的存储结构与基于问题 域的结构间的匹配程度也随之下降，因此，在需求变 化时数据的稳定性较差。
3、范式级别提高则需要访问的表增多，因此性能(速度) 将下降。从实用角度看来，在大多数场合选用第三范 式都比较恰当。
---- 准确地回答“系统必须做什么?”。
• 在分析软件需求和书写软件需求规格说明 书的过程中，分析员和用户都起着关键的、
必不可少的作用。
需求分析的结构化方法都遵守下述准则：
(1) 必须理解并描述问题的信息域，根据这条 准则应该建立数据模型。
(2) 必须定义软件应完成的功能，这条准则要求 建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条
性
课
程
属
图3.2 某校教学管理ER图
性
3.5 数据规范化
规范化的目的是： • 消除数据冗余，即消除表格中数据的重复； • 消除多义性，使关系中的属性含义清楚、
单一；
• 使关系的“概念”单一化，让每个数据项 只是一个简单的数或字符串，而不是一个 组项或重复组；
• 方便操作。使数据的插入、删除与修改操 作可行并方便；
(4). 快速建立软件原型
• 正如第1章已经讲过的，快速原型就是 快速建立起来的旨在演示目标系统主 要功能的可运行的程序。
• 快速建立软件原型是最准确、最有效、 最强大的需求分析技术。
• 快速原型应具备的特性是“快速”、 “容易修改”。
快速构建和修改原型， 通常使用下述3种方法和工具：
(1) 第四代技术 (2) 可重用的软件构件
(3) 形式化规格说明和原型环境
3.3 分析建模与规格说明
1). 分析建模
模型----就是为了理解事物而对事物做出的一 种抽象，是对事物的一种无歧义的书面描述。 通常，由一组图形符号和组织这些符号的规 则组成。
需求分析过程应该建立3种模型: 数据模型 ---- 实体-联系图
功能模型 ---- 数据流图
c. 多对多联系(M∶N)
如：学生与课程间的联系(“学”)是多对多的，即一个学生可以学多门课程，而每 门课程可以有多个学生来学。
• 联系也可能有属性。
如：学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由 于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课 程之间的联系“学”的属性。
说，当我们希望找到数据对象的一个实例时，用标 识符属性作为“关键字”(通常简称为“键”)。 • 应该根据对所要解决的问题的理解，来确定特定数 据对象的一组合适的属性。
如：学生具有学号、姓名、性别、年龄、专业（其它 略）等属性； 课程具有课程号、课程名、学分、学时数等属性； 教师具有职工号、姓名、年龄、职称等属性。
• 使关系模式更灵活，易于实现接近自然语 言的查询方式。
如 何 规 范 化？
• 规范化 --- 将数据的逻辑结构归结为满足一定条件 的二维表（关系）。即：
1. 表格中每个信息项必须是一个不可分割的数据 项，不可是组项。
2. 表格中每一列 (列表示属性)中所有信息项必须 是同一类型，各列的名字 (属性名) 互异，列的次 序任意。
• 需求分析的任务就是借助于当前系统的逻辑模 型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
3.1 需求分析的具体任务
1 确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性 需求、出错处理需求、接口需求、约束、 逆向需求、将来可能提出的要求。
2 分析系统的数据要求
3 导出系统的逻辑模型
(3). 简易的应用规格说明技术
--- 一种面向团队的需求收集法
这种方法提倡用户与开发者密切合作， 共同标识问题，提出解决方案要素，商 讨不同方案并指定基本需求。
使用简易的应用规格说明技术 分析需求的典型过程
1. 初步的访谈，通过用户对基本问题的回答，初步确 定待解决的问题的范围和解决方案。
2. 开发者和用户分别写出“产品需求”。
• 复合信息: 是指具有一系列不同性质或属性 的事物，仅有单个值的事物(例如，宽度)不 是数据对象。
• 可以由一组属性来定义的实体都可以被认为 是数据对象。
如：外部实体、事物、行为、事件、角色、单位、 地点或结构等。
• 数据Βιβλιοθήκη Baidu象彼此间是有关联的。
(2). 属 性
• 属性定义了数据对象的性质。 • 必须把一个或多个属性定义为“标识符”，也就是
(3). 联 系
• 数据对象彼此之间相互连接的方式称为联系，也称为关系。 • 联系可分为以下3种类型：
a. 一对一联系(1∶1)
如：一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是 一对一的。
b. 一对多联系(1∶N)
如：某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程， 但是每门课程只能由一位教师来教。
3. 开发者和用户开会讨论，共同创建一张意见一致的 组合列表。
4. 把与会者分成更小的小组，每个小组的工作目标是 为每张列表中的项目制定小型规格说明。小型规格 说明是对列表中包含的单词或短语的准确说明。
5. 每个小组向全体与会者展示他们制定的小型规格说 明，讨论，以创建出意见一致的确认标准。
6. 由一名或多名与会者根据会议成果起草完整的软件 需求规格说明书。
• 为表示实体型之间的联系，又建立两个 关系：
选课 (学号，课程号，听课出勤率， 作业完成率，分数)
教课 (职工号，课程号，授课效果) • 这五个关系，组成了数据库的模型。 • 在每个关系中，属性名下加下划线）指
明关键字。并规定关键字能唯一地标识 一个元组。
• 通常用“范式(Normal Forms)”定义消除数据冗余的 程度。第一范式(1 NF)数据冗余程度最大，第五范 式(5 NF)数据冗余程度最小。但是：
4 运行环境规定 4.1 设备 4.2 支持软件 4.3 接口 4.4 控制
软件工程思想(林锐 P38—P48)
• 需求分析为什么困难？ • 如何进行需求分析？
3.4 实体-联系图(ER)
Entity Relationship Diagram
• ER图 ---- 是用来建立数据模型的工具。 • 数据模型 ---- 是一种面向问题的数据模型，是按
需求分析
第3章 需求分析
意义： • 软件需求的深入理解是软件开发工作获
得成功的前提条件，不论我们把设计和 编码做得如何出色，不能真正满足用户 需求的程序只会令用户失望，给开发带 来烦恼。
需求分析是软件定义时期的最后一个阶段， 它的基本任务不是确定系统怎样完成它的工 作，而是确定系统必须完成哪些工作，也就 是对目标系统提出完整、准确、清晰、具体 的要求。并在在需求分析阶段结束之前，由 系统分析员写出软件需求规格说明书，以书 面形式准确地描述软件需求。即：
3. 表格中各行 (行表示元组) 互不相同，行的次序 任意。
教工号 001 002
姓名 张毅坤 李林
性别 男 女
职称 教授 讲师
职务 院长
用教学管理例说明如何规范化
• 有三个实体型，即课程、学生和教师， 用三个关系保存它们的信息： 学生(学号，姓名，性别，年龄， 年级，专业，籍贯) 教师(职工号，姓名，年龄，职称， 职务，工资级别，工资) 课程(课程号，课程名，学分，学 时，课程类型)
(2). 面向数据流自顶向下求精
• 数据决定了需要的处理和算法，它是需求分析的出发点。 • 可行性研究阶段产生的是高层数据流图，许多具体的细节
没有包括，许多实际的数据元素被忽略，当时分析员还不 需要考虑这些细节，现在是定义这些数据元素的时候了。
自 顶 向 下 求 精 过 程
问题：
• 使用传统的访谈或面向数据流自顶向下求精 方法定义需求时，用户处于被动地位而且往 往有意无意地与开发者区分“彼此”。由于 不能像同一个团队的人那样齐心协力地识别 和精化需求，这两种方法的效果有时并不理 想。
于用户理解，而且还可能进一步揭示出一些分析员 目前还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这种技术 能保证用户在需求分析过程中始终扮演一个积极主 动的角色。需求分析的目标是获知用户的真实需求， 而这一信息的惟一来源是用户，因此，让用户起积 极主动的作用对需求分析工作获得成功是至关重要 的。