北京理工大学
软件工程实践
汤铭端
中国航天科工集团公司 706所
第三讲
需求分析
内容
? 需求分析概念
? 需求分析过程
? 需求分析方法
? 需求分析产品
目的
? 掌握需求分析基本概念
? 掌握需求分析过程
? 了解基本需求分析方法（ DFD+DD）
? 了解需求规格说明的内容条目
需求分析概念
软件需求的定义
? 客户定义的, 需求, 对开发者是一个较高层次的产品概念。
? 开发者所说的, 需求, 对用户来说像是详细说明。
? 软件需求包含多个层次，不同层次的需求从不同角度与不
同程度反映着细节问题。
? IEEE软件工程术语（ 1997）的需求定义,
（ 1）用户解决问题或达到目标所需的条件或能力。
（ 2）系统或系统部件要满足合同、标准、规范或其它正
式强制性文件所需具有的条件或能力。
（ 3）反映上面（ 1）或（ 2）所描述的条件或能力的文档
说明。
? 上述定义包括从用户（外部）、从开发者（内部）角度来
阐述需求。
需求的层次
? 业务需求（ business requirement）：反
映组织机构或客户对系统、产品高层次
的目标要求。
? 用户需求（ user requirement）：描述用
户使用产品必须要完成的任务。
? 功能需求（ functional requirement）：
定义开发人员必须实现的软件功能。
? 需求规格说明中还包括非功能需求。
软件需求各组成部分之间关系
业务需求
用户需求
功能需求 系统需求
质量属性
其它非功能需求
约束条件
项目视图与范围文件
使用实例文档
软件需求规格说明
需求管理的困难性
不成熟的需求分析
1,无足够用户参与
2,用户需求的不断增加
3,摸棱两可的需求
4,不必要的特征（镀金）
5,过于精简的规格说明
6,忽略了用户分类
7,不准确的计划
高质量需求过程的获益
? 开发后期和整个维护阶段的重做的工作大大减少
? Boehm发现可以节省成本 68倍
? 有研究认为可以节省成本 200倍
? 强调产品开发中的通力合作，面向市场，让用户积极
参与，可以建立忠实的客户关系，避免在无用功能上
白耗精力，弥补用户期望和开发者实际开发间的期望
鸿沟
? 采用系统方法将需求分配到各子系统可以简化集成
? 有效的变更控制和影响分析能降低变更的负面影响
? 清晰、无二义的需求文档有利于测试
需求说明的特征
? 完整性
? 正确性
? 可行性
? 必要性
? 划分优先级
? 无二义性
? 可验证性
需求规格说明的特点
? 完整性
? 先用 TBD标明缺项
? 在开发前必须解决所有 TBD
? 一致性
? 可修改性
? 每项需求只在 SRS中出现一次
? 可追踪性
? 结构、粒度方便设计、实现、测试的追踪
谁是客户
? 定制软件：合同甲方（提出方）
? 通用软件：高层管理者和（或）市场部
? 嵌入式软件：软件所属计算机系统
客户的权利
1 要求分析人员使用符合客户语言习惯的表达
2 要求分析人员了解客户的业务及目标
3 要求分析人员编写软件需求规格说明
4 要求得到需求工作结果的解释说明
5 要求开发人员尊重你的意见
6 要求开发人员对需求及产品实施提供建议
7 描述产品易使用的特性
8 调整需求，允许重用已有的软件组件
9 要求对变更的代价提供真实可信的评估
10 获得满足客户功能和质量要求的系统
客户的义务
1 给分析人员讲解你的业务
2 抽出时间清楚地说明并完善需求
3 准确而详细地说明需求
4 及时地作出决定
5 尊重开发人员的需求可行性及成本评估
6 划分需求优先级别
7 评审需求文档和原型
8 需求出现变更要马上联系
9 应遵守开发机构处理需求变更的过程
10 尊重开发人员采用的需求工程过程
对签定需求协议的认识
? 签约是客户同意需求的标志行为
? 客户不应当忽略签约的严肃性
? 开发方不应当因此拒绝变更
? 签约应当建立在一个需求协议的基线上
? 应当理解为：, 我同意这份文档表达了目前我
们对项目软件需求的了解。进一步的变更可在
此基础上通过项目定义的变更过程来进行。我
知道变更可能会使我们要重新协商成本、资源
和项目时间工期任务等。,
需求开发过程
需求开发过程
? 需求获取
? 需求分析
? 编写需求规格说明
? 需求验证
? 知识培训
? 需求管理
? 项目管理
需求获取的内容
? 在同用户的交流过程中收集各种用户的
信息
? 认真理解用户的各项要求
? 澄清模糊
? 排除不合理
? 明确约束
分析人员的两个信条
第一：只有在彻底了解和掌握了用户的全
部意图之后，才有可能建立起成功的软
件系统。
第二：一切从用户的角度着想，在条件允
许的情况下，应尽可能地保证用户从所
构造的软件系统中获得最大的利益。
容易产生的问题
? 交流障碍
? 误解
? 各方缺乏共同的语言
?, 完整性, 问题
? 需求永远会变化
? 用户本身的意见不一致
? 错误的要求
? 认识上混淆目标和需求
需求获取的过程
? 确定需求开发过程
? 编写项目目标和范围文档
? 将用户群分类并归纳各自特点
? 选择各类用户的产品代表
? 建立起典型用户的核心队伍
? 让用户代表确定使用实例
? 召开应用程序开发联系会议
? 分析用户工作流程
? 确定质量属性和其它非功能属性
? 通过检查当前系统的问题报告来进一步完善需求
? 跨项目重用需求
工作流程
用户
调查 具体模型
逻辑
抽象
当前系统
逻辑模型
当前系统 计算
机化
评审
修改 正式模型
完善
细节
目标系统 目标系统 初始模型
系统模型 用户
建立模型的步骤
? 分析现有系统和过程，建立物理模型
? 抽取特征，建立旧系统的逻辑模型
? 根据新的要求，补充和建立新的逻辑模
型
需求分析的任务
需求分析的内容
? 提炼、分析和仔细审查已收集到的需求
? 确保所有利益相关者都明白其含义并找
出其中的错误、遗漏或其它不足的地方
? 是从用户最初的非形式化需求到满足用
户要求的软件产品的映射过程
? 是对用户意图不断进行提示和判断的过
程
需求分析的步骤
? 绘制系统关联图
? 创建用户接口（界面）原型
? 分析需求可行性
? 确定需求的优先级别
? 为需求建立模型
? 创建数据字典
? 使用质量功能调配（ QFD）
? 明确哪些是客户最关心的特征
编制需求规格说明的过程
? 采用软件需求规格说明（ SRS）模版
? 指明需求的来源
? 为每项需求注上标号
? 记录业务规范（操作原则）
? 创建需求跟踪矩阵
需求规格说明的作用
? 为用户、分析人员和设计人员之间的交
流提供方便
? 支持目标软件系统的确认
? 控制软件开发进程
软件需求规格说明文档条目
1 范围
2 引用文档
3 工程需求
3.1 外部接口需求
3.2 功能需求
3.3 内部接口
3.4 数据元素要求
3.5 适应性要求
3.6 容量和时间要求
3.7 安全要求
3.8 保密要求
3.9 设计约束
3.10 软件质量因素
3.11 人的工程需求
3.12 需求的可跟踪性
4 合格性需求
4.1 合格性方法
4.2 特殊的合格性需求
5 交付准备
软件需求必须包括的属性
1） 标识：每项软件需求都必须有标识, 使以后的各阶段容易跟踪 。
2） 需要：基础软件需求必须用上述标识标明 。 基础软件需求是非协
商性的；其它不那么重要的需求是可协商的 。
3） 优先级：对于递增式交付, 每一项需求必须包括优先级程度, 以
便决定研制进度 。
4） 稳定性：某些需求在软件生存期内是稳定的；另一些可能是更依
赖来自各设计阶段的反馈, 或可能在软件生存期内要有所修改,
这种非稳定性需求应当被指出 。
5） 源：每一项软件需求都必须有一个能回溯到系统需求的索引 。
6） 清晰性：如果需求有一个并且只有一个解释它就是清晰的 。
7） 验证性：每一软件需求都必须是能被验证的 。 这意味着必须能做
到：检查需求已经体现在设计中；证明该软件将实现需求；测试
该软件确实能实现需求 。
IEEE需求规格说明的编写 8原则
1 从实际重分离功能，描述, 做什么, 不描述, 怎么做,
2 要求有一个面向处理的软件系统规格说明语言，以描述
软件系统的动态行为
3 必须对以该软件为元素的系统进行说明，以描述清楚之
间的关系
4 必须对软件系统的运行环境进行说明，以保持接口描述
的一致性
5 必须是认识的模型而不是实际的模型
6 必须是可操作的
7 必须容忍不完备性和可修改性
8 必须局部化和松散耦合，使得变化时只修改一个片段
SRS编写风格（ Kovitz 1999)
? 保持语句和段落的简短
? 采取主动语态的表达方式
? 编写具有正确的语法、拼写和标点的完整句子
? 使用的术语和词汇表中所定义的应该一致
? 需求陈述应该采用一致的样式，如, 主体 +动
作 +可观察的结果,
? 避免使用模糊的、主观的术语以避免不确定性
? 避免使用比较性的词汇
需求表达
? 需求说明语句
? 保持语句和段落的简短
? 采用主动语态的表达方式
? 编写具有正确的语法和标点的完整句子
? 使用的术语应该和词汇表中定义的一致
? 需求陈述应该具有一致的式样，例如, 系统必
须 ……”,或者, 用户必须 ……”,并紧跟一个行为
动作和可观察的结果，例如, 仓库管理子系统必须
现实一张在所请求的仓库中有存货的药品名单。,
需求表达
? 为了减少不确定性，避免采用模糊的、主观
的术语，例如，用户友好、容易、简单、迅
速、有效、支持、许多、最新技术、优越的、
可接受的和健壮的。
? 避免使用比较性的词汇，例如：提高，最大
化，最小化和最佳化。定量地说明所需要提
高的程度或者说清一些参数可接受的最大值
和最小值。
需求表达
?,产品必须在固定的时间间隔内提供状态消息，
并且每次时间间隔不得小于 60秒,
? 后台任务管理器应该在用户界面的指定区域显示状
态消息
? 在后台任务进程启动之后，消息必须每隔 60（ +_10）
秒更新一次，并且保持连续的可见性。
? 如果正在正常处理后台任务进程，那么后台任务管
理器必须显示后台任务进程已完成的百分比
? 当完成后台任务时，后台任务管理器必须显示一个
,已完成, 的消息。
? 如果后台任务中止执行，那么后台任务管理器必须
显示一个出错信息。
需求表达
?,产品必须在显示和隐藏非打印字符之间
进行瞬间切换,
?, 用户在编辑文档时，通过激活特定的触发
机制，可以在显示和隐藏所有 HTML标记之间
进行切换。,
需求表达
?,分析程序应该能生成 HTML标记出错的报告，
这样就可以使 HTML的初学者使用它来迅速排错,
? 在 HTML分析程序完全分析完一个文件后，该分析程
序必须生成一个出错报告，这个报告中包含了在分
析文件中所发生错误的 HTML所在的行号以及文本内
容，还包含了对每个错误的描述。
? 如果分析过程中未发生任何错误，就不必生成任何
错误报告
需求验证
? 审查需求文档
? 以需求为依据编写测试用例
? 编写用户手册
? 确定判别产品合格的准则
需求验证的内容
? 一致性：任何需求不与其它需求矛盾
? 可行性：现有技术条件下可以实现
? 完整性：包括用户需要的每一个功能和
性能
? 有效性：正确有效，确实能够解决用户
面对的问题
知识培训
? 培训需求分析人员
? 培训软件需求的用户代表和管理人员
? 让开发人员了解应用领域的基本概念
? 编写项目术语汇编
分析员的职责
１ ） 作为管理员, 用户和顾客的顾问；
２ ） 从各种来源收集数据, 并综合问题的解答；
３ ） 分析新的系统, 并评价现有的系统；
４ ） 准备文档和管理报告；
５ ） 理解硬件和软件的界面；
６ ） 为了产生软件需求规格说明, 必要时要进行
一些研究工作；
７ ） 为编写软件需求规格说明主持座谈会；
８ ） 不断吸收先进技术 。
分析员的素质
１ ） 能够合乎逻辑地, 象征性地, 抽象地, 创造性地思
考问题；
２ ） 能作为小组中的一个成员很好地开展工作；
３ ） 熟悉计算机硬件和软件的能力；
４ ） 自觉遵守时间, 能按规定的进度完成任务；
５ ） 在系统的分析和设计中能发挥其他人的作用；
６ ） 能保持教师和学生的双重身份, 愿意培养其他人,
而他本人亦能通过夜校, 自学, 培训班等不断提高；
７ ） 能够倾听别人的意见, 但又能根据客观事实来作决
策, 而不是依赖别人的意见；
８ ） 熟悉商业和政策管理部门的组织, 原则 。
分析员应该显示的性格特征
1） 善于领会一些抽象的概念, 重新整理使之成为各
种逻辑成分, 并根据各种逻辑成分综合出问题的
解决办法 。
2） 善于从各种相应冲突或混淆的原始资料中汲取恰
当的依据 。
3） 能够理解用户 ——需求者的环境 。
4） 具备把系统的硬件部分和 （ 或 ） 软件部分应用于
用户 ——需求者环境的能力 。
5） 具备良好的用书面或口头形式进行讨论及交换意
见的能力 。
6） 具有, 既能看到树木, 又能看到森林, 的能力 。
需求管理
? 确定需求变更控制过程
? 建立变更控制委员会（ CCB）
? 进行需求变更影响分析
? 跟踪所有受需求变更影响的工作产品
? 建立需求基准版本和需求控制版本文档
? 维护需求变更历史记录
? 跟踪每项需求的状态
? 衡量需求稳定性
? 使用需求管理工具
与需求分析相关的项目管理
? 选择一种合适的软件开发模型
? 基于需求的项目计划
? 发生需求变更时协商项目约定
? 文档化和管理与需求相关的风险
? 跟踪需求工程耗费的工作量
需求分析方法工具
描述工具
? 数据流图 (Data Flow Diagram，简称 DFD)
? 控制流图 (Control Flow Diagram，简称
CFD)
? 状态转换图（ State Transition diagram，
简称 STD）
? 数据字典 (Data Dictionary，简称 DD)
? 处理说明
分析模型的结构
实体 —
关系图
状态 —迁移图
数据流
图
数据对象描述 加工规格说明
数据
字典
控制规格说明
数据和控制模型的关系
过程模型
PSPEC
DFD
控制模型
CSPEC
CFD
控制输入
数据输出
控制输出
数据输入
数
据
条
件
过
程
启
动
数据流图,DFD（ Data Flow Diagram）
? 数据流图是用来描述系统逻辑模型的一
种图形工具
? 数据流图从数据传递和加工的角度，以
图形的方式刻画数据流从输入到输出的
移动变换过程
数据流图图符
2.1
打印
数据流 Data Flow
加工处理 Process
外部实体 External Entity 数据存储 Data Store
数据流图图符说明
? 数据流：箭头表示数据流方向。一般在旁边标
注数据流名。
? 加工处理：对数据进行加工、处理和变换，从
而实现某个功能或操作
? 外部实体：表示要加工处理的数据是从外部得
到或从外部提供，同时也是数据结果的接收者，
可以是人、组织、其它系统
? 数据存储：表示处理过程中存放各种数据的文
件
建立 DFD的步骤
? 由外向里,先 画系统的输入输出, 然后
画系统的内部, 再画处理的内部 。
? 由顶向下,顶层, 中间层, 底层数据流
图
? 逐层分解,从外向里
数据流图的层次结构
? 为了表达数据处理过程的数据加工
情况，需要采用 层次结构 的数据流
图。按照系统的层次结构进行 逐步
分解,并以分层的数据流图反映这
种结构关系，能清楚地表达和容易
理解整个系统
数据流图的层次
顶层 DFD
? 用一个加工处理表示软件
? 含所有相关外部实体
? 含外部实体与软件中间的
数据流
? 不含数据存储
? 唯一
? 描述软件的作用范围，对
总体功能、输入、输出进
行抽象描述，反映软件和
系统、环境的关系
A B
C
软件
a b c
d
顶层数据流图
软件
系统
外部实体
外部实体
… …
外部实体
外部实体
… …
中间和底层 DFD
2.1
aaa
2.2
bbb
2.3
ccc
ddd数据
分层的数据流图
F0
F11
F12
F13
F14 F15
F21
F22
F23
F24
F25
第 n 层
第 n+1 层
第 n+2 层
数据流图的层次
? 在多层数据流图中,顶层流图 仅包含 一
个加工,它代表被开发系统。它的输入
流是该系统的输入数据，输出流是系统
所输出数据
? 底层流图 是指其 加工不需再做分解 的数
据流图，它处在最底层
? 中间层流图 则表示 对其上层父图的细化 。
它的每一加工可能继续细化，形成子图。
数据流图中的其它图形元素
A
B
C
------ 有 A 则 B 或者 C，或者两者都有
* A
B
C
+ A
B
C
------ 有 A 则 B 与 C，或者两者同时有
------ 有 A 则 B 或 C，但不会同时有 B与 C
------ 当 A 或 B 有一个存在就有 C
A
B C
*
A
B C ------ 只有当 A 与 B 都存在，则有 C
DFD规则和注意事项
? 数据存储不出现在顶层图中，外部实体通常不
出现在顶层图外
? 数据存储之间不应该有数据流
? 仔细、恰当地为处理命名：处理 +对象
? 仔细、恰当地为数据流命名：反映整体含义
? 对处理建立唯一、层次性编号
? 每个处理通常要求既有输入又有输出
? 一个 DFD的处理个数为 7± 2（魔数 7 ± 2）
? 不要试图让 DFD反映处理的顺序
检查数据流图的正确性
a,数据守恒
? 某个处理用以产生输出的数据没有输入给这个处理，
即出现遗漏
? 另一种是一个处理的某些输入并没有在处理中使用
以产生输出
b,数据存储（文件）的使用
? 数据存储（文件）应被数据流图中的处理读和写，
而不是仅读不写、或仅写不读
c,父图和子图的平衡
父子关系和平衡规则
? 父图表示子图间的接口，即数据流的方
向和数量
? 子图代表父图中某个处理的细节
? 子图个数不大于父图中的处理个数
? 所有子图的输入、输出数据流和父图中
相应处理的输入、输出数据流必须一致
父图和子图的平衡
发票 1.3
开领书单
领书单
(a) 父图
1.3.1 学生
领书单
1.3.2
1.3.3 教材
(b)子图
遵守加工编号规则
? 顶层加工不编号
? 第二层的加工编号为 1,2,3,…,n号
? 第三层编号为 1.1,1.2,1.3… n.1,n.2…
等号
? 依此类推
人工销售教材 系统流程图
举 例
学生
开购书
证明
购书
证明 开购书 发票
发 票 收书费
领书单
发书 学生
学
生
教材
购 销
系统
购书单
领书单
缺书单
进书通
知
进书通知
保
管员
1
销售
购书单
领书单
学
生
缺书单
进书通知
2
采购
保
管员
第 1 层
第 2 层
教材存量表 F1
缺书登记表 F2
外部实体 外部实体
教材销售子系统
无效书单
购书单
1.3
登记并开
领书单
1.2
开发票
1.1
审查
有效性
1.4
登记
缺书
1.5
补售
教材
采
购
学
生
学
生
进书通知
有效书单 发票 领书单
暂缺书单
1
销售
购书单
领书单
缺书单
进书通知
2
采购
进书通知
缺书登记表
教材存量表
学
生
保
管员
第 2 层
补售
书单
第 3 层
教材存量表 F1
缺书登记表 F2
F1
书号
单价
数量
各班用书表 F3 售书登记表 F4
外部
项
1
销售
购书单
领书单
缺书单
进书通知
2
采购
进书通知
缺书登记表
教材存量表
学
生
保
管员
采购 子系统
第 2 层
第 3 层
缺书单
2.3
修改教材库
存和待
购量
销
售
进书通知 进书通知
2.1
按书号汇
总缺书
2.2
按出版社统
计缺书
保
管员
教材存量表 F1 待购教材表 F5 教材一览表 F6
缺书登记表 F2
控制板
传感器
家庭
安全
软件
电话线
警 报
控制板显示
警报类型
传感器状态
用户命令和数据
显示数据
电话号码信号
与用户
交互
1
配置
系统
2
启 /停
系统
3
显示消
息状态
5
处理
口令
4
监控
系统
6
配置信息 用户命令和数据
配置请求
配置数据
启 /停
口令
配置数据
配置数据
启 /停消息
显示消息
传感器信息
有效标识消息
传感器状态
电话号码信号
警报类型
评价防
备设置
6.1
显示
格式化
6.2
生成警
报信号
6.3
拨
电话
6.5
读
传感器
6.4
配置信息
传感器标识,类型
传感器状态
电话号码
配置数据
传感器标识,定位
警报数据
传感器信息
电话号码信号
控制流图（ CFD）
2.1
打印
控制流 Control Flow
加工处理 Process
外部实体 External Entity 数据存储 Data Store
控制说明
与用户
交互
1
配置
系统
2
启 /停
系统
3
显示消
息状态
5
处理
口令
4
监控
系统
6
配置信息 显示动作
状态 （ 完
成, 进行
中 ）
控制板
控制板显示
警 报
电话线
传感器
传感器事件
闪烁标志
警报状态
时间溢出
警报信号
启 /停开关
数据字典（ DD）
? 数据字典是对所有与系统相关的数据元
素的一个有组织的列表，以及精确的、
严格的定义，使得用户和系统分析员对
于输入、输出、存储成分和中间计算结
果有共同的理解。
? 数据字典把不同的需求文档和分析模型
紧密结合在一起
数据字典的作用
? DFD中的数据流、数据存储表示某个
有组织的数据集合，它们要由 SA的
其他描述工具 -需求字典 (数据字典 )
来描述,包括,
? 词条描述
? 数据结构描述
? 加工逻辑说明
数据字典的内容
? DD包含的信息
? 名称（标识）
? 别名
? 来源
? 去向
? 组成（内容描述）
? 流动属性（频率、数
据量）
? 补充信息
? 数据的层次关系
? 原数据元素
? 组合项
? 重复项
? 选择项
? 可选项
数据字典基本符号
＝ 表示, 等于,,, 定义为,,, 由什么构成,
＋ 表示, 与,,, 和,
[|] 表示, 或,, 即选择括号中用, |”号分隔
的各项中的某一项
{ } 表示, 重复,, 即括号中的项要重复若干次,
重复次数的上下限也可以在括号边上标出
（ ） 表示, 可选,, 即括号中的项可以没有
** 表示, 注释,
（ 1）数据流词条描述
? 数据流名,
? 说明：简要介绍作用即它产生的原
因和结果
? 数据流来源：来自何方
? 数据流去向：去向何处
? 数据流组成：数据结构
? 数据量流通量：数据量，流通量
举例,
购
书
单 发票 领书 单 审查并
开发票
开领
书单
无效书单
学生 1 2
各班学生
用 书 表
学生
教材存量表
数据流词条说明举例
数据流名,发票
别名, 无
简述, 学生购书时填写的项目
来源, 学生
去向, 加工 1,审查并开发票”
组成, (学号 )＋姓名＋｛书号＋数量｝
数据流量,1000次 /周
高峰值,开学期间 1000次 /天
（ 2）数据元素词条描述
? 数据元素名,
? 类型：数字（离散值，连续值），
文字（编码类型）
? 长度,
? 取值范围,
? 相关的数据元素及数据结构,
数据元素词条举例
数据项名,货物编号
别名,G-No,G-num
简述,本公司的所有货物的编号
类型,字符串
长度,10
取值范围及含义,
第 1位,[J｜ G] (进口 /国产 )
第 2-4位,LB01.,LB29 (类别 )
第 5-7位：, A00”..“A99” (规格 )
第 8-10位：, 001”..“999”(品名编号 )
（ 3）数据文件词条描述
? 数据文件名,
? 简述：存放的是什么数据
? 输入数据,
? 输出数据,
? 数据文件组成：数据结构
? 存储方式：顺序，直接，关键码
? 存取频率,
数据文件（存储）词条举例
文件名,库存记录
别名, 无
简述,存放库存所有可供货物的信息
组成, 货物名称＋编号＋生产厂家
＋单价＋库存量
组织方式,索引文件，以货物编号为
关键字
查询要求,要求能够立即查询
（ 4）加工逻辑词条描述
? 加工名,
? 加工编号：反映该加工的层次
? 简要描述：加工逻辑及功能简述
? 输入数据流,
? 输出数据流,
? 加工逻辑：简述加工程序，加工顺
序
加工逻辑词条举例
加工逻辑名,登记报名单
编号,1.0
激活条件：收到报名单
加工逻辑,{1.1 检查报名单
+ 1.2 编准考证号
+ 1.3 登记考生 }
执行频率,2000次 /日
（ 5）源点及汇 (终 )点词条描述
? 名称：外部实体名
? 简要描述：什么外部实体
? 有关数据流,
? 数目,
DD表示
F1:航班信息文件 ＝ {航空公司名称＋航班号＋起点＋终点＋日期 ＋起飞时
间＋降落时间 }
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
字母＝, A”…,Z”
十进制数字＝, 0”…,9”
起点＝终点＝ 1{汉字 }10
起飞时间＝降落时间＝时＋分
时＝, 00”…,23”
分＝, 00”…,59”
日期＝年＋月＋日
年＝ [2000｜ 2001｜ 2002｜ 2004]
月＝, 01”…,12”
日＝, 01”…,31”
数据组合
重复项,起点＝终点＝ 1{汉字 }10
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
组合项,日期＝年＋月＋日
起飞时间＝降落时间＝时＋分
选择项,年＝ [2000｜ 2001｜ 2002｜ 2004]
原数据项,字母＝, A”…,Z”
十进制数字＝, 0”…,9”
时＝, 00”…,23”
分＝, 00”…,59”
月＝, 01”…,12”
日＝, 01”…,31”
限制重复次数举例
｛ 3 5 或 5 3 ｛ ｝ 表示允许重复 3-5次 ｛ ｝
3 3 或 3 3 ｛ ｝ 表示恰好重复 3 次 ｛ ｝
｛ ｝
｛ ｝
1 表示至少出现 1 次
表示允许重复 0至任意 次
办理取款手续的 DFD 图
储
户
检验
付款 登录
存折
帐卡
检验不合格
现款 付款信息
存折格式
日期
年月日 摘要 支出 存入 余额 操作 复核
户名, 储蓄网点名称, 帐号, 开户日,
性质, 印密,
DD
存折 = 户名 +所号 +帐号 +开户日 +性质 +(印密 )+1{存取行 }20
户名 = 2{字母 }24
所号 =,001”..“999”
帐号 =,00000001”..“99999999”
开户日 = 年 +月 +日
性质 =,1”..“6”
印密 =,0”
存取行 = 日期 +（摘要） +支出 +存入 +余额 +操作 +复核
日期 =年 +月 +日
年 =,1900”..“3000” 月 =,01”..“12” 日 =,01”..“31”
摘要 = 1{字母 }4
支出 = 金额
金额 =,00000000.01”..“999999999.99” … …
数据字典示例
电话号码 =[当地分机号 |外地号码 ]
当地分机号 =[2001|2002… |2999]
外地号码 =9+[当地号码 |长途号码 ]
当地号码 =前缀 +访问的号码
长途号码 =（ 1） +区号 +当地号码
前缀 =[795|799|874|877]
访问的号码 ={[0|1|2|3|4|5|6|7|8|9]}4
区号 =
状态转换图（ STD）
? 通过描述状态以及导致系统改变状态的
事件来表示系统的行为
? STD可以被用来描述 CSPEC
? STD的基本符号,
? (1)状态
? (2)转移
STD示意
系统在, 状态 1”
当, 事件 1”发
生时采取, 动
作 1”将状态转
移到, 状态 3”
状态 1
状态 3
状态 2 事件 1
动作 1
事件 2
动作 2
事件 3
动作 3
事件 4
动作 4
读
用户输入
监控
系统状态
基于传感器
事件的动作
显示
用户反馈
闪烁标记
引发显示消息与状态
时间溢出
引发与用户交互
启 /停开关
引发监控系统
无传感器事件
引发监控系统
传感器事件
引发显示消息与状态
启 /停开关
引发显示消息与状态 显示动作状态
引发与用户交互
处理说明
? 数据流图的每一个基本处理 （ 即不再进一步被
分解的处理 ） 都必须有一个处理说明给出这个
处理的精确描述 。 而其它中间处理则可以没有
处理说明, 事实上它可由其子处理, 子子处理
的说明来描述 。
? 理想的处理说明应该既严格精确又容易被软件
设计人员和用户理解 。 但目前通常还是用自然
语言书写的 。 此外, 常用的方式还有结构化语
言, 决策表, 决策树等 。
处理说明的要求
? 对数据流图的每一个基本处理，必须有
一个基本处理说明
? 基本处理说明必须描述基本处理如何把
输入数据流变换为输出数据流的处理规
则
? 处理说明必须描述实现处理的策略而不
是实现处理的细节
? 处理说明中包含的信息应是充足的，完
备的，有用的，无冗余的
加工说明组成
输入
数据
加工
逻辑
输出
数据
加工说明
描述工具
结构化
语言
判定
表
判定
树
描述把输入数据流变
换为输出数据流的加工过
程，是加工说明的主体。
（ 1）结构化语言（英语）
? 结构化英语的词汇表由
? 英语命令动词
? 数据词典中定义的名字
? 有限的自定义词
? 逻辑关系词 IF_THEN_ELSE,
CASE_OF, WHILE_DO,
REPEAT_UNTIL等组成。
结构化语言
? 是一种介于自然语言和形式化语言之间的语言
? 语言的 正文用基本控制结构进行分割,加工中
的 操作用自然语言短语来表示
? 其基本控制结构有三种,
? 简单陈述句结构,避免复合语句；
? 重复结构, while_do 或
repeat_until 结构。
? 判定结构, if_then_else 或
case_of 结构；
商店业务处理系统中“检查发货
单”
if 发货单金额超过 $500 then
if 欠款超过了 60天 then
在偿还欠款前不予批准
else （欠款未超期）
发批准书，发货单
else （发货单金额未超过 $500）
if 欠款超过 60天 then
发批准书，发货单及赊欠报告
else （欠款未超期）
发批准书，发货单
（ 2）判定表
? 如果数据流图的加工需要依赖于
多个逻辑条件的取值,使用判定
表来描述比较合适
以“检查发货单”为例
判定表格式
（ 3）判定树
? 判定树也是用来表达加工逻辑的一种工
具。有时侯它比判定表更直观。
检
查
发
货
单
金额 >$500
金额 ?$500
欠款 >60天 不发出批准书
欠款 ?60天
发货单
发出批准书,
欠款 >60天 发出批准书,
发货单及赊欠报告
欠款 ?60天 发出批准书,发货单
练习题
? 对以下软件建立软件需求规格说明文档,
? 辅助图书馆处理借还图书的软件系统
? 缺少条件可自行假设
? 在复习前和其它练习题结果一起提交
谢谢！
68389085（ O）
68389504（ H）
mdtang@btamail.net.cn
软件工程实践
汤铭端
中国航天科工集团公司 706所
第三讲
需求分析
内容
? 需求分析概念
? 需求分析过程
? 需求分析方法
? 需求分析产品
目的
? 掌握需求分析基本概念
? 掌握需求分析过程
? 了解基本需求分析方法（ DFD+DD）
? 了解需求规格说明的内容条目
需求分析概念
软件需求的定义
? 客户定义的, 需求, 对开发者是一个较高层次的产品概念。
? 开发者所说的, 需求, 对用户来说像是详细说明。
? 软件需求包含多个层次，不同层次的需求从不同角度与不
同程度反映着细节问题。
? IEEE软件工程术语（ 1997）的需求定义,
（ 1）用户解决问题或达到目标所需的条件或能力。
（ 2）系统或系统部件要满足合同、标准、规范或其它正
式强制性文件所需具有的条件或能力。
（ 3）反映上面（ 1）或（ 2）所描述的条件或能力的文档
说明。
? 上述定义包括从用户（外部）、从开发者（内部）角度来
阐述需求。
需求的层次
? 业务需求（ business requirement）：反
映组织机构或客户对系统、产品高层次
的目标要求。
? 用户需求（ user requirement）：描述用
户使用产品必须要完成的任务。
? 功能需求（ functional requirement）：
定义开发人员必须实现的软件功能。
? 需求规格说明中还包括非功能需求。
软件需求各组成部分之间关系
业务需求
用户需求
功能需求 系统需求
质量属性
其它非功能需求
约束条件
项目视图与范围文件
使用实例文档
软件需求规格说明
需求管理的困难性
不成熟的需求分析
1,无足够用户参与
2,用户需求的不断增加
3,摸棱两可的需求
4,不必要的特征（镀金）
5,过于精简的规格说明
6,忽略了用户分类
7,不准确的计划
高质量需求过程的获益
? 开发后期和整个维护阶段的重做的工作大大减少
? Boehm发现可以节省成本 68倍
? 有研究认为可以节省成本 200倍
? 强调产品开发中的通力合作，面向市场，让用户积极
参与，可以建立忠实的客户关系，避免在无用功能上
白耗精力，弥补用户期望和开发者实际开发间的期望
鸿沟
? 采用系统方法将需求分配到各子系统可以简化集成
? 有效的变更控制和影响分析能降低变更的负面影响
? 清晰、无二义的需求文档有利于测试
需求说明的特征
? 完整性
? 正确性
? 可行性
? 必要性
? 划分优先级
? 无二义性
? 可验证性
需求规格说明的特点
? 完整性
? 先用 TBD标明缺项
? 在开发前必须解决所有 TBD
? 一致性
? 可修改性
? 每项需求只在 SRS中出现一次
? 可追踪性
? 结构、粒度方便设计、实现、测试的追踪
谁是客户
? 定制软件：合同甲方（提出方）
? 通用软件：高层管理者和（或）市场部
? 嵌入式软件：软件所属计算机系统
客户的权利
1 要求分析人员使用符合客户语言习惯的表达
2 要求分析人员了解客户的业务及目标
3 要求分析人员编写软件需求规格说明
4 要求得到需求工作结果的解释说明
5 要求开发人员尊重你的意见
6 要求开发人员对需求及产品实施提供建议
7 描述产品易使用的特性
8 调整需求，允许重用已有的软件组件
9 要求对变更的代价提供真实可信的评估
10 获得满足客户功能和质量要求的系统
客户的义务
1 给分析人员讲解你的业务
2 抽出时间清楚地说明并完善需求
3 准确而详细地说明需求
4 及时地作出决定
5 尊重开发人员的需求可行性及成本评估
6 划分需求优先级别
7 评审需求文档和原型
8 需求出现变更要马上联系
9 应遵守开发机构处理需求变更的过程
10 尊重开发人员采用的需求工程过程
对签定需求协议的认识
? 签约是客户同意需求的标志行为
? 客户不应当忽略签约的严肃性
? 开发方不应当因此拒绝变更
? 签约应当建立在一个需求协议的基线上
? 应当理解为：, 我同意这份文档表达了目前我
们对项目软件需求的了解。进一步的变更可在
此基础上通过项目定义的变更过程来进行。我
知道变更可能会使我们要重新协商成本、资源
和项目时间工期任务等。,
需求开发过程
需求开发过程
? 需求获取
? 需求分析
? 编写需求规格说明
? 需求验证
? 知识培训
? 需求管理
? 项目管理
需求获取的内容
? 在同用户的交流过程中收集各种用户的
信息
? 认真理解用户的各项要求
? 澄清模糊
? 排除不合理
? 明确约束
分析人员的两个信条
第一：只有在彻底了解和掌握了用户的全
部意图之后，才有可能建立起成功的软
件系统。
第二：一切从用户的角度着想，在条件允
许的情况下，应尽可能地保证用户从所
构造的软件系统中获得最大的利益。
容易产生的问题
? 交流障碍
? 误解
? 各方缺乏共同的语言
?, 完整性, 问题
? 需求永远会变化
? 用户本身的意见不一致
? 错误的要求
? 认识上混淆目标和需求
需求获取的过程
? 确定需求开发过程
? 编写项目目标和范围文档
? 将用户群分类并归纳各自特点
? 选择各类用户的产品代表
? 建立起典型用户的核心队伍
? 让用户代表确定使用实例
? 召开应用程序开发联系会议
? 分析用户工作流程
? 确定质量属性和其它非功能属性
? 通过检查当前系统的问题报告来进一步完善需求
? 跨项目重用需求
工作流程
用户
调查 具体模型
逻辑
抽象
当前系统
逻辑模型
当前系统 计算
机化
评审
修改 正式模型
完善
细节
目标系统 目标系统 初始模型
系统模型 用户
建立模型的步骤
? 分析现有系统和过程，建立物理模型
? 抽取特征，建立旧系统的逻辑模型
? 根据新的要求，补充和建立新的逻辑模
型
需求分析的任务
需求分析的内容
? 提炼、分析和仔细审查已收集到的需求
? 确保所有利益相关者都明白其含义并找
出其中的错误、遗漏或其它不足的地方
? 是从用户最初的非形式化需求到满足用
户要求的软件产品的映射过程
? 是对用户意图不断进行提示和判断的过
程
需求分析的步骤
? 绘制系统关联图
? 创建用户接口（界面）原型
? 分析需求可行性
? 确定需求的优先级别
? 为需求建立模型
? 创建数据字典
? 使用质量功能调配（ QFD）
? 明确哪些是客户最关心的特征
编制需求规格说明的过程
? 采用软件需求规格说明（ SRS）模版
? 指明需求的来源
? 为每项需求注上标号
? 记录业务规范（操作原则）
? 创建需求跟踪矩阵
需求规格说明的作用
? 为用户、分析人员和设计人员之间的交
流提供方便
? 支持目标软件系统的确认
? 控制软件开发进程
软件需求规格说明文档条目
1 范围
2 引用文档
3 工程需求
3.1 外部接口需求
3.2 功能需求
3.3 内部接口
3.4 数据元素要求
3.5 适应性要求
3.6 容量和时间要求
3.7 安全要求
3.8 保密要求
3.9 设计约束
3.10 软件质量因素
3.11 人的工程需求
3.12 需求的可跟踪性
4 合格性需求
4.1 合格性方法
4.2 特殊的合格性需求
5 交付准备
软件需求必须包括的属性
1） 标识：每项软件需求都必须有标识, 使以后的各阶段容易跟踪 。
2） 需要：基础软件需求必须用上述标识标明 。 基础软件需求是非协
商性的；其它不那么重要的需求是可协商的 。
3） 优先级：对于递增式交付, 每一项需求必须包括优先级程度, 以
便决定研制进度 。
4） 稳定性：某些需求在软件生存期内是稳定的；另一些可能是更依
赖来自各设计阶段的反馈, 或可能在软件生存期内要有所修改,
这种非稳定性需求应当被指出 。
5） 源：每一项软件需求都必须有一个能回溯到系统需求的索引 。
6） 清晰性：如果需求有一个并且只有一个解释它就是清晰的 。
7） 验证性：每一软件需求都必须是能被验证的 。 这意味着必须能做
到：检查需求已经体现在设计中；证明该软件将实现需求；测试
该软件确实能实现需求 。
IEEE需求规格说明的编写 8原则
1 从实际重分离功能，描述, 做什么, 不描述, 怎么做,
2 要求有一个面向处理的软件系统规格说明语言，以描述
软件系统的动态行为
3 必须对以该软件为元素的系统进行说明，以描述清楚之
间的关系
4 必须对软件系统的运行环境进行说明，以保持接口描述
的一致性
5 必须是认识的模型而不是实际的模型
6 必须是可操作的
7 必须容忍不完备性和可修改性
8 必须局部化和松散耦合，使得变化时只修改一个片段
SRS编写风格（ Kovitz 1999)
? 保持语句和段落的简短
? 采取主动语态的表达方式
? 编写具有正确的语法、拼写和标点的完整句子
? 使用的术语和词汇表中所定义的应该一致
? 需求陈述应该采用一致的样式，如, 主体 +动
作 +可观察的结果,
? 避免使用模糊的、主观的术语以避免不确定性
? 避免使用比较性的词汇
需求表达
? 需求说明语句
? 保持语句和段落的简短
? 采用主动语态的表达方式
? 编写具有正确的语法和标点的完整句子
? 使用的术语应该和词汇表中定义的一致
? 需求陈述应该具有一致的式样，例如, 系统必
须 ……”,或者, 用户必须 ……”,并紧跟一个行为
动作和可观察的结果，例如, 仓库管理子系统必须
现实一张在所请求的仓库中有存货的药品名单。,
需求表达
? 为了减少不确定性，避免采用模糊的、主观
的术语，例如，用户友好、容易、简单、迅
速、有效、支持、许多、最新技术、优越的、
可接受的和健壮的。
? 避免使用比较性的词汇，例如：提高，最大
化，最小化和最佳化。定量地说明所需要提
高的程度或者说清一些参数可接受的最大值
和最小值。
需求表达
?,产品必须在固定的时间间隔内提供状态消息，
并且每次时间间隔不得小于 60秒,
? 后台任务管理器应该在用户界面的指定区域显示状
态消息
? 在后台任务进程启动之后，消息必须每隔 60（ +_10）
秒更新一次，并且保持连续的可见性。
? 如果正在正常处理后台任务进程，那么后台任务管
理器必须显示后台任务进程已完成的百分比
? 当完成后台任务时，后台任务管理器必须显示一个
,已完成, 的消息。
? 如果后台任务中止执行，那么后台任务管理器必须
显示一个出错信息。
需求表达
?,产品必须在显示和隐藏非打印字符之间
进行瞬间切换,
?, 用户在编辑文档时，通过激活特定的触发
机制，可以在显示和隐藏所有 HTML标记之间
进行切换。,
需求表达
?,分析程序应该能生成 HTML标记出错的报告，
这样就可以使 HTML的初学者使用它来迅速排错,
? 在 HTML分析程序完全分析完一个文件后，该分析程
序必须生成一个出错报告，这个报告中包含了在分
析文件中所发生错误的 HTML所在的行号以及文本内
容，还包含了对每个错误的描述。
? 如果分析过程中未发生任何错误，就不必生成任何
错误报告
需求验证
? 审查需求文档
? 以需求为依据编写测试用例
? 编写用户手册
? 确定判别产品合格的准则
需求验证的内容
? 一致性：任何需求不与其它需求矛盾
? 可行性：现有技术条件下可以实现
? 完整性：包括用户需要的每一个功能和
性能
? 有效性：正确有效，确实能够解决用户
面对的问题
知识培训
? 培训需求分析人员
? 培训软件需求的用户代表和管理人员
? 让开发人员了解应用领域的基本概念
? 编写项目术语汇编
分析员的职责
１ ） 作为管理员, 用户和顾客的顾问；
２ ） 从各种来源收集数据, 并综合问题的解答；
３ ） 分析新的系统, 并评价现有的系统；
４ ） 准备文档和管理报告；
５ ） 理解硬件和软件的界面；
６ ） 为了产生软件需求规格说明, 必要时要进行
一些研究工作；
７ ） 为编写软件需求规格说明主持座谈会；
８ ） 不断吸收先进技术 。
分析员的素质
１ ） 能够合乎逻辑地, 象征性地, 抽象地, 创造性地思
考问题；
２ ） 能作为小组中的一个成员很好地开展工作；
３ ） 熟悉计算机硬件和软件的能力；
４ ） 自觉遵守时间, 能按规定的进度完成任务；
５ ） 在系统的分析和设计中能发挥其他人的作用；
６ ） 能保持教师和学生的双重身份, 愿意培养其他人,
而他本人亦能通过夜校, 自学, 培训班等不断提高；
７ ） 能够倾听别人的意见, 但又能根据客观事实来作决
策, 而不是依赖别人的意见；
８ ） 熟悉商业和政策管理部门的组织, 原则 。
分析员应该显示的性格特征
1） 善于领会一些抽象的概念, 重新整理使之成为各
种逻辑成分, 并根据各种逻辑成分综合出问题的
解决办法 。
2） 善于从各种相应冲突或混淆的原始资料中汲取恰
当的依据 。
3） 能够理解用户 ——需求者的环境 。
4） 具备把系统的硬件部分和 （ 或 ） 软件部分应用于
用户 ——需求者环境的能力 。
5） 具备良好的用书面或口头形式进行讨论及交换意
见的能力 。
6） 具有, 既能看到树木, 又能看到森林, 的能力 。
需求管理
? 确定需求变更控制过程
? 建立变更控制委员会（ CCB）
? 进行需求变更影响分析
? 跟踪所有受需求变更影响的工作产品
? 建立需求基准版本和需求控制版本文档
? 维护需求变更历史记录
? 跟踪每项需求的状态
? 衡量需求稳定性
? 使用需求管理工具
与需求分析相关的项目管理
? 选择一种合适的软件开发模型
? 基于需求的项目计划
? 发生需求变更时协商项目约定
? 文档化和管理与需求相关的风险
? 跟踪需求工程耗费的工作量
需求分析方法工具
描述工具
? 数据流图 (Data Flow Diagram，简称 DFD)
? 控制流图 (Control Flow Diagram，简称
CFD)
? 状态转换图（ State Transition diagram，
简称 STD）
? 数据字典 (Data Dictionary，简称 DD)
? 处理说明
分析模型的结构
实体 —
关系图
状态 —迁移图
数据流
图
数据对象描述 加工规格说明
数据
字典
控制规格说明
数据和控制模型的关系
过程模型
PSPEC
DFD
控制模型
CSPEC
CFD
控制输入
数据输出
控制输出
数据输入
数
据
条
件
过
程
启
动
数据流图,DFD（ Data Flow Diagram）
? 数据流图是用来描述系统逻辑模型的一
种图形工具
? 数据流图从数据传递和加工的角度，以
图形的方式刻画数据流从输入到输出的
移动变换过程
数据流图图符
2.1
打印
数据流 Data Flow
加工处理 Process
外部实体 External Entity 数据存储 Data Store
数据流图图符说明
? 数据流：箭头表示数据流方向。一般在旁边标
注数据流名。
? 加工处理：对数据进行加工、处理和变换，从
而实现某个功能或操作
? 外部实体：表示要加工处理的数据是从外部得
到或从外部提供，同时也是数据结果的接收者，
可以是人、组织、其它系统
? 数据存储：表示处理过程中存放各种数据的文
件
建立 DFD的步骤
? 由外向里,先 画系统的输入输出, 然后
画系统的内部, 再画处理的内部 。
? 由顶向下,顶层, 中间层, 底层数据流
图
? 逐层分解,从外向里
数据流图的层次结构
? 为了表达数据处理过程的数据加工
情况，需要采用 层次结构 的数据流
图。按照系统的层次结构进行 逐步
分解,并以分层的数据流图反映这
种结构关系，能清楚地表达和容易
理解整个系统
数据流图的层次
顶层 DFD
? 用一个加工处理表示软件
? 含所有相关外部实体
? 含外部实体与软件中间的
数据流
? 不含数据存储
? 唯一
? 描述软件的作用范围，对
总体功能、输入、输出进
行抽象描述，反映软件和
系统、环境的关系
A B
C
软件
a b c
d
顶层数据流图
软件
系统
外部实体
外部实体
… …
外部实体
外部实体
… …
中间和底层 DFD
2.1
aaa
2.2
bbb
2.3
ccc
ddd数据
分层的数据流图
F0
F11
F12
F13
F14 F15
F21
F22
F23
F24
F25
第 n 层
第 n+1 层
第 n+2 层
数据流图的层次
? 在多层数据流图中,顶层流图 仅包含 一
个加工,它代表被开发系统。它的输入
流是该系统的输入数据，输出流是系统
所输出数据
? 底层流图 是指其 加工不需再做分解 的数
据流图，它处在最底层
? 中间层流图 则表示 对其上层父图的细化 。
它的每一加工可能继续细化，形成子图。
数据流图中的其它图形元素
A
B
C
------ 有 A 则 B 或者 C，或者两者都有
* A
B
C
+ A
B
C
------ 有 A 则 B 与 C，或者两者同时有
------ 有 A 则 B 或 C，但不会同时有 B与 C
------ 当 A 或 B 有一个存在就有 C
A
B C
*
A
B C ------ 只有当 A 与 B 都存在，则有 C
DFD规则和注意事项
? 数据存储不出现在顶层图中，外部实体通常不
出现在顶层图外
? 数据存储之间不应该有数据流
? 仔细、恰当地为处理命名：处理 +对象
? 仔细、恰当地为数据流命名：反映整体含义
? 对处理建立唯一、层次性编号
? 每个处理通常要求既有输入又有输出
? 一个 DFD的处理个数为 7± 2（魔数 7 ± 2）
? 不要试图让 DFD反映处理的顺序
检查数据流图的正确性
a,数据守恒
? 某个处理用以产生输出的数据没有输入给这个处理，
即出现遗漏
? 另一种是一个处理的某些输入并没有在处理中使用
以产生输出
b,数据存储（文件）的使用
? 数据存储（文件）应被数据流图中的处理读和写，
而不是仅读不写、或仅写不读
c,父图和子图的平衡
父子关系和平衡规则
? 父图表示子图间的接口，即数据流的方
向和数量
? 子图代表父图中某个处理的细节
? 子图个数不大于父图中的处理个数
? 所有子图的输入、输出数据流和父图中
相应处理的输入、输出数据流必须一致
父图和子图的平衡
发票 1.3
开领书单
领书单
(a) 父图
1.3.1 学生
领书单
1.3.2
1.3.3 教材
(b)子图
遵守加工编号规则
? 顶层加工不编号
? 第二层的加工编号为 1,2,3,…,n号
? 第三层编号为 1.1,1.2,1.3… n.1,n.2…
等号
? 依此类推
人工销售教材 系统流程图
举 例
学生
开购书
证明
购书
证明 开购书 发票
发 票 收书费
领书单
发书 学生
学
生
教材
购 销
系统
购书单
领书单
缺书单
进书通
知
进书通知
保
管员
1
销售
购书单
领书单
学
生
缺书单
进书通知
2
采购
保
管员
第 1 层
第 2 层
教材存量表 F1
缺书登记表 F2
外部实体 外部实体
教材销售子系统
无效书单
购书单
1.3
登记并开
领书单
1.2
开发票
1.1
审查
有效性
1.4
登记
缺书
1.5
补售
教材
采
购
学
生
学
生
进书通知
有效书单 发票 领书单
暂缺书单
1
销售
购书单
领书单
缺书单
进书通知
2
采购
进书通知
缺书登记表
教材存量表
学
生
保
管员
第 2 层
补售
书单
第 3 层
教材存量表 F1
缺书登记表 F2
F1
书号
单价
数量
各班用书表 F3 售书登记表 F4
外部
项
1
销售
购书单
领书单
缺书单
进书通知
2
采购
进书通知
缺书登记表
教材存量表
学
生
保
管员
采购 子系统
第 2 层
第 3 层
缺书单
2.3
修改教材库
存和待
购量
销
售
进书通知 进书通知
2.1
按书号汇
总缺书
2.2
按出版社统
计缺书
保
管员
教材存量表 F1 待购教材表 F5 教材一览表 F6
缺书登记表 F2
控制板
传感器
家庭
安全
软件
电话线
警 报
控制板显示
警报类型
传感器状态
用户命令和数据
显示数据
电话号码信号
与用户
交互
1
配置
系统
2
启 /停
系统
3
显示消
息状态
5
处理
口令
4
监控
系统
6
配置信息 用户命令和数据
配置请求
配置数据
启 /停
口令
配置数据
配置数据
启 /停消息
显示消息
传感器信息
有效标识消息
传感器状态
电话号码信号
警报类型
评价防
备设置
6.1
显示
格式化
6.2
生成警
报信号
6.3
拨
电话
6.5
读
传感器
6.4
配置信息
传感器标识,类型
传感器状态
电话号码
配置数据
传感器标识,定位
警报数据
传感器信息
电话号码信号
控制流图（ CFD）
2.1
打印
控制流 Control Flow
加工处理 Process
外部实体 External Entity 数据存储 Data Store
控制说明
与用户
交互
1
配置
系统
2
启 /停
系统
3
显示消
息状态
5
处理
口令
4
监控
系统
6
配置信息 显示动作
状态 （ 完
成, 进行
中 ）
控制板
控制板显示
警 报
电话线
传感器
传感器事件
闪烁标志
警报状态
时间溢出
警报信号
启 /停开关
数据字典（ DD）
? 数据字典是对所有与系统相关的数据元
素的一个有组织的列表，以及精确的、
严格的定义，使得用户和系统分析员对
于输入、输出、存储成分和中间计算结
果有共同的理解。
? 数据字典把不同的需求文档和分析模型
紧密结合在一起
数据字典的作用
? DFD中的数据流、数据存储表示某个
有组织的数据集合，它们要由 SA的
其他描述工具 -需求字典 (数据字典 )
来描述,包括,
? 词条描述
? 数据结构描述
? 加工逻辑说明
数据字典的内容
? DD包含的信息
? 名称（标识）
? 别名
? 来源
? 去向
? 组成（内容描述）
? 流动属性（频率、数
据量）
? 补充信息
? 数据的层次关系
? 原数据元素
? 组合项
? 重复项
? 选择项
? 可选项
数据字典基本符号
＝ 表示, 等于,,, 定义为,,, 由什么构成,
＋ 表示, 与,,, 和,
[|] 表示, 或,, 即选择括号中用, |”号分隔
的各项中的某一项
{ } 表示, 重复,, 即括号中的项要重复若干次,
重复次数的上下限也可以在括号边上标出
（ ） 表示, 可选,, 即括号中的项可以没有
** 表示, 注释,
（ 1）数据流词条描述
? 数据流名,
? 说明：简要介绍作用即它产生的原
因和结果
? 数据流来源：来自何方
? 数据流去向：去向何处
? 数据流组成：数据结构
? 数据量流通量：数据量，流通量
举例,
购
书
单 发票 领书 单 审查并
开发票
开领
书单
无效书单
学生 1 2
各班学生
用 书 表
学生
教材存量表
数据流词条说明举例
数据流名,发票
别名, 无
简述, 学生购书时填写的项目
来源, 学生
去向, 加工 1,审查并开发票”
组成, (学号 )＋姓名＋｛书号＋数量｝
数据流量,1000次 /周
高峰值,开学期间 1000次 /天
（ 2）数据元素词条描述
? 数据元素名,
? 类型：数字（离散值，连续值），
文字（编码类型）
? 长度,
? 取值范围,
? 相关的数据元素及数据结构,
数据元素词条举例
数据项名,货物编号
别名,G-No,G-num
简述,本公司的所有货物的编号
类型,字符串
长度,10
取值范围及含义,
第 1位,[J｜ G] (进口 /国产 )
第 2-4位,LB01.,LB29 (类别 )
第 5-7位：, A00”..“A99” (规格 )
第 8-10位：, 001”..“999”(品名编号 )
（ 3）数据文件词条描述
? 数据文件名,
? 简述：存放的是什么数据
? 输入数据,
? 输出数据,
? 数据文件组成：数据结构
? 存储方式：顺序，直接，关键码
? 存取频率,
数据文件（存储）词条举例
文件名,库存记录
别名, 无
简述,存放库存所有可供货物的信息
组成, 货物名称＋编号＋生产厂家
＋单价＋库存量
组织方式,索引文件，以货物编号为
关键字
查询要求,要求能够立即查询
（ 4）加工逻辑词条描述
? 加工名,
? 加工编号：反映该加工的层次
? 简要描述：加工逻辑及功能简述
? 输入数据流,
? 输出数据流,
? 加工逻辑：简述加工程序，加工顺
序
加工逻辑词条举例
加工逻辑名,登记报名单
编号,1.0
激活条件：收到报名单
加工逻辑,{1.1 检查报名单
+ 1.2 编准考证号
+ 1.3 登记考生 }
执行频率,2000次 /日
（ 5）源点及汇 (终 )点词条描述
? 名称：外部实体名
? 简要描述：什么外部实体
? 有关数据流,
? 数目,
DD表示
F1:航班信息文件 ＝ {航空公司名称＋航班号＋起点＋终点＋日期 ＋起飞时
间＋降落时间 }
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
字母＝, A”…,Z”
十进制数字＝, 0”…,9”
起点＝终点＝ 1{汉字 }10
起飞时间＝降落时间＝时＋分
时＝, 00”…,23”
分＝, 00”…,59”
日期＝年＋月＋日
年＝ [2000｜ 2001｜ 2002｜ 2004]
月＝, 01”…,12”
日＝, 01”…,31”
数据组合
重复项,起点＝终点＝ 1{汉字 }10
航空公司名称＝ 2{字母 }4
航班号＝ 3{十进制数字 }3
组合项,日期＝年＋月＋日
起飞时间＝降落时间＝时＋分
选择项,年＝ [2000｜ 2001｜ 2002｜ 2004]
原数据项,字母＝, A”…,Z”
十进制数字＝, 0”…,9”
时＝, 00”…,23”
分＝, 00”…,59”
月＝, 01”…,12”
日＝, 01”…,31”
限制重复次数举例
｛ 3 5 或 5 3 ｛ ｝ 表示允许重复 3-5次 ｛ ｝
3 3 或 3 3 ｛ ｝ 表示恰好重复 3 次 ｛ ｝
｛ ｝
｛ ｝
1 表示至少出现 1 次
表示允许重复 0至任意 次
办理取款手续的 DFD 图
储
户
检验
付款 登录
存折
帐卡
检验不合格
现款 付款信息
存折格式
日期
年月日 摘要 支出 存入 余额 操作 复核
户名, 储蓄网点名称, 帐号, 开户日,
性质, 印密,
DD
存折 = 户名 +所号 +帐号 +开户日 +性质 +(印密 )+1{存取行 }20
户名 = 2{字母 }24
所号 =,001”..“999”
帐号 =,00000001”..“99999999”
开户日 = 年 +月 +日
性质 =,1”..“6”
印密 =,0”
存取行 = 日期 +（摘要） +支出 +存入 +余额 +操作 +复核
日期 =年 +月 +日
年 =,1900”..“3000” 月 =,01”..“12” 日 =,01”..“31”
摘要 = 1{字母 }4
支出 = 金额
金额 =,00000000.01”..“999999999.99” … …
数据字典示例
电话号码 =[当地分机号 |外地号码 ]
当地分机号 =[2001|2002… |2999]
外地号码 =9+[当地号码 |长途号码 ]
当地号码 =前缀 +访问的号码
长途号码 =（ 1） +区号 +当地号码
前缀 =[795|799|874|877]
访问的号码 ={[0|1|2|3|4|5|6|7|8|9]}4
区号 =
状态转换图（ STD）
? 通过描述状态以及导致系统改变状态的
事件来表示系统的行为
? STD可以被用来描述 CSPEC
? STD的基本符号,
? (1)状态
? (2)转移
STD示意
系统在, 状态 1”
当, 事件 1”发
生时采取, 动
作 1”将状态转
移到, 状态 3”
状态 1
状态 3
状态 2 事件 1
动作 1
事件 2
动作 2
事件 3
动作 3
事件 4
动作 4
读
用户输入
监控
系统状态
基于传感器
事件的动作
显示
用户反馈
闪烁标记
引发显示消息与状态
时间溢出
引发与用户交互
启 /停开关
引发监控系统
无传感器事件
引发监控系统
传感器事件
引发显示消息与状态
启 /停开关
引发显示消息与状态 显示动作状态
引发与用户交互
处理说明
? 数据流图的每一个基本处理 （ 即不再进一步被
分解的处理 ） 都必须有一个处理说明给出这个
处理的精确描述 。 而其它中间处理则可以没有
处理说明, 事实上它可由其子处理, 子子处理
的说明来描述 。
? 理想的处理说明应该既严格精确又容易被软件
设计人员和用户理解 。 但目前通常还是用自然
语言书写的 。 此外, 常用的方式还有结构化语
言, 决策表, 决策树等 。
处理说明的要求
? 对数据流图的每一个基本处理，必须有
一个基本处理说明
? 基本处理说明必须描述基本处理如何把
输入数据流变换为输出数据流的处理规
则
? 处理说明必须描述实现处理的策略而不
是实现处理的细节
? 处理说明中包含的信息应是充足的，完
备的，有用的，无冗余的
加工说明组成
输入
数据
加工
逻辑
输出
数据
加工说明
描述工具
结构化
语言
判定
表
判定
树
描述把输入数据流变
换为输出数据流的加工过
程，是加工说明的主体。
（ 1）结构化语言（英语）
? 结构化英语的词汇表由
? 英语命令动词
? 数据词典中定义的名字
? 有限的自定义词
? 逻辑关系词 IF_THEN_ELSE,
CASE_OF, WHILE_DO,
REPEAT_UNTIL等组成。
结构化语言
? 是一种介于自然语言和形式化语言之间的语言
? 语言的 正文用基本控制结构进行分割,加工中
的 操作用自然语言短语来表示
? 其基本控制结构有三种,
? 简单陈述句结构,避免复合语句；
? 重复结构, while_do 或
repeat_until 结构。
? 判定结构, if_then_else 或
case_of 结构；
商店业务处理系统中“检查发货
单”
if 发货单金额超过 $500 then
if 欠款超过了 60天 then
在偿还欠款前不予批准
else （欠款未超期）
发批准书，发货单
else （发货单金额未超过 $500）
if 欠款超过 60天 then
发批准书，发货单及赊欠报告
else （欠款未超期）
发批准书，发货单
（ 2）判定表
? 如果数据流图的加工需要依赖于
多个逻辑条件的取值,使用判定
表来描述比较合适
以“检查发货单”为例
判定表格式
（ 3）判定树
? 判定树也是用来表达加工逻辑的一种工
具。有时侯它比判定表更直观。
检
查
发
货
单
金额 >$500
金额 ?$500
欠款 >60天 不发出批准书
欠款 ?60天
发货单
发出批准书,
欠款 >60天 发出批准书,
发货单及赊欠报告
欠款 ?60天 发出批准书,发货单
练习题
? 对以下软件建立软件需求规格说明文档,
? 辅助图书馆处理借还图书的软件系统
? 缺少条件可自行假设
? 在复习前和其它练习题结果一起提交
谢谢！
68389085（ O）
68389504（ H）
mdtang@btamail.net.cn
