SW06第六章-需求工程过程
合集下载
需求工程的过程模型及其裁剪方法实例
需求工程的过程模型及其裁剪方法实例需求工程是软件工程中极为重要的一个环节，它直接关系到软件最终的质量和用户满意度。
需求工程的过程模型是指在软件开发中，对需求进行收集、分析、规格说明、验证和管理等一系列过程的组合。
不同的项目需要采用不同的需求工程过程模型，以满足项目的特定需求和情况。
本文将探讨需求工程的过程模型及其裁剪方法实例，以便更好地理解和应用需求工程的相关知识。
1. 瀑布模型瀑布模型是需求工程中最常见的过程模型之一，它将需求工程划分为需求获取、需求分析、需求规格、需求验证和需求管理等阶段，各阶段之间存在严格的顺序关系。
瀑布模型适用于需求变动非常小或可预测的项目，但在实际应用中往往难以应对需求变更频繁的情况。
2. 增量模型增量模型是一种逐步完善系统的过程模型，它将系统划分为多个相互独立的子系统，然后逐步完成各个子系统的开发和集成。
增量模型适用于大型复杂项目，能够缩短项目的交付周期，同时也更容易应对需求的变更。
3. 螺旋模型螺旋模型将软件开发过程划分为多个循环，每个循环都包括需求分析、风险分析、软件设计、编码、测试和评审等过程。
螺旋模型适用于对项目风险较高或需求不够明确的情况，通过不断的迭代和风险管理，可以最大程度地降低项目失败的风险。
4. 敏捷模型敏捷模型是一种注重灵活性和响应变化的软件开发方法，它强调团队协作、快速交付和持续反馈。
敏捷模型适用于需求变动频繁或需求不够明确的项目，通过不断地反馈和迭代，可以更好地满足用户的需求。
需求工程的过程模型裁剪方法实例在实际项目中，很少有一个过程模型可以直接拿来使用，因为每个项目都有自己的特点和需求。
需要对现有的过程模型进行裁剪，以满足项目的具体需求。
裁剪的方法主要包括以下几个步骤：1. 识别需求首先需要对项目的需求进行全面的识别和分析，包括项目的特点、约束条件、风险因素等。
只有全面理解了项目的需求，才能更好地选择和裁剪合适的过程模型。
2. 选择原型根据项目的需求和特点，选择一个适合的原型过程模型作为基础模型。
《需求工程》课件
06 需求变更处理
需求变更请求
提出变更
当项目干系人提出需求变更时，应详细记录变更请求的 内容、原因和影响。
确认变更
对变更请求进行评估，确认是否需要进行变更，并通知 相关干系人。
变更影响分析
影响范围
分析变更对项目范围、进度、成本和质量等方面的影响。
资源需求
评估实施变更所需的资源，包括人力、物力和财力等。
需求工程
目录
• 需求工程概述 • 需求获取 • 需求分析 • 需求规格说明 • 需求验证与确认 • 需求变更处理 • 需求工程工具与技术
01 需求工程概述
定义与特点
定义
需求工程是一种系统的方法，用于确 定、捕获和验证系统或产品需求，以 满足用户、客户和其他利益相关者的 期望和要求。
特点
需求工程强调与利益相关者的沟通、 需求分析和验证，以确保需求的正确 性、完整性和一致性。它还涉及到需 求管理，以确保需求在整个产品开发 生命周期中得到满足。
需求工程的重要性
A
减少开发时间和成本
准确的需求可以避免开发过程中的返工和变更 ，从而缩短开发时间和降低成本。
提高产品质量
明确和经过验证的需求有助于提高产品的 质量和性能，满足用户和客户的需求。
B
C
增强用户满意度
通过了解和满足用户需求，可以提高用户对 产品的满意度和忠诚度。
降低维护成本
明确的需求有助于降低产品维护和升级的成 本，因为变更可以在开发阶段进行充分的考 虑和规划。
分析文档中的需求
对审查的文档进行分析，提取其中的需求信 息，以便更好地理解项目的需求背景和要求
。
03
需求分析
需求分类与优先级排序
需求分类是将收集到的原始需求按照一定的标准进行分类的过程，优先级排序则 是根据需求的紧急程度、重要性等因素对需求进行排序。
需求工程资料
需求工程
需求工程是软件工程中至关重要的一个阶段，它涉及到软件开发的前期阶段，是整个软件开发过程中的基础。
在需求工程中，我们需要明确和分析用户的需求，将用户的需求转化为可用的软件规格说明，以指导后续的软件设计和开发工作。
需求工程包含需求获取、需求分析、需求规格说明等阶段，每个阶段都至关重要。
需求获取
需求获取是需求工程的第一步，也是最关键的一步。
在这个阶段，我们需要与用户、客户和利益相关者沟通，了解他们的需求和期望。
可以通过面对面的会议、问卷调查、访谈等方式获取用户需求，确保对需求的全面理解和收集。
只有充分了解用户需求，才能为软件开发提供正确的方向和依据。
需求分析
需求分析是将获取到的需求进行分析和整理，确保需求的一致性、完整性和可行性。
在这个阶段，我们需要对需求进行验证和确认，识别需求中的隐含需求和冲突需求，消除需求的不一致之处。
需求分析的结果是需求规格说明书，其中包含了用户需求的详细描述和开发团队对需求的理解。
需求规格说明
需求规格说明是对需求进行形式化描述的过程，将用户需求转化为具体的软件规格说明。
在这个阶段，我们需要使用各种工具和技术，如用例图、数据流图、状态图等，将用户需求进行详细的分解和描述。
通过需求规格说明书，开发团队可以清晰地了解软件系统的功能、性能、界面等方面的要求，从而指导后续的软件设计和开发工作。
需求工程是软件开发过程中不可或缺的一个环节，有效的需求工程可以帮助开发团队更好地理解用户需求，减少软件开发过程中的风险和错误，提高软件开发的成功率和质量。
因此，对于任何软件开发项目来说，需求工程都是非常重要的。
软件工程课件07需求工程过程34243
有两种面谈方式：
限定式面谈——回答一组预先拟定好的问题。 开放式面谈——没有预定的议程和议题和利益相关
人交谈。
面谈实践
通常是限定式与开放式面谈相结合。 面谈有利于收集到利益相关人的观点以及有关
他们如何与系统互动的信息。 面谈不利于对领域需求的理解
需求工程师不理解特定领域的术语； 人们认为一些领域知识太普通了，以至于不值得去
一个可行性研究决定提出的系统是否值得去做。 研究焦点在于检查
该系统是否对机构目标有贡献； 在既定预算和现有技术的情况下，是否能完
成该系统的工程； 该系统是否能与其它正在使用的系统进行集
成。
可行性研究的实现
实现手段依赖于信息评估（需要什么），信息 收集和报告编写
对机构里的人来说，问题是 如果系统实现不了怎么办? 现有流程的问题是什么? 提出的系统会有多大的帮助? 集成将会遇到什么问题? 需要新的技术吗? 要具备什么技能? 对提出的系统提供支持的必要工具有那些?
观点识别
识别观点要采用：
系统服务的提供者和接受者； 与被识别的系统直接互动的系统； 规则和标准； 业务和非功能需求的源头； 开发和维护系统的工程师； 市场和其它业务观点。
LIBSYS观点的层次结构
Indirect
All VPs Interactor
Dom a in
Library m a na ge r
加入进来，业务环境也发生改变。
需求螺旋
Re quire m e nts classification and
organisation
Re quire m e nts discovery
Re quire m e nts prioritization and
negotiation
限定式面谈——回答一组预先拟定好的问题。 开放式面谈——没有预定的议程和议题和利益相关
人交谈。
面谈实践
通常是限定式与开放式面谈相结合。 面谈有利于收集到利益相关人的观点以及有关
他们如何与系统互动的信息。 面谈不利于对领域需求的理解
需求工程师不理解特定领域的术语； 人们认为一些领域知识太普通了，以至于不值得去
一个可行性研究决定提出的系统是否值得去做。 研究焦点在于检查
该系统是否对机构目标有贡献； 在既定预算和现有技术的情况下，是否能完
成该系统的工程； 该系统是否能与其它正在使用的系统进行集
成。
可行性研究的实现
实现手段依赖于信息评估（需要什么），信息 收集和报告编写
对机构里的人来说，问题是 如果系统实现不了怎么办? 现有流程的问题是什么? 提出的系统会有多大的帮助? 集成将会遇到什么问题? 需要新的技术吗? 要具备什么技能? 对提出的系统提供支持的必要工具有那些?
观点识别
识别观点要采用：
系统服务的提供者和接受者； 与被识别的系统直接互动的系统； 规则和标准； 业务和非功能需求的源头； 开发和维护系统的工程师； 市场和其它业务观点。
LIBSYS观点的层次结构
Indirect
All VPs Interactor
Dom a in
Library m a na ge r
加入进来，业务环境也发生改变。
需求螺旋
Re quire m e nts classification and
organisation
Re quire m e nts discovery
Re quire m e nts prioritization and
negotiation
06第六章线性预测分析
上面我们介绍了预测阶数 P 的选 择，在选定了预测阶数 p = P 的情 况下， 况下，我们现在介绍最佳预测阶 求法。 数 a i和G求法。 求法
四.线性预测方程的推导 定义短时预测均方误差： 定义短时预测均方误差：
ˆ E n = ∑ e 2 ( n) = ∑ [ s( n) − s ( n)]2
随机噪声 发生器
语音产生模型里，辐射、 注：语音产生模型里，辐射、声道以及声门激励的全 部效应简化为一个时变数字滤波器等效。 部效应简化为一个时变数字滤波器等效。 系统函数
S( z ) H ( z) = = U ( z) G 1 − ∑ ai z −i
i =1 p p
差分方程：s (n) = G * u (n) + ∑ ai s (n − i )
1 − az
−1
1 = 1 + az −1 + a 2 z − 2 + a 3 z − 3 L
如果分母多项式收敛足够快，只取少数几项。 如果分母多项式收敛足够快，只取少数几项。
6.3 语音信号的线性预测分析
1. 语音信号模型
基音 周期 冲激串 发生器 浊音/清 音开关 u(n) G 声道参数 时变数字 滤波器 s(n)
线性预测模型采用全极点模型的原因： 线性预测模型采用全极点模型的原因： 全极点模型容易计算，对全极点模型做参数估计是对线性方程 全极点模型容易计算，对全极点模型做参数估计是对线性方程 的求解过程，而含有有限零点则是解非线性方程 解非线性方程。 组的求解过程，而含有有限零点则是解非线性方程。
如果不考虑鼻音和摩擦音，那么语音的声道传递函 如果不考虑鼻音和摩擦音， 数就是一个全极点模型。 数就是一个全极点模型。 对于声道函数既有零点又有极点的， 对于声道函数既有零点又有极点的，可以用全极 点模型来近似表示极零点模型。 点模型来近似表示极零点模型。
需求工程过程PPT课件
2.2.2 分层的数据流图
一、数据流图的图符 四种基本图形符号：
T
A
B
*
C
T
A
B
*
C
T
A
B
+
C
T
A
B
+
C
T
A
B
C
+
T
A
B
C
+
* 与
+ 或
互斥
+
“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。
一批 订单
出版社档案文件
订货存根文件
画图步骤 ： 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例1：图书预定系统（顶层DFD图）
2.2.2 数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。
数据存储
数据源点 或终点
加 工
加工名
数据流
数据流名
文件名
实体名
箭 头
圆或椭圆
单或双杠
矩形框
还有一些辅助的图例:
2.2.3 画分层DFD图的方法
顶层图说明了系统的边界,即系统的输入和输出数据流，顶层图只有一张。底层图由一些不能再分解的加工组成，这些加工都已足够简单，称为基本加工。在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步分解。 画各层DFD图时，“由外向内”。
一、数据流图的图符 四种基本图形符号：
T
A
B
*
C
T
A
B
*
C
T
A
B
+
C
T
A
B
+
C
T
A
B
C
+
T
A
B
C
+
* 与
+ 或
互斥
+
“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。
一批 订单
出版社档案文件
订货存根文件
画图步骤 ： 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例1：图书预定系统（顶层DFD图）
2.2.2 数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。
数据存储
数据源点 或终点
加 工
加工名
数据流
数据流名
文件名
实体名
箭 头
圆或椭圆
单或双杠
矩形框
还有一些辅助的图例:
2.2.3 画分层DFD图的方法
顶层图说明了系统的边界,即系统的输入和输出数据流，顶层图只有一张。底层图由一些不能再分解的加工组成，这些加工都已足够简单，称为基本加工。在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步分解。 画各层DFD图时，“由外向内”。
第3章.需求工程过程
思考题
1. 除了需求开发的四个活动和需求管理活动之外，需求工 程当中还有没有需要执行的活动？如果有的话，它们是 哪些活动？给出你的理由。 2. 需求开发过程具有迭代特性，但是不是所有项目的需求 开发过程都必须是迭代完成的？如果不是，请给出举例 和理由。 3. 需求开发的迭代特性与软件开发过程的迭代式开发有什 么关系？它们之间会互相影响吗？如果会，那么有哪些 影响？ 4. 需求工程细节知识的实践性对不同项目的需求开发过程 的差异性有没有影响？如果有，请说明影响是什么。如 果没有，请说明是哪些因素产生了不同项目的需求开发 过程的差异性。
涉众
硬
数
据
需求获取 需求分析 需求规格说明 需求验证
需求开发
需求基线 需求跟踪信息
需求管理
当前基线
修订的基 线
项控制
项目活动
系统开发
第2节
需求工程过程的活动
2.1 需求获取 –需求获取是从人、文档或者环境中获取需求的过程 –需求工程师必须要利用各种方法和技术来“发现”需 求 –需求获取和需求分析是交织在一起的 2.2 需求获取子活动 –收集背景资料 –定义项目前景和范围 –选择信息的来源 –选择获取方法，执行获取 –记录获取结果
本章小结
• 需求工程有着属于它自己的生命周期模型，存在着针 对需求开发的需求工程过程 • 需求工程过程拥有一些常见的需求工程活动：需求获 取、需求分析、需求规格说明、需求验证和需求管理 • 需求开发活动是互相交织、并发、迭代和递增 的 • 需求工程过程的成功执行需要应用很多有效实践方法
• 文档内每条需求都正确、准确的反映了用户的意图； • 文档记录的需求集在整体上具有完整性和一致性； • 文档的组织方式和需求的书写方式具有可读性和可修 改性
SW06
定义各个任务
定义任务的工作主要包括：它是什么任务、如何协调工作及如 何通信。 (1) 它是什么任务──为任务命名，并简要说明这个任务。 (2) 如何协调工作──定义各个任务如何协调工作。指出它是 事件驱动还是时钟驱动。 (3) 如何通信──定义各个任务之间如何通信。任务从哪里取值， 结果送往何方。 (4) 一个模版──任务的定义如下： – Name (任务名) – Description (描述) – Priority (优先级) – Services included (包含的操作)、 – Communication Via (经由谁通信)。
4. 设计详细的交互
用户界面设计有若干原则，包括：
– 一致性：采用一致的术语、一致的步 骤和一致的活动。
– 操作步骤少：减少敲键和鼠标点 取的次数，减少完成某件事所需的下拉菜 单的距离。
– 不要“哑播放”：每当用户等待 系统完成一个活动时，要给出一些反馈信 息。
– Undo：在操作出现错误时，要恢复或
1. 用户分类
按技能层次分类： 外行／初学者／熟练者／专家 按组织层次分类： 行政人员／管理人员／专业技术人员／其 它办事员 按职能分类： 顾客／职员
2. 描述人及其任务的脚 本
对以上定义的每一类用户，列出对以 下问题做出的考虑：什么人、目的、 特点、成功的关键因素、熟练程度以 及任务脚本。
• 最初的第一级抽象可能描述为：
Rearrange L in nondecreasing order
在OOATOOLTM 中一个例子 什么人──分析员 目的──要求一个工具来辅助分析工作
(摆脱繁重的画图和检查图的工作)。
特点──年龄：42岁；教育水平：大学；
限制：不要微型打印，小于9个点的打印太小
《需求工程》课件
《需求工程》PPT课件
需求工程是一项关键的软件工程领域，旨在有效地获取、分析和管理软件系 统的需求。本课件将介绍需求工程的核心概念、方法和实践，并探讨其在软 件开发和项目管理中的重要性。
什么是需求工程？
需求工程是一个跨学科的领域，涉及到识别、分析、规范和验证软件系统的需求。它旨在确保开发的软件满足 用户和利益相关者的期望和需求。
2 非功能需求
描述系统应具备的性能、可靠性、安全性等方面的特性。
3 用户故事
以用户的视角叙述需求，具有用户愿望和期望的特点。
用户需求的获取方法
访谈
与用户和利益相关者进行面对面 的谈话和讨论，获取需求信息。
调查问卷
通过编制问卷并广泛分发，获取 大量用户的意见和需求。
情境分析观察用户在实际环源自中使用系统 的行为和需求。需求分析的步骤和技术
1
需求分类
将需求按照功能、优先级等进行分类和组织。
2
需求建模
使用UML、用户故事地图等工具，建立需求模型和关系。
3
需求验证
借助原型、模拟和验证工具，检查需求的正确性和可行性。
需求规格说明的编写
需求规格说明是一份详尽而准确的文档，描述了软件系统的功能、性能和约 束条件，为开发人员提供指导和参考。
需求工程的发展历程
1
1970s
早期需求工程方法的诞生，主要关注需求获取和需求分析的基本概念。
2
1980s
需求工程方法逐渐成熟，开始关注需求规格说明和需求验证的方法和工具。
3
1990s
需求工程的方法论得到进一步发展，加强了与软件开发和项目管理的整合。
需求工程的流程与方法
需求获取
通过与利益相关者沟通和访谈，收集并理解用 户的需求。
需求工程是一项关键的软件工程领域，旨在有效地获取、分析和管理软件系 统的需求。本课件将介绍需求工程的核心概念、方法和实践，并探讨其在软 件开发和项目管理中的重要性。
什么是需求工程？
需求工程是一个跨学科的领域，涉及到识别、分析、规范和验证软件系统的需求。它旨在确保开发的软件满足 用户和利益相关者的期望和需求。
2 非功能需求
描述系统应具备的性能、可靠性、安全性等方面的特性。
3 用户故事
以用户的视角叙述需求，具有用户愿望和期望的特点。
用户需求的获取方法
访谈
与用户和利益相关者进行面对面 的谈话和讨论，获取需求信息。
调查问卷
通过编制问卷并广泛分发，获取 大量用户的意见和需求。
情境分析观察用户在实际环源自中使用系统 的行为和需求。需求分析的步骤和技术
1
需求分类
将需求按照功能、优先级等进行分类和组织。
2
需求建模
使用UML、用户故事地图等工具，建立需求模型和关系。
3
需求验证
借助原型、模拟和验证工具，检查需求的正确性和可行性。
需求规格说明的编写
需求规格说明是一份详尽而准确的文档，描述了软件系统的功能、性能和约 束条件，为开发人员提供指导和参考。
需求工程的发展历程
1
1970s
早期需求工程方法的诞生，主要关注需求获取和需求分析的基本概念。
2
1980s
需求工程方法逐渐成熟，开始关注需求规格说明和需求验证的方法和工具。
3
1990s
需求工程的方法论得到进一步发展，加强了与软件开发和项目管理的整合。
需求工程的流程与方法
需求获取
通过与利益相关者沟通和访谈，收集并理解用 户的需求。
需求工程过程
需求工程过程
迭代模型与瀑布模型的差别
需求开发过程
需求开发是一个迭代的过 程
获取
分析
重新评估 编写规约
证实
重写 更正并减小误差
验证
需求工程的推荐方法
列出了近50种方法，分别属于7个类型，它们可以帮助大 部分项目开发团队更好地完成他们的需求工作。
知识
需求管理
项目管理
l 观察用户执行工作的过程
2) 以培需求训为需依据求编分写测析试员用例
3) 为每项需求注上标号 制定一种惯例来为S R S中的每项需求 提供一个独立的可识别的标号或记号。这种惯例应当很健全， 允许增加、删除和修改。作了标号的需求使得需求能被跟踪， 记录需求变更并为需求状态和变更活动建立度量。
4) 记录业务规范 业务规范是指关于产品的操作原则，比如谁能 在什么情况下采取什么动作。将这些编写成S R S中的一个独 立部分，或一独立的业务规范文档。某些业务规范将引出相应 的功能需求；当然这些需求也应能追溯相应业务规范。
范 定义质量属
为了检帮助查开问发人题员报对应告用领域有一个基本的理解，度可以安排一个研讨课程，内容是性客户的业务活动、术语和产品的目标。 l 采用重S用RS需模板求
知识技能
▪ 开发者也应该了解产品应用领域中的基本概念和术语。 ▪ 培训需求分析员
所有将要成为分析员的团队成员都应该接受需求工程方面的基本培 训。
定义。在需求阶段，数据字典至少应定义客户数据项
以确保客户与开发小组是使用一致的定义和术语。分 析和设计工具通常包括数据字典组件。
7) 使用质量功能调配 质量功能调配( Q F D）是一种 高级系统技术，它将产品特性、属性与对客户的重要 性联系起来。该技术提供了一种分析方法以明确那些 是客户最为关注的特性。
迭代模型与瀑布模型的差别
需求开发过程
需求开发是一个迭代的过 程
获取
分析
重新评估 编写规约
证实
重写 更正并减小误差
验证
需求工程的推荐方法
列出了近50种方法，分别属于7个类型，它们可以帮助大 部分项目开发团队更好地完成他们的需求工作。
知识
需求管理
项目管理
l 观察用户执行工作的过程
2) 以培需求训为需依据求编分写测析试员用例
3) 为每项需求注上标号 制定一种惯例来为S R S中的每项需求 提供一个独立的可识别的标号或记号。这种惯例应当很健全， 允许增加、删除和修改。作了标号的需求使得需求能被跟踪， 记录需求变更并为需求状态和变更活动建立度量。
4) 记录业务规范 业务规范是指关于产品的操作原则，比如谁能 在什么情况下采取什么动作。将这些编写成S R S中的一个独 立部分，或一独立的业务规范文档。某些业务规范将引出相应 的功能需求；当然这些需求也应能追溯相应业务规范。
范 定义质量属
为了检帮助查开问发人题员报对应告用领域有一个基本的理解，度可以安排一个研讨课程，内容是性客户的业务活动、术语和产品的目标。 l 采用重S用RS需模板求
知识技能
▪ 开发者也应该了解产品应用领域中的基本概念和术语。 ▪ 培训需求分析员
所有将要成为分析员的团队成员都应该接受需求工程方面的基本培 训。
定义。在需求阶段，数据字典至少应定义客户数据项
以确保客户与开发小组是使用一致的定义和术语。分 析和设计工具通常包括数据字典组件。
7) 使用质量功能调配 质量功能调配( Q F D）是一种 高级系统技术，它将产品特性、属性与对客户的重要 性联系起来。该技术提供了一种分析方法以明确那些 是客户最为关注的特性。
需求工程的六个步骤
需求工程的六个步骤《需求工程的六个步骤》嘿，你知道吗？在很多事情背后啊，都有着一套科学的方法，就像需求工程。
这需求工程啊，就像是一场精心策划的旅程，有着六个超重要的步骤呢。
第一步，需求获取。
这就好比我们要去旅行，得先知道目的地有啥好玩的，好吃的一样。
在需求工程里，我们得去了解用户到底想要啥。
这可不是一件简单的事儿啊，你得跟用户聊天，观察他们的行为，收集各种各样的信息。
有时候，用户可能自己都不太清楚自己想要啥，就像你去一个陌生的地方，只知道大概方向，具体的却很模糊。
这时候，我们就得像个侦探一样，从他们的只言片语，从他们做事的习惯里去挖掘真正的需求。
这一步要是没做好，后面可就全乱套啦！你想啊，如果连要去哪儿都没搞清楚，这旅行还咋进行下去呢？第二步，需求分析。
好啦，我们获取了一堆需求，现在就像是拎着一堆旅行纪念品一样，得好好整理整理了。
这个时候，我们要把那些需求分类，找出哪些是重要的，哪些是次要的。
就像我们整理旅行收获的时候，把最有意义的东西放在显眼的地方，把不太重要的放一边。
这一步要是做仔细了，就能发现需求之间的联系和矛盾。
要是不做呢？那可就乱成一锅粥了，就像你把旅行纪念品胡乱塞在箱子里，到时候想用的时候都找不到。
第三步，需求规格说明。
这一步啊，就像是把我们的旅行计划写在纸上。
我们要把需求准确地描述出来，用清晰的语言告诉大家这个需求是啥样的。
这就好比我们写旅行攻略，要写清楚哪里好玩，怎么去，需要注意什么。
如果这个说明写得模棱两可，那可就糟糕了。
就像你给朋友的旅行攻略写得含糊不清，朋友到了目的地肯定会埋怨你。
这需求规格说明可是给后面的开发人员或者执行者看的，可不能马虎啊。
第四步，需求验证。
哇，到这一步就像是旅行前的最后检查一样。
我们得找用户来看看我们写的需求规格说明是不是真的符合他们的想法。
这就好比我们把写好的旅行攻略给有经验的旅行者看，让他们挑挑毛病。
如果用户看了之后说，这不是我想要的啊，那我们就得赶紧改。
第三讲需求工程过程
发现活动进行的问题并在发现问题之后能 够改进过程
需求工程过程
活动（活动的任务定义）：
需求抽取 需求分析 需求协商 需求验证 （瀑布式、迭代式、螺旋式、„„） 执行活动的参与者 活动的输入输出 支持活动的工具
活动的序（活动的计划安排）
其它与活动关联的对象
需求工程过程
第三讲：需求工程过程
目的：介绍为软件加强型系统中的复 杂软件设计的需求工程过程，涉及
抽取需求 分析需求 验证需求 管理需求
主要关注点：需求工程中要做些什么
主要内容
相关概念 需求工程的输入与输出 需求工程过程模型 需求抽取和分析 需求验证和管理
什么是过程？
需求抽取过程
业务目标 组织结构 识别需求 相关者 需求相关 者需求
要解决的 问题
应用领域
目标优先 化
领域需求
系统约束
现有系统
领域知识 过滤
组织需求
需求分析过程
目标：发现初步需求中的冲突 主要活动：
必要性检查 一致性和完整性检查 可行性检查
需求协商过程
目标：确定能得到一致同意的需求 主要活动：
理解应用领域
需求抽取
理解问题
应用领域
要解决 的问题
理解系统需求相 关者的需要和要 满足的约束
需求相关者的 需要和约束
业务场景
理解业务
需求抽取涉及的因素
应搜集什么信息 从什么来源中搜集信息 用什么机制或技术搜集信息
需求的来源
SW工程图
6.2
标准工程视图
6.2
标准工程视图
6.2.5 相对视图 相对视图是一个正交视图，由模型的两个正交面或基准面及各自的具体 方位的规格定义。 第一方向下，选择一个视向 (前视、上视、左视等)，然后在工程视 图中为此方向在模型中选择面。 第二方向下，选择另一视向，与第一方向正交，然后在工程视图中 为此方向选择另一个面。 创建相对视图图解如图6-19所示：
6.2
标准工程视图
2．标准方法生成标准三视图 在“工程图”工具栏上单击“标准三视图”按钮 ，或者依次执行“插入 ”|“工程视图”|“标准三视图”，弹出“标准三视图”面板，如图6-12所示。 打开要创建三视图的零件——“支座-基于草图的特征”，单击“确定”按 钮，程序自动创建标准三视图，如图6-13所示。
6.1
工程图概述
02在“新建SolidWorks文件”对话框中选择“工程图”，确定后即可 弹出如图6-4所示的“图纸格式/大小”对话框。
6.1
工程图概述
03在“图纸格式/大小”对话框中选择图纸格式，或者单击“浏览”按钮，导航到所 需图纸格式文件，然后单击“打开”按钮，亦可加载用户自定义的图纸格式。 对“图纸格式／大小”对话框中其他选项介绍如下： 标准图纸大小：选择一标准图纸大小，或单击浏览找出自定义图纸格式文件。 显示图纸格式（可为标准图纸大小使用）：显示边界、标题块等。 标准图纸大小：指定一宽度与高度。 04设置好对话框中其他各个选项，或使用默认值，确定后弹出如图6-5所示的窗口， 用户通过“浏览”打开需要制作工程图的零件来生成工程图。
6.2
标准工程视图
6.2
标准工程视图
6.3.2 辅助视图 辅助视图的用途相当于机械制图中的斜视图，是一种特殊的投影视图，在恰当的 角度上向选定的面或轴进行投影，用来表达零件的倾斜结构。 生成辅助视图步骤如下： 01单击“工程图”工具栏上的“辅助视图”按钮 ，或依次执行“插入”|“工程视 图”|“辅助视图”命令 ，弹出“辅助视图”面板。 02选择参考边线：参考边线可以是零件的边线、侧轮廓边线、轴线或者所绘制的 直线段。 03将指针移动到要创建辅助视图的方向，指针移动过程中，辅助视图预览在指针 位置，同时在辅助视图的反侧显示投影方向的箭头符号 。 04视图移动到合适位置后，单击放置投影视图在指针单击的位置。若有必要，用 户可更改视图方向。 05单击确认按钮 ，完成辅助视图的创建。 从工程图中已有视图生成辅助视图的过程，如图6-21所示。
需求工作流程(1).ppt
需求來自於
系統的直接使用者； 其他關鍵人員（例如，管理者、維護者、
安裝人員）； 與此系統互動之其他系統； 與此系統互動之硬體設備； 法律和管制限制； 技術限制； 商業目標。
撰寫願景文件
一般而言，需求工程一開始會用願景 （Vision）文件來描繪此系統欲達成的目標， 以及系統開發完成後對關鍵人員的好處，這 樣一份文件最主要是希望從關鍵人員的觀點 中掌握系統開發的目標，並由系統分析人員 於UP專案起始階段產出，產出願景文件之 後，需求工程才算真正的開始。
需求應該僅說明系統該做什麼(What)而已， 而不是直接說明系統該怎麼做(How) 。
需求模型
UP有一個正規的需求描述方式，它是採用使用案 例模型來說明需求的內容，我們以傳統功能性與 非功能性需求的想法為基礎，再加上需求模型來 加強描述需求的內容。
使用案例模型通常是透過一套UML模塑工具來建 立，如Rational Rose 。
?需求應該僅?明系統該做?麼what而已而?是直接?明系統該怎麼做how需求模型?up有一個正規的需求描述方式它是採用使用案?模型??明需求的內容我們以傳統功能性與非功能性需求的想法為基礎再加上需求模型?加強描述需求的內容
需求工作流程
需求工作流程
需求工作流程（Requirement Workflow）中的大 部分工作，會出現在專案啟始和細部評估階段。
每個需求屬性都是一個可描述的名稱以及數值。 例如
一個需求可以有一個名為完成日期（dueDate）的屬性， 同時這屬性有一個日期的數值是這需求非得完成的日 期。
最常見的需求屬性是要需求的優先順序 （Priority），此屬性的數值是指該需求在所有需 求中的優先順序，普遍用來指定優先順序的是 MoSCoW代碼。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2013-7-21
20
实例：ATM系统
一个自动柜员机系统，提供自动化的银行服 务 采用非常简化了的银行客户服务系统, 提供 比较狭窄的服务范围 具体服务包括现金提取，信息传递 (送一个 信息请求一个服务),余额查询和资金划转
2013-7-21
21
实例：ATM系统相关人员
SW06
需求工程过程
2013-7-21
1
目标
需求工程的活动及其之间的关系 需求导出和分析的一些技术 需求有效性验证 需求管理的必要性，及它如何支持其它需求 工程活动
2013-7-21
2
内容
可行性研究 需求导出和分析 需求验证 需求管理
2013-7-21
3
一 需求工程过程概述
2013-7-21
5
1.2 需求工程概述
软件需求工程是在计算机系统的软件功能分配和
软件设计之间起着重要桥梁作用的一项软件工程
活动。
需求分析（工程）是发现、求精、建模和规约目
标系统的过程，即指出软件目标产品必须“做什 么”，描述软件系统提供的服务和所受到的约束， 是一个对服务和约束的发现、分析、建立文档和 检验的过程。
2013-7-21 44
原因： 深入实际
需求来自于人们实际的工作而非过程定义中 对它们的要求 需求来源于合作和对其他人们活动的了解
2013-7-21
45
例子
软件系统在社会和组织的环境中使用，从而社会和 组织会影响甚至是支配系统的需求 考虑一个允许高级管理者不经过中层管理者而直接 存取数据的系统
2.3 可行性研究的步骤
基于信息的评估(什么是必需)，信息汇总和报告写作 对组织中的人们提出下面的一些问题(分析信息) 如果系统没有实现，那将会怎样? 当前的业务处理过程中的问题是什么? 被规划的系统会如何帮助? 系统集成将会有什么问题? 需要新的技术吗? 什么技术? 所规划系统的需要哪些支持支持?
2013-7-21
8
需求工程过程
2013-7-21
9
二 可行性研究
2013-7-21
10
2.1 可行性研究概述
可行性研究决定所规划的系统是否值得开发 可行性研究主要集中在： 研究系统是否符合机构的总体目标；
研究系统能否在现有技术条件、预算和时间限制
内完成；
研究系统能否把已存在的其他系统集成
2013-7-21
26
VORD标准格式
2013-7-21
27
视点识别
2013-7-21
28
视点服务信息
2013-7-21
29
视点数据和控制信息
2013-7-21
30
视点层次
2013-7-21
31
客户视点和现金支取描述
2013-7-21
32
面向视点的导出总结
对于有多视点（客户）的需求分析过程，关 键是发现众多视点的存在，考察不同视点接 收的服务，收集这些信息并提供一个框架以 解决不同视点提出的需求冲突。具体分为视 点识别、视点组织、视点文档编写和视点系 统映射四部分内容。
2013-7-21
15
需求导出与分析面临的困难
用户不知道需要系统要干什么 用户用他们自己的专业术语来描述需求 不同的用户可能产生矛盾的需求 组织的和政治上的因素可能影响系统需求 需求在分析过程期间改变。 新的用户出现， 系统会有新的需求
2013-7-21
16
3.2 需求导出与分析过程活动
2013-7-21
40
出借用例
2013-7-21
41
图书馆用例
2013-7-21
42
ATM 序列图
2013-7-21
43
3.3.3 深入实际的方法
一位社会学家花相当的时间观察和分析人们 是如何实际工作的 因为人们无法解释或清楚地说出他们的工作 重要的社会和组织的因素可能得到观察 深入实际研究揭示了这样一项内容，工作通 常比简单的系统模型所描述的更丰富和更复 杂
2013-7-21
50
4.2 需求有效性验证方法
需求检查
对需求文档中定义的需求执行多种类型检查
需求评审
对需求进行系统的手工分析
设计原型
使用系统的一个可运行的模型检查需求。 Covered in Chapter 8
测试用例产生
为需求开发测试检查 易测性
2013-7-21
面向视点的方法 基于场景的分析方法 深入实际的方法
2013-7-21
19
3.3.1 面向视点的导出
对于任何中、大型系统，通常有多个不同类型的用 （客）户，必然会有不同的视点考虑。从不同视点 观察一个问题，可以得到不同的解决方法。 多视点的分析是很重要的，因为没有单一正确的分 析系统需求的方法
51
需求检查
有效性：Does the system provide the functions which best support the customer’s needs? 一致性：Are there any requirements conflicts? 完备性：Are all functions required by the customer included? 现实性：Can the requirements be implemented given available budget and technology 可检验性检查：Can the requirements be checked
对被分析的系统有不同的理解
服务的接收者
视点是位于系统的外部并接受从它来的服务。特别
适合于交互式系统
2013-7-21 23
外部视点
交互系统提供服务给最终用户，将视点看做系统服 务接收者对交互系统分析是有效的： 自然把最终用户当做系统服务的接收者 视点是构造需求导出的一个自然的方法 比较容易决定一个视点是否是有效的
2013-7-21
4
1.1 需求工程的重要性
输入：《合同》/《立项建议书》 输出：《用户需求报告》《需求规格说明书》 需求分析为什么重要？ (1)大型系统的失败，最后均归结到需求分析。 (2)《用户需求报告》是一个里程碑/基线。 (3) 需求分析占软件开发工作量的30%左右。 (4) 需求获取中的错误，会发散式的传播。
领域了解 需求收集 分类 冲突解决 优先排序 需求检查
2013-7-21
17
需求分析和导出过程
过 程 入 口
需 求 描 述 领 域 了 解 需 求 检 查 优 先 排 序 需 求 文 档 需 求 收 集 需 求 分 类 冲 突 解 决
2013-7-21
18
3.3 需求导出与分析方法
2013-7-21
52
需求评审
当需求定义被明确表达出来之后 , 评审 应该进行 客户应该参与到评审中 评审可能是正式的或非正式的。
2013-7-21
53
评审内容
可测试性。 Is the requirement realistically testable? 可理解性。 Is the requirement properly understood? 可跟踪性。 Is the origin of the requirement clearly stated? 适应性。 Can the requirement be changed without a large impact on other requirements?
2013-7-21
11
2.2 可行性研究任务
可行性研究任务是信息评估、信息汇总和可 行性报告。 信息评估是找出和分析相关的信息；信息汇 总是建立系统的逻辑模型，并从技术可行性、 经济可行性、操作可行性和时间可行性等方 面探索解决方案；可行性研究报告给出是否 要开发系统的意见和建议。
12
2013-7-21
场景开始时的系统状态 场景中的一般事件流程 哪些会出错以及如何处理 同其他协作活动 场景完成时的系统状态
2013-7-21
35
(2) 事件场景
事件场景可以用来描述系统如何响应一些特 别的事件的发生，例如 “开始交易” 为事件场景给出了一个图形的约定
发送和接收的数据 控制信息 异常处理
38
异常描述
在这个例子中，异常是 超时：用户在规定时间内没有能够输入个人身份 号码 无效的卡：卡无法得到识别并退回 偷来的卡：识别出卡是偷来的，因而机器将其没 收
2013-7-21
39
(3) 用例（USE-CASE）
用例是一种基于场景的需求导出技术 用例是基于 UML 技术的场景，识别出交互的 参与者并描述交互本身 可以使用序列图把更详细的需求加入 需求导出与分析
2013-7-21
14
3.1 需求导出与分析
需求导出和分析这个活动是软件开发技术人员和客 户及系统最终用户一起调查应用领域、即系统应该 提供什么服务、系统应该具有升么样的性能以及硬 件约束.从一个活动到另一个活动会有持续的反馈， 是一个重复的过程 所有对系统需求有直接或间接影响力的人员统称稀 项目相关人员，如最终用户、管理者、维护人员、 领域专家等，统称项目相关人员
下一个预期的事件
2013-7-21
36
事件场景-开始交易
2013-7-21
37