《软件工程》教学课件05软件需求分析
合集下载
《软件工程》PPT课件
第四课时
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
软件工程课件(全)
03
识别项目中的关键路径，确保项目按计划进 行
04
及时调整项目计划，应对项目变更和不确定 性
风险管理策略制定
识别项目中的潜在风险， 包括技术风险、市场风险、 资源风险等
制定相应的风险应对策略 和措施，如风险规避、减 轻、转移和接受等
评估风险的概率和影响程 度，制定风险优先级列表
监控风险状态，及时调整 风险管理计划
质量改进
根据质量评估结果，制定相应的改进措施， 如优化性能、增强安全性等。
经验教训总结
对测试过程中遇到的问题进行总结，形成经 验教训，为后续项目提供参考。
06
项目管理与团队协作
项目计划制定与监控
01 制定详细的项目计划，包括项目目标、范围 、时间表、资源需求、成本估算等
02 设立项目里程碑，对项目进度进行阶段性监 控
开发方向。
持续集成和测试
03
迭代增量模型强调持续集成和测试的重要性，以确保每个迭代
周期都能交付高质量的软件产品。
03
需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领 域专家等进行沟通，收集原始
需求。
需求分类
将收集到的需求按照功能、性 能、安全、易用性等方面进行 分类。
需求筛选
去除重复、模糊、不切实际的 需求，确保需求的准确性和可 行性。
处理变更请求
根据实际情况，决定是否接受变更请求，并 制定相应的实施计划。
跟踪和验证变更
对实施的变更进行跟踪和验证，确保变更的 正确性和完整性。
04
系统设计与实现
系统架构设计
分层架构
将系统划分为表示层、业务逻辑层和数据访问层，实现高内聚、 低耦合的设计。
软件工程需求分析课件
当描绘循环运行过程时，通常并不关心循 环是怎样启动的。 当描绘单程生命期时，需要表明初始状态 和最终状态。
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）
一.数据流图的作用
《软件工程实用教程》第5_章_面向对象的需求分析
第5 章 面向對象的需求分析
5.2.2 封裝、繼承和多態
1．封裝 封裝是指把對象的外部特徵與內部實現細節分開，使 得一個對象的外部特徵對其他對象來說是可訪問的， 而它的內部細節對其他對象是隱蔽的。 對象具有封裝性的條件如下： (1) 有一個清楚的邊界，所有私有數據和操作的代碼都被 封裝在這個邊界內，從外面看不見更不能訪問； (2) 有確定的介面，這些介面描述這個對象和其他的對象 之間相互的作用； (3) 受保護的內部實現，這個實現給出了由軟體對象提供 的功能的細節，實現細節能在定義這個對象的類的外 面訪問。
第5 章面向對象的需求分析
通過在不同程度上運用抽象原則（忽略事物 之間的一些差異），可以得到較一般的類和 較特殊的類。特殊類繼承一般類的屬性和操 作，面向對象方法支持這種繼承關係的描述 與實現，從而簡化系統的構造過程及其文檔； 複雜對象可以用簡單的對象作為其構成部分 （稱為聚合）； 對象之間通過消息進行通信，以實現對象之 間的動態聯繫； 通過關聯表達對象之間的靜態關係。
第5 章面向對象的需求分析
5.1.3 面向對象方法的優點 1. 與人們習慣的思維方法一致 2. 可使軟體系統結構更加穩定 3. 軟體具有更好的可複用性 4. 軟體更加便於維護與擴充
第5 章面向對象的需求分析
5.1.4 面向對象建模
用例模型：包含所有用例及其與用戶之間的關係； 對象模型：包含問題域涉及的類及其屬性和關係，其 作用是更詳細地提煉用例，將系統的行為初步分 配給提供行為的一組對象； 設計模型：將系統的靜態結構定義為子系統、類和介 面，並定義由子系統、類和介面之間的協作來實 現的用例； 實現模型：包含構件和類到構件的映射； 配置模型：定義電腦的物理節點和構件到這些節點的 映射； 測試模型：描述用於驗證用例的測試用例。
软件工程课程ppt课件
项目管理工具
如Microsoft Project、JIRA等，用于项目计划制定、 任务跟踪和团队协作。
团队协作与沟通
团队协作的重要性
建立高效协作机制，提 高团队整体效能。
沟通技巧
倾听、表达清晰、及时 反馈等，促进团队成员 之间的有效沟通。
协作工具
如Git、GitHub、 Confluence等，支持版 本控制、代码托管和团 队协作。
软件工程课程ppt课 件
目录
• 软件工程概述 • 软件需求分析 • 软件设计 • 软件开发 • 软件测试与质量保证 • 软件维护与演化 • 软件工程管理与实践
01
软件工程概述
软件工程的定义与发展
定义
软件工程是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科。
发展历程
从20世纪60年代的软件危机开始，软件工程逐渐发展成为一个独立的学科领域，经历了瀑布模 型、螺旋模型、敏捷开发等不同的开发模式和方法。
阐述持续集成和持续交付的概念、原 理和实践，以及如何通过持续集成和 持续交付来加速软件的演化过程并提 高软件的质量。
07
软件工程管理与实践
项目管理方法与工具
传统项目管理方法
包括瀑布模型、螺旋模型等，强调项目计划、进度控 制和风险管理。
敏捷项目管理方法
如Scrum、Kanban等，注重快速响应变化、持续集 成和交付。
兼容性测试
测试软件在不同硬件、操 作系统、浏览器等环境下 的兼容性。
自动化测试
使用自动化工具进行软件 测试，提高测试效率和准 确性。
缺陷管理与跟踪
缺陷记录
详细记录缺陷信息，包括缺陷描述、重现 步骤、严重程度等。
缺陷分析
对缺陷进行统计分析，找出缺陷产生的原 因和规律。
如Microsoft Project、JIRA等，用于项目计划制定、 任务跟踪和团队协作。
团队协作与沟通
团队协作的重要性
建立高效协作机制，提 高团队整体效能。
沟通技巧
倾听、表达清晰、及时 反馈等，促进团队成员 之间的有效沟通。
协作工具
如Git、GitHub、 Confluence等，支持版 本控制、代码托管和团 队协作。
软件工程课程ppt课 件
目录
• 软件工程概述 • 软件需求分析 • 软件设计 • 软件开发 • 软件测试与质量保证 • 软件维护与演化 • 软件工程管理与实践
01
软件工程概述
软件工程的定义与发展
定义
软件工程是一门研究用工程化方法构建和维护有效、实用和高质量的软件的学科。
发展历程
从20世纪60年代的软件危机开始，软件工程逐渐发展成为一个独立的学科领域，经历了瀑布模 型、螺旋模型、敏捷开发等不同的开发模式和方法。
阐述持续集成和持续交付的概念、原 理和实践，以及如何通过持续集成和 持续交付来加速软件的演化过程并提 高软件的质量。
07
软件工程管理与实践
项目管理方法与工具
传统项目管理方法
包括瀑布模型、螺旋模型等，强调项目计划、进度控 制和风险管理。
敏捷项目管理方法
如Scrum、Kanban等，注重快速响应变化、持续集 成和交付。
兼容性测试
测试软件在不同硬件、操 作系统、浏览器等环境下 的兼容性。
自动化测试
使用自动化工具进行软件 测试，提高测试效率和准 确性。
缺陷管理与跟踪
缺陷记录
详细记录缺陷信息，包括缺陷描述、重现 步骤、严重程度等。
缺陷分析
对缺陷进行统计分析，找出缺陷产生的原 因和规律。
软件工程-需求分析PPT文档30页
❖ 知识就是财富 ❖ 丰富你的人生
71、既然我已经踏上这条道路，那么，任何东西都不应妨碍我沿着这条路走下去。——康德 72、家庭成为快乐的种子在外也不致成为障碍物但在旅行之际却是夜间的伴侣。——西塞罗 73、坚持意志伟大的事业需要始终不渝的精神。——伏尔泰 74、路漫漫其修道远，吾将上下而求索。——屈原 75、内外相应，言行相称。——韩非
软件工程-需求分析
1、 舟 遥 遥 以 轻飏， 风飘飘 而吹衣 。 2、 秋 菊 有 佳 色，裛 露掇其 英。 3、 日 月 掷 人 去，有 志不获 骋。 4、 未 言 心 相 醉，不 再接杯 酒。 5、 黄 发 垂 髫 ，并怡
71、既然我已经踏上这条道路，那么，任何东西都不应妨碍我沿着这条路走下去。——康德 72、家庭成为快乐的种子在外也不致成为障碍物但在旅行之际却是夜间的伴侣。——西塞罗 73、坚持意志伟大的事业需要始终不渝的精神。——伏尔泰 74、路漫漫其修道远，吾将上下而求索。——屈原 75、内外相应，言行相称。——韩非
软件工程-需求分析
1、 舟 遥 遥 以 轻飏， 风飘飘 而吹衣 。 2、 秋 菊 有 佳 色，裛 露掇其 英。 3、 日 月 掷 人 去，有 志不获 骋。 4、 未 言 心 相 醉，不 再接杯 酒。 5、 黄 发 垂 髫 ，并怡
软件工程第三章 软件需求分析 PPT课件
购 书 申 学 请 书 购 单 开发票 发 票 领 书 单 发书
生
审查 有效性
开领 书单
书
学 生
学生购买教材的逻辑模型
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
计算机售书系统的逻辑模型
需求分析过程示意
对象 系统
抽象（映射） 模型应用
模型 系统
模型构造的过程
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现 行 系 统
描述重要的业务 功能，无论系统 是如何实施的。
描述现实系统是 如何在物理上实 现的。 描述新系统是如 何实施的（包括 技术）。
目 标 系 统
描述新系统的主要 业务功能和用户新 的需求，无论系统 应如何实施。
接收、发送数据的频率？
数据的准确性和精度？ 数据流量？ 数据需保持的时间？
(8)
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
需对访问系统或系统信息
加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序 和操作系统隔离？ 系统备份要求？
(1)
功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改
或升级？
(2)
性能需求
软件开发的技术性指标：
存储容量限制 执行速度、相应时间 吞吐量
(3)
环境需求
生
审查 有效性
开领 书单
书
学 生
学生购买教材的逻辑模型
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
计算机售书系统的逻辑模型
需求分析过程示意
对象 系统
抽象（映射） 模型应用
模型 系统
模型构造的过程
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现 行 系 统
描述重要的业务 功能，无论系统 是如何实施的。
描述现实系统是 如何在物理上实 现的。 描述新系统是如 何实施的（包括 技术）。
目 标 系 统
描述新系统的主要 业务功能和用户新 的需求，无论系统 应如何实施。
接收、发送数据的频率？
数据的准确性和精度？ 数据流量？ 数据需保持的时间？
(8)
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
需对访问系统或系统信息
加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序 和操作系统隔离？ 系统备份要求？
(1)
功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改
或升级？
(2)
性能需求
软件开发的技术性指标：
存储容量限制 执行速度、相应时间 吞吐量
(3)
环境需求
软件工程需求分析需求分析PPT课件
• 小组负责人要求每位参加者列出问题及环境中的有 关对象，对这些对象施行的操作以及对象间的相互 作用。列出的操作和对象尽可能完全，如，控制面 板、电话机、监控中心、烟雾传感器、门窗监视器、 警报器等对象，以及用户编程控制、电话拔号、报 警等操作。
• 负责人应要求小组成员对接收传感器事件、用户编 程控制、电话报警等操作进行更详细的描述，必要 时可用流程图表示。
• 细化数据流图（DFD），必要时，对实时系统还要 绘制控制流图（CFD）；
• 编制数据字典；
2020/7/31
19
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
20
需求获取的目标
• 对用户需求进行鉴别、综合，清除用户需求的 模糊性、歧义性和不一致性；
• 把对原始问题的理解和软件开发经验结合起来， 鉴别由于用户的片面性或短期行为所导致的不 合理要求，发现用户尚未发现的但具有真正价 值的潜在需求；
2020/7/31
28
家庭保安系统
分析初期联合小组的工作程序
联合小组首先制定工作制度：每次会议开始 前必须有确定的议程，参加者必须针对各项议程 进行充分的准备，并用文字表示。
经过会议讨论，明确问题的范围、问题与环 境的关系，并就开发软件产品的必要性达成共识。
2020/7/31
29
例 家庭保安系统
• 这个计划到综合测试后期执行。
2020/7/31
8
3. 修订开发计划
• 系统调查与可行性研究阶段的最后，草拟了初步 的开发计划，当时由于需求尚不详细，现可有了 详细的需求分析结果以后，应该使开发计划更准 确一些。
2020/7/31
• 负责人应要求小组成员对接收传感器事件、用户编 程控制、电话报警等操作进行更详细的描述，必要 时可用流程图表示。
• 细化数据流图（DFD），必要时，对实时系统还要 绘制控制流图（CFD）；
• 编制数据字典；
2020/7/31
19
5.1.4 需求分析的活动和原则
• 活动主要分为： – 需求获取； – 分析建模； – 需求评审
2020/7/31
20
需求获取的目标
• 对用户需求进行鉴别、综合，清除用户需求的 模糊性、歧义性和不一致性；
• 把对原始问题的理解和软件开发经验结合起来， 鉴别由于用户的片面性或短期行为所导致的不 合理要求，发现用户尚未发现的但具有真正价 值的潜在需求；
2020/7/31
28
家庭保安系统
分析初期联合小组的工作程序
联合小组首先制定工作制度：每次会议开始 前必须有确定的议程，参加者必须针对各项议程 进行充分的准备，并用文字表示。
经过会议讨论，明确问题的范围、问题与环 境的关系，并就开发软件产品的必要性达成共识。
2020/7/31
29
例 家庭保安系统
• 这个计划到综合测试后期执行。
2020/7/31
8
3. 修订开发计划
• 系统调查与可行性研究阶段的最后，草拟了初步 的开发计划，当时由于需求尚不详细，现可有了 详细的需求分析结果以后，应该使开发计划更准 确一些。
2020/7/31
《软件工程》PPT课件
设计方法
E-R图、范式化、反范式化等
优化策略
索引优化、查询优化、存储优化等
04
软件测试与质量保证
测试策略与计划制定
确定测试目标
明确测试的目的和范围，确保测试工作有针对 性。
制定测试计划
根据测试目标，制定详细的测试计划，包括测 试资源、时间表、风险管理等。
选择测试方法
根据软件特点和测试需求，选择合适的测试方法，如黑盒测试、白盒测试、灰 盒测试等。
《软件工程》PPT课件
目录
• 引言 • 软件需求分析 • 软件设计与开发 • 软件测试与质量保证 • 软件维护与演化 • 软件工程管理与实践
01
引言
软件工程概述
软件工程定义
软件工程是一门研究计算机软件开发、 维护和管理的科学，旨在通过系统方 法、工具和技术来提高软件开发的效 率和质量。
软件工程的目标
B
C
D
持续改进与优化
在项目执行过程中，不断总结经验教训， 持续改进和优化项目管理流程和方法。
迭代开发与交付
通过短周期的迭代开发和交付，不断收集 用户反馈，及时调整产品方向和开发计划。
THANKS
感谢观看
回归测试
02
03
缺陷分析
在修复缺陷后，进行回归测试以 验证修复效果，确保软件质量得 到提升。
对缺陷进行统计分析，找出缺陷 产生的原因和规律，为改进软件 开发过程提供依据。
质量保证措施
代码审查 通过代码审查，检查代码是否符合编码
规范和设计要求，提高代码质量。
质量度量与监控 建立质量度量体系，对软件质量进行 度量和监控，及时发现和解决问题。
在给定成本和时间内，设计、实现和 维护软件系统。同时，软件工程也致 力于开发高质量、高可靠性和易于维 护的软件产品。
软件工程需求分析 教学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
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SOFTWARE ENGINEERING
软件需求分析
为了更好地理解问题, 人们常常采用建立问 为了更好地理解问题, 题模型的方法.所谓模型, 题模型的方法. 所谓模型 ,就是为了理解事 物而对事物作出的一种抽象, 物而对事物作出的一种抽象, 是对事物的一 种无歧义的书面描述.通常, 种无歧义的书面描述. 通常, 模型由一组图 示符号和组织这些符号的规则组成, 示符号和组织这些符号的规则组成, 利用它 们来定义和描述问题域中的术语和概念. 们来定义和描述问题域中的术语和概念 .更 进一步讲,模型是一种思考工具, 进一步讲 , 模型是一种思考工具 ,利用这种 工具可以把知识规范地表示出来. 工具可以把知识规范地表示出来.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析的任务 -----分析系统的数据要求 -----分析系统的数据要求
任何一个软件系统本质上都是信息 处理系统, 处理系统 , 系统必须处理的信息和 系统应该产生的信息在很大程度上 决定了系统的面貌, 决定了系统的面貌 , 对软件设计有 深远影响, 因此, 必须分析系统的 深远影响 , 因此 , 数据要求, 数据要求 , 这是软件需求分析的一 个重要任务. 个重要任务.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析
通常,通过快速建立原型,让用户和领 通常,通过快速建立原型, 域专家经过亲身体验, 域专家经过亲身体验,对系统模型进行 更有效的审查. 更有效的审查.模型常常会经过多次必 要的修改, 要的修改,通过不断改正错误的或不全 面的认识,最终, 面的认识,最终,软件开发人员对问题 有了透彻的理解, 有了透彻的理解,从而为后续的开发工 作奠定了坚实基础. 作奠定了坚实基础.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析
对于那些因过分复杂而不能直接理解的 系统,特别需要建立模型, 系统,特别需要建立模型,建模的目的 主要是为了减少复杂性. 主要是为了减少复杂性.人的头脑每次 只能处理一定数量的信息, 只能处理一定数量的信息,模型通过把 系统的重要部分分解成人的头脑一次能 处理的若干个子部分, 处理的若干个子部分,从而减少系统的 复杂程度. 复杂程度.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析
在编程过程中, 事情清晰; 在检验了软件的早期版本后项目共利益者才 能够更好地理解需求;事情变化太快, 能够更好地理解需求; 事情变化太快 , 需求 工程是浪费时间; 工程是浪费时间 ; 底线是开发一个可运行的 程序,其他都是次要的. 程序,其他都是次要的. 构成这些论点的原因在于其中也包含了部分 的真实情况 ( 尤其是不超过一个月的小项 目).
2003.01.10 SOFTWARE ENGINEERING
软件需求分析
为了开发复杂的软件系统,系统分析员 为了开发复杂的软件系统, 应该从不同角度抽象出目标系统的特性, 应该从不同角度抽象出目标系统的特性, 使用精确的表示方法构造系统的模型, 使用精确的表示方法构造系统的模型, 验证模型是否满足用户对目标系统的需 求,并在设计过程中逐渐把和实现有关 的细节加进模型中, 的细节加进模型中,直至最终用程序实 现模型. 现模型.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析的任务
为了开发出真正满足用户需求的软件产品, 为了开发出真正满足用户需求的软件产品, 首先必须确切地知道用户的需求. 首先必须确切地知道用户的需求 .对软件需 求的深入理解,是软件开发工作获得成功的 求的深入理解, 前提和关键, 前提和关键 ,不论我们把设计和编码工作做 得多么出色, 得多么出色 ,不能真正满足用户需求的软件 只会给用户带来失望,给开发者带来烦恼. 只会给用户带来失望,给开发者带来烦恼. 需求分析是软件定义时期的最后一个阶段, 需求分析是软件定义时期的最后一个阶段, 它的基本任务是准确地回答" 它的基本任务是准确地回答" 系统必须做什 这个问题. 么?"这个问题. 这个问题
2003.01.10 SOFTWARE ENGINEERING
Software Requirements Analysis
软件需求分析
有几种原因使需求分析变得困难: 有几种原因使需求分析变得困难:
(1)客户说不清楚需求或无需求,用户意见不统 客户说不清楚需求或无需求, 错误的需求等; 一,错误的需求等; 需求自身经常变动; (2)需求自身经常变动; 分析人员或客户理解有误,缺乏共同语言, (3)分析人员或客户理解有误,缺乏共同语言, 交流障碍. 交流障碍.
2003.01.10 SOFTWARE ENGINEERING
Software Requirements Analysis
软件需求分析
在进行需求分析时必须注意: 在进行需求分析时必须注意: (1)尽可能地分析清楚哪些是稳定的 需求,哪些是易变的需求. 需求,哪些是易变的需求.以便在进行 系统设计时, 系统设计时,将软件的核心建筑在稳定 的需求上. 的需求上. 在合同中一定要说清楚"做什么" (2)在合同中一定要说清楚"做什么" 不做什么" 如果合同含含糊糊, 和"不做什么".如果合同含含糊糊, 日后扯皮的事情就多. 日后扯皮的事情就多.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析
一旦建立起模型之后,这个模型就要经 一旦建立起模型之后, 受用户和各个领域专家的严格审查. 受用户和各个领域专家的严格审查.由 于模型的规范化和系统化, 于模型的规范化和系统化,因此比较容 易暴露出系统分析员对目标系统认识的 片面性和不一致性.通过审查, 片面性和不一致性.通过审查,往往会 发现许多错误,发现错误是正常现象, 发现许多错误,发现错误是正常现象, 这些错误可以在成为目标系统中的错误 之前,就被预先清除掉. 之前,就被预先清除掉.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析的任务
1,确定系统的综合要求 系统功能要求
系统性能要求:如响应时间,存储容量,安全性能等. 系统性能要求:如响应时间,存储容量,安全性能等.
系统运行要求:主要是对系统运行时的环境要求, 系统运行要求:主要是对系统运行时的环境要求, 如系统软件,外存和数据通信接口等. 如系统软件,外存和数据通信接口等. 将来可能提出的要求:为扩充及修改作准备. 将来可能提出的要求:为扩充及修改作准备. 2,分析系统的数据要求 导出系统的逻辑模型: DFD,DD等描述 3,导出系统的逻辑模型:用DFD,DD等描述 修正系统的开发计划: 4,修正系统的开发计划:通过需求对系统的成本及进 度有了更精确的估算,可进一步修改开发计划. 度有了更精确的估算,可进一步修改开发计划.
需求分析的结果是系统开发的基础,关系到工程的 需求分析的结果是系统开发的基础, 成败和软件产品的质量.因此, 成败和软件产品的质量.因此,必须采取行之有效 的办法对需求分析进行严格的审查和验证. 的办法对需求分析进行严格的审查和验证.
Boehm对软件需求的定义:研究一种无二义性的 Boehm对软件需求的定义: 对软件需求的定义 表达工具, 表达工具,它能为用户和软件人员双方都接受 并能够把"需求"严格地,形式地表达出来. 并能够把"需求"严格地,形式地表达出来.
2003.01.10 SOFTWARE ENGINEERING
软件需求分析
模型可以帮助我们思考问题,定义术语, 模型可以帮助我们思考问题,定义术语, 在选择术语时作出适当的假设, 在选择术语时作出适当的假设,并且可 以帮助我们保持定义和假设的一致性. 以帮助我们保持定义和假设的一致性. 在对目标系统进行分析的初始阶段,面 在对目标系统进行分析的初始阶段, 对大量模糊的,涉及众多专业领域的, 对大量模糊的,涉及众多专业领域的, 错综复杂的信息, 错综复杂的信息,系统分析员往往感到 无从下手. 无从下手.模型提供了组织大量信息的 一种有效机制. 一种有效机制.
让我们先接受"需求会变动"这个事实吧, 让我们先接受"需求会变动"这个事实吧, 免得在需求变动时惊慌失措.错误观点: 免得在需求变动时惊慌失措.错误观点:反 需求会变动" 软件也很灵活, 正"需求会变动",软件也很灵活,所以只 做简单的需求分析就开始编程更有效. 做简单的需求分析就开始编程更有效.
2003.01.10 SOFTWARE ENGINEERING
Software Requirements Analysis
软件需求分析
如果客户本身就懂软件开发,能把需求说得清 如果客户本身就懂软件开发, 清楚楚,这样的需求分析将会非常轻松,愉快. 清楚楚,这样的需求分析将会非常轻松,愉快. 如果客户全不懂软件,但信任软件开发方,这 如果客户全不懂软件,但信任软件开发方, 事也好办.分析人员可以引导客户, 事也好办.分析人员可以引导客户,先阐述常 规的需求,再由客户否定不需要的, 规的需求,再由客户否定不需要的,最终确定 客户真正的需求. 客户真正的需求. 最怕的就是"不懂装懂"或者"半懂充内行" 最怕的就是"不懂装懂"或者"半懂充内行" 的客户,他们会提出不切实际的需求. 的客户,他们会提出不切实际的需求.如果这 些客户甚至觉得自己是上帝的父母, 些客户甚至觉得自己是上帝的父母,那么沟通 和协商都会很困难. 和协商都会很困难.
2003.01.10 SOFTWARE ENGINEERING
信息技术项目成功的3 信息技术项目成功的3要素 用户参与程度 高级管理层的支持 明确的需求说明
2003.01.10
SOFTWARE ENGINEERING
软件需求分析的困难