软件需求工程
2 第二 章第二章 软件需求工程2
2.1 软件需求分析的基本概念
2.2 结构化分析方法
2.3 原型化方法
(维护报告 )
问题定义编 码需求分析设 计可行性研究运行与维护测 试开发时期运行时期计划时期
(目标与范围说明书 )
(可行性论证论告 )
(测试报告 )
(程序 )
(设计文档 )
(需求说明书 )
瀑布模型软件需求分析是软件生命期中重要的一步,也是决定性的一步 。
2.1 软件需求分析的基本概念对系统应该提供的服务和所受到的约束进行理解,分析,建立文档,检验的过程 ——需求工程
1.什么是软件需求工程？
2.软件需求分析的任务是什么？
3.需求工程过程
4.软件需求分析方法
2.1 软件需求分析的基本概念
2.1.1 软件需求分析的任务需求分析阶段的任务：
在可行性分析的基础上,进一步了解确定用户需求 。 准确地回答
,系统必须做什么？,的问题 。 获得需求规格说明书 。
Boehm对软件需求的定义：
研究一种无二义性的表达工具,它能为用户和软件人员双方都接受并能够把,需求,严格地,形式地表达出来 。
由于需求分析方法不同,描述形式不同 。 其实现步骤如下图所示：
当前系统模型化目标系统物理模型具体化物理模型抽象化逻辑模型实例化逻辑模型做什么 导出理解需求表达需求
2.1.1 软件需求分析的任务软 件需 求用 户需 求 系 统需 求功能需求非功能需求领域需求
2.1.2 需求工程过程问题识别分析与综合编写文档分析评审
2.1.2 需求分析过程可行性研究 需求导出 和分析需求描述需求有效性验证可行性报告系统模型用户需求和系统需求需求文挡近几年来已提出许多软件需求分析与说明的方法,每一种分析方法都有独特的观点和表示方法,但都适用下面的基本原则 。
2.1.3 需求分析的原则
2.1.3 需求分析的原则
1,能够表达和理解问题的信息域和功能域对于计算机程序处理的数据,其信息域包括信息流 （ 如下图,
即数据通过一个系统时的变化方式 ),信息内容和信息结构,而功能域反映上述三方面的控制信息 。
数据存储转换 1
转换 2
附加数据输入数据中间数据结果数据
2.1.3 需求分析的原则
2,能够对问题进行分解和不断细化,建立问题的层次结构 。
3,需要给出系统的逻辑视图和物理视图软件需求的逻辑视图给出的是软件要达到的功能和要处理信息之间的关系,而不是实现的细节 。
软件需求的物理视图给出的是处理功能和信息结构的实际表现形式,这往往是由设备本身决定的 。
2.1.4 需求分析方法不同的开发方法,需求分析的方法也有所不同,常见的分析方法有：
2.1.4 需求分析方法功能分析方法将系统看作若干功能模块的集合,每个功能又可以分解为若干子功能,子功能还可继续分解,分解的结果已经是系统的雏形 。
面向对象的分析方法面向对象的分析方法 （ OOA） 的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型 。
信息建模法是从数据的角度对现实世界建立模型的,基本工具是 ER图 。
结构化分析方法是一种以数据,数据的封闭性为基础,从问题空间到某种表示的映射方法,由数据流图 （ DFD图 ） 表示 。
结构化开发方法 （ Structured Developing Method）
,应用最广泛的方法,主要特点是快速,自然和方便 。
,逐步求精 。 它的基本原则是功能的分解与抽象 。
2.2 结构化分析方法结构化开发方法的组成
70年代初 结构化程序设计方法 SP法 （ Structured Program）
70年代中 结构化设计方法 SD法 （ Structured Design）
70年代末 结构化分析方法 SA法 （ Structured Analysis）
SA,SD,SP 法相互衔接,形成了一整套开发方法 。
若将 SA,SD 法结合起来,又称为结构化分析与设计技术
（ SADT 技术 ） 。
2.2.1 SA法概述分解,对于一个复杂的系统,
为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决 （ 如右图 ） 。
一,SA法的基本思想结构化分析方法的基本思想是,分解,和,抽象,。
抽象,分解可以分层进行,即先考虑问题最本质的属性,
暂把细节略去,以后再逐层添加细节,直至涉及到最详细的内容,这种用最本质的属性表示一个系统的方法就是,抽象,。
2.2.1 SA法的概述
1.1
1.2 1.3
x
2
1 3
2.1
2.2
2.3
1.1
1.3
1,建立当前系统的,具体模型,。
基本思想与步骤三,SA法的描述方法
1,分层的数据流图
2,数据词典
3、描述加工逻辑的结构化语言、判定表及判定树
2.2.1 SA法的概念二,SA法的步骤
4,为了对目标系统做完整的描述,还需要考虑人机界面和其他一些问题 。
3,建立目标系统的逻辑模型 。
2,抽象出当前系统的逻辑模型 。
顾客出版社验证订单汇总订单订单 出版社订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件订货存根文件
DFD图的例子加工名编号加工名编号 文件名文件名顾客出版社验证订单汇总订单订单 出版社订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件订货存根文件画图步骤,1、确定外部实体及输入、输出数据流。
2、确定分解顶层的加工。
3、确定使用的文件。
4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例 1：图书预定系统 （顶层 DFD图）
P26 图 2.7
2.2.2 数据流图数据流图 （ Data Flow Diagram,DFD） 是描述系统中数据流程的图形工具,它标识了一个系统的逻辑输入和逻辑输出,以及把逻辑输入转换为逻辑输出所需的加工处理 。
数据存储数据源点或终点加 工 加工名数据流 数据流名文件名实体名箭 头圆或椭圆单或双杠矩形框还有一些辅助的图例,
2.2.2 分层的数据流图一,数据流图的图符四种基本图形符号：
T
A
B
*
C
T
A B *
C
T
A
B
+ C
T
A B +
C
T
A
B
C
+ TA
B
C
+
* 与 + 或 互斥+
―先全局后局部,先整体后细节,先抽象后具体,
通常可将这种分层的 DFD图,分为顶层,中间层,底层 。
具体步骤：
1。 先确定系统范围,画出顶层的 DFD图 。
2。 逐层分解顶层 DFD图,获得若干中间层 DFD图 。
3。 画出底层的 DFD图 。
2.2.3 画分层 DFD图的方法顶层图说明了系统的边界,即系统的输入和输出数据流,顶层图只有一张 。 底层图由一些不能再分解的加工组成,这些加工都已足够简单,称为 基本加工 。 在顶层和底层之间的是中间层 。 中间层的数据流图描述了某个加工的分解,而它的组成部分又要进一步分解 。
画各层 DFD图时，“由外向内”。
X
1 32
1.1
1.2
1.4
1.3
2.1 2.2
1.1.1 1.1.2
2.1.32.1.2
2.1.1 2.2.2
2.2.32.2.1
顶层中间层底层先全局后局部,
先整体后细节,
先抽象后具体,
0图
1图 2图
1.1图 2.1图 2.2图分层
DFD
图经过初步的需求分析,得到系统功能要求：
1,监视病员的病症 （ 血压,体温,脉搏等 ） 。
2,定时更新病历 。
3,病员出现异常情况时报警 。
4,随机地产生某一病员的病情报告 。
2.2.4 实例：医院病房监护系统产生病情报告监视病情更新病历
2.2.4 实例：医院病房监护系统系统功能要求：
1、监视病员的病症（血压、体温、脉搏等）
2、定时更新病历
3、病员出现异常情况时报警。
4、随机地产生某一病员的病情报告。
顶层：
病员护士护士病员监护系统病员 日志病症信号要求报告病症 报告报警例 2 医院病房监护系统第一层：
病员护士护士中央监视病员 日志病症信号要求报告病症 报告报警局部监视生成报告病员极限更新日志病员数据格式化病员数据生理信号极限值
1
3
2 4
日志数据日志数据医院病房监护系统顶层 DFD图第二层：加工,中央监视”分解计算超过极限值否病员 数 据超过 极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温脉搏生理信号极限值时间脉搏血压日期时钟 格式化病员数据
3.1
3.2
3.3 3.4
医院病房监护系统二层 DFD图计算超过极限值否病员 数据超过 极限值报警开解信号产生报警信息病员极限格式化病员数据体温生理信号极限值时间脉搏血压日期时钟 格式化病员数据
3.1
3.2
3.3
3.4
第二层：加工,中央监视”分解医院病房监护系统分层 DFD图图 2..15
第一层格式化病员数据生理信号极限值病员护士护士中央监视病员 日志病症 报告局部监视生成报告病员极限更新日志病员数据
1
3
2 4
日志数据图 2..16
加工分解的原则自然性,概念上合理,清晰；
均匀性,理想的分解是将一个问题分解成大小均匀的几个部分；
分解度,一般每一个加工每次分解最多不要超过７个子加工,分解应分解到基本加工为止 。
2.2.5 画分层 DFD图的基本原则数据守恒与数据封闭原则所谓数据守恒是指加工的输入输出数据流是否匹配,
即每一个加工既有输入数据流又有输出数据流 。 或者说一个加工至少有一个输入数据流,一个输出数据流 。
数据封闭是对整个系统而言 。
合理使用文件当文件作为某些加工之间的交界面时,文件必须画出来,一旦文件作为数据流图中的一个独立成份画出来了,那么他同其他成份之间的联系也应同时表达出来 。
DFD图不是流程图,不表示软件的控制流程。
2.2.5 画分层 DFD图的基本原则子图与父图的,平衡,
父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同 (相对应），分层数据流图的这种特点称为子图与父图,平衡,。
2.2.6 分层 DFD图的改进
DFD图必须经过 反复修改,才能获得最终的目标系统的逻辑模型（目标系统的 DFD图）。可从以下方面考虑 DFD图的改进：
1、检查数据流的正确性
① 数据 守恒
② 子图、父图的平衡
③ 文件使用是否合理。特别注意输入 /出文件的数据流。
2、改进 DFD图的易理解性
① 简化加工之间的联系（加工间的数据流越少，独立性越强，易理解性越好）。
② 改进分解的均匀性。
③ 适当命名（各成分名称无二义性，准确、具体）。
分层数据流图只是表达了系统的,分解,,为了完整地描述这个系统,还需借助,数据词典,和,小说明
” 对图中的每个数据和加工给出解释 。
对数据流图中包含的所有元素的定义的集合构成了数据词典 。 词典中可有以下四种类型的条目,
2.2.7 数据词典 (DD)
数据流 文件 数据项 加工
A,数据流条目 给出某个数据流的定义，通常是列出该数据流的各组成数据项。
例如,报名单＝姓名＋单位名＋年龄＋性别＋课程名常用符号：＝、＋、［｜］、｛｝、（）、
C,数据项条目数据项条目给出某个数据单项的定义,通常是数据项的值类型,允许的取值范围 。
B、文件条目 给出某个文件的定义，同数据流一样，文件的定义通常是列出文件记录的组成数据流例如某销售系统的订单文件：
订单文件＝订单编号＋顾客名称＋产品名称＋订货数量＋交货日期
D,加工条目加工类条目就是,加工小说明,。一般应该单独列出
。
nm{...}
2.2.8 加工说明结构化语言判定表判定树对数据流图中每一个不能再分解的基本加工都必须有一个 小说明 给出这个加工的精确描述。小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。加工逻辑是其中最基本的部分，是指用户对这个加工的逻辑要求。
对基本加工说明有三种描述方式：
结构化语言是介于自然语言和形式语言之间的一种半形式语言，它是自然语言的一个受限制的子集。一般分为两层结构：外层语法较具体，为控制结构（顺序、选择、循环）,
内层较灵活，表达“做什么”。
一,结构化语言例如：外层可为以下结构：
1、顺序结构
2、选择结构
IF–THEN-ELSE; CASE-OF-ENDCASE；
3、循环结构
WHILE-DO; REPEAT-UNTIL
例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于 1000元，同时必须信誉好，或者虽然信誉不好，但是 20年以上的老主顾。
应用举例用结构化语言来描述：
如果 营业额大于 1000元同时 如果信誉好则 优惠处理。
否则 正常处理。
否则 信誉不好但是 20年以上的老主顾，则优惠处理。
否则 营业额小于、等于 1000元则 正常处理。
显然，用结构化语言来描述组合条件不清晰。
判定表是一种二维的表格，常用于较复杂的组合条件
（与结构化语言比较）。
条件框 条件条目操作框 操作条目二,判定表特点：可处理较复杂的组合条件，但不易理解,不易输入计算机。
通常由四部分组成。
条件框 — 条件定义。
操作框 — 操作的定义。
条件条目 — 各条件的取值及组合。
操作条目 — 在各条件取值组合下所执行的操作。
例如,对商店每天的营业额所收税率营业额 X （ ￥） 1000≤X<5000 5000 ≤X<10000 X≥10000
税 率 5% 8% 10%
例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于 1000元，同时必须信誉好，或者虽然信誉不好，但是 20年以上的老主顾。
1 2 3 4
>1000元 Y Y Y N
信誉好 Y N N -
>20 年 - Y N -
优 惠 X X
正 常 X X
化简后
1 2 3 4 5 6 7 8
>1000元 Y Y Y Y N N N N
信誉好 Y Y N N Y Y N N
>20 年 Y N Y N Y N Y N
优 惠 X X X
正 常 X X X X X
Y-满足条件 N-不满足条件 X-选中判定的结论判定表 应用举例特点,描述一般组合条件较清晰，易理解。不易输入计算机。
营业额
> 1000元
≤ 1000元 正常处理好的支付信誉 优惠处理坏的支付信誉
> 20年 优惠处理
< 20年 正常处理如上例三,判定树按照传统的瀑布模型进行软件开发,由于将软件开发这样一个充满回朔的过程硬性地割裂开,虽然强调各个阶段的复审,而用户所提出的需求往往是模糊的,因此很难得到一个完整精确的规格说明,直接影响到后期的开发,针对其主要缺点推出了原型化方法 。
2.3 原型化方法
2.3 原型化方法什么是原型化方法 （ Prototyping Method）？
原型是软件开发过程中,软件的一个早期可运行的版本,它反映了最终系统的部分重要特性 。
原型化方法的基本思想是花费少量代价建立一个可运行的系统,
使用户及早获得学习的机会,原型化方法又称速成原型法 （ Rapid
Prototyping）,强调的是软件开发人员与用户的不断交互,通过原型的演进不断适应用户任务改变的需求 。 将维护和修改阶段的工作尽早进行,使用户验收提前,从而使软件产品更加适用 。
由于软件项目的特点和运行原型的目的不同,分为两种类型：
2.3.1 软件原型的分类
2.3.1 软件原型的分类
2,追加 （ add on） 型也称 快速建立渐进原型 RCP法 （ Rapid Cyclic Prototyping） 法采用循环渐进的开发方式,对系统模型作连续精化,即先构造一个功能简单而且质量要求不高的模型系统,将系统需要具备的性质逐步添加上去,通过不断地扩充修改,逐步追加新的要求,直至所有性质全部满足,此时的原型模型也就是最终的产品 。
1,废弃 （ throw away） 型也称为 快 速 建 立 需 求 规 格 原 型 RSP 法 （ Rapid Specific
Prototyping）,先构造一个功能简单而且质量要求不高的模型系统,针对这个模型系统反复进行分析修改,让用户学习 。 待需求说明书一旦确定,原型将被废弃,后阶段的工作仍按照瀑布模型开发 。
1.快速分析快速确定软件系统的基本要求,确定原型所要体现的特性 （ 总体结构,功能,性能,界面等 ） 。
2.构造原型根据基本规格说明,忽略细节,只考虑主要特性,快速构造一个可运行的系统 。 有三类原型：
用户界面原型,功能原型,性能原型 。
3.运行和评价原型用户试用原型并与开发者之间频繁交流,发现问题,目的是验证原型的正确性 。
4.修正与改进对原型进行修改,增删 。
2.3.2 快速原型开发模型快速原型法的工作模型如图所示,按以下步骤循环执行 。
原型化模型
2.3.2 快速原型开发模型构造原型运行 /评价原型原型完成否要细部说明否严格说明细部效果满意否整理原型提供文档修正改进原型
Y
Y
N
N
快速分析，确定初步规格说明
Y
N
快速 原型化开发过程
2.3.2 快速原型开发模型快速建立系统原型进行系统的分析和构造有如下优点：
1、增进软件开发人员和用户对系统需求的理解。便于将用户模糊的功能需求明确化。
2,为用户提供了一种强有力的学习手段 。
3、易于确定系统的性能，是理解和确认软件需求规格说明的工具。
4、按照 RCP 法建立的原型即为最终的产品。
细化的原型化模型需求工程小结需求工程小结最初，需求工程仅仅是软件工程的一个组成部分，是软件生命周期的第一个阶段。
在传统软件工程生命周期中，涉及需求的阶段称作需求分析。一般来说，需求分析的作用是：
● 系统工程师说明软件的功能和性能，指明软件和其他系统成分的接口，并定义软件必须满足的约束；
● 软件工程师求精软件的配置，建立数据模型、功能模型和行为模型；
● 为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型；
● 提供开发人员和客户需求规格说明，用于作为评估软件质量的依据。
需求工程小结需求工程小结软件需求分析的工作，是软件开发人员与用户密切配合，充分交换意见，达到对需求分析一致的意见。在开发人员一方，进行需求分析工作的主要是系统分析员和系统工程师等，他们处于用户和高级程序员之间，负责沟通用户和开发人员的认识和见解，起着桥梁作用，是需求分析的主要角色。
需求分析阶段的最终任务是要完成目标系统的需求规格说明，确定系统的功能和性能，为后阶段的开发打下基础。
需求分析的方法和技术因具体的系统而定，常用的有
SA法，原型法,OOA法等。
需求工程小结需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。
需求工程的基本活动包括：
● 抽取需求；
● 模拟和分析需求；
● 传递需求；
● 认可需求；
● 进化需求。
需求工程小结一、需求抽取 —— 非常困难，主要原因有：
● 缺乏领域知识，应用领域的问题常常是模糊的、不精确的；
● 存在默认的知识，即难以描述的日常知识（常识问题）；
● 存在多个知识源，而且多知识源之间可能有冲突；
● 面对的客户可能有偏见，如不能提供你需要了解什么或不想告知你需要了解的事情。
需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等，还有知识工程方法，
如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。
需求工程小结二,模拟和分析需求
● 指导抽取；
● 帮助需求工程师了解进展；
● 帮助发现问题；
● 帮助检查对问题的理解。
需求分析和模拟又包含三个层次的工作。
1、需求建模
2、需求模拟（分为企业模拟、功能需求模拟和非功能需求模拟等）
3、需求规格说明
2 第二 章第二章 软件需求工程2
2.1 软件需求分析的基本概念
2.2 结构化分析方法
2.3 原型化方法
(维护报告 )
问题定义编 码需求分析设 计可行性研究运行与维护测 试开发时期运行时期计划时期
(目标与范围说明书 )
(可行性论证论告 )
(测试报告 )
(程序 )
(设计文档 )
(需求说明书 )
瀑布模型软件需求分析是软件生命期中重要的一步,也是决定性的一步 。
2.1 软件需求分析的基本概念对系统应该提供的服务和所受到的约束进行理解,分析,建立文档,检验的过程 ——需求工程
1.什么是软件需求工程？
2.软件需求分析的任务是什么？
3.需求工程过程
4.软件需求分析方法
2.1 软件需求分析的基本概念
2.1.1 软件需求分析的任务需求分析阶段的任务：
在可行性分析的基础上,进一步了解确定用户需求 。 准确地回答
,系统必须做什么？,的问题 。 获得需求规格说明书 。
Boehm对软件需求的定义：
研究一种无二义性的表达工具,它能为用户和软件人员双方都接受并能够把,需求,严格地,形式地表达出来 。
由于需求分析方法不同,描述形式不同 。 其实现步骤如下图所示：
当前系统模型化目标系统物理模型具体化物理模型抽象化逻辑模型实例化逻辑模型做什么 导出理解需求表达需求
2.1.1 软件需求分析的任务软 件需 求用 户需 求 系 统需 求功能需求非功能需求领域需求
2.1.2 需求工程过程问题识别分析与综合编写文档分析评审
2.1.2 需求分析过程可行性研究 需求导出 和分析需求描述需求有效性验证可行性报告系统模型用户需求和系统需求需求文挡近几年来已提出许多软件需求分析与说明的方法,每一种分析方法都有独特的观点和表示方法,但都适用下面的基本原则 。
2.1.3 需求分析的原则
2.1.3 需求分析的原则
1,能够表达和理解问题的信息域和功能域对于计算机程序处理的数据,其信息域包括信息流 （ 如下图,
即数据通过一个系统时的变化方式 ),信息内容和信息结构,而功能域反映上述三方面的控制信息 。
数据存储转换 1
转换 2
附加数据输入数据中间数据结果数据
2.1.3 需求分析的原则
2,能够对问题进行分解和不断细化,建立问题的层次结构 。
3,需要给出系统的逻辑视图和物理视图软件需求的逻辑视图给出的是软件要达到的功能和要处理信息之间的关系,而不是实现的细节 。
软件需求的物理视图给出的是处理功能和信息结构的实际表现形式,这往往是由设备本身决定的 。
2.1.4 需求分析方法不同的开发方法,需求分析的方法也有所不同,常见的分析方法有：
2.1.4 需求分析方法功能分析方法将系统看作若干功能模块的集合,每个功能又可以分解为若干子功能,子功能还可继续分解,分解的结果已经是系统的雏形 。
面向对象的分析方法面向对象的分析方法 （ OOA） 的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型 。
信息建模法是从数据的角度对现实世界建立模型的,基本工具是 ER图 。
结构化分析方法是一种以数据,数据的封闭性为基础,从问题空间到某种表示的映射方法,由数据流图 （ DFD图 ） 表示 。
结构化开发方法 （ Structured Developing Method）
,应用最广泛的方法,主要特点是快速,自然和方便 。
,逐步求精 。 它的基本原则是功能的分解与抽象 。
2.2 结构化分析方法结构化开发方法的组成
70年代初 结构化程序设计方法 SP法 （ Structured Program）
70年代中 结构化设计方法 SD法 （ Structured Design）
70年代末 结构化分析方法 SA法 （ Structured Analysis）
SA,SD,SP 法相互衔接,形成了一整套开发方法 。
若将 SA,SD 法结合起来,又称为结构化分析与设计技术
（ SADT 技术 ） 。
2.2.1 SA法概述分解,对于一个复杂的系统,
为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决 （ 如右图 ） 。
一,SA法的基本思想结构化分析方法的基本思想是,分解,和,抽象,。
抽象,分解可以分层进行,即先考虑问题最本质的属性,
暂把细节略去,以后再逐层添加细节,直至涉及到最详细的内容,这种用最本质的属性表示一个系统的方法就是,抽象,。
2.2.1 SA法的概述
1.1
1.2 1.3
x
2
1 3
2.1
2.2
2.3
1.1
1.3
1,建立当前系统的,具体模型,。
基本思想与步骤三,SA法的描述方法
1,分层的数据流图
2,数据词典
3、描述加工逻辑的结构化语言、判定表及判定树
2.2.1 SA法的概念二,SA法的步骤
4,为了对目标系统做完整的描述,还需要考虑人机界面和其他一些问题 。
3,建立目标系统的逻辑模型 。
2,抽象出当前系统的逻辑模型 。
顾客出版社验证订单汇总订单订单 出版社订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件订货存根文件
DFD图的例子加工名编号加工名编号 文件名文件名顾客出版社验证订单汇总订单订单 出版社订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件订货存根文件画图步骤,1、确定外部实体及输入、输出数据流。
2、确定分解顶层的加工。
3、确定使用的文件。
4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例 1：图书预定系统 （顶层 DFD图）
P26 图 2.7
2.2.2 数据流图数据流图 （ Data Flow Diagram,DFD） 是描述系统中数据流程的图形工具,它标识了一个系统的逻辑输入和逻辑输出,以及把逻辑输入转换为逻辑输出所需的加工处理 。
数据存储数据源点或终点加 工 加工名数据流 数据流名文件名实体名箭 头圆或椭圆单或双杠矩形框还有一些辅助的图例,
2.2.2 分层的数据流图一,数据流图的图符四种基本图形符号：
T
A
B
*
C
T
A B *
C
T
A
B
+ C
T
A B +
C
T
A
B
C
+ TA
B
C
+
* 与 + 或 互斥+
―先全局后局部,先整体后细节,先抽象后具体,
通常可将这种分层的 DFD图,分为顶层,中间层,底层 。
具体步骤：
1。 先确定系统范围,画出顶层的 DFD图 。
2。 逐层分解顶层 DFD图,获得若干中间层 DFD图 。
3。 画出底层的 DFD图 。
2.2.3 画分层 DFD图的方法顶层图说明了系统的边界,即系统的输入和输出数据流,顶层图只有一张 。 底层图由一些不能再分解的加工组成,这些加工都已足够简单,称为 基本加工 。 在顶层和底层之间的是中间层 。 中间层的数据流图描述了某个加工的分解,而它的组成部分又要进一步分解 。
画各层 DFD图时，“由外向内”。
X
1 32
1.1
1.2
1.4
1.3
2.1 2.2
1.1.1 1.1.2
2.1.32.1.2
2.1.1 2.2.2
2.2.32.2.1
顶层中间层底层先全局后局部,
先整体后细节,
先抽象后具体,
0图
1图 2图
1.1图 2.1图 2.2图分层
DFD
图经过初步的需求分析,得到系统功能要求：
1,监视病员的病症 （ 血压,体温,脉搏等 ） 。
2,定时更新病历 。
3,病员出现异常情况时报警 。
4,随机地产生某一病员的病情报告 。
2.2.4 实例：医院病房监护系统产生病情报告监视病情更新病历
2.2.4 实例：医院病房监护系统系统功能要求：
1、监视病员的病症（血压、体温、脉搏等）
2、定时更新病历
3、病员出现异常情况时报警。
4、随机地产生某一病员的病情报告。
顶层：
病员护士护士病员监护系统病员 日志病症信号要求报告病症 报告报警例 2 医院病房监护系统第一层：
病员护士护士中央监视病员 日志病症信号要求报告病症 报告报警局部监视生成报告病员极限更新日志病员数据格式化病员数据生理信号极限值
1
3
2 4
日志数据日志数据医院病房监护系统顶层 DFD图第二层：加工,中央监视”分解计算超过极限值否病员 数 据超过 极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温脉搏生理信号极限值时间脉搏血压日期时钟 格式化病员数据
3.1
3.2
3.3 3.4
医院病房监护系统二层 DFD图计算超过极限值否病员 数据超过 极限值报警开解信号产生报警信息病员极限格式化病员数据体温生理信号极限值时间脉搏血压日期时钟 格式化病员数据
3.1
3.2
3.3
3.4
第二层：加工,中央监视”分解医院病房监护系统分层 DFD图图 2..15
第一层格式化病员数据生理信号极限值病员护士护士中央监视病员 日志病症 报告局部监视生成报告病员极限更新日志病员数据
1
3
2 4
日志数据图 2..16
加工分解的原则自然性,概念上合理,清晰；
均匀性,理想的分解是将一个问题分解成大小均匀的几个部分；
分解度,一般每一个加工每次分解最多不要超过７个子加工,分解应分解到基本加工为止 。
2.2.5 画分层 DFD图的基本原则数据守恒与数据封闭原则所谓数据守恒是指加工的输入输出数据流是否匹配,
即每一个加工既有输入数据流又有输出数据流 。 或者说一个加工至少有一个输入数据流,一个输出数据流 。
数据封闭是对整个系统而言 。
合理使用文件当文件作为某些加工之间的交界面时,文件必须画出来,一旦文件作为数据流图中的一个独立成份画出来了,那么他同其他成份之间的联系也应同时表达出来 。
DFD图不是流程图,不表示软件的控制流程。
2.2.5 画分层 DFD图的基本原则子图与父图的,平衡,
父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同 (相对应），分层数据流图的这种特点称为子图与父图,平衡,。
2.2.6 分层 DFD图的改进
DFD图必须经过 反复修改,才能获得最终的目标系统的逻辑模型（目标系统的 DFD图）。可从以下方面考虑 DFD图的改进：
1、检查数据流的正确性
① 数据 守恒
② 子图、父图的平衡
③ 文件使用是否合理。特别注意输入 /出文件的数据流。
2、改进 DFD图的易理解性
① 简化加工之间的联系（加工间的数据流越少，独立性越强，易理解性越好）。
② 改进分解的均匀性。
③ 适当命名（各成分名称无二义性，准确、具体）。
分层数据流图只是表达了系统的,分解,,为了完整地描述这个系统,还需借助,数据词典,和,小说明
” 对图中的每个数据和加工给出解释 。
对数据流图中包含的所有元素的定义的集合构成了数据词典 。 词典中可有以下四种类型的条目,
2.2.7 数据词典 (DD)
数据流 文件 数据项 加工
A,数据流条目 给出某个数据流的定义，通常是列出该数据流的各组成数据项。
例如,报名单＝姓名＋单位名＋年龄＋性别＋课程名常用符号：＝、＋、［｜］、｛｝、（）、
C,数据项条目数据项条目给出某个数据单项的定义,通常是数据项的值类型,允许的取值范围 。
B、文件条目 给出某个文件的定义，同数据流一样，文件的定义通常是列出文件记录的组成数据流例如某销售系统的订单文件：
订单文件＝订单编号＋顾客名称＋产品名称＋订货数量＋交货日期
D,加工条目加工类条目就是,加工小说明,。一般应该单独列出
。
nm{...}
2.2.8 加工说明结构化语言判定表判定树对数据流图中每一个不能再分解的基本加工都必须有一个 小说明 给出这个加工的精确描述。小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。加工逻辑是其中最基本的部分，是指用户对这个加工的逻辑要求。
对基本加工说明有三种描述方式：
结构化语言是介于自然语言和形式语言之间的一种半形式语言，它是自然语言的一个受限制的子集。一般分为两层结构：外层语法较具体，为控制结构（顺序、选择、循环）,
内层较灵活，表达“做什么”。
一,结构化语言例如：外层可为以下结构：
1、顺序结构
2、选择结构
IF–THEN-ELSE; CASE-OF-ENDCASE；
3、循环结构
WHILE-DO; REPEAT-UNTIL
例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于 1000元，同时必须信誉好，或者虽然信誉不好，但是 20年以上的老主顾。
应用举例用结构化语言来描述：
如果 营业额大于 1000元同时 如果信誉好则 优惠处理。
否则 正常处理。
否则 信誉不好但是 20年以上的老主顾，则优惠处理。
否则 营业额小于、等于 1000元则 正常处理。
显然，用结构化语言来描述组合条件不清晰。
判定表是一种二维的表格，常用于较复杂的组合条件
（与结构化语言比较）。
条件框 条件条目操作框 操作条目二,判定表特点：可处理较复杂的组合条件，但不易理解,不易输入计算机。
通常由四部分组成。
条件框 — 条件定义。
操作框 — 操作的定义。
条件条目 — 各条件的取值及组合。
操作条目 — 在各条件取值组合下所执行的操作。
例如,对商店每天的营业额所收税率营业额 X （ ￥） 1000≤X<5000 5000 ≤X<10000 X≥10000
税 率 5% 8% 10%
例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于 1000元，同时必须信誉好，或者虽然信誉不好，但是 20年以上的老主顾。
1 2 3 4
>1000元 Y Y Y N
信誉好 Y N N -
>20 年 - Y N -
优 惠 X X
正 常 X X
化简后
1 2 3 4 5 6 7 8
>1000元 Y Y Y Y N N N N
信誉好 Y Y N N Y Y N N
>20 年 Y N Y N Y N Y N
优 惠 X X X
正 常 X X X X X
Y-满足条件 N-不满足条件 X-选中判定的结论判定表 应用举例特点,描述一般组合条件较清晰，易理解。不易输入计算机。
营业额
> 1000元
≤ 1000元 正常处理好的支付信誉 优惠处理坏的支付信誉
> 20年 优惠处理
< 20年 正常处理如上例三,判定树按照传统的瀑布模型进行软件开发,由于将软件开发这样一个充满回朔的过程硬性地割裂开,虽然强调各个阶段的复审,而用户所提出的需求往往是模糊的,因此很难得到一个完整精确的规格说明,直接影响到后期的开发,针对其主要缺点推出了原型化方法 。
2.3 原型化方法
2.3 原型化方法什么是原型化方法 （ Prototyping Method）？
原型是软件开发过程中,软件的一个早期可运行的版本,它反映了最终系统的部分重要特性 。
原型化方法的基本思想是花费少量代价建立一个可运行的系统,
使用户及早获得学习的机会,原型化方法又称速成原型法 （ Rapid
Prototyping）,强调的是软件开发人员与用户的不断交互,通过原型的演进不断适应用户任务改变的需求 。 将维护和修改阶段的工作尽早进行,使用户验收提前,从而使软件产品更加适用 。
由于软件项目的特点和运行原型的目的不同,分为两种类型：
2.3.1 软件原型的分类
2.3.1 软件原型的分类
2,追加 （ add on） 型也称 快速建立渐进原型 RCP法 （ Rapid Cyclic Prototyping） 法采用循环渐进的开发方式,对系统模型作连续精化,即先构造一个功能简单而且质量要求不高的模型系统,将系统需要具备的性质逐步添加上去,通过不断地扩充修改,逐步追加新的要求,直至所有性质全部满足,此时的原型模型也就是最终的产品 。
1,废弃 （ throw away） 型也称为 快 速 建 立 需 求 规 格 原 型 RSP 法 （ Rapid Specific
Prototyping）,先构造一个功能简单而且质量要求不高的模型系统,针对这个模型系统反复进行分析修改,让用户学习 。 待需求说明书一旦确定,原型将被废弃,后阶段的工作仍按照瀑布模型开发 。
1.快速分析快速确定软件系统的基本要求,确定原型所要体现的特性 （ 总体结构,功能,性能,界面等 ） 。
2.构造原型根据基本规格说明,忽略细节,只考虑主要特性,快速构造一个可运行的系统 。 有三类原型：
用户界面原型,功能原型,性能原型 。
3.运行和评价原型用户试用原型并与开发者之间频繁交流,发现问题,目的是验证原型的正确性 。
4.修正与改进对原型进行修改,增删 。
2.3.2 快速原型开发模型快速原型法的工作模型如图所示,按以下步骤循环执行 。
原型化模型
2.3.2 快速原型开发模型构造原型运行 /评价原型原型完成否要细部说明否严格说明细部效果满意否整理原型提供文档修正改进原型
Y
Y
N
N
快速分析，确定初步规格说明
Y
N
快速 原型化开发过程
2.3.2 快速原型开发模型快速建立系统原型进行系统的分析和构造有如下优点：
1、增进软件开发人员和用户对系统需求的理解。便于将用户模糊的功能需求明确化。
2,为用户提供了一种强有力的学习手段 。
3、易于确定系统的性能，是理解和确认软件需求规格说明的工具。
4、按照 RCP 法建立的原型即为最终的产品。
细化的原型化模型需求工程小结需求工程小结最初，需求工程仅仅是软件工程的一个组成部分，是软件生命周期的第一个阶段。
在传统软件工程生命周期中，涉及需求的阶段称作需求分析。一般来说，需求分析的作用是：
● 系统工程师说明软件的功能和性能，指明软件和其他系统成分的接口，并定义软件必须满足的约束；
● 软件工程师求精软件的配置，建立数据模型、功能模型和行为模型；
● 为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型；
● 提供开发人员和客户需求规格说明，用于作为评估软件质量的依据。
需求工程小结需求工程小结软件需求分析的工作，是软件开发人员与用户密切配合，充分交换意见，达到对需求分析一致的意见。在开发人员一方，进行需求分析工作的主要是系统分析员和系统工程师等，他们处于用户和高级程序员之间，负责沟通用户和开发人员的认识和见解，起着桥梁作用，是需求分析的主要角色。
需求分析阶段的最终任务是要完成目标系统的需求规格说明，确定系统的功能和性能，为后阶段的开发打下基础。
需求分析的方法和技术因具体的系统而定，常用的有
SA法，原型法,OOA法等。
需求工程小结需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。
需求工程的基本活动包括：
● 抽取需求；
● 模拟和分析需求；
● 传递需求；
● 认可需求；
● 进化需求。
需求工程小结一、需求抽取 —— 非常困难，主要原因有：
● 缺乏领域知识，应用领域的问题常常是模糊的、不精确的；
● 存在默认的知识，即难以描述的日常知识（常识问题）；
● 存在多个知识源，而且多知识源之间可能有冲突；
● 面对的客户可能有偏见，如不能提供你需要了解什么或不想告知你需要了解的事情。
需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等，还有知识工程方法，
如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。
需求工程小结二,模拟和分析需求
● 指导抽取；
● 帮助需求工程师了解进展；
● 帮助发现问题；
● 帮助检查对问题的理解。
需求分析和模拟又包含三个层次的工作。
1、需求建模
2、需求模拟（分为企业模拟、功能需求模拟和非功能需求模拟等）
3、需求规格说明
