需求工程

一. EA配置ATM项目

1. 导入.eap文件

2. 导入源Java文件

3. 配置分析器

build

platform

run

4. 编译运行

二. ATM界面介绍

1. 操作人员面板

2. 顾客面板

3. EA质量保证估算

三. 需求工程

1. 定义

是应用已证实有效的原理和方法，通过合适的工具和符号，系统地描述出待开发系统及其行为特征和相关约束

2. 需求工程任务框图

3. 需求工程主要活动

(1). 需求获取

• 向系统相关者进行问卷调查
• 主持与用户的面谈和讨论
• 需求专题讨论会
• 复查现有的报表、表格和过程描述
• 观察商业过程和工作流
• 应用案例
• 建立原型
• 头脑风暴
• 联合应用开发（Joint Application Development， JAD）
• 快速应用开发（Rapid Application Development， RAD）

(2). 需求分析

1. 需求分析的成果

1. 完成功能定义，以及对质量和约束的说明
2. 完成领域建模，即对客户的业务活动进行描述

2. 需求分析的核心在于建立分析模型

1. 需求分析采用多种形式（如文本和图形等）描述需求，通过建立需求的各种视图，解释出一些更深的问题
2. 分析建模的方法有很多，其中最重要的两种模型是结构化模型和面向对象模型

3. 需求分析建模

Ⅰ. 结构化模型

1. 基本思想

自顶向下
逐步求精
模块化设计
结构化编码

2. 基本原则

抽象和分解

3. 结构化分析模型

1. 核心层
   数据字典
2. 图层
   实体关系图ERD（Entity-Relationship Model）

实体
 属性
 联系

数据流程图DFD（Data Flow Diagram）

基本元素

状态转换图STD（State Transition Diagram）

状态图

1. 模型层
   数据模型：层次模型、概念数据模型、物理模型
   功能模型：DFD
   行为模型：STD

Ⅱ. 面向对象模型

1. 基本要点

OMT三个模型

对象模型
动态模型
功能模型

Coad五个层次

主题层
对象类层
结构层
属性层
服务层

OOA五个活动

标识对象类
标识结构
定义主题
定义属性
定义服务

2. 用例图UCD

• 获取原始的功能需求
• 开发用例图
• 描述需求对象的行为
• 构建用例模型

3. OO分析与设计Gap与Bridge：鲁棒图

用例面向问题域，设计面向机器域
用例非OO思维，设计是OOM思维
用例规约是自然语言描述，设计是形式化语言描述

面向对象分析与设计存在鸿沟，鲁棒图分析起到了桥梁的作用

鲁棒图三要素

边界Boundary
控制Control
实体Entity

鲁棒图原则

Actor只能与Bounday进行互动
Boundary及Entity必须透过Control交谈
Entity与Entity必须透过Control
Boundary与Boundary之间必须透过Control

4. OOA动态建模：顺序图

顺序图SD（Sequence Diagram）是将交互关系表示为一个二维图。
纵向是时间轴，时间沿竖线向下沿伸。横向轴代表在协作中各独立对象的类元角色。
类元角色用生命线表示。
当对象存在时，角色用一条虚线表示，
当对象的过程处于激活状态时，生命线是一个双道线/长条矩形

5. OOA动态模型：活动图

活动图AD（Activity Diagram）是阐明业务用例实现的工作流程。
业务用例由一系列活动组成，它们共同为业务主角生成某些工件。
工作流程通常包括一个基本工作流程和一个或多个备选工作流程

4. 需求分析的任务

需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题

4. 需求分析的过程

过程1：问题识别

从系统的角度来理解软件并评审 软件范围是否恰当
确定对目标系统的综合要求，即软件需求
提出软件需求实现条件，以及需求应达到的标准

过程2：分析内容

功能需求
性能需求
环境需求
可靠性需求
安全保密要求
用户界面需求

核心需求

用户需求分类
(1)功能性需求:

定义了系统做什么（描述系统必须支持的功能和过程）

(2)非功能性需求（技术需求）:

定义了系统工作时的特性（描述操作环境和性能目标）

过程3：分析与综合

从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。剔除其不合理的部分，增加其需要部分
最终综合成系统的解决方案，给出目标系统的详细逻辑模型

常用的分析方法

面向数据流的结构化分析方法（ODFA）
面向数据结构的Jackson方法（ODS_JSD）
结构化数据系统开发方法（DSSD）
面向对象的分析方法（OOA）

过程4：编制需求文档

软件需求说明书
数据要求说明书
初步的用户手册
修改、完善与确定软件开发实施计划

过程5：需求分析评审

系统定义的目标是否与用户的要求一致;
系统需求分析阶段提供的文档资料是否齐全;
文档中的所有描述是否完整、清晰、准确反映用户要求;
与所有其它系统成分的重要接口是否都已经描述;

(3). 需求规格说明

1. 定义

软件需求说明书SRS(Software Requirements Specification)： 是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等

2. 作用

作用：软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础

对于提供什么软件产品，为顾客和供方之间的协议建立基础
减少开发工作
为估计成本和进度提供基础
为验证和确认提供基线
便于软件产品转移
作为进一步增强的基础

3. 文档要求：

获取的需求需要被编写成文档，主要目的是为了在系统涉众之间交流需求信息
业务需求被写入项目前景和范围文档
用户需求被写入用户需求文档（或者用例文档）
系统需求被写入需求规格说明
必须描述一定的功能、性能
必须用确定的方法叙述这些功能
SRS不描述任何设计、验证或项目管理的细节

4. 术语

合同：是顾客和供方共同签署的具体有法律约束力的文件。其中包括产品的技术、组织、成本和进度计划要求等内容

顾客：为产品支付费用，并通常（但不必要）确定需求的个人或群体，在某些情况下，顾客和供方可以是同一组织的成员

供方：为顾客开发产品的个人或群体。在某些情况下，顾客和供方可以是同一组织的成员

用户：直接运行系统产品或与产品进行交互作用的个人或集团。用户和顾客通常不是同一个人或群体

(4). 需求验证

1. 定义

需求验证是为了确保需求说明准确、完整地表达必要的质量特点

2. 方法

• 审查需求文档
• 以需求为依据编写测试用例
• 编写用户手册
• 确定合格的标准

(5). 需求管理

1. 需求管理的变更、跟踪

四. ATM案例简介(Mind Mapping Model/Diagram)

1. 思维导图

2. 需求建模（本讲重点）

(1). 用例模型

用例图（use casediagrams）：在软工需求分析阶段用来描述用户需求，从用户角度描述系统的功能， 并指出各功能的执行者，强调谁在使用系统，系统完成什么功能。

(1). 用例图中的四个基本组件

用例图包括：参与者或角色（actor）、用例（use case)、关系、系统。

1、 参与者：

是系统外的一个实体，它以某种方式参与用例我执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行，所以参与者可以是人，可以是事物，可以是时间、气压等环境因素或者其他系统等。它在系统之外，与系统直接交互。用一个群体概念给参与者命名，反映该参与者的身份与行为（如客户、管理员等）。

2、 用例：

用例代表系统的某项完整的功能，是动作步骤的集合。系统的功能是通过参与者使用用例来实现的。在这里，我们把用例看做是一个“黑盒”，只反映的是系统的一项功能，不涉及实现细节。
用例的命名：用例是从用户的角度来描述系统的功能，也就是从参与者的角度出发进行命名（如，使用“登录”，而不用“身份验证“）。还有，用例最好使用行业专业术语。

3、关系：

除了参与者与用例之间的关联关系外，还可以定义参与者之间的泛化关系，用例之间的包含、泛化与扩展关系。应用这些关系的目的是从系统中抽取出公共行为及其变体。

4、 系统：

系统指一个软件系统、一项业务、一个商务活动、一台机器等等。系统的功能通过用例来表现，换句话说，就是所有的用例构成了整个系统。从这个角度来说，用例（use case)也可以称为系统的子功能。系统用矩形表示，也可以省略。

(2). 用例图中的关系

1、包含关系

在包含关系中，基本用例吸收了被包含用例的行为，如果没有后者它将是不完整的。
包含关系的划分有两个好处：一是被包含用例被抽取出来，基本用例得以简化；二是可以抽象出公共事件流，实现代码复用。

有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。如:

2、扩展

将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
对于一个扩展用例，可以在基用例上有几个扩展点。
例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

3、泛化关系

1）参与者之间的泛化关系
例如，一个网上订购系统，可以有网上客户、电话客户、直接客户等。可以看出，他们有共同的行为特征，这就是可以用到面向对象的抽象，抽象出更为一般的化的参与者——客户。通过泛化来描述多个参与者之间的共同行为，不同的参与者以独特的方式来使用系统。

2）用例与用例之间的关系
用例与用例之间也存在着泛化关系，通常用于表示同一业务目的（父用例）的不同技术实现（各个子用例）。
例如某购物系统为用户提供不同的支付方式，那么”支付”这个复杂用例就可以用泛化关系表示。

(3). 包含关系与扩展关系共同点

扩展用例与包含用例都是基用例的一部分.

基本用例不执行，扩展用例与包含用例都不会执行
扩展用例可以扩展多个基本用例，包含用例可以被多个基本用例包含

区别：
扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。

包含关系中基本用例的基本流执行时，包含用例一定会执行。

(2). 需求模型

1. 文本描述

2. EA需求模型