软件工程之 需求获取ppt课件
合集下载
软件工程3软件需求分析ppt课件
1）从问题描述中分析出4种基本组成成分 （1）外部实体：顾客。 （2）数据流：顾客ID、现金、IC卡信息、购物
单、发票信息、维护结果、对账结果、结账信 息、正确的帐户信息。
（3）加工：发卡、维护、对账及错误处理、发 票打印、结算。
（4）数据存储：发卡记录、结账记录。
2）画出系统的基本模型
图3-2 IC卡管理系统的顶层数据流图
以火车票售票为例，如果是学生，并且每年累计的 乘车次数少于4次，则售半票，否则售全票。用形式化 语言可描述如下：
IF 乘客是学生 THEN
IF 每年累计的乘车次数少于4次 THEN 售半票 ELSE 售全票 ENDIF ELSE 售全票 ENDIF
结构化语言的特点是简单直观，且容易转化为程序， 但它不方便处理组合条件。
（1）变换型数据流图
具有较明显的输入、变换（或主加工）和输 出的数据流图称为变换型数据流图。在变换型 数据流图中，主加工是系统的中心。如图3-2 所示的是一个典型的变换型数据流图，图中 “发卡”是主加工，“现金”是输入，“IC卡” 是输出。
图3-2 IC卡管理系统的顶层数据流图
（2）事务型数据流图
3.1.2 需求分析的原则
1．分析人员要使用符合用户语言习惯的表达
2．分析人员要了解用户的业务及目标 3．分析人员必须编写软件需求报告 4．要求得到需求工作结果的解释说明 5．开发人员要尊重客户的意见 6．开发人员要对需求及产品实施提出建议和解决方案
7．描述产品使用特性 8．允许重用已有的软件组件 9．要求对变更的代价提供真实可靠的评估 10．获得满足客户功能和质量要求的系统 11．给分析人员讲解业务
某个加工将它的输入分离成一串发散的数据 流，形成许多活动路径，并根据输入的值选择 其中一条路径，具有这样特征的数据流图是事 务型数据流图。
ch3软件工程需求工程PPT课件
34
Requirements Elicitation is difficult
用户和开发人员的背景不同，立场不同
首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够 和用户进行有效沟通的粗略的知识框架
默认（Tacit）知识现象
软件需求可以直接映射为系统行为，定义了系统中需要实 现的功能，描述了开发人员需要实现什么
将用户需求转化为软件需求的过程是一个复杂的过程
首先需要分析问题领域及其特性，从中发现问题域和计算机系统的 共享知识，建立系统的知识模型；
然后将用户需求部署到系统模型当中，即定义系列的系统行为，让 它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
11
需求的重要性
4.在需求阶段，代表性的错误为疏忽、不一致和 二义性。
美国海军研究实验室从20世纪70年代起就对软件开 发技术不断地进行研究。他们对海军A－7E飞机上 的并行操作程序进行实地测试，以验证许多新设想 的可行性。得出的研究数据表明：A—7E项目中77 ％的需求错误特点是不明确、疏忽、不一致和二义 性。按错误类型对这些错误分布进行分析的结果是 ：
业务需求反映企业/组织对软件系统的高层次目标需求，也 就是说是软件需求的建设目标。
系统建立的战略出发点，表现为高层次的目标（Objective ），它描述了组织为什么要开发系统 。
为了满足用户的业务需求，需求工程师需要描述系统高层 次的解决方案，定义系统应该具备的特性（Feature）
参与各方必须要对高层次的解决方案达成一致，以建立一 个共同的前景（Vision）
（1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正 式规定文档所需具有的条件或能力。 （3）一种反映上面（1）或（2）所描述的条件或能力的 文档说明。
Requirements Elicitation is difficult
用户和开发人员的背景不同，立场不同
首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够 和用户进行有效沟通的粗略的知识框架
默认（Tacit）知识现象
软件需求可以直接映射为系统行为，定义了系统中需要实 现的功能，描述了开发人员需要实现什么
将用户需求转化为软件需求的过程是一个复杂的过程
首先需要分析问题领域及其特性，从中发现问题域和计算机系统的 共享知识，建立系统的知识模型；
然后将用户需求部署到系统模型当中，即定义系列的系统行为，让 它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
11
需求的重要性
4.在需求阶段，代表性的错误为疏忽、不一致和 二义性。
美国海军研究实验室从20世纪70年代起就对软件开 发技术不断地进行研究。他们对海军A－7E飞机上 的并行操作程序进行实地测试，以验证许多新设想 的可行性。得出的研究数据表明：A—7E项目中77 ％的需求错误特点是不明确、疏忽、不一致和二义 性。按错误类型对这些错误分布进行分析的结果是 ：
业务需求反映企业/组织对软件系统的高层次目标需求，也 就是说是软件需求的建设目标。
系统建立的战略出发点，表现为高层次的目标（Objective ），它描述了组织为什么要开发系统 。
为了满足用户的业务需求，需求工程师需要描述系统高层 次的解决方案，定义系统应该具备的特性（Feature）
参与各方必须要对高层次的解决方案达成一致，以建立一 个共同的前景（Vision）
（1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正 式规定文档所需具有的条件或能力。 （3）一种反映上面（1）或（2）所描述的条件或能力的 文档说明。
软件工程Chapter_4 需求工程PPT课件
17 16
4.1.5非功能需求
非功能需求
从各个角度对系统的约束和限制，反映了应用对软 件系统质量和特性的额外要求，例如响应时间、数 据精度、可靠性、开发过程的标准等。
举例：MiniLibrary
✓系统应在 20 秒之内响应所有的请求。 ✓系统每周 7 天、每天 24 小时都可以使用。 ✓对于一个没有经验的用户而言，经过两个小时的培训就 可以使用系统的所有功能。
面谈之前
n 确立面谈目的 n 确定要包括的相关用户 n 确定参加会议的项目小组成员 n 建立要讨论的问题和要点列表 n 复查有关文档和资料 n 确立时间和地点 n 通知所有参加者有关会议的目的、时间和地点
30
4.2.1 用户面谈
面谈过程需要认真的计划和准备（续）
进行面谈
n 衣着得体，准时到达 n 寻找异常和错误情况 n 深入调查细节 n 详细记录 n 指出和记录下未回答条目和未解决问题
的浪费 软件规格说明有助于开发人员与客户在“What to
do”问题上达成正式契约 需求分析形成了软件开发的基线，有助于管理软件的
演化和变更 软件需求是软件质量的基础，为系统验收测试提供了
标准
4
软件需求的重要性
Trace ability
5
案例：小型图书资料管理系统
• 问题描述
– 某学院打算开发一个小型图书资料管理系统 MiniLibrary，该 系统基于 Internet 实现教师和学生对各种图书资料的借阅、查 询和管理。
14 13
案例：用户需求：MiniLibrary
• 举例：
用户可以通过 Internet 随时查询图书信息和个人借阅情况， 并可以快捷地查找和浏览所需要的电子资料。
• 分析：上述需求描述包含了三个不同的需求
4.1.5非功能需求
非功能需求
从各个角度对系统的约束和限制，反映了应用对软 件系统质量和特性的额外要求，例如响应时间、数 据精度、可靠性、开发过程的标准等。
举例：MiniLibrary
✓系统应在 20 秒之内响应所有的请求。 ✓系统每周 7 天、每天 24 小时都可以使用。 ✓对于一个没有经验的用户而言，经过两个小时的培训就 可以使用系统的所有功能。
面谈之前
n 确立面谈目的 n 确定要包括的相关用户 n 确定参加会议的项目小组成员 n 建立要讨论的问题和要点列表 n 复查有关文档和资料 n 确立时间和地点 n 通知所有参加者有关会议的目的、时间和地点
30
4.2.1 用户面谈
面谈过程需要认真的计划和准备（续）
进行面谈
n 衣着得体，准时到达 n 寻找异常和错误情况 n 深入调查细节 n 详细记录 n 指出和记录下未回答条目和未解决问题
的浪费 软件规格说明有助于开发人员与客户在“What to
do”问题上达成正式契约 需求分析形成了软件开发的基线，有助于管理软件的
演化和变更 软件需求是软件质量的基础，为系统验收测试提供了
标准
4
软件需求的重要性
Trace ability
5
案例：小型图书资料管理系统
• 问题描述
– 某学院打算开发一个小型图书资料管理系统 MiniLibrary，该 系统基于 Internet 实现教师和学生对各种图书资料的借阅、查 询和管理。
14 13
案例：用户需求：MiniLibrary
• 举例：
用户可以通过 Internet 随时查询图书信息和个人借阅情况， 并可以快捷地查找和浏览所需要的电子资料。
• 分析：上述需求描述包含了三个不同的需求
软件工程PPT课件第3章 软件需求分析
–多个来回
6
软件需求分析的通信途径
7
分析建模
结构化分析模型 面向对象分析模型 分析模型描述工具
DFD、DD和PSPEC（加工规约）
CFD、CSPEC（控制规约）和STD E-R图 用例图，对象-关系图，对象-行为图
8
结构化分析模型
数据对象 说明 E-R图 加工说明 DFD图
44
数据流图
数据流图(DFD)是一种图形化技术，它描绘信息
流和数据从输入移动到输出的过程中所经受的变换 。 在数据流图中没有任何具体的物理部件，它只是 描绘数据在软件中流动和被处理的逻辑过程。 数据流图是系统逻辑功能的图形表示，即使不是 专业的计算机技术人员也容易理解它，因此是分析 员与用户之间极好的通信工具。 此外，设计数据流图时只需考虑系统必须完成的 基本逻辑功能，完全不需要考虑怎样具体地实现这 些功能。
2
需求分析的结构化分析方法准则
(1) 必须理解并描述问题的信息域，根 据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条 准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件 行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模 型进行分解，用层次的方式展示细节。
40
分析模型的元素
数据字典(DD)：模型核心(中心库) E-R图(ERD)： 数据流图(DFD)
指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能;
DFD中每个功能的描述包含在加工规约 (小说明)。
状态变迁图(STD)
指明作为外部事件的结果,系统将如何 动作。
41
3.4.2 数据建模
4
需求分析的任务和步骤
软件项目需求管理ppt课件
需求开发的主要困难与对策
知识技艺问题
运用域的知识是无边无际的，任何人都不能够是“万事通〞。
当需求分析员缺乏运用域知识时，他该怎样办？
首先他要有勇气做事，否那么连实际的时机都没有。
其次他该当赶紧补习运用域知识。
态度问题
相当多的开发人员习惯于被动地对待需求开发。每当遇到费事、波折 时，他们会发牢骚，找出一堆用户的缺陷。很多开发人员错误地以为：
软件企业的指点该当给具有错误观念的开发人员们洗脑：需求分析员 的天职就是在有限的时间内获取准确而细致的用户需求，假设做不到
需求获取
需求获取时期的主要任务： ⑴ 归纳和整理用户提出的各种问题和要
求； ⑵ 弄清用户企图经过软件到达的目的； ⑶ 借助各种工具和方法，陈说用户提出
的实践需求，并标定软件的作用范围。 最终目的弄明白要“做什么〞。
开发者对待需求工程的态度可分“被动型〞、“自动型〞和“领先型〞三 种，只需后两种才有能够开发出胜利的产品。
“被动型〞是指开发者被动地对待需求工程中的各项活动，能少干那么少 干，能偷懒那么偷懒。他们以为需求是用户的事情而不是本人的事情。开 发过程中经常发生需求变卦，导致产品迷失方向，不是半途而废就是堕入 半死不活的形状。
需求文档包括用户需求和详细的系统需求描画。 要求 正确：正确地反映用户的真实意图； 清楚：易读易懂； 无二义性 一致 完备:没有脱漏一些必要的需求； 可实现： “可实现〞意味着在技术上是可行的，
并且满足时间、费用、质量等约束； 可验证 确定优先级：确定高中低三个级别，将风险降到
最低。
“我们必需建立一个计算机自动客户效力系统。〞罗斯玛丽呼 应道。
史蒂夫建议：“难道我们不能把售后效力转给麦肯罗公司〔公 司下属的一家子公司，以效力为主〕做吗？向他们要求一下，看他 们能否能把电开工具的效力也接过去？〞
软件工程需求分析 教学PPT课件
– 使用户积极配合
2021/7/4
15
3.2.2 面向数据流自顶向下求精
• 数据决定了需要的处理和算法，是需求分析的出 发点。
• 结构化分析方法——面向数据流的自顶向下的逐 步求精进行需求分析的方法。
– 高层数据流图 – 从输出端回溯 – 并逐步细节化
2021/7/4
16
3.2.2 面向数据流自顶向下求精
1. 一对一联系(1∶1) 2. 一对多联系(1∶N) 3. 多对多联系(M∶N)
• 联系也可能有属性。
2021/7/4
29
3.4.4 实体—联系图的符号
• 使用实体—关系图来建立数据模型，满足第一条分析
准则。
必须理解和表示问题的信息域
– 把实体—关系图简称为ER图，用ER图描绘的数据模型也可 以称为ER模型。
• 模型由一组图形符号和组织这些符号的规则组成。 • 结构化分析就是一种建立模型的活动，通常建立数据模型、功
能模型和行为模型
2021/7/4
3
第3章 需求分析
4. 写出准确的软件需求规格说明。 5. 对需求分析的结果(分析模型和
规格说明) 严格审查。
2021/7/4
4
2021/7/4
第3章 需求分析
描
述
数据 字典
处 理 规
数据 格 流图
说
明
状态转换图
控制规格说明
2021/7/4
24
3.3.2 软件需求规格说明
• 软件需求规格说明——分析阶段的最终成果。 • 软件需求规格说明的框架。
– 见《软件需求规格说明书框架.doc》 • 自然语言：容易书写、容易理解 • 形式化方法：无歧义、明确
2021/7/4
2021/7/4
15
3.2.2 面向数据流自顶向下求精
• 数据决定了需要的处理和算法，是需求分析的出 发点。
• 结构化分析方法——面向数据流的自顶向下的逐 步求精进行需求分析的方法。
– 高层数据流图 – 从输出端回溯 – 并逐步细节化
2021/7/4
16
3.2.2 面向数据流自顶向下求精
1. 一对一联系(1∶1) 2. 一对多联系(1∶N) 3. 多对多联系(M∶N)
• 联系也可能有属性。
2021/7/4
29
3.4.4 实体—联系图的符号
• 使用实体—关系图来建立数据模型，满足第一条分析
准则。
必须理解和表示问题的信息域
– 把实体—关系图简称为ER图，用ER图描绘的数据模型也可 以称为ER模型。
• 模型由一组图形符号和组织这些符号的规则组成。 • 结构化分析就是一种建立模型的活动，通常建立数据模型、功
能模型和行为模型
2021/7/4
3
第3章 需求分析
4. 写出准确的软件需求规格说明。 5. 对需求分析的结果(分析模型和
规格说明) 严格审查。
2021/7/4
4
2021/7/4
第3章 需求分析
描
述
数据 字典
处 理 规
数据 格 流图
说
明
状态转换图
控制规格说明
2021/7/4
24
3.3.2 软件需求规格说明
• 软件需求规格说明——分析阶段的最终成果。 • 软件需求规格说明的框架。
– 见《软件需求规格说明书框架.doc》 • 自然语言：容易书写、容易理解 • 形式化方法：无歧义、明确
2021/7/4
软件工程需求工程教学课件
4 需求工程
4.1 需求捕获 4.2 需求分析 4.3 需求定义 4.4 需求管理 4.5 需求验证
需求的重要性
需求没有做好，对后续产品来说是巨大的灾害 1.浪费时间和资源来满足用户并不需要的需求〔过度实现一些功能〕； 2、开发出来的产品技术上先进，但不满足用户需求； 3、总是需要比较长的时间来达成对产品设计的共识； 4、在产品设计，开发和测试工作中对于用户需求的解释不一致； 5、员工会厌倦因需求不断被重新解释而导致的返工； 6、未说明的或不正确的需求会导致员工与用户间的不满； 7、不稳定的产品，用户的不满意对我们未来的市场造成损失； 8、浪费时间，增加本钱，使得在一些投标的工程中不能低价；
些门因为过高或者过低不方便翻开的问题了。 3.为方便老人开门，门口采用大按钮，按一下门
就开。 4.冰箱在不影响老人取放食物的情况下，能自动
关门。 5.冰箱内部有各种常用标签，如水果、肉类、蔬
4.1 需求捕获
看看下面列举的工程中的一些实际情况： 1.我们并不可能访问所有的用户，了解到每个用户的想 法。 2.我们能访问到的用户所提到的需求，并不一定是全部 的需求。 3.局部用户提到的需求，可能是不合理的。 4.不同用户之前提出的需求，可能是矛盾的。 5.很多用户只有朦胧的想法，需要我们提出具体方案让 他去确认。 如果我们不主动出击、不勤加思考，获取到的需求很可 能是不彻底、不完整的。系统的专业程度越高，越需要 我们主动去挖掘需求。
计的根底。
软件需求的层次
1) 业务需求 反映了组织或客户对系统、产品高 层次的目标要求，它们一般在工程视图和范围 文档中给予说明。
2) 用户需求 描述用户使用软件需要完成哪些任 务，它们可通过使用实例图或脚本说明加以说 明。
3) 功能―非功能需求 定义了开发者必须实现的 软件功能，而非功能需求如表所示:
4.1 需求捕获 4.2 需求分析 4.3 需求定义 4.4 需求管理 4.5 需求验证
需求的重要性
需求没有做好，对后续产品来说是巨大的灾害 1.浪费时间和资源来满足用户并不需要的需求〔过度实现一些功能〕； 2、开发出来的产品技术上先进，但不满足用户需求； 3、总是需要比较长的时间来达成对产品设计的共识； 4、在产品设计，开发和测试工作中对于用户需求的解释不一致； 5、员工会厌倦因需求不断被重新解释而导致的返工； 6、未说明的或不正确的需求会导致员工与用户间的不满； 7、不稳定的产品，用户的不满意对我们未来的市场造成损失； 8、浪费时间，增加本钱，使得在一些投标的工程中不能低价；
些门因为过高或者过低不方便翻开的问题了。 3.为方便老人开门，门口采用大按钮，按一下门
就开。 4.冰箱在不影响老人取放食物的情况下，能自动
关门。 5.冰箱内部有各种常用标签，如水果、肉类、蔬
4.1 需求捕获
看看下面列举的工程中的一些实际情况： 1.我们并不可能访问所有的用户，了解到每个用户的想 法。 2.我们能访问到的用户所提到的需求，并不一定是全部 的需求。 3.局部用户提到的需求，可能是不合理的。 4.不同用户之前提出的需求，可能是矛盾的。 5.很多用户只有朦胧的想法，需要我们提出具体方案让 他去确认。 如果我们不主动出击、不勤加思考，获取到的需求很可 能是不彻底、不完整的。系统的专业程度越高，越需要 我们主动去挖掘需求。
计的根底。
软件需求的层次
1) 业务需求 反映了组织或客户对系统、产品高 层次的目标要求，它们一般在工程视图和范围 文档中给予说明。
2) 用户需求 描述用户使用软件需要完成哪些任 务，它们可通过使用实例图或脚本说明加以说 明。
3) 功能―非功能需求 定义了开发者必须实现的 软件功能，而非功能需求如表所示:
《软件需求分析》第3章 需求获取课件
分的时间与开发人员进行交流和讨论 ； 2. 有时用户希望通过简单的方法和说明，或者
通过简单回答开发人员的询问后，软件开发 人员就能清楚地理解他们的需求，而不需要 花费太多的时间进行讨论；
2023/6/25
15
3.4实地收集需求信息
3. 用户和开发人员都只考虑自己的利益；如： 有些用户由于缺乏使用计算机的经验，导致 产生畏难情绪；有些用户认为开发软件系统 自己的关系不大，对待需求信息的收集工作 采取消极的态度。
4
3.2确定项目的目标和范围
此阶段的基本任务是根据项目目标把项目 相关人员定位到一个共同的和明确的方向上， 并决定软件系统的范围。
项目的范围与项目的目标特别是软件系统 的目标需求是密切相关的。
2023/6/25
5
3.2确定项目的目标和范围
在收集目标需求时，目标需求会来源于各 个不同的人，这些人对要开发的软件系统及该 系统最终能为用户或客户提供哪些价值有比较 清楚的了解。
理。
10)尊重需求工程中开发人员采用的流程（过程）。
2023/6/25
10
3.3确定调查对象
软件需求可来自与各个方面，而且用户类 也不一定都是指人。有时也可以把其它应用系 统或计算机硬件设备和接口等视为附加的用户 类成员，这样就可确定软件系统与哪些外部应 用系统或计算机硬件相关的需求。这就是说需 求信息来源除了来自用户类外，还可来自于其 它方面。
7
3.3确定调查对象
软件系统面临的用户是很多的，而这些用 户由于所在的部门、职责和掌握的知识不同而 存在差异，为了避免忽视和遗漏某些用户的情 况，可以根据用户的某些方面将用户分类。
2023/6/25
8
3.3确定调查对象
在将用户分类后，在分类的基础上进一步 寻找每类用户的代表或联络人，这些人代表了 一个特定的用户类，并可充当该用户类与开发 人员之间的“窗口”。
通过简单回答开发人员的询问后，软件开发 人员就能清楚地理解他们的需求，而不需要 花费太多的时间进行讨论；
2023/6/25
15
3.4实地收集需求信息
3. 用户和开发人员都只考虑自己的利益；如： 有些用户由于缺乏使用计算机的经验，导致 产生畏难情绪；有些用户认为开发软件系统 自己的关系不大，对待需求信息的收集工作 采取消极的态度。
4
3.2确定项目的目标和范围
此阶段的基本任务是根据项目目标把项目 相关人员定位到一个共同的和明确的方向上， 并决定软件系统的范围。
项目的范围与项目的目标特别是软件系统 的目标需求是密切相关的。
2023/6/25
5
3.2确定项目的目标和范围
在收集目标需求时，目标需求会来源于各 个不同的人，这些人对要开发的软件系统及该 系统最终能为用户或客户提供哪些价值有比较 清楚的了解。
理。
10)尊重需求工程中开发人员采用的流程（过程）。
2023/6/25
10
3.3确定调查对象
软件需求可来自与各个方面，而且用户类 也不一定都是指人。有时也可以把其它应用系 统或计算机硬件设备和接口等视为附加的用户 类成员，这样就可确定软件系统与哪些外部应 用系统或计算机硬件相关的需求。这就是说需 求信息来源除了来自用户类外，还可来自于其 它方面。
7
3.3确定调查对象
软件系统面临的用户是很多的，而这些用 户由于所在的部门、职责和掌握的知识不同而 存在差异，为了避免忽视和遗漏某些用户的情 况，可以根据用户的某些方面将用户分类。
2023/6/25
8
3.3确定调查对象
在将用户分类后，在分类的基础上进一步 寻找每类用户的代表或联络人，这些人代表了 一个特定的用户类，并可充当该用户类与开发 人员之间的“窗口”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
从上述历史事实可以看出健壮的需求规格说明书对
软件开发是多么的重要,在一个复杂软件系统的开发
中，编写需求规格说明书是很必要的。首先，清晰、
明确的说明书可以将软件系统的需求信息和解决方
案更好的传递给开发者。说明书能够弥补人们记忆
能力的不足，而且不会像人类的记忆一样慢慢褪去。
更重要的是需求规格说明书可以成为项目开发的一
1、可靠性：指在给定的时间内以及规定的环境条件下，软 件系统能完成所要求功能的概率。其定量指标通常用平均无 故障时间和平均修复时间来衡量。
2、可用性：指用户学习和使用软件系统功能的简易程度，也 包括对系统的输出结果易于理解的程度。
3、可维护性：指在软件系统中发现并纠正一个故障或进行一 次更改的简易程度。可维护性取决于理解、更改和测试软件 的简易程度。
2、性能需求（Performance Requirement）：系统整体 或系统组成部分应该拥有的性能特征，例如CPU使用率、内 存使用率等。
3、质量属性（Quality Attribute）：系统完成工作的质量， 即系统需要在一个“好的程度”上实现功能需求。
4、对外接口（External Interface）：系统和环境中其他系 统之间需要建立的接口，包括硬件接口、软件接口、数据库 接口等。
第5章 需求获取
1
第五章 需求获取
5.1软件需求的定义 5.2软件需求的类型 5.3需求获取 5.4需求规格说明书 5.5需求验证 5.6需求变更
2
教学目的与要求：
⒈掌握需求的基本概念及类型; ⒉掌握如何进行获取需求; ⒊掌握需求规格说明书； 4.掌握需求验证； ⒋理解软件需求变更管理。
教学重点：
下被加以验证的，例如评审方法。但是， 当有些需求涉及复杂的动态行为时，可能 就需要使用原型或者模拟方法来加以验证。
21
5.5.2需求验证的方法
3、利用跟踪关系 功能需求通常有业务需求、用户需求和系统需求
三个不同的抽象层次，并存在逐步细化的关系： 业务需求→用户需求→系统需求。 基于这种细化关系，可以建立需求之间的跟踪关 系：业务需求（系统特性）→用户需求（业务、 任务）→系统需求（分析模型）。也就是说，上 述的链条中，每一个前项都可以跟踪到后项，后 项是对前项的展开和细化。
4、可移植性：指把一个软件系统从一种运行环境移植到另 一个运行环境所花费的工作量的量度。
5、效率：执行功能时的响应时间、处理时间和吞吐速度。 9 比如要求系统需要满足所有用户查询都必须在7秒内完成。
5.3需求获取
构建一个软件系统最困难的部分是确定构 建什么。其他部分工作不会像这部分工作 一样，在出错之后会如此严重地影响随后 实现的系统，并且在以后修补竟会如此的 困难。
24
5.6.1需求变化
需求开发是一个获取、明确并定义需求的 过程，但需求并不是在需求开发结束之后 就会恒定不变的。在产品开发和实现中或 者产品递交之后，用户也常常提出需求的 变化，这会给系统的开发工作带来额外的 烦恼，增加工作量。尤其是在软件应用日 益复杂的情况下，需求变更带来的影响越 发明显。
13
5.3.1需求获取的方法
4、原型法
原型（prototype）是在软件开发中被广泛使用的一
种工具，在软件开发过程中的各个阶段，包括需求
开发，都会使用不同类型的原型来达到不同的目的。
通常，人们更愿意从原型使用的角度来理解原型概
念。如果在最终的物件（Final Artifact）产生之前，
一个中间物件（Mediate Artifact）被用来在一定广
4
5.1需求的定义
不同背景的人对需求会有不同的看法，像瞎子摸象一样大 家会站在自己的立场去理解需求，因此需求在软件工程中 没有统一的定义，IEEE对需求的定义为：
1、用户为解决某个问题或达到某个目标而需具备的 条件或能力。
2、系统或系统组件为符合合同、标准、规范或其他正式 文档而必须满足的条件或必须具备的能力。
IEEE的定义中同时包括了用户的观点（第一条）和开发 者的观点（第二条）。
关于需求还有其他不同的定义，产生这些不同的原因有两 点：一是需求工程的发展过程还不太长，人们的认识还不 够；二是真正的需求实际上是人们的想法，很难给予准确 的定义。
5
5.2需求的类型
1、功能需求（Functional Requirement）：和系统主要工 作相关的需求，即在不考虑物理约束的情况下，用户希望系 统所能够执行的活动，这些活动可以帮助用户完成任务。
18
5.5需求验证
5.5.1引言 Standish group1999年的调查报告表明坚实的
需求基础是影响项目成败的重要因素。这份调查 报告重申了需求在软件开发中的重要性，另一方 面从侧面也可以看到需求验证在实践中的重要性。 需求验证是要检验需求能否反映客户的意愿，是 要发现需求中的问题。需求验证很重要，如果在 后续的开发或当系统投入使用时才发现需求规格 说明书中的错误，就会导致更大的代价返工。由 需求问题而对系统做变更的成本比修改设计或代 码错误的成本要大得多。
度和深度范围内表现这个最终物件，那么这个中间
物件就被认为是最终物件在该广度和深度上的原型。
也就是说原型通常仅仅是真实系统的一个部分或者
一个模型，重要的不在于使用什么材料和工具来创
建它们，而是人们怎么利用它们来探索和论证未来
物件的某个方面。
14
5.3.2需求获取常见的困难
在需求获取中有很多困难是客观存在的， 了解这些困难对更好地了解需求获取活动 有中重要的意义。下面介绍一些常见的困 难。
1、用户和开发人员立场不同 2、用户固执地坚持某些功能 3、用户消极参与
15
5.4 需求规格说明书
Swanick空中交通控制系统原计划在1998年完工， 但直到2001年尚未交付使用，额外开支高达1亿英 镑以上。经官方调查，发现其中的一个主要原因在 于“缺乏健壮的需求规格说明导致无法继续进行系 统实现”。
⒈软件需求的基本概念及类型;
⒉如何进行获取需求;
⒊什么是需求规格说明书以及什么是优秀的需求
规格说明书。
4.需求验证和需求变更管理。
3
引言
团队和管理对项目开发很重要，但项目开发的成败取决于是否正 确的进行需求获取。
注：从前有一个人，从魏国到楚国去。他带上很多的盘缠，雇了上好的车， 驾上骏马，请了驾车技术精湛的车夫，就上路了。楚国在魏国的南面，可这 个人不问青红皂白让驾车人赶着马车一直向北走去。路上有人问他的车是要 往哪儿去，他大声回答说：“去楚国！”路人告诉他说：“到楚国去应往南 方走，你这是在往北走，方向不对。”那人满不在乎地说：“没关系，我的 马快着呢！”路人替他着急，拉住他的马，阻止他说：“方向错了，你的马 再快，也到不了楚国呀！”那人依然毫不醒悟地说：“不打紧，我带的路费 多着呢！”路人极力劝阻他说：“虽说你路费多，可是你走的不是那个方向， 你路费多也只能白花呀！”那个一心只想着要到楚国去的人有些不耐烦地说： “这有什么难的，我的车夫赶车的本领高着呢！”路人无奈，只好松开了拉 住车把子的手，眼睁睁看着那个盲目上路的魏人走了。寓言告诉我们，无论 做什么事，都要首先看准方向，才能充分发挥自己的有利条件；如果方向错 了，条件再有利也达不到目的。同样在项目开发中有再好的团队，再好的技 术，如果没有正确的进行需求获取，那么项目不可能成功！
22
5.5.2需求验证的方法
需求验证的方法还有开发测试用例、用户 手册编制和自动化分析等方法
23Biblioteka 5.6 需求变更[Standish1995]认为对需求变化有效处理 是项目成功的关键因素。[Robert2002]将 “需求变化”和“糟糕的项目计划”并列 为导致项目失败的两个最主要的因素。在 需求变化的处理上，变更控制起到至关重 要的作用。
8
5.2需求的类型
1.2.2非功能性需求
除了功能需求外，软件需求还包含非功能需求，包括性能需 求、质量属性、对外接口和约束。非功能需求是衡量软件能 否良好运行的定性指标。因此，非功能需求也是非常重要的。 在非功能需求中，质量属性对系统的影响极大，因此在某些 情况下，非功能需求又被用来特指质量属性。
—Fred Brooks
10
5.3.1需求获取的方法
1、面谈 用户面谈是一种十分直接而常用的需求获
取方法，它也经常与其他需求获取技术一 起使用，以便更好地澄清和理解一些细节 问题。需要说明的是，面谈过程应该进行 认真的计划和准备，我们将以小型图书馆 系统的一次面谈举例说明其主要步骤。
11
5.3.1需求获取的方法
19
5.5.2需求验证的方法
1、需求评审 评审又被称为同级评审，是指由作者之外
的其他人来检查产品问题地方法。在系统 中，评审是主要的静态分析手段，所以评 审也是需求评审的一种主要方法。原则上， 每一个需求都应该经过评审。
20
5.5.2需求验证的方法
2、原型与模拟 在大多数情况下，需求都是在静态的方式
12
5.3.1需求获取的方法
3、调查问卷 调查问卷是一种经常和面谈配合使用的需
求获取方法。它在内容的安排上类似于结 构化面谈方法，完全按照事先确定的问题 来得到反馈信息，较多地使用封闭式问题。 但是在交流的媒介上，调查问卷方法和面 谈方法有着明显的差异，面谈方法以口头 语言为主要的交流媒介，而调查问卷以文 档为主要的交流媒介。
个重要依，它可以作为软件估算和项目进度安排的
基础。
16
5.4.1需求说明规格模板
17
5.4.2优秀需求规格说明书的特性
优秀需求规格说明书应该具备下面的特性： 1、完备性。需求规格说明书是完备的，当且仅当描述了用户所有
有意义的需求，包括功能、性能、约束、质量属性和对外接口。需求 的完备性要求不能遗漏任何需求或者必要的信息，但需求遗漏问题很 难被发现，为避免需求的遗漏，需求工程师要做好需求的分析，建立 并控制正确的项目范围。 2、一致性。一致性是指本层次与其他软件需求或高层需求不相矛 盾。 3、可修改性。需求规格说明书必须能够被修改，并可以为提供每 项需求维护修改的历史记录。人们可以对其中任一需求进行容易、完 整、一致的修改。 4、可跟踪性。需求的可跟踪性是指可以跟踪一个需求使用期限的 全过程。它为我们提供了从需求到产品实现整个过程范围的明确查阅 的能力。它的目的是确保所有的工作成果符合用户需求。 人们可以很容易地写出一个完全优秀的需求，但是没有人能够写出一 个完全优秀的需求规格说明文档。所以上述的特性并不是对需求规格 说明文档的严格验收标准，它们只是用于指导人们进行文档的编写和 审阅，以产生更好的需求文档，开发更好的软件产品。