第2章 软件需求工程
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
件的图形符号构成。
第2章 软件需求工程
34 第 34 页
结构化需求分析与建模
面向状态转换的行为建模
现款
付款
付款信息
登录
办理取款手续的 DFD 图
2018/8/10
第2章 软件需求工程
25 第 25 页
结构化需求分析与建模
面向数据流的功能建模——DFD图的分解过程
DFD图可以用来表示任何抽象级别的系统功能，随着系统功 能和信息的逐渐增加，DFD图通过分解来逐层细化用户需求。 分解步骤如下： 确定系统的外部信息源、数据源或与外部系统的接口。 画出顶层（0层）DFD图。
保 管员 第 2 层
缺书登记表
教材销售子系统
外部 项
缺书登记表
F2
1.4
登记 缺书
F1 书号 单价 数量
采 购
进书通知
1.5
补售 教材
教材存量表
F1
补售 书单
暂缺书单
学 生
无效书单 购书单
1.1
审查 有效性
有效书单
1.2
开发票
发票
1.3
登记并开 领书单
领书单
学 生
各班用书表
F3
售书登记表
F4
2018/8/10
第2章 软件需求工程
31 第 31 页
结构化需求分析与建模
面向数据流的功能建模——DFD图分层注意事项
在逐层细化DFD图时，还要注意以下几点：
父图和子图的平衡关
系 DFD图的编号 平衡规则
第2章 软件需求工程
32 第 32 页
. 注意父图和子图的平衡
学生 发票
1.3.1 领书单 1.3.3 1.3.2
第 3 层
29 第 29 页
第2章 软件需求工程
教材存量表
购书单 领书单
学 生
1 销售
进书通知
2 采购
缺书单 进书通知
保 管员 第 2层
采购 子系统
缺书登记表
缺书登记表
F2
2.1
按书号汇 总缺书
2.2
按出版社统 计缺书
教材存量表
F1
待购教材表
F5
教材一览表
F6
缺书单
销 售
进书通知
2.3
修改教材库 存和待 购量
第一次精化：划分系统的子系统。
逐层求精：对各子系统进一步精化。
第2章 软件需求工程
26 第 26 页
分层的数据流图
F0
第 n 层
F12
F11 F13 F14 F15
第 n+1 层
F21 F22 F23 F25 F24
第 n+2 层
2018/8/10
27 第 27 页
第2章 软件需求工程
外部实体
好的方法，以便能达成共识。
个别会谈和小组会议 问卷调查 面向用例的场景分析
快速原型法
第2章 软件需求工程
16 第 16 页
结构化需求分析与建模
结构化分析概述
结构化分析的核心是数据。数据包括在分析、设计和实现 中涉及的概念、术语、属性等所有内容，并把这些内容定义在数 据字典中。围绕数据字典，完成功能模型、数据模型和行为模型 的结构化建模过程。
第2章
2.1 2.2 2.3 2.4 2.5
第2章 软件需求工程
软件需求工程
软件需求的基本概念 需求工程的过程 需求获取技术 结构化需求分析与建模 需求评审
1 第 1 页
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回 答“系统必须做什么?”这个问题。 需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必 须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以 书面形式准确地描述软件需求。 在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户 都起着关键的、必不可少的作用。只有用户才真正知道自己需要什么，但 是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需 求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求， 但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户 沟通获取用户对软件的需求。 需求分析和规格说明是一项十分艰巨复杂的工作。用户与分析员之间 需要沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏， 也可能存在二义性。因此，不仅在整个需求分析过程中应该采用行之有效 的通信技术，集中精力过细地工作，而且必须严格审查验证需求分析的结 果。
需求工程的过程
需求工程中的参与人员
第2章 软件需求工程
11 第 11 页
需求工程的过程
需求工程过程中的活动
可行性研究(可行性研究的目的不是解决问题，而是确定问题是否值得去解决。可行性研究分析过
程：首先，进一步分析和澄清问题定义;然后，分析员应该导出系统的逻辑模型;最后，探索若干种可 供选择的主要解法)
第2章 软件需求工程
6 第 6 页
3. 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可 以使用系统的程度。 4. 出错处理需求 这类需求说明系统对环境错误应该怎样响应。 例如，如果它接收到从另一个系统发来的违 反协议格式的消息，应该做什么 ? 注意，上 述这类错误并不是由该应用系统本身造成的。
在面向对象建模中，从数据对象里能抽象出更高层次的对象 吗？或者数据对象能组合吗？
在面向对象建模中，从数据对象里能细化出更具体的数据吗？
或者数据对象能分解吗？
第2章 软件需求工程
18 第 18 页
结构化需求分析与建模
面向数据的数据建模
数据对象（实体） 属性 关系和基数
第2章 软件需求工程
19 第 19 页
领书单
学 生
各班学生用书表
教材存量表
----学生购买教材的
逻辑模型
2018/8/10
21 第 21 页
第2章 软件需求工程
结构化需求分析与建模
面向数据流的功能建模
数据流图（Data Flowing Diagram，DFD）是结构化建模
中最流行的功能建模工具。DFD描述从数据输入、数据转换到数 据输出的全过程。能对DFD图分层，分层的DFD更进一步刻画了
建立目标系统逻辑模型的步骤
用户 调查
当前系统
具 体 模 型
逻辑 抽象
当前系统
逻辑模型
计算 机化
用户
系统模型
评审 修改
目标系统 正式模型
完善 细节
目标系统 初始模型
建立系统模型的工作流程
2018/8/10
第2章 软件需求工程
20 第 20 页
数据的 加工
无效书单
外部 实体
学 生
审查并 开发票
发票
开领 书单
第2章 软件需求工程
8 第 8 页
在某些情况下，“出错处理”指的是当应用系统 发现它自己犯下一个错误时所采取的行动。但是， 应该有选择地提出这类出错处理需求。我们的目 的是开发出正确的系统，而不是用无休止的出错 处理代码掩盖自己的错误。总之，对应用系统本 身错误的检测应该仅限于系统的关键部分，而且 应该尽可能少。 5. 接口需求 接口需求描述应用系统与它的环境通信的格式。 常见的接口需求有：用户接口需求；硬件接口需 求；软件接口需求；通信接口需求。
系统的功能分解。
外部系统
外部系统
输入数据
系统 目标 系统 目标
输入数据
输出数据
输出数据
外部系统
外部系统
用户
用户
输入数据
输入数据
输出数据
输出数据
用户
用户
第2章 软件需求工程
22 第 22 页
结构化需求分析与建模
面向数据流的功能建模——DFD图基本图形符号
或 数据加工，实现数据变换。其中要注明加 工的名字。
或
外部实体，即数据源或外部系统。其中要 注明数据源或外部系统的名字。
数据存储。其中注明数据存储名字或编号。 数据流，描述变换的加工数据及数据流方 向。箭头上部要注明数据流的名字。
或
第2章 软件需求工程
23 第 23 页
附加符号
第2章 软件需求工程
24 第 24 页
帐卡 检验不合格 存折
检验
储 户
1.3
开领书单
领书单 教材
(a) 父图
(a)子图
2018/8/10
第2章 软件需求工程
33 第 33 页
结构化需求分析与建模
面向状态转换的行为建模
状态转换图（ Status Transition Diagram，STD）通过 描述系统状态及引起状态转换的事件来表示系统行为。STD图
同时也反映了事件执行的行为。STD图主要由状态、转换和事
学 生
购书单 领书单
外部实体
教材 购销 系统
缺书单 进书通知
保 管员 第 1 层
教材存量 销售
进书通知
2 采购
缺书单
进书通知
保 管员
缺书登记表
F2 第 2 层
2018/8/10
第2章 软件需求工程
28 第 28 页
教材存量表
购书单 领书单
学 生
1 销售
进书通知
2 采购
缺书单 进书通知
第2章 软件需求工程
9 第 9 页
8. 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范 畴，但是据分析将来很可能会提出来的要求。这 样做的目的是，在设计过程中对系统将来可能的 扩充和修改预做准备，以便一旦确实需要时能比 较容易地进行这种扩充和修改。
第2章 软件需求工程
10 第 10 页
第2章 软件需求工程
2 第 2 页
软件需求的基本概念
需求分析的任务
确定系统将要实现的各项要求 数据分析 定义逻辑模型
适应需求变更
第2章 软件需求工程
3 第 3 页
软件需求的基本概念
需求分析的原则
软件人员要从用户角度考虑软件需求 以流程为主线 尽量重用软部件
划分需求的优先级
需求变更要及时反馈
第2章 软件需求工程
4 第 4 页
软件需求的基本概念
软件需求的内容
软件 需求
功能 需求
性能 需求
领域 需求
其它 需求
数据*
用户 操作
时 间
空 间
… …
安 全性
法律 需求
道德 需求
预期 需求
第2章 软件需求工程
5 第 5 页
1. 功能需求 这方面的需求指定系统必须提供的服务。 通过需求分析应该划分出系统必须完成的 所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或 容量约束，通常包括速度 ( 响应时间 ) 、信 息量速率、主存容量、磁盘容量、安全性 等方面的需求。
数据对象 说明
实体关系 模型 加工规格 说明
数据 字典
状态转换图
数据 流图
控制规格说明
第2章 软件需求工程
17 第 17 页
结构化需求分析与建模
面向数据的数据建模
数据建模需要回答以下几个问题： 系统中有哪些数据对象？ 数据对象具有哪些属性？ 数据对象间有什么关系？
数据对象分别处于系统的哪些功能或流程中？
需求获取
需求分析
需求验证
需求变更
需求管理
第2章 软件需求工程
13 第 13 页
需求工程的过程
需求确认的目的是为了：
⑴ 软件需求规格说明书正确描述系统功能和特征； ⑵ 通过可行性分析论证、需求获取和需求分析过程，能正
确得到用户需求；
⑶ 需求内容满足一致性、完整性、正确性、可修改性和可 验证性；
⑷ 需求为后续系统设计、实现、验收测试提供充分的准备。
进书通知
保 管员
第 3 层
2018/8/10
第2章 软件需求工程
30 第 30 页
结构化需求分析与建模
面向数据流的功能建模——DFD图命名
对DFD图中各部分元素的命名切忌用空洞的名词，这样不仅会给 系统设计带来歧义，而且难以确定数据的结构和组织方式。命名 时应遵循以下原则：
用名词或名词短语，避免使用空洞、无意义的词汇； 尽量使用需求描述中的已有词和领域术语； 命名出现困难时，考虑是否是数据流划分是否正确，并重 获需求； 顶层DFD图中的加工名就是软件项目的名字； 分层DFD图中，数据存储一般局限在某一层或少数几层中。
第2章 软件需求工程
14 第 14 页
需求工程的过程
需求工程的管理——贯穿整个需求工程的全过程。在需求工
程管理过程中存在两大难题：一是需求确认困难；二是需求不
断变更。
需求变更管理过程
申请 需求变更
变更描述
变更分析
变更修改
确认后的 变更确认 需求
第2章 软件需求工程
15 第 15 页
需求获取技术
需求获取是需求分析的前提，没有完整、正确的获取用户需求 ，就不能保证软件产品质量。因此，软件人员与用户交流需要
第2章 软件需求工程
7 第 7 页
6. 约束 设计约束或实现约束描述在设计或实现应用系统 时应遵守的限制条件。在需求分析阶段提出这类 需求，并不是要取代设计 ( 或实现 ) 过程，只是说 明用户或环境强加给项目的限制条件。常见的约 束有：精度；工具和语言约束；设计约束；应该 使用的标准；应该使用的硬件平台。 7. 逆向需求 逆向需求说明软件系统不应该做什么。理论上有 无限多个逆向需求，我们应该仅选取能澄清真实 需求且可消除可能发生的误解的那些逆向需求。
• • •
技术可行性研究：当前技术是否可行 操作可行性研究：系统在用户中是可操作的吗 法律可行性研究：技术、经济、操作可行性符合法律规范
• 经济可行性研究：系统产生的效益是否超过成本
需求获取 需求分析与建模
需求评审
第2章 软件需求工程
12 第 12 页
需求工程的过程
需求工程的迭代模型
基 线 可行性分析 技术/成本分析
第2章 软件需求工程
34 第 34 页
结构化需求分析与建模
面向状态转换的行为建模
现款
付款
付款信息
登录
办理取款手续的 DFD 图
2018/8/10
第2章 软件需求工程
25 第 25 页
结构化需求分析与建模
面向数据流的功能建模——DFD图的分解过程
DFD图可以用来表示任何抽象级别的系统功能，随着系统功 能和信息的逐渐增加，DFD图通过分解来逐层细化用户需求。 分解步骤如下： 确定系统的外部信息源、数据源或与外部系统的接口。 画出顶层（0层）DFD图。
保 管员 第 2 层
缺书登记表
教材销售子系统
外部 项
缺书登记表
F2
1.4
登记 缺书
F1 书号 单价 数量
采 购
进书通知
1.5
补售 教材
教材存量表
F1
补售 书单
暂缺书单
学 生
无效书单 购书单
1.1
审查 有效性
有效书单
1.2
开发票
发票
1.3
登记并开 领书单
领书单
学 生
各班用书表
F3
售书登记表
F4
2018/8/10
第2章 软件需求工程
31 第 31 页
结构化需求分析与建模
面向数据流的功能建模——DFD图分层注意事项
在逐层细化DFD图时，还要注意以下几点：
父图和子图的平衡关
系 DFD图的编号 平衡规则
第2章 软件需求工程
32 第 32 页
. 注意父图和子图的平衡
学生 发票
1.3.1 领书单 1.3.3 1.3.2
第 3 层
29 第 29 页
第2章 软件需求工程
教材存量表
购书单 领书单
学 生
1 销售
进书通知
2 采购
缺书单 进书通知
保 管员 第 2层
采购 子系统
缺书登记表
缺书登记表
F2
2.1
按书号汇 总缺书
2.2
按出版社统 计缺书
教材存量表
F1
待购教材表
F5
教材一览表
F6
缺书单
销 售
进书通知
2.3
修改教材库 存和待 购量
第一次精化：划分系统的子系统。
逐层求精：对各子系统进一步精化。
第2章 软件需求工程
26 第 26 页
分层的数据流图
F0
第 n 层
F12
F11 F13 F14 F15
第 n+1 层
F21 F22 F23 F25 F24
第 n+2 层
2018/8/10
27 第 27 页
第2章 软件需求工程
外部实体
好的方法，以便能达成共识。
个别会谈和小组会议 问卷调查 面向用例的场景分析
快速原型法
第2章 软件需求工程
16 第 16 页
结构化需求分析与建模
结构化分析概述
结构化分析的核心是数据。数据包括在分析、设计和实现 中涉及的概念、术语、属性等所有内容，并把这些内容定义在数 据字典中。围绕数据字典，完成功能模型、数据模型和行为模型 的结构化建模过程。
第2章
2.1 2.2 2.3 2.4 2.5
第2章 软件需求工程
软件需求工程
软件需求的基本概念 需求工程的过程 需求获取技术 结构化需求分析与建模 需求评审
1 第 1 页
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回 答“系统必须做什么?”这个问题。 需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必 须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以 书面形式准确地描述软件需求。 在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户 都起着关键的、必不可少的作用。只有用户才真正知道自己需要什么，但 是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需 求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求， 但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户 沟通获取用户对软件的需求。 需求分析和规格说明是一项十分艰巨复杂的工作。用户与分析员之间 需要沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏， 也可能存在二义性。因此，不仅在整个需求分析过程中应该采用行之有效 的通信技术，集中精力过细地工作，而且必须严格审查验证需求分析的结 果。
需求工程的过程
需求工程中的参与人员
第2章 软件需求工程
11 第 11 页
需求工程的过程
需求工程过程中的活动
可行性研究(可行性研究的目的不是解决问题，而是确定问题是否值得去解决。可行性研究分析过
程：首先，进一步分析和澄清问题定义;然后，分析员应该导出系统的逻辑模型;最后，探索若干种可 供选择的主要解法)
第2章 软件需求工程
6 第 6 页
3. 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可 以使用系统的程度。 4. 出错处理需求 这类需求说明系统对环境错误应该怎样响应。 例如，如果它接收到从另一个系统发来的违 反协议格式的消息，应该做什么 ? 注意，上 述这类错误并不是由该应用系统本身造成的。
在面向对象建模中，从数据对象里能抽象出更高层次的对象 吗？或者数据对象能组合吗？
在面向对象建模中，从数据对象里能细化出更具体的数据吗？
或者数据对象能分解吗？
第2章 软件需求工程
18 第 18 页
结构化需求分析与建模
面向数据的数据建模
数据对象（实体） 属性 关系和基数
第2章 软件需求工程
19 第 19 页
领书单
学 生
各班学生用书表
教材存量表
----学生购买教材的
逻辑模型
2018/8/10
21 第 21 页
第2章 软件需求工程
结构化需求分析与建模
面向数据流的功能建模
数据流图（Data Flowing Diagram，DFD）是结构化建模
中最流行的功能建模工具。DFD描述从数据输入、数据转换到数 据输出的全过程。能对DFD图分层，分层的DFD更进一步刻画了
建立目标系统逻辑模型的步骤
用户 调查
当前系统
具 体 模 型
逻辑 抽象
当前系统
逻辑模型
计算 机化
用户
系统模型
评审 修改
目标系统 正式模型
完善 细节
目标系统 初始模型
建立系统模型的工作流程
2018/8/10
第2章 软件需求工程
20 第 20 页
数据的 加工
无效书单
外部 实体
学 生
审查并 开发票
发票
开领 书单
第2章 软件需求工程
8 第 8 页
在某些情况下，“出错处理”指的是当应用系统 发现它自己犯下一个错误时所采取的行动。但是， 应该有选择地提出这类出错处理需求。我们的目 的是开发出正确的系统，而不是用无休止的出错 处理代码掩盖自己的错误。总之，对应用系统本 身错误的检测应该仅限于系统的关键部分，而且 应该尽可能少。 5. 接口需求 接口需求描述应用系统与它的环境通信的格式。 常见的接口需求有：用户接口需求；硬件接口需 求；软件接口需求；通信接口需求。
系统的功能分解。
外部系统
外部系统
输入数据
系统 目标 系统 目标
输入数据
输出数据
输出数据
外部系统
外部系统
用户
用户
输入数据
输入数据
输出数据
输出数据
用户
用户
第2章 软件需求工程
22 第 22 页
结构化需求分析与建模
面向数据流的功能建模——DFD图基本图形符号
或 数据加工，实现数据变换。其中要注明加 工的名字。
或
外部实体，即数据源或外部系统。其中要 注明数据源或外部系统的名字。
数据存储。其中注明数据存储名字或编号。 数据流，描述变换的加工数据及数据流方 向。箭头上部要注明数据流的名字。
或
第2章 软件需求工程
23 第 23 页
附加符号
第2章 软件需求工程
24 第 24 页
帐卡 检验不合格 存折
检验
储 户
1.3
开领书单
领书单 教材
(a) 父图
(a)子图
2018/8/10
第2章 软件需求工程
33 第 33 页
结构化需求分析与建模
面向状态转换的行为建模
状态转换图（ Status Transition Diagram，STD）通过 描述系统状态及引起状态转换的事件来表示系统行为。STD图
同时也反映了事件执行的行为。STD图主要由状态、转换和事
学 生
购书单 领书单
外部实体
教材 购销 系统
缺书单 进书通知
保 管员 第 1 层
教材存量 销售
进书通知
2 采购
缺书单
进书通知
保 管员
缺书登记表
F2 第 2 层
2018/8/10
第2章 软件需求工程
28 第 28 页
教材存量表
购书单 领书单
学 生
1 销售
进书通知
2 采购
缺书单 进书通知
第2章 软件需求工程
9 第 9 页
8. 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范 畴，但是据分析将来很可能会提出来的要求。这 样做的目的是，在设计过程中对系统将来可能的 扩充和修改预做准备，以便一旦确实需要时能比 较容易地进行这种扩充和修改。
第2章 软件需求工程
10 第 10 页
第2章 软件需求工程
2 第 2 页
软件需求的基本概念
需求分析的任务
确定系统将要实现的各项要求 数据分析 定义逻辑模型
适应需求变更
第2章 软件需求工程
3 第 3 页
软件需求的基本概念
需求分析的原则
软件人员要从用户角度考虑软件需求 以流程为主线 尽量重用软部件
划分需求的优先级
需求变更要及时反馈
第2章 软件需求工程
4 第 4 页
软件需求的基本概念
软件需求的内容
软件 需求
功能 需求
性能 需求
领域 需求
其它 需求
数据*
用户 操作
时 间
空 间
… …
安 全性
法律 需求
道德 需求
预期 需求
第2章 软件需求工程
5 第 5 页
1. 功能需求 这方面的需求指定系统必须提供的服务。 通过需求分析应该划分出系统必须完成的 所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或 容量约束，通常包括速度 ( 响应时间 ) 、信 息量速率、主存容量、磁盘容量、安全性 等方面的需求。
数据对象 说明
实体关系 模型 加工规格 说明
数据 字典
状态转换图
数据 流图
控制规格说明
第2章 软件需求工程
17 第 17 页
结构化需求分析与建模
面向数据的数据建模
数据建模需要回答以下几个问题： 系统中有哪些数据对象？ 数据对象具有哪些属性？ 数据对象间有什么关系？
数据对象分别处于系统的哪些功能或流程中？
需求获取
需求分析
需求验证
需求变更
需求管理
第2章 软件需求工程
13 第 13 页
需求工程的过程
需求确认的目的是为了：
⑴ 软件需求规格说明书正确描述系统功能和特征； ⑵ 通过可行性分析论证、需求获取和需求分析过程，能正
确得到用户需求；
⑶ 需求内容满足一致性、完整性、正确性、可修改性和可 验证性；
⑷ 需求为后续系统设计、实现、验收测试提供充分的准备。
进书通知
保 管员
第 3 层
2018/8/10
第2章 软件需求工程
30 第 30 页
结构化需求分析与建模
面向数据流的功能建模——DFD图命名
对DFD图中各部分元素的命名切忌用空洞的名词，这样不仅会给 系统设计带来歧义，而且难以确定数据的结构和组织方式。命名 时应遵循以下原则：
用名词或名词短语，避免使用空洞、无意义的词汇； 尽量使用需求描述中的已有词和领域术语； 命名出现困难时，考虑是否是数据流划分是否正确，并重 获需求； 顶层DFD图中的加工名就是软件项目的名字； 分层DFD图中，数据存储一般局限在某一层或少数几层中。
第2章 软件需求工程
14 第 14 页
需求工程的过程
需求工程的管理——贯穿整个需求工程的全过程。在需求工
程管理过程中存在两大难题：一是需求确认困难；二是需求不
断变更。
需求变更管理过程
申请 需求变更
变更描述
变更分析
变更修改
确认后的 变更确认 需求
第2章 软件需求工程
15 第 15 页
需求获取技术
需求获取是需求分析的前提，没有完整、正确的获取用户需求 ，就不能保证软件产品质量。因此，软件人员与用户交流需要
第2章 软件需求工程
7 第 7 页
6. 约束 设计约束或实现约束描述在设计或实现应用系统 时应遵守的限制条件。在需求分析阶段提出这类 需求，并不是要取代设计 ( 或实现 ) 过程，只是说 明用户或环境强加给项目的限制条件。常见的约 束有：精度；工具和语言约束；设计约束；应该 使用的标准；应该使用的硬件平台。 7. 逆向需求 逆向需求说明软件系统不应该做什么。理论上有 无限多个逆向需求，我们应该仅选取能澄清真实 需求且可消除可能发生的误解的那些逆向需求。
• • •
技术可行性研究：当前技术是否可行 操作可行性研究：系统在用户中是可操作的吗 法律可行性研究：技术、经济、操作可行性符合法律规范
• 经济可行性研究：系统产生的效益是否超过成本
需求获取 需求分析与建模
需求评审
第2章 软件需求工程
12 第 12 页
需求工程的过程
需求工程的迭代模型
基 线 可行性分析 技术/成本分析