第三章软件需求分析基础
合集下载
软件工程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
需求分析的任务和步骤
第03章 软件需求分析
第三章
软件需求分析
一、需求分析的任务
二、分析过程
三、概念模型和规范化
四、软件需求分析工具
五、验证软件需求
六、小结
一、需求分析的任务
仍然回答“What”，而不是“How”， 但更细致、精确（合同的拟定）
可行性分析 DFD DD 功能具体化 需求规格说明 加细 DFD DD 算法 描述 IPO
Final stage of Definition phase
2、范式
通常用范式来消除数据冗余的程度。第一范式（1NF）数据冗余程 度最大，第五范式（5NF）数据冗余程度最小。 范式太高，存在的缺点为（1） 存储过程复杂；（2）稳定性较差； （3）性能下降。较为理想是选用第三范式。 ※ 第一范式：每个属性值都必须是原子值（不可再分的数据项）。例 如：下表（表3-1）是满足第一范式的关系数据库（W）。 日期 95.05 95.05 95.05 95.05 95.06 95.06 95.06 95.06 工号 101 102 103 104 101 102 103 104 姓名 丁一 王二 张三 李四 丁一 王二 张三 李四 工种 车工 车工 钳工 电工 车工 车工 钳工 电工 定额 80 80 75 70 80 80 75 70 超额 22% 17% 14% 20% 19% 25% 16% 26% 车间 金工 金工 动力 动力 金工 金工 动力 动力 车间主任 李明 李明 赵杰 赵杰 李明 李明 赵杰 赵杰
101 102 103 104
丁一 王二 张三 李四
车工 车工 钳工 电工
80 80 75 70
金工 金工 动力 动力
李明 李明 赵杰 赵杰
表3-3
W2关系数据库
表3-2 W1关系数据库
软件需求分析
一、需求分析的任务
二、分析过程
三、概念模型和规范化
四、软件需求分析工具
五、验证软件需求
六、小结
一、需求分析的任务
仍然回答“What”，而不是“How”， 但更细致、精确（合同的拟定）
可行性分析 DFD DD 功能具体化 需求规格说明 加细 DFD DD 算法 描述 IPO
Final stage of Definition phase
2、范式
通常用范式来消除数据冗余的程度。第一范式（1NF）数据冗余程 度最大，第五范式（5NF）数据冗余程度最小。 范式太高，存在的缺点为（1） 存储过程复杂；（2）稳定性较差； （3）性能下降。较为理想是选用第三范式。 ※ 第一范式：每个属性值都必须是原子值（不可再分的数据项）。例 如：下表（表3-1）是满足第一范式的关系数据库（W）。 日期 95.05 95.05 95.05 95.05 95.06 95.06 95.06 95.06 工号 101 102 103 104 101 102 103 104 姓名 丁一 王二 张三 李四 丁一 王二 张三 李四 工种 车工 车工 钳工 电工 车工 车工 钳工 电工 定额 80 80 75 70 80 80 75 70 超额 22% 17% 14% 20% 19% 25% 16% 26% 车间 金工 金工 动力 动力 金工 金工 动力 动力 车间主任 李明 李明 赵杰 赵杰 李明 李明 赵杰 赵杰
101 102 103 104
丁一 王二 张三 李四
车工 车工 钳工 电工
80 80 75 70
金工 金工 动力 动力
李明 李明 赵杰 赵杰
表3-3
W2关系数据库
表3-2 W1关系数据库
《软件工程》第3章 软件需求分析
【本章重点】 本章重点】
需求分析的方法 ； 需求分析的任务和原则 ；
【教学目标】 教学目标】
掌握需求分析的基本概念； 掌握需求分析的基本概念； 掌握如何使用需求获取技术来进行数据采集； 掌握如何使用需求获取技术来进行数据采集； 掌握结构化分析的思想与过程； 掌握结构化分析的思想与过程； 掌握数据流建模技术。 掌握数据流建模技术。
3.2 面向数据流的分析方法
3.2.2 数据流图
1．数据流图中的主要图形元素
3.2 面向数据流的分析方法
2．分层的数据流图
在多层数据流图中，可以把顶层数据流图、 在多层数据流图中，可以把顶层数据流图、底层数 据流图和中间层数据流图区分开来。顶层数据流图仅 据流图和中间层数据流图区分开来。 包含一个加工，它代表被开发系统。 包含一个加工，它代表被开发系统。它的输入流是该 系统的输入数据，输出流是系统的输出数据。顶层数 系统的输入数据，输出流是系统的输出数据。 据流图的作用在于表明被开发系统的范围， 据流图的作用在于表明被开发系统的范围，以及它和 周围环境的数据交换关系。 周围环境的数据交换关系。底层数据流图是指其加工 不须再做分解的数据流图，其加工称为“原子加工” 不须再做分解的数据流图，其加工称为“原子加工”。 中间层数据流图则表示对其上层父图的细化。 中间层数据流图则表示对其上层父图的细化。它的每 一个加工可以继续细化，形成子图。 一个加工可以继续细化，形成子图。中间层次的多少 视系统的复杂程度而定。 视系统的复杂程度而定。
3.2 面向数据流的分析方法
4．数据流图的优缺点
总体概念强，每一层都明确强调“干什么” 总体概念强，每一层都明确强调“干什么”，“需要 什么” 给出什么” 什么”，“给出什么”; 可以反映出数据的流向和处理过程; 可以反映出数据的流向和处理过程; 由于自顶向下分析， 由于自顶向下分析，容易及早发现系统各部分的逻辑 错误，也容易修正; 错误，也容易修正; 容易与计算机处理相对应; 容易与计算机处理相对应; 不直观，一般都要在作业流程分析的基础上加以概括、 不直观，一般都要在作业流程分析的基础上加以概括、 抽象、 抽象、修正来得到
软件工程 第3章需求分析
名字：定货报表 别名：定货信息 描述：每天一次送给采购员的 逐一确定 需要定货的零件表 元素的来 定义：定货报表 = 零件编号 +零件名称+ 源 定货数量+目前价格+主要供应 商+次要供应商
位置：定货报告 定货信息 库存清单
面向数据流方法的分析的应用
6 D1 库存清单 事务 1 包含零件编 号、名称、 目前价格
深入调查
外部输入或系 统生成
3.2.2 面向数据流的自顶向下求精
• 回溯时常遇到的问题：为了得到某个数据元素需要 用到数据流图中还没有的数据元素，或者得出这个 数据元素要用的算法尚不完全清楚。 • 因此，需要向用户等有关人员请教，他们的回答使 分析员对目标系统的认识更深入具体，系统中更多 的数据元素被划分出来，更多的算法搞清楚了。 • 把分析过程中得到的有关数据元素的信息记录在数 据字典中，把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位置上。
• 主要目标：把数据流和数据存储定义到元 素级别（不可分解为止）
数据的来源、去 向、数据结构定 义等
可行性 分析忽 略了细 节
3.2.2 面向数据流的自顶向下求精
自顶向下，逐 层细化的方法
• 结构化分析方法是一种什么方法呢？ • 从数据流图的输出端着手分析，这是因为系 统的基本功能是产生这些输出的关键原因。 • 输出数据决定了系统必须具有的最基本的组 成元素（包括功能和数据结构组成）。
3.4.1 数据对象
• 它的范畴很大，可以是外部实体(例如，产生 或使用信息的任何事物)、事物(例如，报表)、 行为(例如，打电话)、事件(例如，响警报)、 角色(例如，教师、学生)、单位(例如，会计 科)、地点(例如，仓库)或结构(例如，文件) 等。 • 总之，可以由一组属性来定义的实体都可以 被认为是数据对象。
位置：定货报告 定货信息 库存清单
面向数据流方法的分析的应用
6 D1 库存清单 事务 1 包含零件编 号、名称、 目前价格
深入调查
外部输入或系 统生成
3.2.2 面向数据流的自顶向下求精
• 回溯时常遇到的问题：为了得到某个数据元素需要 用到数据流图中还没有的数据元素，或者得出这个 数据元素要用的算法尚不完全清楚。 • 因此，需要向用户等有关人员请教，他们的回答使 分析员对目标系统的认识更深入具体，系统中更多 的数据元素被划分出来，更多的算法搞清楚了。 • 把分析过程中得到的有关数据元素的信息记录在数 据字典中，把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位置上。
• 主要目标：把数据流和数据存储定义到元 素级别（不可分解为止）
数据的来源、去 向、数据结构定 义等
可行性 分析忽 略了细 节
3.2.2 面向数据流的自顶向下求精
自顶向下，逐 层细化的方法
• 结构化分析方法是一种什么方法呢？ • 从数据流图的输出端着手分析，这是因为系 统的基本功能是产生这些输出的关键原因。 • 输出数据决定了系统必须具有的最基本的组 成元素（包括功能和数据结构组成）。
3.4.1 数据对象
• 它的范畴很大，可以是外部实体(例如，产生 或使用信息的任何事物)、事物(例如，报表)、 行为(例如，打电话)、事件(例如，响警报)、 角色(例如，教师、学生)、单位(例如，会计 科)、地点(例如，仓库)或结构(例如，文件) 等。 • 总之，可以由一组属性来定义的实体都可以 被认为是数据对象。
软件工程第三章需求应用全面分析
结构化英语、判定树、判定表用于描述数据流 图中的处理逻辑说明。
• SA方法的实质*：是采用一组分层数据流图及数据
字典作为系统的模型，从总体来看，是一种依赖数
据流图的自顶向下的建模方法。
2020/11/25
5
数据流图：分层扩展的功能模
型
数据流图（DFD）是SA方法中用于建立系统逻辑模型 的一种工具，它以图形的方式描绘数据在系统中处理的流 动过程。由于它只反映系统需要完成的逻辑功能，所以它 是一种功能模型。*
配件库存
顾客
订货单 发货单
1
处理 业务Biblioteka 订货单 发货单供应 商
2020/11/25
15
数据流图： DFD绘制步骤（续）
* （2）再绘制二层DFD：是顶图的分解，表明子系统划分及其 边界。 • 系统划分几个子系统，一个子系统在二层图中只有一个处理逻辑（需
求来源是业务子系统或用例图中的用例）； • 每一子系统析取所有的外部项、输入输出数据流和主要数据存储； • 各子系统之间的依赖关系（数据流直接依赖，数据存储缓存依赖）。
软件工程 Software Engineering
第三章 需求应用全面分析
2020/11/25
1
本章主要内容
• 3.1 软件需求概念
-软件需求的问题、定义、层次、来源、依据、目标
• 3.2 需求工程过程
- 需求开发：需求获取、需求分析、规格说明、需求验证 - 需求管理：覆盖需求开发全过程
• 3.3 需求获取技术
数据存储可以是一个文件，也可以是文件的一部分或 数据库记录的一部分。数据可以存储在磁盘、磁带、存储 器等任何介质上。指向数据存储的箭头可以是单向的，也 可以是双向的。
软件系统的需求分析_[全文]
![软件系统的需求分析_[全文]](https://img.taocdn.com/s3/m/af002ef8afaad1f34693daef5ef7ba0d4a736db8.png)
第三章软件系统的需求分析</B> 第三章软件系统的需求分析</B> 第三章软件系统的需求分析</B> 软件项目立项后，就进入了软件生存周期中的开发时期，由开发单位负责开发时期各阶段的软件全部实际工作。
而软件系统的需求分析</B>阶段仅仅是软件开发时期的开始.立项是软件生命周期中的“问题定义”阶段，即“问题是什么？”而可行性分析</B>是立项的支持条件，即“是否由可行的解决办法？”，需求分析</B>是在软件计划的基础上进行的，确定“系统必须做什么？”，需求分析</B>阶段的结果产生的系统需求规格说明书，是以后各阶段开发工作的基础，完善的需求分析</B>对软件开发工作的成败和产品的质量极为重要。
第一节需求分析</B>的任务需求分析</B>的主要任务不是确定系统如何完成它的具体工作，而是确定系统必须完成哪些工作，在用户的参与下提出目标系统的完整、准确、清晰、具体的实际要求，软件应完成的具体功能和性能，确定软件设计受到的限制及软件同其它系统的接口细节，描述软件用到的数据形式，逐步细化到详细定义：描述软件要处理的数据域、要完成的功能范围、要达到的性能要求，并为软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示，在软件完成后，并为软件验收和质量评价提供依据。
第一节需求分析</B>的任务引题（小事例）对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。
怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。
软件开发的意义也就在于此。
而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
第一节需求分析</B>的任务引题（小事例）经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部--门店的连锁经营模式。
L-第三章-软件工程课件需求分析
6
教学要求
教学目的：了解需求分析的任务和步骤、评 审标准和过程；掌握基本技术，理解需求规 格说明书的作用与组成。 教学重点：基本技术、需求规格说明书的作 用与组成。 教学难点：基本技术。
7
需求分折简介
软件需求指用户对所开发的软件在功能、 性能、环境、可靠性等各方面的要求。
需求分析主要回答待开发的系统必须 “做什么”，并用 《 需求规格说明书 》 的 形式准确、详细、规范地表达出来。
8
注意
①需求分析阶段，系统分析员的主要关注点 是“做什么（ what ) ” ，不是“怎样做 （ how）”； ②需求分析阶段，系统分析员应该给出软件 求规格书。
9
§3.1需求分析的任务
四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
34
一、基本概念(2)
联系：客观事物之间的联系。联系分为三种： 一对一（ 1 : 1 ) ．班级和班长 一对多联系（ 1 : N ) ．班级和学生，系与教师，学生与宿舍 多对多联系（ M : N ) 课程与学生，教师和课程，学生和学会 二、 E 一 R 图的结构 三种基本元素：
35
例:教学E-R图
46
注意的原则 ( 1 )
数据流图上所有图形符号只限于前述四种基本图 形元素； 数据流图的主图必须包括前述四种基本元素，缺 一不可； 数据流图的主图上的数据流必须封闭在外部实体 之间； 每个数据处理至少有一个输入数据流和一个输出 数据流； 在数据流图中，需按层给数据处理框编号。编号 表明该处理所处层次及上下层的亲子关系；
36
例
仓库，职工，零件和供应商的ER图
37
三、如何建立实体一联系图？
教学要求
教学目的：了解需求分析的任务和步骤、评 审标准和过程；掌握基本技术，理解需求规 格说明书的作用与组成。 教学重点：基本技术、需求规格说明书的作 用与组成。 教学难点：基本技术。
7
需求分折简介
软件需求指用户对所开发的软件在功能、 性能、环境、可靠性等各方面的要求。
需求分析主要回答待开发的系统必须 “做什么”，并用 《 需求规格说明书 》 的 形式准确、详细、规范地表达出来。
8
注意
①需求分析阶段，系统分析员的主要关注点 是“做什么（ what ) ” ，不是“怎样做 （ how）”； ②需求分析阶段，系统分析员应该给出软件 求规格书。
9
§3.1需求分析的任务
四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
34
一、基本概念(2)
联系：客观事物之间的联系。联系分为三种： 一对一（ 1 : 1 ) ．班级和班长 一对多联系（ 1 : N ) ．班级和学生，系与教师，学生与宿舍 多对多联系（ M : N ) 课程与学生，教师和课程，学生和学会 二、 E 一 R 图的结构 三种基本元素：
35
例:教学E-R图
46
注意的原则 ( 1 )
数据流图上所有图形符号只限于前述四种基本图 形元素； 数据流图的主图必须包括前述四种基本元素，缺 一不可； 数据流图的主图上的数据流必须封闭在外部实体 之间； 每个数据处理至少有一个输入数据流和一个输出 数据流； 在数据流图中，需按层给数据处理框编号。编号 表明该处理所处层次及上下层的亲子关系；
36
例
仓库，职工，零件和供应商的ER图
37
三、如何建立实体一联系图？
软件需求分析
第三章软件需求分析软件需求分析是软件定义阶段的最后一个步骤，它的基本任务是要准确地答复“系统必须做什么?”这个问题，即对目标系统提出完整、准确、清晰、具体的要求。
需求分析的结果是系统开发的基础，直接影响软件产品及工程的质量。
软件需求分析是一个不断进行揭示和判断的过程。
在此过程中我们将对在软件可行性研究阶段确定的软件范围加以提炼使之具体化，并分析各软件部件可能采用的解决方法。
在软件需求分析阶段，软件的开发者和软件需求者起着同样的重要作用。
软件需求者设法把有关软件功能和性能的一些模糊的概念加以重述，使之成为具体的细节，而软件开发者则起着询问、参谋和问题解决者的作用。
在需求分析中需要大量地交换意见，这其间充满着传错信息和发生误解的可能性，而我们的任务就是面对各种矛盾，协调各种人与人、人与物，物与物之间的关系。
3.1 需求分析的任务系统的综合要求包括下面几个方面。
(1) 确定系统的功能要求。
提出系统必须完成的全部所有功能。
(2) 确定系统的性能要求。
包括系统的响应时间、系统需要的存储容量、后援存储器容量、系统重新启动、系统的安全性和可靠性等方面的性能要求。
(3) 确定系统的运行要求。
主要是指系统运行时所处的环境要求，包括支持系统运行的软件环境，工具软件和系统软件；支持系统运行的硬件环境，外存储器、通信接口、输入和输出等外部设备。
(4) 系统的扩充要求。
不属于当前系统的开发范围，是将来有可能提出的要求，目的是使在现有的设计中为将来的扩充做准备。
任何一个软件系统其本质上都是一个信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的概貌，同时也对软件设计有着深远的影响。
因此，分析系统的数据要求，是软件需求分析的任务之一。
系统的数据来源和去处一般含如下几个方面。
(1) 从系统以外来，再到系统以外去；(2) 从系统以外来，再到系统内部去；(3) 从系统内部来，再到系统内部去；(4) 从系统内部来，再到系统外部去。
《软件需求分析》第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.软件需求的概念和分类
比较权威的需求的定义来自于IEEE软件工程标准词汇 表中的定义：
l 用户解决问题或达到目标所需要的条件。 l 系统或系统部件要满足合同、标准、规范或其他
正式规定的文档所要具有的条件。
l 反映上面两条的文档说明。
需求一方面反映了系统的外部行为，另一方面反映了 系统的内部特性，反映的方式是需求文档。
3.1.1 需求分析
需求分析是一种软件工程活动，使得系统分析 员能够刻划出软件的功能和性能、指明软件和 其他系统元素的接口、并建立软件必须满足的 约束。
需求分析是软件设计师进行软件分解的基础， 需求分析建造了软件处理的数据模型、功能模 型和行为模型。
需求规约为软件设计师和客户提供了软件建造 完后，进行质量评估的依据。
可行性研究阶段
这个阶段要回答的关键问题是“对于上一个阶 段所确定的问题有行得通的解决办法吗？”
系统分析员需要进行一次大大压缩和简化了的 系统分析和设计的过程。
只有当投资取得较大效益时，该工程项目才值 得继续进行下去。
系统分析员得出该工程项目不值得做的结论， 应该及时中止投资该工程项目，避免更大的浪 费。
比较通俗的需求定义如下：需求是指明系统必须实现 什么的规格说明，它描述了系统的行为、特性或属性， 是在开发过程中对系统的约束。
需求的类别
功能需求：指定系统必须提供的服务，通过需 求分析应该划分出系统必须完成的所有功能；
性能需求：指定系统必须满足的定时约束或容 量约束，通常包括速度（响应时间）、信息量 速率、主存容量、磁盘容量、安全性等方面的 需求；
可行性研究
问题识别 市场调查 分析准备 环境分析 物理分析 功能分析
信息分析 动态分析 确立系统方案，
作出各种估算 模型评审
问题的初步认识
了解系统应解决的问题，这些问题 是如何提出的
设想这些问题如何解决才能满足要 求
了解问题的结构
市场调查
了解市场对待开发软件的需求情况
限制条件
操作需求 可维护性和可移植性需求 安全性需求 文化与政策 法律需求
需求的质量
完整性 正确性 可行性 必要性 划分优先级 无二义性 可验证性 设计无关性
2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型 导出目标系统的逻辑模型，解决目标系统“做 什么”的问题。
调查市场上已有的类似软件系统的功能、 性能、价格情况
分析准备
确立分析计划 规定由谁参加分析作业，任务分配 对参加分析的人员进行必要的培训
环境分析
明确系统的目的和限制条件 使用单位的状况、经营方针和组织机构 使用单位的计算机利用情况 相关的硬件、软件及其它接口部分 用户的操作环境及操作要求 习惯、法律、制度上对软件的制约 开发能具备的技术条件和设备条件
所要做的工作是深入描述软件的功能和性能， 确定软件设计的限制和软件同其他系统元素的 接口细节，定义软件的其他有效性需求。
必须全面理解用户的各项要求，但只能接受合 理的要求。
要将软件的需求准确地表达出来，形成软件需 求说明书。
怎么做
模型化
当
具体化
目标系统
物理模型
物理分析
了解实际业务活动状况，特别对一些活 动要点进行分析
明确在这些要点之间什么东西在流动， 如何进行流动
对物理流量进行分析 对其模型化，得到实际业务系统（当前
系统）的物理模型
功能分析
决定系统应具备的功能 (工作域) 分析功能的结构：功能展开和功能分配 分析各功能之间的关系，整理它们之间
实例化 逻辑模型
理
导 出
解 需 求
表 达 需 求
问题定义阶段
在需求分析之前，需要描述和定义问题。问题 定义阶段必须回答的关键问题是“要解决的问 题是什么” 。
系统分析员扼要地写出对问题的理解，提出关 于问题性质、工程目标和规模的书面报告，最 后得出使用户和使用部门负责人都满意的文档。
问题定义阶段是软件生存周期中最简短的阶段， 一般只需要一天甚至更少的时间。
传递的信息 利用数据流图，描述信息在系统流动与
处理的情况
信息分析
调查系统的输入、输出、保存信息 明确信息的结构及各信息之间的关系 调查各信息的信息量 调查各种报表和文件的格式 建立粗略的数据词典，定义系统中使用
的数据
动态分析
系统内每一部分有几种状态 各种状态转换的条件 同步产生的条件与同步后状态的变化
可靠性和可用性需求：定量地指定系统的可靠 性与可用性；
出错处理需求：说明系统对环境错误应该怎样 响应；
接口需求：描述应用系统与其环境通信的格式， 常见的接口需求有用户接口需求、硬件接口需 求、软件接口需求和通信接口需求；
约束：描述了应用系统应遵守的限制条件，常 见的约束有：精度约束、工具和语言约束、设 计约束、应该使用的标准、应该使用的硬件平 台等；
第三章 软件需求分析基础
主要内容
需求分析的概念和原则 传统的软件需求分析基础
3.1 需求分析的概念和原则
需求分析的基本任务是准确地回答“系统必须做什 么？”这一核心问题。
需求分析是发现、求精、建模和规约的过程。这一过 程包括：详细精化最初由系统分析员建立在软件项目 计划中确定的软件范围，创建所需数据流、控制流以 及操作行为的模型，在此基础上选择解决方案。
确立系统方案，进行各种估算
粗略地估算成本 估算可能取得的效益 提出可能需要的资源，包括人员、硬件、
软件等 提出大概的进度安排
模型评审
将目标系统的逻辑模型提出管理部分与 用户进行评审
复查问题定义、工程规模和系统目标
系统建模
为了开发系统模型，可通过构造模型进一步分析系 统。
可以用系统流程图，数据流图和数据字典。