软件需求分析PPT课件
- 格式：ppt
- 大小：329.50 KB
- 文档页数：1
下载文档原格式
合集下载
如何写软件需求分析 ppt课件
预先估计以后 系统可能达到 的目标
ppt课件
7
(2) 分析与综合
从信息流和信息结构出发，逐步细化 所有的软件功能，找出系统各元素之 间的联系、接口特性和设计上的约束， 分析它们是否满足功能要求，是否合 理。剔除其不合理的部分，增加其需 要部分。最终综合成系统的解决方案， 给出目标系统的详细逻辑模型。
ENDIF
ENDIF
ppt课件
51
（2）判定表
如果数据流图的加工需 要依赖于多个逻辑条件 的取值，使用判定表来 描述比较合适
ppt课件
52
以“检查发货单”为 例
ppt课件
53
（3）判定树
判定树也是用来表达加工逻辑的一种 工具。有时侯它比判定表更直观。
ppt课件
54
back
ppt课件
55
最常用的动态分析方法
ppt课件
35
图上每个元素都必须有名字 数据流图中不可夹带控制流
初画时可以忽略琐碎的细节，以集中 精力于主要数据流
ppt课件
36
数据词典（DD，Data Dictionary）
数据词典与数据流图配合，能清楚地 表达数据处理的要求 词条描述 —— 对于在数据流图中每 一个被命名的图形元素，均加以定义， 其内容有:名字，别名或编号，分类， 描述，定义，位置，其它，等
状态迁移图 时序图 Petri网
ppt课件
56
状态迁移图
状态迁移图是描述系统的状 态如何相应外部的信号进行 推移的一种图形表示。
圆圈“○”表示可得到的 系统状态
箭头“→”表示从一种状 态向另一种状态的迁移。
ppt课件
57
例如, 当有多个申请占用CPU运 行的进程时, 有关CPU分配的 进程的状态迁移。
ppt课件
7
(2) 分析与综合
从信息流和信息结构出发，逐步细化 所有的软件功能，找出系统各元素之 间的联系、接口特性和设计上的约束， 分析它们是否满足功能要求，是否合 理。剔除其不合理的部分，增加其需 要部分。最终综合成系统的解决方案， 给出目标系统的详细逻辑模型。
ENDIF
ENDIF
ppt课件
51
（2）判定表
如果数据流图的加工需 要依赖于多个逻辑条件 的取值，使用判定表来 描述比较合适
ppt课件
52
以“检查发货单”为 例
ppt课件
53
（3）判定树
判定树也是用来表达加工逻辑的一种 工具。有时侯它比判定表更直观。
ppt课件
54
back
ppt课件
55
最常用的动态分析方法
ppt课件
35
图上每个元素都必须有名字 数据流图中不可夹带控制流
初画时可以忽略琐碎的细节，以集中 精力于主要数据流
ppt课件
36
数据词典（DD，Data Dictionary）
数据词典与数据流图配合，能清楚地 表达数据处理的要求 词条描述 —— 对于在数据流图中每 一个被命名的图形元素，均加以定义， 其内容有:名字，别名或编号，分类， 描述，定义，位置，其它，等
状态迁移图 时序图 Petri网
ppt课件
56
状态迁移图
状态迁移图是描述系统的状 态如何相应外部的信号进行 推移的一种图形表示。
圆圈“○”表示可得到的 系统状态
箭头“→”表示从一种状 态向另一种状态的迁移。
ppt课件
57
例如, 当有多个申请占用CPU运 行的进程时, 有关CPU分配的 进程的状态迁移。
软件需求-第8课-软件需求分析概述ppt课件
1 需求分析的根本任务 建立分析模型
建模的目的（为什么要建模？）
软件行业的复杂程度与例子中的行业比较，其复杂程度可以说是有过 之而无不及。
为什么要建模？通过建模可以更好地理解正在开发的系统。
原先，由于计算机应用还不算普及，因此软件系统的规模和复杂度都 相对较小。使用“数据结构+算法=程序”的模式就可以解决大部分问题。
软件的生存周期
计划时期 开发时期 运行时期
问题定义
可行性研究
产品:需求分析报告
需求分析
软件设计
编
码
测
试
维
护
5
第8章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
1 需求分析的根本任务 需求分析根本任务：建立分析模型，创建解决方案。
1 需求分析的根本任务 4）基于数据的分解策略
目标系统
主题域1
。。。
主题域n
主题类1 主题类n
逻辑数据1 逻辑数据m
物理数据1 物理数据w
16
第8章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
1 需求分析的根本任务 4）基于数据的分解策略
1 需求分析的根本任务
从实践角度考虑，需求分析不是分析如何实现用户的需求。 实际上，需求分析是以业务分析为导向，将用户零散的需求串联 起来，形成一个体系完成、组织合理、内容清晰的框架，为今后 的设计开发工作打下良好的基础。
What to do? Yes
How to do ? No
8
第8章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
建模的目的（为什么要建模？）
软件行业的复杂程度与例子中的行业比较，其复杂程度可以说是有过 之而无不及。
为什么要建模？通过建模可以更好地理解正在开发的系统。
原先，由于计算机应用还不算普及，因此软件系统的规模和复杂度都 相对较小。使用“数据结构+算法=程序”的模式就可以解决大部分问题。
软件的生存周期
计划时期 开发时期 运行时期
问题定义
可行性研究
产品:需求分析报告
需求分析
软件设计
编
码
测
试
维
护
5
第8章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
1 需求分析的根本任务 需求分析根本任务：建立分析模型，创建解决方案。
1 需求分析的根本任务 4）基于数据的分解策略
目标系统
主题域1
。。。
主题域n
主题类1 主题类n
逻辑数据1 逻辑数据m
物理数据1 物理数据w
16
第8章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
1 需求分析的根本任务 4）基于数据的分解策略
1 需求分析的根本任务
从实践角度考虑，需求分析不是分析如何实现用户的需求。 实际上，需求分析是以业务分析为导向，将用户零散的需求串联 起来，形成一个体系完成、组织合理、内容清晰的框架，为今后 的设计开发工作打下良好的基础。
What to do? Yes
How to do ? No
8
第8章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
《软件需求分析》课件
关系定义
定义实体之间的关系，如 关联、依赖、聚合等。
实体关系图绘制
使用图形化工具绘制实体 关系图，展示实体之间的 关联关系。
Part
04
需求规格说明
需求规格说明编写
确定需求来源
明确软件需求来自哪些方面，如用户、市场、技术等 ，确保全面覆盖。
编写规范统一
遵循统一的编写规范，确保需求规格说明的清晰、准 确和一致性。
需求分析的过程
需求调研
通过与用户沟通、调查问 1
卷、现场观察等方式，了 解用户需求和业务场景。
需求确认
4
将分析出来的需求与用户 进行确认，确保双方对需 求的理解一致。
需求分析
2
对收集到的需求进行整理
、分类、抽象，形成系统
需求。
需求评审
3 对分析出来的需求进行审
查和评估，确保需求的正 确性和完整性。
访谈技巧
注意倾听、引导和追问，以获得深入的需求 信息。
记录和分析
详细记录访谈内容，并进行分析，提取关键 需求。
问卷调查
设计问卷
根据软件的功能和目标，设计合理的问卷。
选择调查对象
确保调查对象的代表性和广泛性。
发布和收集问卷
通过适当的渠道发布问卷，并确保问卷的完整性和准确性。
数据分析
对收集到的数据进行统计分析，提取关键需求。
详细描述
社交网络平台用户数量庞大，用户交互频 繁，对系统的可用性和响应速度要求极高 。同时，由于社交网络平台的功能更新频 繁，需求变化较快，需求分析需要关注系 统的可扩展性和灵活性。此外，社交网络 平台还需要考虑用户隐私和数据安全等问 题。
THANKS
感谢您的观看
非功能需求定义
软件工程需求分析课件
当描绘循环运行过程时，通常并不关心循 环是怎样启动的。 当描绘单程生命期时，需要表明初始状态 和最终状态。
43
例题：
办公室复印机的工作过程大致如下： 未接到复印命令时处于闲臵状态，一旦接到复 印命令则进入复印状态，完成一个复印命令规定的 工作后又回到闲臵状态，等待下一个复印命令； 如果执行复印命令时发现缺纸，则进入缺纸状 态，发出警告，等待装纸，装满纸后进入闲臵状态， 准备接受复印命令；如果复印时发生卡纸故障，则 进入卡纸状态，发出警告等待维修人员排除故障， 故障排除后回到闲臵状态。
系统对事件的响应，既可以是做一个（或一系 列）动作，也可以是仅仅改变系统本身的状态 ，还可以是既改变状态又做动作。
40
初态： 终态： 中间状态：
状态名 状态变量
活动表
事件：
事件名（参数表）[条件]/动作表达式
状态转换：
41
状态图中使用的主要符号
42
状态图可以表示系统循环运行过程，也可 以表示系统单程生命期。
时就应该再次订货。
27
再次阅读可知：
事务有类型，需要根据不同情况处理；---处理事务
对各类事务要更改库存信息；对出库事务当 库存量少于临界值时，要产生订货信息。
订货信息不同于订货报表，报表要有严格的 格式。------产生报表
28
库存清单（信息）
订货 订货报表 CRT终端 事务 2 1 采购员 （仓库管 处理事务 信息 产生报表 （部） 理员） 订 货 信 息 订货信息 订 货 信 息
11
系统流程图（4）
12
系统流程图（5）
13
数据流图（1）
一.数据流图的作用
43
例题：
办公室复印机的工作过程大致如下： 未接到复印命令时处于闲臵状态，一旦接到复 印命令则进入复印状态，完成一个复印命令规定的 工作后又回到闲臵状态，等待下一个复印命令； 如果执行复印命令时发现缺纸，则进入缺纸状 态，发出警告，等待装纸，装满纸后进入闲臵状态， 准备接受复印命令；如果复印时发生卡纸故障，则 进入卡纸状态，发出警告等待维修人员排除故障， 故障排除后回到闲臵状态。
系统对事件的响应，既可以是做一个（或一系 列）动作，也可以是仅仅改变系统本身的状态 ，还可以是既改变状态又做动作。
40
初态： 终态： 中间状态：
状态名 状态变量
活动表
事件：
事件名（参数表）[条件]/动作表达式
状态转换：
41
状态图中使用的主要符号
42
状态图可以表示系统循环运行过程，也可 以表示系统单程生命期。
时就应该再次订货。
27
再次阅读可知：
事务有类型，需要根据不同情况处理；---处理事务
对各类事务要更改库存信息；对出库事务当 库存量少于临界值时，要产生订货信息。
订货信息不同于订货报表，报表要有严格的 格式。------产生报表
28
库存清单（信息）
订货 订货报表 CRT终端 事务 2 1 采购员 （仓库管 处理事务 信息 产生报表 （部） 理员） 订 货 信 息 订货信息 订 货 信 息
11
系统流程图（4）
12
系统流程图（5）
13
数据流图（1）
一.数据流图的作用
软件工程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
需求分析的任务和步骤
《软件需求工程》课件
需求变更管理
需求变更分类
将需求变更分为功能性需求变更、非功 能性需求变更和设计约束变更等。
变更影响分析
对需求变更的影响进行分析，评估变 更对项目进度、成本和风险等方面的
影响。
变更控制流程
建立严格的变更控制流程，包括变更 申请、审批、实施和验证等阶段。
变更实施与跟踪
实施需求变更，并对变更实施过程进 行跟踪，确保变更的有效性和正确性 。
用于记录和管理需求变更，确保需求的一致性和完整性。
如Enterprise Architect、Visio等，用于绘制数据流图、实体关 系图等，帮助分析人员更好地理解和管理需求。
通过建立需求与设计、代码、测试用例之间的关联，确保需求 的实现和验证。
如录音笔、屏幕录制软件等，用于记录用户的原始需求和问题 ，便于后续分析和整理。
风险识别
识别需求工程中可能出现的风险，如需求变 更频繁、需求不清晰等。
风险应对措施
制定风险应对计划，包括风险预防、减轻和 转移等措施。
风险评估
对识别出的风险进行评估，分析风险发生的 概率和影响程度。
风险监控与报告
对风险应对措施的实施过程进行监控，定期 报告风险状态和应对效果。
06 软件需求工程实践
需求分析的步骤
01
需求获取
通过与用户沟通、观察用户操作 等方式，了解用户的需求和期望
。
03
需求评审
对已定义的需求进行审查和评估 ，确保需求的准确性和完整性。
02
需求分析和定义
对获取的需求进行整理、分类和 细化，明确需求的范围、功能、
性能等要求。
04
需求变更管理
建立需求变更的流程和机制，确 保在项目过程中对需求的变更进
软件需求分析PPT课件
原型设计工具
原型设计工具用于快速创建软件原型， 帮助团队更好地理解用户需求和设计 软件界面。
常见的原型设计工具包括Axure、 Sketch、Figma等，这些工具支持快 速设计和制作高保真原型，方便团队 成员进行讨论和评审。
需求分析建模工具
需求分析建模工具用于对软件需求进行分析、建模和规格编写，帮助团队更好地 理解和规范软件需求。
评审
组织专家或利益相关者对需求规格说 明进行评审，确保内容的准确性和完 整性。
修改
根据评审结果，对需求规格说明进行 修改和完善，确保满足利益相关者的 需求。
需求规格说明的发布与维护
发布
将需求规格说明正式发布给相关人员，确保利益相关者了解和遵循。
维护
在软件开发生命周期中，对需求规格说明进行维护和更新，确保其与实际需求保持一致。
定期对需求变更进行审查，确保变 更得到有效控制。
沟通与协调
及时向相关干系人报告变更情况， 确保信息一致性。
04
06 软件需求分析工具
需求管理工具
需求管理工具用于记录、跟踪和管理 软件需求，确保需求变更得到及时处 理和正确实施。
常见的需求管理工具包括Jira、 MantisBT等，这些工具提供了需求跟 踪、版本控制、变更管理等功能，帮 助团队更好地协作和管理需求。
需求分析的流程
需求整理
对收集到的需求进行分类、筛 选、合并、去重等处理。
需求规格说明
编写需求规格说明书，明确需 求的细节和验收标准。
需求收集
通过访谈、问卷调查、原型演 示等方式收集用户需求。
需求分析
对整理后的需求进行深入分析， 明确系统功能、性能等方面的 具体要求。
需求评审
组织专家或团队对需求规格说 明书进行评审，确保需求的准 确性和完整性。
软件需求管理PPT课件
编写需求规格说明书
将分析和评估后的需求编写成正 式的需求规格说明书，明确软件 系统的功能、性能、非功能需求、 约束和假设条件等。
评审和确认
对编写好的需求规格说明书进行 评审和确认，确保其准确性和完 整性。
需求分析的工具
思维导图工具
如XMind、MindManager等，用于整理和 分析需求。
原型制作工具
初步需求收集
在项目启动阶段进行，主要目的是确定项目的目标和 范围。
深化需求收集
在初步需求收集之后进行，主要目的是细化功能需求 和非功能需求。
变更需求收集
在软件开发过程中进行，主要目的是应对利益相关者 提出的需求变更请求。
03 需求分析
需求分析的目标
确定软件系统的功能和性能 要求。
确定软件系统的约束和假设 条件。
软件需求的重要性
确保开发目标明确
提高软件质量
明确软件的目标和范围，避免开发偏 离方向。
明确的质量要求有助于提高软件的稳 定性和用户体验。
减少返工和变更成本
尽早识别和解决需求问题，降低开发 成本和时间。
软件需求管理过程
01
需求收集
通过与用户沟通、市场调研等方式 获取原始需求。
需求规格说明
编写详细的需求文档，明确各项需 求的细节。
03
为后续的软件开发和测试提供明确的依据。
04
便于需求变更的管理和控制。
需求规格说明的内容
功能需求
包括业务流程、数据流程、界面交互等。
约束和假设条件
如技术限制、开发环境、资源等方面的约束。
非功能需求
包括性能、安全、可用性、可维护性等方面 的要求。
验收标准
用于评估软件是否满足需求的明确标准。
第三章：需求分析PPT课件
-
3.2 获取需求的方法
1、访谈
访谈有两种基本形式，分别是正式的和非正式的访谈。
当需要调查大量人员的意见时，向被调查人分发调查表 是一个十分有效的做法。
在访问用户的过程中使用情景分析技术往往非常有效。
情景分析技术的用处主要体现在下述两个方面：
(1) 它能在某种程度上演示目标系统的行为，从而便于用户 理解，而且还可能进一步揭示出一些分析员目前还不知道 的需求。
一般使用第三范式。
17
-
3.6 状态转换图
在需求分析过程中应该建立起软件系统的行为模型。状态转换图(简 称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统 的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作(例 如，处理数据)。
1、状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种 行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可 以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态，还可以是 既改变状态又做动作。
7．其它需求
-
3.4概念模型
最常用的表示概念性数据模型的方法：实体—联 系方法(Entity-Relationship Approach)，简称ER模型。
E-R模型包含三个基本成分：“实体”、“联 系”、“属性”
(1)实体：是客观世界中存在的且可相互区分的事物。 它可以是人或物，也可以是具体事物或抽象事物。 – 例如：教师、学生、课程是实体。 实体用矩形框表示，如： 教师
在状态图中定义的状态主要有：初态(即初始状态)、终态(即最终状态) 和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。
状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。
《软件需求分析》课件
2
需求分析
对收集到的需求进行分类、分析方法和验证。
3
需求规格说明
编写需求规格文档和需求规格说明书，并满足格式要求。
软件需求分析的工具和技术
用例图和用例描述
通过用例图和用例描述来描 述系统的功能和行为。
数据库图
使用数据库图来描述系统中 的数据结构和关系。
业务流程图
使用业务流程图来描绘系统 的业务流程和工作流程。
系统交互图
使用系统交互图来描述系统与用户或其他系统之 间的交互过程。
其他工具和技术
还有其他一些工具和技术可以用于辅助软件需求 分析，比如原型设计等。
软件需求分析的挑战和解决办法
1 需求不准确
通过与利益相关者密切合作，使用迭代的方 法来不断澄清和明确需求。
2 需求冲突
通过协商和妥协，以及优先级排序等方法来 解决需求之间的冲突。
《软件ቤተ መጻሕፍቲ ባይዱ求分析》PPT课 件
欢迎大家来到本次课程《软件需求分析》的PPT课件。在这个课程中，我们 将会深入探讨软件需求分析的核心内容和使用的工具和技术。
引言
在本节中，我们将介绍什么是软件需求分析、为什么进行软件需求分析以及 软件需求分析的重要性。
软件需求分析流程
1
需求收集
通过收集多渠道的需求来源，并编写需求文档。
3 需求变更
建立灵活的变更管理机制，通过评估和影响 分析来控制需求变更。
4 需求管理
建立完善的需求管理过程和工具，确保需求 的跟踪、审批和变更控制。
总结
通过本次课程，我们了解了软件需求分析的意义、流程、工具和技术，以及面临的挑战和解决办法。
参考资料
书籍 报告 文 网站
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对系统定义是否成功进行确认;
.
需求分析流程
.
软件需求分析的原则
需要能够表达和理解问题的信息域 和功能域 要能以层次化的方式对问题进行分 解和不断细化 要给出系统的逻辑视图和物理视图
.
面向数据流自顶向下求精 －结构化分析方法
面向数据流进行需求分析的方法
结构化分析方法适合于数据处理类 型软件的需求分析
.
(3) 编制需求分析阶段的文档 软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计
划
.
(4) 需求分析评审
系统定义的目标是否与用户的要求一 致;
系统需求分析阶段提供的文档资料是 否齐全;
文档中的所有描述是否完整、清晰、 准确反映用户要求;
与所有其它系统成分的重要接口是否 都已经描述;
欠款>60天 不发出批准书
检 查 发
金额>$500
欠款60天 发出批准书、 发货单
货 单
金额$500
欠款>60天 发出批准书、 发货单及赊欠报告
欠款60天 发出批准书、
发货单
.
简易的应用规格说明技术
面向团队 初步访谈 审查需求 得出意见一致的列表 定出小型规格说明 整套确认标准 完整的软件需求规格说明书
资源使用需求 成本消耗需求 开发进度需求 出错处理需求 接口需求 将来可能提出 的要求
.
分析系统的数据要求
采用建立数据模型的方 法分析系统的数据 数据结构规范化问题－ 范式
.
借助于当前系统的逻辑模型导出 目标系统的逻辑模型，解决目标 系统的 “做什么” 的问题。
.
3.2 需求分析的方法及过程
(1) 问题识别
语言的正文用基本控制结构进行分 割，加工中的操作用自然语言短语 来表示
其基本控制结构有三种：
简单陈述句结构：避免复合语句；
重复结构：while_do 或 repeat_until 结构。
判定结构：if_then_else 或 case_of 结构；
.
商店业务处理系统中“检查发货单”
if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else （欠款未超期） 发批准书，发货单
（包括第3章和第4章内容）
软件需求分析的任务和过程 结构化分析方法 原型化方法 图形分析方法 有穷状态机 Petri网
.
3.1 软件需求分析的任务
确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正开发计划
.
软件的综合需求（P46）：
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 约束 逆向需求 用户界面需求
else （发货单金额未超过$500） if 欠款超过60天 then 发批准书，发货单及赊欠报告 else （欠款未超期） 发批准书，发货单
.
（2）判定表
如果数据流图的加工需要依赖于多 个逻辑条件的取值，使用判定表来 描述比较合适
.
以“检查发货单”为 例
.
.
（3）判定树
判定树也是用来表达加工逻辑的一 种工具。有时侯它比判定表更直观。
.
原型化方法
——5点成因
1. 在开发初期，要想得到一个完整准确 的规格说明不是一件容易的事。特别 是对一些大型的软件项目。
2. 用户往往对系统只有一个模糊的想法， 很难完全准确地表达对系统的全面要 求。
3. 软件开发者对于所要解决的应用问题 认识更是模糊不清
.
4. 随着开发工作向前推进，用户可能会 产生新的要求，或因环境变化，要求 系统也能随之变化；开发者又可能在 设计与实现的过程中遇到些没有预料 到的实际困难，需要以改变需求来解 脱困境。
.
用于写加工逻辑说明的工具 结构化英语 判定表 判定树
.
（1）结构化英语
结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等组成。
.
是一种介于自然语言和形式化语言 之间的语言
因此，ERD用于数据建模，DFD用 于功能据流图的每一个基本加工，必 须有一个基本加工逻辑说明
基本加工逻辑说明必须描述基本加 工如何把输入数据流变换为输出数 据流的加工规则 加工逻辑说明必须描述实现加工的 策略而不是实现加工的细节 加工逻辑说明中包含的信息应是充 足的，完备的，有用的，无冗余的
.
被开发项目的数据流与数据结构是 否足够，确定;
所有图表是否清楚，在不补充说明 时能否理解;
主要功能是否已包括在规定的软件 范围之内，是否都已充分说明;
设计的约束条件或限制条件是否符 合实际;
开发的技术风险是什么;
.
是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需
求; 是否详细制定了检验标准，它们能否
从系统的角度来理解软件并评审软 件范围是否恰当
确定对目标系统的综合要求，即软 件的需求
提出这些需求实现条件，以及需求 应达到的标准
.
问题识别的另一项工作是建立分析所 需要的通信途径，以保证能顺利地对 问题进行分析。
.
(2) 分析与综合
从信息流和信息结构出发，逐步细 化所有的软件功能，找出系统各元 素之间的联系、接口特性和设计上 的约束，分析它们是否满足功能要 求，是否合理。剔除其不合理的部 分，增加其需要部分。最终综合成 系统的解决方案，给出目标系统的 详细逻辑模型。
结构化分析的分析模型
数据对象描述
加工规格说明
实体— 联系图
数据流图
数据 词典
状态—迁移图 控制规格说明
分析模型的结构 .
在模型的核心是数据词典，它描述 了所有的在目标系统中使用的和生成的 数据对象。
围绕着这个核心的有三种图：实 体—联系图(ERD)描述数据对象及数据 对象之间的关系；数据流图(DFD)描述 数据在系统中如何被传送或变换，以及 描述如何对数据流进行变换的功能（子 功能）；状态—迁移图(STD)描述系统对 外部事件如何响应，如何动作。
具体来说，结构化分析方法就是用 抽象模型的概念，按照软件内部数 据传递、变换的关系，自顶向下逐 层分解，直到找到满足功能要求的 所有可实现的软件为止
.
结构化分析方法使用工具： 数据流图－记录补充的数据流、数 据存储和处理 数据字典－记录数据元素信息 IPO图－描述算法 结构化英语 判定表与判定树
.
.
需求分析流程
.
软件需求分析的原则
需要能够表达和理解问题的信息域 和功能域 要能以层次化的方式对问题进行分 解和不断细化 要给出系统的逻辑视图和物理视图
.
面向数据流自顶向下求精 －结构化分析方法
面向数据流进行需求分析的方法
结构化分析方法适合于数据处理类 型软件的需求分析
.
(3) 编制需求分析阶段的文档 软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计
划
.
(4) 需求分析评审
系统定义的目标是否与用户的要求一 致;
系统需求分析阶段提供的文档资料是 否齐全;
文档中的所有描述是否完整、清晰、 准确反映用户要求;
与所有其它系统成分的重要接口是否 都已经描述;
欠款>60天 不发出批准书
检 查 发
金额>$500
欠款60天 发出批准书、 发货单
货 单
金额$500
欠款>60天 发出批准书、 发货单及赊欠报告
欠款60天 发出批准书、
发货单
.
简易的应用规格说明技术
面向团队 初步访谈 审查需求 得出意见一致的列表 定出小型规格说明 整套确认标准 完整的软件需求规格说明书
资源使用需求 成本消耗需求 开发进度需求 出错处理需求 接口需求 将来可能提出 的要求
.
分析系统的数据要求
采用建立数据模型的方 法分析系统的数据 数据结构规范化问题－ 范式
.
借助于当前系统的逻辑模型导出 目标系统的逻辑模型，解决目标 系统的 “做什么” 的问题。
.
3.2 需求分析的方法及过程
(1) 问题识别
语言的正文用基本控制结构进行分 割，加工中的操作用自然语言短语 来表示
其基本控制结构有三种：
简单陈述句结构：避免复合语句；
重复结构：while_do 或 repeat_until 结构。
判定结构：if_then_else 或 case_of 结构；
.
商店业务处理系统中“检查发货单”
if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else （欠款未超期） 发批准书，发货单
（包括第3章和第4章内容）
软件需求分析的任务和过程 结构化分析方法 原型化方法 图形分析方法 有穷状态机 Petri网
.
3.1 软件需求分析的任务
确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正开发计划
.
软件的综合需求（P46）：
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 约束 逆向需求 用户界面需求
else （发货单金额未超过$500） if 欠款超过60天 then 发批准书，发货单及赊欠报告 else （欠款未超期） 发批准书，发货单
.
（2）判定表
如果数据流图的加工需要依赖于多 个逻辑条件的取值，使用判定表来 描述比较合适
.
以“检查发货单”为 例
.
.
（3）判定树
判定树也是用来表达加工逻辑的一 种工具。有时侯它比判定表更直观。
.
原型化方法
——5点成因
1. 在开发初期，要想得到一个完整准确 的规格说明不是一件容易的事。特别 是对一些大型的软件项目。
2. 用户往往对系统只有一个模糊的想法， 很难完全准确地表达对系统的全面要 求。
3. 软件开发者对于所要解决的应用问题 认识更是模糊不清
.
4. 随着开发工作向前推进，用户可能会 产生新的要求，或因环境变化，要求 系统也能随之变化；开发者又可能在 设计与实现的过程中遇到些没有预料 到的实际困难，需要以改变需求来解 脱困境。
.
用于写加工逻辑说明的工具 结构化英语 判定表 判定树
.
（1）结构化英语
结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等组成。
.
是一种介于自然语言和形式化语言 之间的语言
因此，ERD用于数据建模，DFD用 于功能据流图的每一个基本加工，必 须有一个基本加工逻辑说明
基本加工逻辑说明必须描述基本加 工如何把输入数据流变换为输出数 据流的加工规则 加工逻辑说明必须描述实现加工的 策略而不是实现加工的细节 加工逻辑说明中包含的信息应是充 足的，完备的，有用的，无冗余的
.
被开发项目的数据流与数据结构是 否足够，确定;
所有图表是否清楚，在不补充说明 时能否理解;
主要功能是否已包括在规定的软件 范围之内，是否都已充分说明;
设计的约束条件或限制条件是否符 合实际;
开发的技术风险是什么;
.
是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需
求; 是否详细制定了检验标准，它们能否
从系统的角度来理解软件并评审软 件范围是否恰当
确定对目标系统的综合要求，即软 件的需求
提出这些需求实现条件，以及需求 应达到的标准
.
问题识别的另一项工作是建立分析所 需要的通信途径，以保证能顺利地对 问题进行分析。
.
(2) 分析与综合
从信息流和信息结构出发，逐步细 化所有的软件功能，找出系统各元 素之间的联系、接口特性和设计上 的约束，分析它们是否满足功能要 求，是否合理。剔除其不合理的部 分，增加其需要部分。最终综合成 系统的解决方案，给出目标系统的 详细逻辑模型。
结构化分析的分析模型
数据对象描述
加工规格说明
实体— 联系图
数据流图
数据 词典
状态—迁移图 控制规格说明
分析模型的结构 .
在模型的核心是数据词典，它描述 了所有的在目标系统中使用的和生成的 数据对象。
围绕着这个核心的有三种图：实 体—联系图(ERD)描述数据对象及数据 对象之间的关系；数据流图(DFD)描述 数据在系统中如何被传送或变换，以及 描述如何对数据流进行变换的功能（子 功能）；状态—迁移图(STD)描述系统对 外部事件如何响应，如何动作。
具体来说，结构化分析方法就是用 抽象模型的概念，按照软件内部数 据传递、变换的关系，自顶向下逐 层分解，直到找到满足功能要求的 所有可实现的软件为止
.
结构化分析方法使用工具： 数据流图－记录补充的数据流、数 据存储和处理 数据字典－记录数据元素信息 IPO图－描述算法 结构化英语 判定表与判定树
.