需求分析课件全解
合集下载
第三章需求分析1PPT课件
第 44页页
注意 ① 需求分析阶段，系统分析员的主要关注点是“做什
么（ what ) ” ，不是“怎样做（ how）”； ② 需求分析阶段，系统分析员应该给出软件需求规格
书。
第 55页页
§3.1需求分析的任务
▪ 四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
▪ 数据流图（Data Flow Diagram,DFD） ：用来创建功能模 型，描述了信息流和数据转换。
▪ 教学目的：了解需求分析的任务和步骤、评审标准 和过程；掌握基本技术，理解需求规格说明书的作 用与组成。
▪ 教学重点：基本技术、需求规格说明书的作用与组 成。
▪ 教学难点：基本技术。
第 33页页
需求分折简介
▪ 软件需求指用户对所开发的软件在功能、性能、 环境、可靠性等各方面的要求。
▪ 需求分析主要回答待开发的系统必须“做什么” ，并用 《 需求规格说明书 》 的形式准确、详细、 规范地表达出来。
第 2222页页
例：结构化分析方法建立的需求模型
▪ 结构化分析（ Structured Analysis , SA ）是面向数据流 进行分析的方法，主要建立以下几种模型：
▪ 实体关系图(Entity-Relationship Diagram,E-R图)来创建数 据模型，描述系统中所有重要的数据对象；
密切合作，共同标识问题，提出解决方案要素，商 讨不同方案并指定基本需求。 ▪ 具体过程见教材 P60 面 ▪ 提问：此方法将产生什么样的产品？
第 1188页页
§3.2.4快速建立软件原型
▪ 快速原形就是快速建立起来的旨在演示目标系统主要 功能的可运行的程序。
注意 ① 需求分析阶段，系统分析员的主要关注点是“做什
么（ what ) ” ，不是“怎样做（ how）”； ② 需求分析阶段，系统分析员应该给出软件需求规格
书。
第 55页页
§3.1需求分析的任务
▪ 四项主要任务： 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
▪ 数据流图（Data Flow Diagram,DFD） ：用来创建功能模 型，描述了信息流和数据转换。
▪ 教学目的：了解需求分析的任务和步骤、评审标准 和过程；掌握基本技术，理解需求规格说明书的作 用与组成。
▪ 教学重点：基本技术、需求规格说明书的作用与组 成。
▪ 教学难点：基本技术。
第 33页页
需求分折简介
▪ 软件需求指用户对所开发的软件在功能、性能、 环境、可靠性等各方面的要求。
▪ 需求分析主要回答待开发的系统必须“做什么” ，并用 《 需求规格说明书 》 的形式准确、详细、 规范地表达出来。
第 2222页页
例：结构化分析方法建立的需求模型
▪ 结构化分析（ Structured Analysis , SA ）是面向数据流 进行分析的方法，主要建立以下几种模型：
▪ 实体关系图(Entity-Relationship Diagram,E-R图)来创建数 据模型，描述系统中所有重要的数据对象；
密切合作，共同标识问题，提出解决方案要素，商 讨不同方案并指定基本需求。 ▪ 具体过程见教材 P60 面 ▪ 提问：此方法将产生什么样的产品？
第 1188页页
§3.2.4快速建立软件原型
▪ 快速原形就是快速建立起来的旨在演示目标系统主要 功能的可运行的程序。
第3章-需求分析课件
❖ 2。需求分析
❖ 这个阶段对已收集的需求进行提炼、分析和审查，即对问 题的分析和方案的综合，确保所有的需求含义都被理解， 并找出可能错误，遗漏或不足的地方。
❖ 分析人员在这一步骤中的任务是根据对问题及其环境的理 解与软件开发经验，改正用户需求的模糊性、歧义性和不 一致性，排除由于用户的片面性和短期行为所导致的不合 理要求、挖掘用户尚未提出但具有价值的潜在需求，并在 用户的帮助下对相互冲突的要求进行折衷，使用户需求逐 步精确化、一致化和完全化。
经过评审确认的需求规格说明将成为客户方与开发方的 合同。如果评审未通过，比如发现了遗漏或错误，则必 须进行迭代，直至通过评审为止。
需求分析的任务
与软件实际运行相关的需求分析任务
1、确定对系统的综合要求 2、分析系统的数据要求 3、异出系统的逻辑模型 4、修正项目开发划 5、开发原型系统
3.3.2 需求分析的一般性技术
在分析阶段构筑的模型不应涉及软件实现的细节，以免分散分 析人员的注意力、限制软件设计人员为提高软件质量和效率而 选择实现方法的自由度。
需求分析结束时确立的软件模型是生成需求规格说明的依据， 也是软件设计和实现的基础。
3.3.2.3 快速原型技术
如果按照传统的软件开发方法，需要经过漫长的开 发时间之后用户才能看到目标软件的最初版本。此 时用户常常会提出许多修改意见，有时甚至全盘否 定，导致开发失败。为了降低开发风险，在需求分 析阶段常常采用快速原型技术。
发挥。 ③所提问题汇总后应能反映应用问题及其子问题的全貌、并且
不要过分详细。
2．观察用户工作流程
如果可能，可通过实际观察用户的手工操作过 程来提取新系统的初步用户需求。
观察手工操作过程不是为了模拟手工操作过程， 而是为了获取第一手资料，并从中提取出有价 值的需求。分析人员有了第一手资料，再结合 自己的软件开发和应用的经验，就能够发现不 合理的用户需求、提出用户还没有意识到的潜 在的但却很有价值的用户需求，并能够从软件 的角度改进操作流程和操作规范，从而可获得 用户满意的分析结果。
需求分析 PPT课件
9
3.3 分析建模与规格说明 3.3.1 分析建模
模型：就是为了理解事物而对事物做出的一 种抽象，是对事物的一种无歧义的书面描述。 通常，模型由一组图形符号和组织这些符号 的规则组成。
结构化分析过程：实质上是一种创建模型的 活动。系统分析员从不同角度抽象出目标系 统的特性，使用精确的表示方法构造系统的 模型，验证模型是否满足用户对目标系统的 需求，并在设计过程中逐渐把和实现有关的 细节加进模型中，直至最终用程序实现模型。
带箭头的连线：称为状态转换，箭头指明了转 换方向。
19
状态图中使用的主要符号
20
活动表的语法格式： 事件名(参数表)/动作表达式
“事件名”可以是任何事件的名称。 常用的3种标准事件：
entry事件指定进入该状态的动作； exit事件指定退出该状态的动作； do事件则指定在该状态下的动作。
数据对象 数据对象的属性 数据对象彼此间相互连接的关系
14
实体-联系图的符号
ER图中包含： 实体(即数据对象)，用矩形框表示； 关系，用连接相关实体的菱形框表示； 属性，用椭圆形或圆角矩形表示，并用直线
把实体(或关系)与其属性连接起来。
15
例1：某校教学管理系统的ER图
16
状态转换图
需要时可以为事件指定参数表。活动表中的 动作表达式描述应做的具体动作。
21
事件表达式的语法： 事件说明［守卫条件］／动作表达式
事件说明的语法为：事件名(参数表)。 守卫条件是一个布尔表达式。如果同时使用
事件说明和守卫条件，则当且仅当事件发生 且布尔表达式为真时，状态转换才发生。如 果只有守卫条件没有事件说明，则只要守卫 条件为真状态转换就发生。 动作表达式是一个过程表达式，当状态转换 开始时执行该表达式。
3.3 分析建模与规格说明 3.3.1 分析建模
模型：就是为了理解事物而对事物做出的一 种抽象，是对事物的一种无歧义的书面描述。 通常，模型由一组图形符号和组织这些符号 的规则组成。
结构化分析过程：实质上是一种创建模型的 活动。系统分析员从不同角度抽象出目标系 统的特性，使用精确的表示方法构造系统的 模型，验证模型是否满足用户对目标系统的 需求，并在设计过程中逐渐把和实现有关的 细节加进模型中，直至最终用程序实现模型。
带箭头的连线：称为状态转换，箭头指明了转 换方向。
19
状态图中使用的主要符号
20
活动表的语法格式： 事件名(参数表)/动作表达式
“事件名”可以是任何事件的名称。 常用的3种标准事件：
entry事件指定进入该状态的动作； exit事件指定退出该状态的动作； do事件则指定在该状态下的动作。
数据对象 数据对象的属性 数据对象彼此间相互连接的关系
14
实体-联系图的符号
ER图中包含： 实体(即数据对象)，用矩形框表示； 关系，用连接相关实体的菱形框表示； 属性，用椭圆形或圆角矩形表示，并用直线
把实体(或关系)与其属性连接起来。
15
例1：某校教学管理系统的ER图
16
状态转换图
需要时可以为事件指定参数表。活动表中的 动作表达式描述应做的具体动作。
21
事件表达式的语法： 事件说明［守卫条件］／动作表达式
事件说明的语法为：事件名(参数表)。 守卫条件是一个布尔表达式。如果同时使用
事件说明和守卫条件，则当且仅当事件发生 且布尔表达式为真时，状态转换才发生。如 果只有守卫条件没有事件说明，则只要守卫 条件为真状态转换就发生。 动作表达式是一个过程表达式，当状态转换 开始时执行该表达式。
讲：需求分析PPT课件
管理员调整报表的格式以及一些设置 输出信息：
输出房间的报表
第5章 需求分析
案例分析
3）信息界面
楼房管理界面
第5章 需求分析
案例分析
房间管理界面
第5章 需求分析
案例分析
4）与系统交互的信息
第5章 需求分析
案例分析
第5章 需求分析
案例分析
第5章 需求分析
案例分析
第5章 需求分析
案例分析
5）涉及的业务对象 楼房：楼房编号，楼房描述 单元房：房间号，建筑面积，使用面积，销售价格
第4章 需求分析
需求捕获基本技法
(三)功能需求捕获（业务人员）
1) 你希望计算机帮助你处理哪些业务? 2) 你将给这些业务提交要处理的什么数据? 3) 你希望获得什么处理结果? 4) 你把获取的处理结果又如何处理?
第4章 需求分析
需求捕获基本技法
(四)性能需求捕获（管理人员，业务人员）
1) 你对系统的处理效率有什么具体要求? 2) 如果你的信息被其他人获取,会对你的工作造成什么影响? 3) 如果系统出现故障,多长时间恢复能够不影响你的日常工作? 4) 谈谈你对色彩、画面的感觉和喜好。
5) 我和你将一起把你设想的处理用界面描述出来,并希望你能够作出评价.
第4章 需求分析
4.3 需 求 分 析
4.3.1 概述
1、需求分析的任务 是在需求调查的基础上，结合组织目标、业务现
状、技术水平、投资能力等因素，对用户提出的需求 从系统目标、结构、业务功能、技术性能、风险等方 面进行深入分析，最后确定出全面、合理、可行的系 统需求。
维修管理
第4章 需求分析
案例分析
5.小区物业管理职能域
(1) 楼宇管理
输出房间的报表
第5章 需求分析
案例分析
3）信息界面
楼房管理界面
第5章 需求分析
案例分析
房间管理界面
第5章 需求分析
案例分析
4）与系统交互的信息
第5章 需求分析
案例分析
第5章 需求分析
案例分析
第5章 需求分析
案例分析
第5章 需求分析
案例分析
5）涉及的业务对象 楼房：楼房编号，楼房描述 单元房：房间号，建筑面积，使用面积，销售价格
第4章 需求分析
需求捕获基本技法
(三)功能需求捕获（业务人员）
1) 你希望计算机帮助你处理哪些业务? 2) 你将给这些业务提交要处理的什么数据? 3) 你希望获得什么处理结果? 4) 你把获取的处理结果又如何处理?
第4章 需求分析
需求捕获基本技法
(四)性能需求捕获（管理人员，业务人员）
1) 你对系统的处理效率有什么具体要求? 2) 如果你的信息被其他人获取,会对你的工作造成什么影响? 3) 如果系统出现故障,多长时间恢复能够不影响你的日常工作? 4) 谈谈你对色彩、画面的感觉和喜好。
5) 我和你将一起把你设想的处理用界面描述出来,并希望你能够作出评价.
第4章 需求分析
4.3 需 求 分 析
4.3.1 概述
1、需求分析的任务 是在需求调查的基础上，结合组织目标、业务现
状、技术水平、投资能力等因素，对用户提出的需求 从系统目标、结构、业务功能、技术性能、风险等方 面进行深入分析，最后确定出全面、合理、可行的系 统需求。
维修管理
第4章 需求分析
案例分析
5.小区物业管理职能域
(1) 楼宇管理
第3章需求分析ppt课件
观点对数据建立的模型。它描述了从用户角度看到的数据， 反映了用户的现实环境，而且与在软件系统中的实现方法无 关。 数据模型中包含3种相互关联的信息：数据对象（实体）、数 据对象的属性及数据对象彼此间相互连接的关系。
(1). 数据对象
数据对象: 是对软件必须理解的复合信息的抽象。 复合信息: 是指具有一系列不同性质或属性的事物，
或升级？
7
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
8
(3) 环境需求
• 硬件设备：机型、外设、接口、
地点、分布、温度、 湿度、磁场干扰等
•软件：
操作系统 网络 数据库
9
(4) 界面需求
• 有来自其它系统的输入吗？ • 到自其它系统的输出吗？ • 对数据格式有规定吗？ • 对数据存储介质有规定吗？
第3章 需求分析
为什么需要需求分析
开发人员往往急于求成 希望对开发进行指导 希望开发人员对用户的要求理解 希望用户理解开发人员 测试部门有理可依
2
需求分析的任务
准确地定义未来系统的目标，确定为了满 足用户的需求系统必须做什么。用 <需求规格 说明书> 规范的形式准确地表达用户的需求。
开发人员同意的。
24
软件客户需求义务书 （1）(Note 13)
客户有下列义务： 1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。 5. 要尊重开发人员的成本估算和对需求的可行性分析。
•建立分析小组
领域专家： 主角 系统分析员：导演
(1). 数据对象
数据对象: 是对软件必须理解的复合信息的抽象。 复合信息: 是指具有一系列不同性质或属性的事物，
或升级？
7
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
8
(3) 环境需求
• 硬件设备：机型、外设、接口、
地点、分布、温度、 湿度、磁场干扰等
•软件：
操作系统 网络 数据库
9
(4) 界面需求
• 有来自其它系统的输入吗？ • 到自其它系统的输出吗？ • 对数据格式有规定吗？ • 对数据存储介质有规定吗？
第3章 需求分析
为什么需要需求分析
开发人员往往急于求成 希望对开发进行指导 希望开发人员对用户的要求理解 希望用户理解开发人员 测试部门有理可依
2
需求分析的任务
准确地定义未来系统的目标，确定为了满 足用户的需求系统必须做什么。用 <需求规格 说明书> 规范的形式准确地表达用户的需求。
开发人员同意的。
24
软件客户需求义务书 （1）(Note 13)
客户有下列义务： 1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。 5. 要尊重开发人员的成本估算和对需求的可行性分析。
•建立分析小组
领域专家： 主角 系统分析员：导演
需求分析PPT课件
多种可供选择的设计方案
适应需求的变化
10
需求分析的规约（表示）
模型化表示
将需求定义用工具（例如数据流图和数据字典） 严格地描述出来
分析方法
结构化方法（自顶向下，逐步求精）
面向数据流的结构化分析方法。（SA） 面向数据结构的Jackson方法。(JSD)
面向对象方法（OO）
面向数据内容的面向对象分析方法。(OOA) 等
人与人之间的通信
与用户、同事、专家交流
需求的不断变化
确定稳定的需求和可能变化的需求
8
需求获取的内容
物理环境 界面 用户或者人的因素 功能 文档 数据 资源 安全性 质量保证
9
需求获取的技术
手段
发调查表
与用户谈话
Use Case分析法
比较好的方法：
方便通信
定义系统边界的方法
划分、投影、抽象的方法
分析员用问题领域的术语
17
数据流图和数据字典（7）
数据字典：任务是对于数据流图中出现的所有被 命名的图形元素在数据词典中作为一个词条加以 精确定义。
数据字典的的内容：图形元素的名字，别名或编号， 分类，描述，定义，位置等
数据词条描述：数据流是数据结构在系统内传播的 路径，一个数据流词条包括以下几项内容：
数据流名：简要介绍作用即它产生的原因和结果。 数据流来源：来自何方。 数据流去向：去向何处。 数据流组成：数据结构。 每个数据量流通量：数据量，流通量。
6
需求分析的过程（3）
对于比较复杂的问题，必须建立适当的比较形 式化的抽象系统模型。 不同类型的问题需要建立不同类型的系统模型。 在分析过程中数据模型是首先要集中精力考虑 的问题。系统抽象模型的建立包括三个阶段
《需求分析》课件
2
需求验证
确认需求是否满足用户期望和项目目标。
3
需求变更
控制需求变更，确保变更符合项目目标。
需求跟踪和追踪
介绍如何跟踪和追踪需求，确保项目的需求得到满足并实现。
需求与设计的关系
讨论需求分析与设计之间的密切联系，以及设计如何满足需求。
《需求分析》PPT课件
通过本课件，我们将深入探讨需求分析的重要性、定义和作用，以及步骤流 程、方法技巧，并介绍需求文档的编写和维护，需求评审和验证的重要性， 以及需求的变更和控制等方面知识。
理解需求分析的重要性
深入理解需求分析在项目开发中的关键作用，如何准确识别用户和业务需求，并对需求变更进行控制。
需求分析的定义和作用
详细介绍需求分析的定义和作用，以及为什么需求分析在项目开发过程中至 关重要。
需求分析的步骤和流程
1
需求识别
确保全面获取项目的用户需求和业务需求。
2
需求分析
对收集到的需求进行分析、整理和归纳。
3
需求验证
确认需求的准确性、一致性和完整性。
需求收集的方法和技巧
用户访谈
与用户面对面交流，深入问卷，收集用户的反馈和意见。
观察研究
观察用户在实际场景中的行为和需求。
用户需求和业务需求的区别
解释用户需求和业务需求的概念，并强调两者的重要区别和关联。
需求文档的编写和维护
提供编写和维护高质量需求文档的方法、技巧和最佳实践。
需求评审和验证
1
需求评审
确保需求的准确性和可行性，提前发现和解决潜在问题。
第3章需求分析PPT课件
49％不正确的事实，31％疏忽，l 3％不一致，5％二义性
28.09.2020
6
需求分析的重要性
需求错误是可以被检查出来的
28.09.2020
7
需求分析的重要性
在需求过程中会产生很多错误。 许多错误并没有在早期被发现。 这样的错误是能够在产生的初期被检查出来的。 如果没有及时检查出来这些错误，软件费用会直
T h e top factors w ere rep orted to b e
1 . in co m p lete req u irem en ts (1 3 .1 % )
2 . la ck o f u ser in v o lv em en t (1 2 .4 % )
3 . la ck o f reso u rces (1 0 .6 % )
28.09.2020
3
需求分析的重要性
To u n d ersta n d w h y, Sta n d ish (1 9 9 5 ) a sk ed th e su rv e y
resp o n dຫໍສະໝຸດ en ts to ex p la in th e ca u ses of th e fa iled p ro jects.
线上升
28.09.2020
8
需求工程
需求是什么?需求就是以一种清晰、简洁、一致
且无二义性的方式，对一个待开发系统中各个有 意义方面的陈述的一个集合。
需求工程一般指应用已证实有效的原理、方法，
通过合适的工具和记号，系统地描述出待开发系 统及其行为特征和相关约束；通常是一些过程的 集合：需求获取(需求引出)、需求分析和编写软 件规格说明书(SRS)及验证(包括鉴定和证实)。
28.09.2020
6
需求分析的重要性
需求错误是可以被检查出来的
28.09.2020
7
需求分析的重要性
在需求过程中会产生很多错误。 许多错误并没有在早期被发现。 这样的错误是能够在产生的初期被检查出来的。 如果没有及时检查出来这些错误，软件费用会直
T h e top factors w ere rep orted to b e
1 . in co m p lete req u irem en ts (1 3 .1 % )
2 . la ck o f u ser in v o lv em en t (1 2 .4 % )
3 . la ck o f reso u rces (1 0 .6 % )
28.09.2020
3
需求分析的重要性
To u n d ersta n d w h y, Sta n d ish (1 9 9 5 ) a sk ed th e su rv e y
resp o n dຫໍສະໝຸດ en ts to ex p la in th e ca u ses of th e fa iled p ro jects.
线上升
28.09.2020
8
需求工程
需求是什么?需求就是以一种清晰、简洁、一致
且无二义性的方式，对一个待开发系统中各个有 意义方面的陈述的一个集合。
需求工程一般指应用已证实有效的原理、方法，
通过合适的工具和记号，系统地描述出待开发系 统及其行为特征和相关约束；通常是一些过程的 集合：需求获取(需求引出)、需求分析和编写软 件规格说明书(SRS)及验证(包括鉴定和证实)。
需求分析详解PPT课件
6. 由一名或多名与会者根据会议成果起草完整的软件需求规 格说明书。
第19页/共61页
3.2.4 快速建立软件原型
• 快速建立软件原型是最准确、最有效、最强大的需求分析技术。所谓软件原型，就是快速建立起来的旨在 演示目标系统主要功能的可运行的程序。
• 构建软件原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。 • 软件原型的应该具备的第一个特性是“快速”，第二个特性是“容易修改”。
第5页/共61页
• 在分析软件需求和书写软件需求规格说明书的过程 中，分析员和用户都起着关键的、必不可少的作用。
第6页/共61页
第3章 需求分析
• 所有的需求分析方法都遵守下述准则： • (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 • (2) 必须定义软件应完成的功能，这条准则要求建立功能模型。 • (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 • (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。
• 当需要调查大量人员的意见时，请被调查人填写调查表是十分有效的做法。
第13页/共61页
3.2.1 访谈
• 在访问用户的过程中使用情景分析技术往往十分有效。所谓情景分析，就是对用 户将来使用目标系统解决某个具体问题的方法和结果进行分析。系统分析员利用 情景分析技术往往能够获知用户的具体需求。
• 情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用
第10页/共61页
3.1 需求分析的任务
任务3：导出系统的逻辑模型 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、
第19页/共61页
3.2.4 快速建立软件原型
• 快速建立软件原型是最准确、最有效、最强大的需求分析技术。所谓软件原型，就是快速建立起来的旨在 演示目标系统主要功能的可运行的程序。
• 构建软件原型的要点是，它应该实现用户看得见的功能，省略目标系统的“隐含”功能。 • 软件原型的应该具备的第一个特性是“快速”，第二个特性是“容易修改”。
第5页/共61页
• 在分析软件需求和书写软件需求规格说明书的过程 中，分析员和用户都起着关键的、必不可少的作用。
第6页/共61页
第3章 需求分析
• 所有的需求分析方法都遵守下述准则： • (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 • (2) 必须定义软件应完成的功能，这条准则要求建立功能模型。 • (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 • (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。
• 当需要调查大量人员的意见时，请被调查人填写调查表是十分有效的做法。
第13页/共61页
3.2.1 访谈
• 在访问用户的过程中使用情景分析技术往往十分有效。所谓情景分析，就是对用 户将来使用目标系统解决某个具体问题的方法和结果进行分析。系统分析员利用 情景分析技术往往能够获知用户的具体需求。
• 情景分析技术的用处主要体现在下述两个方面： (1) 它能在某种程度上演示目标系统的行为，从而便于用
第10页/共61页
3.1 需求分析的任务
任务3：导出系统的逻辑模型 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、
《需求分析概述》PPT课件
类图
数据字典
对象角色模型
对象约束语言 微规格说明
交互图
活动图
状态（转移）图/矩阵
业务过程模型 Petri网
2.4 Zachman 框架
数据（What） 功能（Howt） 位置（Network） 人（Who）
时间（When） 动机（Why）
目标/范围 （规划者视图） （上下文模型）
业务的重要事物
业务的重要处理
Design Implementation
Integration
Project scope Business Model
的是获取某个可以转换为知识的事物的信息
1. 需求分析的根本任务
创建解决方案 将一个问题分解成的、更简单和易于管理的子
问题来帮助寻找解决方案 创建解决方案的过程是创造性的 帮助开发者建立问题的定义，并确定被定义的
事物之间的逻辑关系 这些逻辑关系可以形成信息的推理，进而可以
被用来验证解决方案的正确性。
信息的描述具有明确化、准确化 和确定化的特征
需求分析阶段不适宜建立形式 化的计算模型
重点是问题，缺乏和软件实现相 关的技术细节
用户无法理解
软件的常见构建单位 单位之间的常见关系
子系统
· 合作
模块 类、对象
· 依赖 · 包含、继承、协作
数据 函数 语言逻辑单位
机器码
· 调用、使用 · 控制逻辑 · 序列
过程/数据关系建模
功能实体矩阵Function/Entity Matrix
信息工程方法
功能分解图Function Decomposition Diagram
过程依赖图Process Dependency Diagram
需求分析概述PPT课件
界面需求
评估产品的用户界面设计，确保用户友好、 易于操作。
评审方法
专家评审
邀请行业专家对需求进行评估和审查。
用户评审
邀请目标用户参与评审，收集用户意 见和建议。
原型评审
制作产品原型进行评审，直观展示产 品功能和界面设计。
文档评审
对需求文档进行详细审查，确保文档 的完整性和准确性。
评审步骤
准备阶段
分析需求
对筛选出的需求进行深入分析， 明确需求的具体内容、实现方 式和预期效果。
评审和确认
组织相关人员进行评审，确保 需求分析的准确性和可行性， 并获得用户的最终确认。
04
需求规格说明
需求规格说明的内容
01
02
03
04
功能需求
描述软件或系统的所有功能， 包括用户直接使用或间接使用 ，以及系统内部处理的功能。
用于记录和整理用户提出的需求。
思维导图
帮助梳理需求的逻辑关系和层次结构。
需求管理工具
如Jira、Trello等，用于跟踪和管理需求状态。
整理需求的步骤
筛选需求
根据业务目标和实际情况，筛 选出有价值的需求。
整理需求
将分析后的需求整理成文档， 明确需求的优先级、责任人和 时间计划。
收集需求
通过访谈、问卷调查、会议等 方式收集用户需求。
01
02
变更评估
对变更申请进行评估，分析其对项目 进度、成本、质量等方面的影响。
03
变更决策
根据评估结果，决定是否接受变更， 并制定相应的实施计划和调整方案。
变更验证
对实施后的变更进行验证，确保其满 足预期效果，并对项目其他部分的影 响进行监控。
05
评估产品的用户界面设计，确保用户友好、 易于操作。
评审方法
专家评审
邀请行业专家对需求进行评估和审查。
用户评审
邀请目标用户参与评审，收集用户意 见和建议。
原型评审
制作产品原型进行评审，直观展示产 品功能和界面设计。
文档评审
对需求文档进行详细审查，确保文档 的完整性和准确性。
评审步骤
准备阶段
分析需求
对筛选出的需求进行深入分析， 明确需求的具体内容、实现方 式和预期效果。
评审和确认
组织相关人员进行评审，确保 需求分析的准确性和可行性， 并获得用户的最终确认。
04
需求规格说明
需求规格说明的内容
01
02
03
04
功能需求
描述软件或系统的所有功能， 包括用户直接使用或间接使用 ，以及系统内部处理的功能。
用于记录和整理用户提出的需求。
思维导图
帮助梳理需求的逻辑关系和层次结构。
需求管理工具
如Jira、Trello等，用于跟踪和管理需求状态。
整理需求的步骤
筛选需求
根据业务目标和实际情况，筛 选出有价值的需求。
整理需求
将分析后的需求整理成文档， 明确需求的优先级、责任人和 时间计划。
收集需求
通过访谈、问卷调查、会议等 方式收集用户需求。
01
02
变更评估
对变更申请进行评估，分析其对项目 进度、成本、质量等方面的影响。
03
变更决策
根据评估结果，决定是否接受变更， 并制定相应的实施计划和调整方案。
变更验证
对实施后的变更进行验证，确保其满 足预期效果，并对项目其他部分的影 响进行监控。
05
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
使关系模式更灵活，易于实现接近自然语言的查询 方式。
规范化 --- 将数据的逻辑结构归结为满足一定条件的二维表 （关系）。即： 1. 表格中每个信息项必须是一个不可分割的数据项，不可 是组项。 2. 表格中每一列 (列表示属性)中所有信息项必须是同一 类型，各列的名字 (属性名) 互异，列的次序任意。 3. 表格中各行 (行表示元组) 互不相同，行的次序任意。
状态变迁通常是由事件触发的，在这种情况下应
在表示状态转换的箭头线上标出触发转换的事件
表达式；如果在箭头线上未标明事件，则表示在
源状态的内部活动执行完之后自动触发转换。
电话系统的状态图
3.7 其他图形工具
层次方框图 Warnier图
IPO图
3.7.1
层次方框图
层次方框图用树形结构的一系列多层次的矩 形框描绘数据的层次结构。
第3章 需求分析
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 需求分析的任务 与用户沟通获取需求的方法 分析建模与规格说明 实体-联系图 数据规范化 状态转换图+有穷状态机 其他图形工具 验证软件需求 小结
需求分析的意义
软件需求的深入理解是软件开发工作获得成
功的前提条件，不论我们把设计和编码做得如何
面向数据流自顶向下求精
需求分析的结果
需求分析所要做的工作是深入描述软件的功 能和性能，确定软件设计的约束和软件同其 他系统元素的接口细节，定义软件的其他有 效性需求。
分析员通过需求分析，逐步细化软件分配， 描述软件要处理的信息域，并给软件开发提 供一种可转化为数据设计、结构设计和过程 设计的信息与功能表示。
4 运行环境规定 4.1 设备 4.R)
ER图 ---- 是用来建立数据模型的工具。
数据模型 ---- 它描述了从用户角度看到的数
据，反映了用户的现实环境，而且与在软件系
统中的实现方法无关。
数据模型中包含3种相互关联的信息：数据对象 （实体）、数据对象的属性及数据对象彼此间 相互连接的关系。
3.3.2 软件需求规格说明(SRS)
Software Requirement Specification 通常用自然语 言+模型，完整、准确、具体地描述系统的数据要求、
功能需求、性能需求、可靠性和可用性要求、出错处
理需求、接口需求、约束、逆向需求以及将来可能提
出的要求。
软件需求规格说明书，是需求分析阶段得出的
3.8
验证软件需求
验证软件需求的正确性，一般应从4个方面进行： (1) 一致性 所有需求必须是一致的，任何一条需求不能和其 他需求互相矛盾。 (2) 完整性 需求必须是完整的，规格说明书应该包括用户需要
的每一个功能或性能。
(3) 现实性 指定的需求应该是用现有的硬件技术和软件技术基 本上可以实现的。 (4) 有效性 必须证明需求是正确有效的，确实能解决用户面对 的问题。
3.3
分析建模与规格说明
分析建模 模型
就是为了理解事物而对事物做出的一种抽象， 是对事物的一种无歧义的书面描述。通常，由一组 图形符号和组织这些符号的规则组成。
建模方法 第一种是结构化分析 (Structured Analysis，SA)
具体的建模方法/表达方式有：
功能建模：数据流图（DFD/CFD） 数据建模：实体关系图（ERD） 基于行为的建模： Petri网、状态图
最主要的文档。
软件需求说明书的编写提示（GB856T—88） 1 引言 1.1 编写目的 1.2 背景 2 任务概述 2.1 目标 2.2 用户的特点
1.3 定义
1.4 参考资料
2.3 假定和约束
3 需求规定 3.1 对功能的规定 3.2 对性能的规定 3.2.1 精度 3.2.2 时间特性要求 3.2.3 灵活性 3.3 输人输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求
出色，不能真正满足用户需求的程序只会令用户
失望，给开发带来烦恼。
需求分析是软件定义时期的最后一个阶段， 它的基本任务不是确定系统怎样完成它的工 作，而是确定系统必须完成哪些工作，也就
是对目标系统提出完整、准确、清晰、具体
的要求。 在需求分析阶段结束之前，由系统分析 员写出软件需求规格说明书，以书面形式准 确地描述软件需求。
3.6
状态转换图
状态转换图(简称为状态图) 通过描绘系统的状态及引起系统状态转换的事件，来表示系 统的行为。此外，状态图还指明了作为特定事件的结果系统将做 哪些动作(例如，处理数据)。
状 态
状态是任何可以被观察到的系统行为模式，一个状态 代表系统的一种行为模式。一张状态图中只能有一个 初态，而终态则可以有0至多个。
3.9 小结
需求分析
需求分析是确定系统必须具有的功能、性能
两个阶段:需求获取阶段和需求规约阶段
成果:软件需求说明书 方法:结构化分析(SA) 结构化分析技术 自顶向下逐层分解 数据流图，数据词典，IPO图
3.9 小结
需求分析的任务: what functions + other requirements
快速建立软件原型
软件需求分析方法 任何信息处理系统的基本功能都是把输入数据 转变成需要的输出信息。 数据是需求分析的出发点。数据决定了需要的 处理和算法。 典型的面向过程的软件需求分析方法就是：结 构化分析方法(SA)，是面向数据流进行需求分析 的方法。
结构化分析
结构化分析方法是抽象模型的概念，按照软 件内部数据传递、变换的关系，自顶向下逐 层分解，直到找到满足功能要求的所有可实 现的软件为止。 抽象和分解是这个方法的主要手段，由于数 据传递与变换而形成的数据流，是这个方法 的主要依据。
IPO图
输入（I） 1.事务 2.库存清单 处理（P） 1. 更新库存清单主 文件 2. 判断零件的库存 数量是否少于库存 量临界 3. 向“处理定货” 加工输出需定货的 库存信息。 “更新库存清单”加工的IPO图 输出（O） 1.更新后的库存 清单 2.需定货的库存 信息
3.7.3
IPO图
左边的框中列出有关的 输入数据。 中间的框内列出主要的 处理，处理框中列出处 理的次序暗示了执行的 顺序。 在右边的框内列出产生 的输出数据。
事 件
事件是在某个特定时刻发生的事情，它是对引起
系统做动作或(和)从一个状态转换到另一个状态
的外界事件的抽象。
简而言之，事件就是引起系统做动作或(和)转换
状态的控制信息。
符 号
初态用实心圆表示，终态用一对同心圆(内圆为实心圆) 表示。
中间状态用圆角矩形表示，可以用两条水平横线把它分 成上、中、下3个部分。上面部分为状态的名称，这部 分是必须有的；中间部分为状态变量的名字和值，这部 分是可选的；下面部分是活动表，这部分也是可选的。
在分析软件需求和书写软件需求规格说明书 的过程中，分析员和用户都起着关键的、必 不可少的作用。
3.1 需求分析的具体任务
1 确定对系统的综合要求 2 分析系统的数据要求
3 导出系统的逻辑模型 4 修正系统开发计划
3.2 与用户沟通获取需求的方法
访谈 面向数据流自顶向下求精
简易的应用规格说明技术
举 例
零件编号 零件名称 定货数量 目前价格
字符 (8) 字符 (1,20) 整数 (1,5) 实数
定货报表 主要供应商
供应商编号
供应商名称
字符 (8)
字符(1,20) 字符(1,50) 字符(8) 字符(1,20) 字符(1,50)
供应商地址
供应商编号 次要供应商 供应商名称 供应商地址
定货报表的Warnier图
活动表的语法格式：事件名(参数表)/动作表达式
其中，“事件名”可以是任何事件的名称。在活
动表中经常使用下述3种标准事件：entry，exit
和do。
entry事件指定进入该状态的动作; exit事件指定退出该状态的动作; do事件则指定在该状态下的动作。
状态图中两个状态之间带箭头的连线称为状态转 换，箭头指明了转换方向。
实体-联系图的符号
ER图中包含了实体(即数据对象)、关系和属性等3 种基本成分。
通常用矩形框代表实体；
用连接相关实体的菱形框表示关系； 用椭圆形或圆角矩形表示实体(或关系)的属性； 并用直线把实体(或关系)与其属性连接起来。
举
教 师 属 性
例
对象
学 生 属 性 联 系 属 性
关系
图3.2 某校教学管理ER图
课 程 属 性
3.5
数据规范化
规范化的目的是：
消除数据冗余，即消除表格中数据的重复； 消除多义性，使关系中的属性含义清楚、单一； 使关系的“概念”单一化，让每个数据项只是一个 简单的数或字符串，而不是一个组项或重复组； 方便操作。使数据的插入、删除与修改操作可行并 方便；
供应商 编号
供应商 名称
供应商 地址
3.7.2
Warnier图
Warnier图也用树形结构描绘信息，但是这种图形 工具比层次方框图提供了更丰富的描绘手段。
用Warnier图可以表明信息的逻辑组织。
它可以指出一类信息或一个信息元素是重复出现的， 也可以表示特定信息在某一类信息中是有条件地出 现的。 重复和条件约束是说明软件处理过程的基础，所以 很容易把Warnier图转变成软件设计的工具。
一种改进的IPO图(也称为IPO表)
在需求分析阶段可以使用 IPO表简略地描述系统的 主要算法(即数据流图中 各个处理的基本算法)。 需求分析阶段，IPO表中 的许多附加信息暂时还不 具备，但在设计阶段可以 进一步补充修正这些图， 作为设计阶段的文档。
在需求分析阶段用IPO表 作为描述算法具有优点。