❖ 简易的应用规格说明技术 ❖ 快速原型法
用户和系统其他人员参与需求分 析
3.2.1 访谈
❖ 最早并且仍然广泛使用 ❖ 正式的访谈：具体问题的问答形式 ❖ 非正式的访谈：开放式、交互性的问答 ❖ 需要调查大量人员时采用“调查表”技术 ❖ 还使用“情景分析技术”（用户角度）,就是
对用户将来使用目标系统解决某个具体问题 的方法和结果进行分析。
❖ 功能分解可以完成数据流图的细化； ❖ 细化过程中注意及时的更新数据字典；
书写文档
❖ 需求规格说明 ❖ 数据要求 ❖ 用户系统描述 ❖ 修正的开发计划
需求分析的过程示图
面向数据流方法的分析的应用
来源、数据组 成是什么？
仓库管理员
事务
定货系统
定货报表
采购员
来源：由哪个加工产生或从哪个文件读出？
❖ 实体之间不是孤立的。 ❖ 注意区分面向对象中的“对象”和ER中的
“数据对象”。
3.4.1 数据对象
❖ 它的范畴很大，可以是外部实体(例如，产生 或使用信息的任何事物)、事物(例如，报表)、 行为(例如，打电话)、事件(例如，响警报)、 角色(例如，教师、学生)、单位(例如，会计 科)、地点(例如，仓库)或结构(例如，文件) 等。
❖ 从数据流图的输出端着手分析，这是因为系 统的基本功能是产生这些输出的关键原因。
❖ 输出数据决定了系统必须具有的最基本的组
成元素（包括功能和数据结构组成）。
3.2.2 面向数据流的自顶向下求精
❖ 注意1：第2章给出了1种数据流图的分析方法 （教材），其目的主要是导出较高层次较粗 糙的数据流图，而需要准确地收集需求，采 用本章的从数据流图的输出向输入的回溯方 法。
对象-行为模型
3.3 分析建模与规格说明
❖ 结构化分析方法的创建的几个主要模型及关 键元素如下：
数据模型：E-R图（E-RD）（本章介绍） 功能模型：数据流图（DFD） 行为模型：状态转换图（STD）（本章介绍） 数据字典：模型中心（DD）
❖ 根据上述模型整理出软件需求规格说明书
3.4 实体-联系图
化学制品仓 库存货清单
1
化学制品 请求
1
存储
执行
M M
化学制品容器
3.5 数据规范化
❖ 概念模型转化为数据模型后考虑的问题 ❖ 数据库中范式的定义
第一范式：原子属性 第二范式：消除部分函数依赖 第三范式：消除传递函数依赖
3.6 状态转换图
❖ 通过描绘系统的状态及引起系统状态转换的 事件，来表示系统的行为。
是否需要这个 软件以及对需 求进行组合
单独议题需求 列表的讨论
完整的需求规 格说明书
针对每个议题制 定一统一的需求 列表
3.2.4 快速原型法
❖ 快速建立起来的旨在演示目标系统主要功能 的可运行的程序。
❖ 它是最准确、有效和强大的需求分析技术。 ❖ 基本特性：
快速：快速的提供给用户一个可运行的软件； 容易修改：根据用户的要求可迅速构建新的原型；
它反映了分析员建立的对系统已有的认识。） ❖ 用户要及时纠正和补充分析员的认识
❖ 它验证了已知的元素，补充了未知的元素， 填补了文档中的空白；
❖ 分析员对系统的认识是一个螺旋式上升的过 程。
细化数据流图
❖ 为了追踪更详细的数据流，应该把数据流图 扩展到更低的层次；
❖ 通过追踪这些细化的数据流图产生了新的问 题，新的问题的答案可能在数据字典中增加 新的条目，并且将产生新的算法；
3.6.1 状态
❖ 三种状态类型：初态、终态和中间态
State_1
❖ 状态图可表示循环运行过程以及单程运行过 程。
State_1
State_2
State_1
State_3
3.6.2 事件
❖ 某个特定时刻发生的“事情”。 ❖ 它是对引起系统做动作或(和)从一个状态转
换到另一个状态的外界事件的抽象。 ❖ 它是控制信息，状态是受事件触发的。
3.1.1 确定系统的综合要求
基本的、
核心的
❖ 功能要求
时间、存储 量、安全性
MTTF
用户、硬件、 软件、通信
系统不应该 做什么
❖ 性能要求
❖ 可靠性和可用性要求 ❖ 出错处理要求
对环境错误 应该如何响
应
❖ 接口要求 ❖ 约束
限制条件、 精度、语言
❖ 逆向要求 ❖ 扩展要求
对系统可能 的扩充或修
改
3.1.2 分析和设计系统的数据要求
❖ 软件系统的本质是对数据进行处理。 ❖ 通常要求建立完整的概念模型（E-R模型） ❖ 数据字典缺乏直观性（考虑图形化的描述复
杂数据的组成） ❖ 必要时需要对数据模型进行规范化（范式） ❖ 阶段性成果：
E-R图 层次方框图或Warnier图
3.1.3 分析和设计系统的功能模型
3.1 需求分析的任务
具体任务：
确定对系统的综合要求（系统需要什么？） 分析和设计系统的数据要求 （处理的数据对象
是什么？）
在可行性分析的基础之上分析和设计系统的功 能模型（系统功能的模型表示是什么？）
分析和设计描述软件动态变化的行为模型（系 统的状态是如何改变的？）
编写软件需求规格说明书，可能需要修正系统 开发计划
❖ 把分析过程中得到的有关数据元素的信息记录在数 据字典中，把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位置上。
面向数据流方法的分析过程
❖ 沿数据流图回溯 ❖ 用户复查 ❖ 细化数据流图 ❖ 修正开发计划 ❖ 书写文档 ❖ 审查和复审
沿数据流图回溯
第3章 需求分析
为什么需要需求分析？
❖ 开发人员往往急于求成 ❖ 希望对开发进行指导 ❖ 希望开发人员对用户的要求理解 ❖ 希望用户理解开发人员 ❖ 测试部门有理可依
需求分析做什么? Is What Not How
❖ 准确地回答”系统必须做什么?”这个问题； ❖ 对系统提出完整、准确、清晰、具体的要求； ❖ 写出软件需求规格说明书； ❖ 用户要很好地参与到需求分析过程中来；(需
求要不断迭代) ❖ 注意区别”可行性分析”和”需求分析”的
异同； ❖ 设计出系统的”数据模型”、细化的“逻辑
模型”和“行为模型”；(关键所在)
需求分析做什么?
所有的结构化分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这条
准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要
3.2.1 访谈
❖ 情景分析 (1) 它在某种程度上演示目标系统的行为，便
于用户理解，而且还可能进一步揭示出一些 分析员还不知道的需求。 (2) 由于情景分析较易为用户所理解，使用这 种技术能保证用户在需求分析过程中始终扮 演一个积极主动的角色。
可行性分析 忽略了细节
3.2.2 面向数据流的自顶向下求精
3.3 分析建模与规格说明
❖ 模型，就是为了理解事物而对事物做出 的一种抽象，是对事物的一种无歧义的 书面描述。
❖ 系统分析员应该从不同角度抽象出目标 系统的特性，使用精确的表示方法构造
系统的模型。
数据角度、功能角 度、行为角度
DFD、DD、STD、 E-R
模型的作用
现实世界
影射
计算机世界
模型的作用
❖ 阶段性成果：
状态转换图(STD)
3.1.5 编写需求规格说明，可能需要 修正系统的开发计划
❖ 根据上述的阶段性成果，汇总为“软件需求 规格说明书”，以提交评审
❖ 在可行性分析的基础上，较准确地估计系统 的开发成本和进度
❖ 修正开发计划
3.2 与用户沟通获取需求的方法
❖ 访谈
❖ 面向数据流自顶向下求精
❖ 信息系统的本质决定数据是需求分析的起点 ❖ 系统分析员一定要搞清楚数据的细节
❖ 分析的对象：高层数据流图（什么阶段得到 的？）
❖ 主要目标：把数据流和数据存储定义到元素
级别（不可分解为止）
数据的来源、去向、数 据结构定义等
3.2.2 面向数据流的自顶向下求精
自顶向下，逐 层细化的方法
❖ 结构化分析方法是一种什么方法呢？
❖ 从数据流图的输出向输入回溯，依次确定每 个数据元素的来源（组成和实现算法）；
❖ 把数据元素的信息记录到数据字典中； ❖ 把对算法的简明描述记录到IPO图中； ❖ 补充的数据流、数据存储和处理应该添加到
数据流图的适当位置上。
用户复查
❖ 数据流图是帮助复查的极好工具； ❖ 分析员向用户解释数据的来源（组成和处理，
现实世界
面
OOAOOP 法
结构化
结 分析
构
化 结构化 开 设计
发
方 法
结构化 编程
计算机世界
结构化分析模型的组成结构
数
加
据 E-R图
数据流图 工
对 象
(DFD) 说
数据字典
明
（DD）
说
明
状态转换图
(STD图)
控制说明
面向对象分析模型的组成结构
操作、 类模/对型象(使Us用e 实Cas例e)对系象模-关型
❖ 确定系统综合要求和分析系统数据要求顺利 完成之后即可导出详细的系统功能模型。
❖ 阶段性成果：
细化后并经过多次校验的数据流图(DFD) 与数据流图相辅相存的数据字典(DD) 概要性的描述主要加工的处理算法(IPO)
3.1.4 分析和设计系统的行为模型
❖ 确定系统的动态变化的方式，采用状态转换 图来描述。
求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，
这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行
分解，用层次的方式展示细节。
需求获取面临的挑战