软件工程需求分析模板精品PPT课件
合集下载
软件工程需求工程程序幻灯片PPT
软件工程需求工程程序幻 灯片PPT
本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！ 本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！ 本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！ 本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！
學習目標
瞭解主要的需求工程活動以及它們之間的關係 瞭解數種需求抽取與分析的技術 瞭解需求確認的重要性，以及在此程序中如何進行
雛形法（prototyping）：在使用這種確認方式時，必 須向終端使用者與客戶展示一個可執行的系統模型。 他們可以用此模型來體驗，確認是否符合他們的真正 需求。
產生測試案例（test-case generation）：需求應該要 能夠接受測試。如果能讓需求測試成為確認程序的一 部分，通常可以發現需求上的問題。如果很難或不可 能設計出這樣的測試，通常表示這個需求很難實作， 最好重新考慮是否要變更需求。
訪談：與系統關係人的正式訪談或非正式訪談， 都是大部分需求工程程序的一部分。在這些訪 談過程中，需求工程小組會訪問關係人一些問 題，關於他們現在所使用的系統與即將開發的 系統。需求就是從這些問題的回答推導出來的。 訪談可能的形式有兩種：
限定的訪談：關係人所回答的是一些事先定義 好的問題。
開放式訪談：沒有事先定義問題和議程。需求 工程小組會與關係人一起討論某些議題，因而 更瞭解關係人的需求。
在系統安裝上線後，還是一定會有新需求出現。 對使用者和客戶而言，他們很難預料新系統對 組織會有什麼影響。等使用者對系統有經驗之 後，他們可能會發現新的需求和不同的優先順 序。
需求的演進
持久和短暫的需求
從演進的觀點來看，需求可分成2類：
持久的需求（enduring requirement）：這些 是指非常穩定的需求，它們衍生自組織的核心 活動，並且直接與系統的領域有關。比如說， 醫院領域的需求一定會與病人、醫生、護士和 治療有關，這些需求可以衍生自領域模型，模 型中顯示描述此應用領域特質的實體和關係。
本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！ 本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！ 本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！ 本课件PPT仅供大家学习使用 学习完请自行删除，谢谢！
學習目標
瞭解主要的需求工程活動以及它們之間的關係 瞭解數種需求抽取與分析的技術 瞭解需求確認的重要性，以及在此程序中如何進行
雛形法（prototyping）：在使用這種確認方式時，必 須向終端使用者與客戶展示一個可執行的系統模型。 他們可以用此模型來體驗，確認是否符合他們的真正 需求。
產生測試案例（test-case generation）：需求應該要 能夠接受測試。如果能讓需求測試成為確認程序的一 部分，通常可以發現需求上的問題。如果很難或不可 能設計出這樣的測試，通常表示這個需求很難實作， 最好重新考慮是否要變更需求。
訪談：與系統關係人的正式訪談或非正式訪談， 都是大部分需求工程程序的一部分。在這些訪 談過程中，需求工程小組會訪問關係人一些問 題，關於他們現在所使用的系統與即將開發的 系統。需求就是從這些問題的回答推導出來的。 訪談可能的形式有兩種：
限定的訪談：關係人所回答的是一些事先定義 好的問題。
開放式訪談：沒有事先定義問題和議程。需求 工程小組會與關係人一起討論某些議題，因而 更瞭解關係人的需求。
在系統安裝上線後，還是一定會有新需求出現。 對使用者和客戶而言，他們很難預料新系統對 組織會有什麼影響。等使用者對系統有經驗之 後，他們可能會發現新的需求和不同的優先順 序。
需求的演進
持久和短暫的需求
從演進的觀點來看，需求可分成2類：
持久的需求（enduring requirement）：這些 是指非常穩定的需求，它們衍生自組織的核心 活動，並且直接與系統的領域有關。比如說， 醫院領域的需求一定會與病人、醫生、護士和 治療有關，這些需求可以衍生自領域模型，模 型中顯示描述此應用領域特質的實體和關係。
软件需求-第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章 软件需求分析概述 认识到了贫困户贫困的根本原因，才能开始对症下药，然后药到病除。近年来国家对扶贫工作高度重视，已经展开了“精准扶贫”项目
[工学]软件需求工程ppt课件
![[工学]软件需求工程ppt课件](https://360docs-1393072327.cos.ap-beijing.myqcloud.com/27ccc0d0580216fc710afd3d.webp)
用例的粒度
用例该大该 小，无规范 答案，看涉 众对系统的 期望
识别系统用例
识别系统用例
识别系统用例
识别系统用例
识别系统用例
每一款产品 都是独特的， 有差别的。 因此需求也 是不同的
业务知识， 设计部件可 以复用
识别系统用例
改良点： 访问和操 作数据对 象
识别系统用例
新财务系统用例
银行系统
识别系统执行者
识别系统执行者
步骤
识别系统用例
识别系统用例
识别系统用例
哪个 是正 确的
请假不 是目的， 是手段。 系统不 能承诺 能请到
假
右边 是正 确的
当把人事系统， 上级员工和人 事部专员包含 在一同时，请 假就是用例
假设开发 的是数据 库衔接的 组件，这 是系统用 例
业务执行者和系统执行者
• 在找业务执行者 时必需抛开计算机系统，没有这 些系统业务人员也客观存在。
• 假设在了解业务的阶段就引入计算机系统的概念 ，将会混淆现有业务和未来有计算机参与时的业 务。
• 留意：要建立一个符合客户需求的计算机系统， 首要条件是完全彻底地搞清客户的业务，而不是 预先假设曾经有了一个计算机系统，再让客户来 假设需求计算机系统帮他们做什么。
识别系统用例
假设不同用户登 录的方式和涉及 的利益不同，就 应分开表示
识别系统用例
假设不同的 审批所涉及 的利益不同， 应分开表示
识别系统用例
解答
• 发货不是用这个系统产生的。违反价值结果要由 系统来生成。
识别系统用例
识别系统用例
识别系统用例
识别系统用例
练习
➢ 评判以下的用例命名： ➢ 1、进展图像导入 ➢ 运用弱动词，改为导入图像 ➢ 2、处置业务 ➢ 运用弱动词和弱名词 ➢ 3、生成贷款记录 ➢ 运用弱动词，生成只是内部一个步骤
软件工程需求分析课件
当描绘循环运行过程时，通常并不关心循 环是怎样启动的。 当描绘单程生命期时，需要表明初始状态 和最终状态。
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章 软件需求分析
5
理
D5 订单表
订单49
1. 数据流图的四个基本成分
2
或
2
数据处理(加工) 数据流（数据对象）
或
II
数据存储 (文件或数据库）
2
或
位于被建模系统之外的信息生 产者或消费者,称为外部项。 说明数据输入的源点(数据源) 或数据输出的汇点(数据池)
50
2. DFD各成分的作用和 命名注意事项
数据流
表示数据和数据流向
抽象出当前系统的逻辑模型
购 书 申 学请
购
生
审查 有效性
书 单
开发票
发 票
开领 书单
领 书 单 发书
书
学 生
学生购买教材的逻辑模型
35
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
36
计算机售书系统的逻辑模型
28
(10) 软件成本消耗 与开发进度需求
开发有规定的时间表吗？
软硬件投资有无限制？
29
(11) 质量保证
系统的可靠性要求？
系统必须监测和隔离错误吗？
规定系统平均出错时间？
出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
4
需求分析的任务和步骤
需求分析的任务
建立分析模型 编写需求说明
需求分析的步骤
问题分析
需求描述
需求验证（评审）
5
需求获取的常用方法
软件项目需求分析模板PPT课件
软件需求分析报告文档模板
1. 引言 1.1 编写目的 1.2 1.3 1.4 预期读者和阅读建议 1.5 产品范围 1.6 参考文献
2020/10/13
1
2. 综合描述 2.1 产品的状况 2.2 产品的功能 2.3 用户类和特性 2.4 运行环境 2.5 设计和实现上的限制 2.6 假设和约束(依赖) 3. 外部接口需求 3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通讯接口
3.3 系统接口设计
3.3.1 系统接口表 3.3.2 系统接口传输协议说明
3.4 系统完整性设计
2020/10/13
6
谢谢您的指导
THANK YOU FOR YOUR GUIDANCE.
感谢阅读！为了方便学习和使用，本文档的内容可以在下载后随意修改，调整和打印。欢迎下载！
汇报人：XXXX 日期：20XX年XX月XX日
2020/10/11 编写目的
1.2 项目风险
1.3 预期读者和阅读建议
1.4 参考资料
2. 设计概述
2.1 限制和约束
2.2 设计原则和设计要求
•2020/10/13
5
3. 系统逻辑设计 3.1 系统组织设计 3.2 系统结构设计
3.2.1 系统特性表 3.2.2 系统特性结构图
2020/10/13
2
4. 系统功能需求
4.1 说明和优先级
4.2 激励／响应序列
4.3 输入／输出数据
5. 其它非功能需求
5.1 性能需求
5.2 安全措施需求
5.3 安全性需求
5.4 软件质量属性
5.5 业务规则
250.260/10用/13 户文档
3
6. 词汇表 7. 数据定义 8. 分析模型 9. 待定问题列表
1. 引言 1.1 编写目的 1.2 1.3 1.4 预期读者和阅读建议 1.5 产品范围 1.6 参考文献
2020/10/13
1
2. 综合描述 2.1 产品的状况 2.2 产品的功能 2.3 用户类和特性 2.4 运行环境 2.5 设计和实现上的限制 2.6 假设和约束(依赖) 3. 外部接口需求 3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通讯接口
3.3 系统接口设计
3.3.1 系统接口表 3.3.2 系统接口传输协议说明
3.4 系统完整性设计
2020/10/13
6
谢谢您的指导
THANK YOU FOR YOUR GUIDANCE.
感谢阅读！为了方便学习和使用，本文档的内容可以在下载后随意修改，调整和打印。欢迎下载！
汇报人：XXXX 日期：20XX年XX月XX日
2020/10/11 编写目的
1.2 项目风险
1.3 预期读者和阅读建议
1.4 参考资料
2. 设计概述
2.1 限制和约束
2.2 设计原则和设计要求
•2020/10/13
5
3. 系统逻辑设计 3.1 系统组织设计 3.2 系统结构设计
3.2.1 系统特性表 3.2.2 系统特性结构图
2020/10/13
2
4. 系统功能需求
4.1 说明和优先级
4.2 激励／响应序列
4.3 输入／输出数据
5. 其它非功能需求
5.1 性能需求
5.2 安全措施需求
5.3 安全性需求
5.4 软件质量属性
5.5 业务规则
250.260/10用/13 户文档
3
6. 词汇表 7. 数据定义 8. 分析模型 9. 待定问题列表