例：
, Name
I D#
31
例如：
Title ID# Name ID# Name Instructor Student
Sex
Sex
……
Instructor ID
21
2.需求文档的版本控制 版本控制是管理需求的一个必要方面。需求文档的每一个 版本必须被统一确定，小组内每个成员必须能够得到需求的当 前版本，必须清楚地将变更写成文档，并及时通知到项目开发 所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指 定的人来更新需求。 每一个公布的需求文档的版本应该包括一个修正版本的历 史情况，即已做变更的内容、变更日期、变更人姓名以及变更 原因，可以考虑给每个需求标记上版本号，当修改满足需求后 就增加版本号。 版本控制的最有力方法是用一个商业需求管理工具的数据库 存储需求，这些工具可以跟踪和报告每个需求的变动历史， 特别是当需要恢复早期的需求时非常有意义。
3.2.1 需求开发
一. 需求获取
从用户获得需求，并整理成文档。 注：分析员与各种层析的客户进行交流，如决策人，具体使 用人，系统维护人员等等。 OOA中常采用方法：用例方法获取需求。
二. 需求分析
对上阶段获取的需求进行分析、提炼，并用相应的分析模型 描述出来，分析出高质量的需求。
7
1 主要任务：

10
2 与用户沟通获取需求的方 法

快速建立软件原型
构建和修改原型的方法和工具
第四代技术：包括数据库查询和报表语言、程序和应用 系统生成器以及其他非常高级的非过程语言 可重用的软件构件 形式化规格说明和原型环境

Байду номын сангаас
11
1 主要任务：

分析系统的数据要求
任何一个软件系统本质是都是信息处理系统，分析
数据词典
判定表与判定树、 结构化英语 层次方框图、Warnier图、IPO图
28
3.3.1 分析模型
结构化分析导出的分析模型包括数据模型、功能模型和行为模型 ，该模型以“数据字典”为核心，它描述了软件使用的所有数据 对象。
数 据 模 型
实体关系图
数据流图
功 能 模 型
数据字典
状态转换图
行为模型
29
系统的数据要求是需求分析的一个重要任务 分析系统的数据要求通常是采用建立E-R图 复杂数据的表示方法主要有数据字典、层次方框图、 Warnier图 数据结构规范化

导出系统的逻辑模型：通常用数据流图、E-R图、 状态转换图、数据字典和主要处理的算法 修正系统开发计划
12

3.需求分析的过程
定义：指应用已证实有效的技术、方法进行需求分析，确定
客户需求，帮助分析人员理解问题并定义目标系统的所有 外部特征的一门学科。
主要活动：
需求获取 需求建模（需求分析） 需求传递：编写规格（规约）说明书 需求验证 需求管理
需求工程的层次分解示意图 需求工程
需求开发
需求管理
问题获取
需求分析
编写规格说明
验证

面向数据流自顶向下求精 简易的应用规格说明技术

典型过程 进行初步的访谈,初步确定待解决的问题的范围和解决方案 开发者和用户分别写出“产品需求” 选定会议时间和地点及主持会议的协调人 要求与会者做好参会准备 会议开始后首先讨论“是否需要这个新产品”，得到确认后， 讨论每人的列表，严格禁止批评和争论
实体关系图（Entity-Relationship Diagram，ERD）：作为数 据建模的基础，描述数据对象及其关系； 数据流图（Data Flow Diagram，DFD）：作为功能建模的基础 ，描述数据怎样转换以及转换的功能；
状态转换图（State-Transition Diagram，STD）：作为行为建 模的基础，表示系统的各种行为状态以及状态间的转换方式。

出错处理需求(有选择地提出) 接口需求：软件同其它系统元素的接口细节 约束需求：软件设计的约束,主要有：精度，工具和语言约束，设 计约束，应该使用的标准，应该使用的硬件平台 逆向需求：系统不应该做什么 将来可能提出的要求
8
2 与用户沟通获取需求的方 法

访谈 访谈有正式的访谈和非正式的访谈 发放调查表 情景分析技术
（1）用户解决问题或达到目标所需的条件或能力； （2）系统或系统部件要满足合同、标准、规范或其它正式规定 文档所需具有的条件或能力。 （3）一种反映（1）或（2）所描述的条件或能力的文档说明。 定义从两个角度阐述需求： 用户角度 系统的外部行为 开发者角度 系统的内部特性 其关键的问题：编写需求文档。
20
1.需求变更控制
一些需求的改进是合理的且不可避免。 不被控制的变更是项目陷入混乱、不能按进度执行或软件质量 低劣的共同原因，因此，需求变更应该实现以下要求： ● 应仔细评估已建议的变更； ● 挑选合适的人选对变更做出决定； ● 变更应及时通知所有涉及的人员； ● 项目要按一定的程序来采纳需求变更。
使用需求跟踪能力矩阵分析变更产生的影响
CMM:软件能力成熟度模型的目标之一：进行需求管理
25
2.需求管理工具 需求管理工具有两种类型： a.以文档为核心的 b.以数据库核心的
26
3.3 分析建模
现在在主导地位的分析方法为： 结构化分析方法(SA)和面向对象的分析方法(OOA) 本节主要讲SA。 结构化分析方法最早开始于20世纪60年代末和70年代 初。DeMaro在1979年出版的《Structured Analysis and System Specification》一书中，给出了数据流 图等结构化分析工具，并使用数据字典和加工说明等 作为图形工具的补充。

需求分析研究的对象是软件项目的用户要求 确定对系统的综合要求 功能需求:系统必须完成的所有功能 性能需求:系统必须满足的定时约束或容量约束,如速度、信息量速 率、主存容量、磁盘容量、安全性等方面的需求 可靠性和可用性需求

可靠性需求：系统的可靠性，如“某系统一月内不能出现2次故障” 可用性需求：与可靠性需求相关，量化了用户可以使用系统的程度， “任何时候主机或备份机上的系统应该至少有一个是可用的，且在一 月内在任何计算机上该系统不可用的时间不能超过总时间的2%”

需求传递（编制需求文档）
软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 注：格式见附录
四 需求验证（需求评审） 系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述;
30
一.实体 -联系图(Entity-Relationship Diagram)
数据模型有三种基本元素：数据对象、属性、关系。
⑴ Entities ⑵ Relations
1 1
Student , Instructor 例：
,
Class Teach N
例：
1
Enrolled in N M
⑶ Attributes

17


被开发项目的数据流与数据结构是否足够，确定; 所有图表是否清楚，在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内，是否都已 充分说明; 设计的约束条件或限制条件是否符合实际; 开发的技术风险是什么; 是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准，它们能否对系统定义是否成 功进行确认;
2
3.1.2 需求的层次
软件需求包括四个不同的层次： 1.业务需求：描述了组织结构或客户对系统的高层次的目标要求。 2.用户需求：描述了用户使用产品必须要完成的任务，使用实例模型描述。 3.功能需求：定义了开发人员实现的软件的功能。 4.约束需求：描述系统的约束和限制条件。
注：以上需求应详细的写到软件需求规格说明书里。
13
问题识别的另一项工作是建立分析所需要的通信途径， 以保证能顺利地对问题进行需求分析。
14
(2) 分析与综合
A.主要任务（建立系统的逻辑模型） 从信息流和信息结构出发，逐步细化所有的软件功能， 找出系统各元素之间的联系、接口特性和设计上的约 束，分析它们是否满足功能要求，是否合理。剔除其 不合理的部分，增加其需要部分。最终综合成系统的 解决方案，给出目标系统的详细逻辑模型。 B.常用的分析方法
(1) 问题识别 从系统的角度来理解软件并评审软件范围是否恰当 确定对目标系统的综合要求，即软件的需求 提出这些需求实现条件，以及需求应达到的标准
软件的需求包括：
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求


资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可 能达到的目标
18
需求开发流程
19
3.2.2 需求管理
需求管理从形成需求基线开始，分析变更影响并控制变更过 程。 主要包括变更控制、版本控制和需求跟踪等活动。
变更控制就是在一定的程序下有效地实施整个变更过程；
版本管理保证了在需求文档中记录和反映所有的需求变化；
需求跟踪帮助人们全面地分析变更带来的影响，从而作出正确 的变更决策。 三者统一起来，真正做到了管理需求变化过程，以及维护需求 变化后的一致性和完整性。
3
3.1.3 需求错误的原因

需求描述模棱两可，有时写的过于简单； 用户的要求不断变换，需求也不断变化； 参与的用户过少，而且忽略了用户的分类； 追求个性化，添加不必要的特性。
需求越来越复杂，但很重要，现在提出了采用工 程化的思想对需求进行分析，引出需求工程的概念。