软件工程
电子教案
王树林
Chapter 11 Analysis concepts and principles
软件需求理解对软件开发工作是至关重要
的。
需求分析任务是发现、求精、建摸和规约
的过程。
客户：尽力描述功能和性能。
开发者,功能的询问者、和问题解决者。
Chapter 11 Analysis concepts and principles
11.1 需求分析
需求分析是一种软件工程活动。
系统工程
软件需求分析
软件设计
Chapter 11 Analysis concepts and principles
软件需求分析的 5个阶段：
（ 1）问题分析，
（ 2）问题评估和方案综合，
（ 3）建摸，
（ 4）规约，
（ 5）复审。
Chapter 11 Analysis concepts and principles
在这个阶段要得到详细的规约是不
可能的。
11.2 通信技术
开发者与客户之间的通信与交流经
常是不顺畅的。
11.2.1 过程的启动
客户与开发者之间最常用的方式为
预备会议或访谈。
Chapter 11 Analysis concepts and principles
11.2.2 便利的应用规约技术
客户与软件工程师经常有无意识的
“我们和你们”的区分不是按需要来将
一支队伍标识和精化，而是各自定义自
己的“版图”，并通过一系列备忘录、
正式的意见书、文档以及提问和回答会
议来相互通信。事实说明，这种方法不
是很有效的。
正是由于这个原因，才开发了一种面向团队的
需求收集方法，被称之为便利的应用规约技
术（ FAST）。 该方法鼓励客户与开发者之间
的合作，提出解决方案。
? 在中立的地点举行会议，由开发者和客户出
席。
? 建立准备和参与会议的规则。
? 鼓励思维的交流。
? 一个协调者控制会议。
? 使用一种“定义机制”（工作表、图表、墙
版）。
Chapter 11 Analysis concepts and principles
Chapter 11 Analysis concepts and principles
? 目标是标识问题、提出解决方案的要素、商
议不同方法，营造解决问题的氛围。
例如：假定为消费产品公司工作的 FAST团队提
供了下面的产品描述。
我们的研究表明，家庭安全系统的市场正以每年 40%的比率增长，
我们希望能进入该市场，并试图建立基于微处理器的家庭安全
系统，该系统将保护和识别一系列意外事件，如非法入侵，火
警、水灾或其他。该产品暂时称为 SafeHome,产品将采用合适
的传感器来检测各种情况，具体使用时房主可按需编程，并且
当系统检测的意外情况时，会自动地给监控机构拨打电话。
Chapter 11 Analysis concepts and principles
为 SafeHome描述的对象可能包括：若干烟雾传
感器、若干窗口和门传感器、若干运动检测
器、一个报警器、一个事件（启动某传感
器），一个控制面板，一个显示器，一串电
话号码、一次电话拨号。
服务的列表可能包括：设置报警器、监控传感
器、电话拨号、控制面板编程、以及读显示
器。
开发约束列表：系统的制造成本必须低于 200万
美圆、界面友好、标准电话接口和性能标准
列表。
Chapter 11 Analysis concepts and principles
开发商
记录员
协调者
客户
FAST会议
Chapter 11 Analysis concepts and principles
11.2.3 质量功能部署
质量功能部署（ QFD） 是一种质量管理技
术，他将客户的需要翻译为软件的技术
需求。
QFD标识三类需求：
? 正常的需求
? 期望的需求
? 兴奋的需求
Chapter 11 Analysis concepts and principles
11.3 分析原则
分析方法与一组操作原则相关联。
1.必须表示和理解问题的信息域。
2.必须定义软件将完成的功能。
3.必须表示软件的行为。
4.必须划分描述信息、功能和行为的模型，从而
使得可以以层次的方式揭示细节。
5.分析过程应该从要素信息移向细节实现。
Chapter 11 Analysis concepts and principles
针对需求工程的指导性原则；
? 在开始建立分析模型前先理解问题。
? 开发原型，使得用户能够了解将如何发生人
机交互。
? 记录每个需求的起源和原因。
? 使用多个需求视图。
? 给需求赋予优先级。
? 努力删除含糊性。
Chapter 11 Analysis concepts and principles
11.3.1 信息域
所有的软件应用程序均可被称为数据处理。
软件也处理事件。一个事件表示了系统控
制的某些方面。例如：一个压力传感器检测
压力是否超过安全值，并发送警报到监控软
件，警报信号是一个事件。
信息域包含三个不同的数据和控制视图。
（ 1）信息内容和关系。
（ 2）信息流。
（ 3）信息结构。
Chapter 11 Analysis concepts and principles
? 信息内容表示了单个数据和控制对象。
他们构成了某个更大的由软件变换的信
息集合。如工资数据对象是一组数据的
集合：姓名、付款总额等。数据和控制
对象可和其他的数据和控制对象相关联。
信息流表示了数据和控制在系统中流动时
的变化方式。
Chapter 11 Analysis concepts and principles
Transform#1 Transform#2
Data/control
Store
Input
object
Output
objectIntermediate data and
control
数据变换是程序必须完成的功能和子功能。
? 信息结构表示了各种数据和控制项的内部组
织
11.3.2 建摸
建摸是为了更好地理解实际实体。对软件
变换的信息进行建摸，对变换发生的功能进
行建摸、以及对变换发生时的行为进行建摸。
在软件需求分析阶段，我们创建将要建造的
系统的模型，着重描述系统必须做什么、而
不是如何做。一般使用图形符号体系创建模
型。
Chapter 11 Analysis concepts and principles
Chapter 11 Analysis concepts and principles
? 功能建摸：
三个常见功能：输入、处理和输出。
从单个的语境层模型开始，经过一系列的迭代，
将提供越来越多的功能细节，直至得到所有
系统功能的完全描绘。
行为模型：
一个计算机程序总是存在某个状态 — 一种外
部可观测到的行为模式（如等待、计算打印
等）。仅当某事件发生时才改变。
Chapter 11 Analysis concepts and principles
需求分析阶段创建的模型扮演了一系列的
角色：
? 模型帮助分析员理解系统的信息、功能
和行为，因此，使得需求分析任务更容
易实现。
? 模型成为复审的焦点。成为确定规约的
完整性、一直性和紧缺性的重要依据。
? 模型成为设计的基础。
Chapter 11 Analysis concepts and principles
11.3.3 划分
问题经常太大而且复杂，以至于难于进行
整体理解。为此往往将这样的问题划分为易
于理解的子问题，并建立子问题的接口，以
使得可以完成整个的功能。
在概念上，我们建立功能的层次表示，然
后划分最上层的元素，（ 1）在垂直方向上划
分显露更多的细节，（ 2）在层次上水平划分
问题。
Chapter 11 Analysis concepts and principles
01
Alarm
Check
fire
SAFEHOME
1 2 3
4 5 6
7 8 9
* 0 #
armed power
off away stay
max test bypass
instant code chime
ready
panic
Away
Stay
Instant
Bypass
Not ready
Chapter 11 Analysis concepts and principles
Safehome software
Configure system Monitor sensors Interact with user
水平分解
功能水平分解
Chapter 11 Analysis concepts and principles
Safehome software
Configure system Monitor sensors Interact with user
Poll for
sensor event
Activate
Alarm function
Read
Sensor
Status
identify
event
type
activate
deactivate
sensor
activate
audible
alarm
dial
phone
number
功能的
垂直划
分
Chapter 11 Analysis concepts and principles
11.3.4 基本视图和实现视图
软件需求的基本视图给出了将要完成的功能和
将要处理的信息，而不管实现细节。细节在
以后解决。
软件需求的实现视图给出了处理功能和信息结
构的现实世界表示，常通过规定适应某些实
现细节的方式来刻划。如 Safehome软件系统
的一个输入设备是边界传感器，该传感器通
过感知电路的中断而检测进入是否合法。该
传感器的一般特性应该作为软件需求规约的
一部分。分析员必须识别这些元素而带来的
约束。
Chapter 11 Analysis concepts and principles
11.4 软件原型
11.4.1 选择原型方法
11.4.2 原型方法和工具
为了使软件原型方法有效，必须快
速地开发原型以使得客户可以评估结果
和建议做修改。
基本方法和工具如下：
Chapter 11 Analysis concepts and principles
? 第四代技术 — 是理想的快速原型开发技术；
? 可复用软件构件；
? 混合型方法
? 形式化规约和原形环境。
11.5 规约
规约的模式与软件的质量有很大关系，不完整
的、不一致的或易误解的规约必然会严重影
响软件质量。
Chapter 11 Analysis concepts and principles
11.5.1 规约原则
11.5.2 表示
软件需求可以用一系列方式来刻化。
? 表示格式和内容应该和问题相关。表示
形式随着应用领域的变化而发生变化。
例如制造自动化系统的规约将使用和程
序设计语言编译器的规约用不同的符号。
? 包含在规约中的信息应该是嵌套的。
Chapter 11 Analysis concepts and principles
? 图和符号在数量上有所限制，在使用上
应该一致。
? 表示应该是可修定的。
11.5.3 软件需求规约
软件需求规约是分析任务的最终产物。
软件需求规约框架。（略）
Chapter 11 Analysis concepts and principles
11.6 规约复审
复审首先在宏观上进行。在该层次上，复
审者试图保证规约是完整的。
? 叙述的软件目标与系统目标是否一致？
? 设计约束是现实的吗？
? 是否考虑过开发的风险？
? 是否考虑过开发的技术风险？
? 是否复审过初步的用户手册？
? 是否存在不一致性？
等等
Summary
Requirements analysis is the first technical step in
the software engineering process,It is at this
point that a general statement of software scope
is refined into a concrete specification that
becomes the foundation for all software
engineering activities that follow.
Analysis must focus on the information,
functional,and behavioral domains of a problem,
To better understand what is required,models are
created,the problem is partitioned,and
representations that depict the essence of
requirements and later,implementations details,
Summary
are developed,
In many cases,it is not possible to completely
specify a problem at an early stage,Prototyping
offers an alternative approach that results in an
executable model of the software from which
requirements can be refined,To properly conduct
prototyping special tools and techniques are
required.
电子教案
王树林
Chapter 11 Analysis concepts and principles
软件需求理解对软件开发工作是至关重要
的。
需求分析任务是发现、求精、建摸和规约
的过程。
客户：尽力描述功能和性能。
开发者,功能的询问者、和问题解决者。
Chapter 11 Analysis concepts and principles
11.1 需求分析
需求分析是一种软件工程活动。
系统工程
软件需求分析
软件设计
Chapter 11 Analysis concepts and principles
软件需求分析的 5个阶段：
（ 1）问题分析，
（ 2）问题评估和方案综合，
（ 3）建摸，
（ 4）规约，
（ 5）复审。
Chapter 11 Analysis concepts and principles
在这个阶段要得到详细的规约是不
可能的。
11.2 通信技术
开发者与客户之间的通信与交流经
常是不顺畅的。
11.2.1 过程的启动
客户与开发者之间最常用的方式为
预备会议或访谈。
Chapter 11 Analysis concepts and principles
11.2.2 便利的应用规约技术
客户与软件工程师经常有无意识的
“我们和你们”的区分不是按需要来将
一支队伍标识和精化，而是各自定义自
己的“版图”，并通过一系列备忘录、
正式的意见书、文档以及提问和回答会
议来相互通信。事实说明，这种方法不
是很有效的。
正是由于这个原因，才开发了一种面向团队的
需求收集方法，被称之为便利的应用规约技
术（ FAST）。 该方法鼓励客户与开发者之间
的合作，提出解决方案。
? 在中立的地点举行会议，由开发者和客户出
席。
? 建立准备和参与会议的规则。
? 鼓励思维的交流。
? 一个协调者控制会议。
? 使用一种“定义机制”（工作表、图表、墙
版）。
Chapter 11 Analysis concepts and principles
Chapter 11 Analysis concepts and principles
? 目标是标识问题、提出解决方案的要素、商
议不同方法，营造解决问题的氛围。
例如：假定为消费产品公司工作的 FAST团队提
供了下面的产品描述。
我们的研究表明，家庭安全系统的市场正以每年 40%的比率增长，
我们希望能进入该市场，并试图建立基于微处理器的家庭安全
系统，该系统将保护和识别一系列意外事件，如非法入侵，火
警、水灾或其他。该产品暂时称为 SafeHome,产品将采用合适
的传感器来检测各种情况，具体使用时房主可按需编程，并且
当系统检测的意外情况时，会自动地给监控机构拨打电话。
Chapter 11 Analysis concepts and principles
为 SafeHome描述的对象可能包括：若干烟雾传
感器、若干窗口和门传感器、若干运动检测
器、一个报警器、一个事件（启动某传感
器），一个控制面板，一个显示器，一串电
话号码、一次电话拨号。
服务的列表可能包括：设置报警器、监控传感
器、电话拨号、控制面板编程、以及读显示
器。
开发约束列表：系统的制造成本必须低于 200万
美圆、界面友好、标准电话接口和性能标准
列表。
Chapter 11 Analysis concepts and principles
开发商
记录员
协调者
客户
FAST会议
Chapter 11 Analysis concepts and principles
11.2.3 质量功能部署
质量功能部署（ QFD） 是一种质量管理技
术，他将客户的需要翻译为软件的技术
需求。
QFD标识三类需求：
? 正常的需求
? 期望的需求
? 兴奋的需求
Chapter 11 Analysis concepts and principles
11.3 分析原则
分析方法与一组操作原则相关联。
1.必须表示和理解问题的信息域。
2.必须定义软件将完成的功能。
3.必须表示软件的行为。
4.必须划分描述信息、功能和行为的模型，从而
使得可以以层次的方式揭示细节。
5.分析过程应该从要素信息移向细节实现。
Chapter 11 Analysis concepts and principles
针对需求工程的指导性原则；
? 在开始建立分析模型前先理解问题。
? 开发原型，使得用户能够了解将如何发生人
机交互。
? 记录每个需求的起源和原因。
? 使用多个需求视图。
? 给需求赋予优先级。
? 努力删除含糊性。
Chapter 11 Analysis concepts and principles
11.3.1 信息域
所有的软件应用程序均可被称为数据处理。
软件也处理事件。一个事件表示了系统控
制的某些方面。例如：一个压力传感器检测
压力是否超过安全值，并发送警报到监控软
件，警报信号是一个事件。
信息域包含三个不同的数据和控制视图。
（ 1）信息内容和关系。
（ 2）信息流。
（ 3）信息结构。
Chapter 11 Analysis concepts and principles
? 信息内容表示了单个数据和控制对象。
他们构成了某个更大的由软件变换的信
息集合。如工资数据对象是一组数据的
集合：姓名、付款总额等。数据和控制
对象可和其他的数据和控制对象相关联。
信息流表示了数据和控制在系统中流动时
的变化方式。
Chapter 11 Analysis concepts and principles
Transform#1 Transform#2
Data/control
Store
Input
object
Output
objectIntermediate data and
control
数据变换是程序必须完成的功能和子功能。
? 信息结构表示了各种数据和控制项的内部组
织
11.3.2 建摸
建摸是为了更好地理解实际实体。对软件
变换的信息进行建摸，对变换发生的功能进
行建摸、以及对变换发生时的行为进行建摸。
在软件需求分析阶段，我们创建将要建造的
系统的模型，着重描述系统必须做什么、而
不是如何做。一般使用图形符号体系创建模
型。
Chapter 11 Analysis concepts and principles
Chapter 11 Analysis concepts and principles
? 功能建摸：
三个常见功能：输入、处理和输出。
从单个的语境层模型开始，经过一系列的迭代，
将提供越来越多的功能细节，直至得到所有
系统功能的完全描绘。
行为模型：
一个计算机程序总是存在某个状态 — 一种外
部可观测到的行为模式（如等待、计算打印
等）。仅当某事件发生时才改变。
Chapter 11 Analysis concepts and principles
需求分析阶段创建的模型扮演了一系列的
角色：
? 模型帮助分析员理解系统的信息、功能
和行为，因此，使得需求分析任务更容
易实现。
? 模型成为复审的焦点。成为确定规约的
完整性、一直性和紧缺性的重要依据。
? 模型成为设计的基础。
Chapter 11 Analysis concepts and principles
11.3.3 划分
问题经常太大而且复杂，以至于难于进行
整体理解。为此往往将这样的问题划分为易
于理解的子问题，并建立子问题的接口，以
使得可以完成整个的功能。
在概念上，我们建立功能的层次表示，然
后划分最上层的元素，（ 1）在垂直方向上划
分显露更多的细节，（ 2）在层次上水平划分
问题。
Chapter 11 Analysis concepts and principles
01
Alarm
Check
fire
SAFEHOME
1 2 3
4 5 6
7 8 9
* 0 #
armed power
off away stay
max test bypass
instant code chime
ready
panic
Away
Stay
Instant
Bypass
Not ready
Chapter 11 Analysis concepts and principles
Safehome software
Configure system Monitor sensors Interact with user
水平分解
功能水平分解
Chapter 11 Analysis concepts and principles
Safehome software
Configure system Monitor sensors Interact with user
Poll for
sensor event
Activate
Alarm function
Read
Sensor
Status
identify
event
type
activate
deactivate
sensor
activate
audible
alarm
dial
phone
number
功能的
垂直划
分
Chapter 11 Analysis concepts and principles
11.3.4 基本视图和实现视图
软件需求的基本视图给出了将要完成的功能和
将要处理的信息，而不管实现细节。细节在
以后解决。
软件需求的实现视图给出了处理功能和信息结
构的现实世界表示，常通过规定适应某些实
现细节的方式来刻划。如 Safehome软件系统
的一个输入设备是边界传感器，该传感器通
过感知电路的中断而检测进入是否合法。该
传感器的一般特性应该作为软件需求规约的
一部分。分析员必须识别这些元素而带来的
约束。
Chapter 11 Analysis concepts and principles
11.4 软件原型
11.4.1 选择原型方法
11.4.2 原型方法和工具
为了使软件原型方法有效，必须快
速地开发原型以使得客户可以评估结果
和建议做修改。
基本方法和工具如下：
Chapter 11 Analysis concepts and principles
? 第四代技术 — 是理想的快速原型开发技术；
? 可复用软件构件；
? 混合型方法
? 形式化规约和原形环境。
11.5 规约
规约的模式与软件的质量有很大关系，不完整
的、不一致的或易误解的规约必然会严重影
响软件质量。
Chapter 11 Analysis concepts and principles
11.5.1 规约原则
11.5.2 表示
软件需求可以用一系列方式来刻化。
? 表示格式和内容应该和问题相关。表示
形式随着应用领域的变化而发生变化。
例如制造自动化系统的规约将使用和程
序设计语言编译器的规约用不同的符号。
? 包含在规约中的信息应该是嵌套的。
Chapter 11 Analysis concepts and principles
? 图和符号在数量上有所限制，在使用上
应该一致。
? 表示应该是可修定的。
11.5.3 软件需求规约
软件需求规约是分析任务的最终产物。
软件需求规约框架。（略）
Chapter 11 Analysis concepts and principles
11.6 规约复审
复审首先在宏观上进行。在该层次上，复
审者试图保证规约是完整的。
? 叙述的软件目标与系统目标是否一致？
? 设计约束是现实的吗？
? 是否考虑过开发的风险？
? 是否考虑过开发的技术风险？
? 是否复审过初步的用户手册？
? 是否存在不一致性？
等等
Summary
Requirements analysis is the first technical step in
the software engineering process,It is at this
point that a general statement of software scope
is refined into a concrete specification that
becomes the foundation for all software
engineering activities that follow.
Analysis must focus on the information,
functional,and behavioral domains of a problem,
To better understand what is required,models are
created,the problem is partitioned,and
representations that depict the essence of
requirements and later,implementations details,
Summary
are developed,
In many cases,it is not possible to completely
specify a problem at an early stage,Prototyping
offers an alternative approach that results in an
executable model of the software from which
requirements can be refined,To properly conduct
prototyping special tools and techniques are
required.
