软件工程之 需求获取
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2、性能需求（Performance Requirement）：系统整体或 系统组成部分应该拥有的性能特征，例如CPU使用率、内存 使用率等。
3、质量属性（Quality Attribute）：系统完成工作的质量， 即系统需要在一个“好的程度”上实现功能需求。
4、对外接口（External Interface）：系统和环境中其他系 统之间需要建立的接口，包括硬件接口、软件接口、数据库 接口等。
5、约束（Constraint）：进行系统构造时需要遵守的约束， 例如编程语言、硬件设施等。
.
5.2需求的类型
.
5.2需求的类型
1.2.1功能需求 业务需求（Business Requirement）表示组织或客
户高层次的目标。它描述了组织为什么要开发系统，即组 织希望达到的目标。例如实现车辆的有效管理和利用。业 务需求通常来自项目的投资人、购买产品的客户、实际用 户的管理者。 用户需求（User Requirement）就是执行实际工作的 用户对系统所能完成的具体任务的期望。业务需求是由组 织的专门部门提出，但普通用户才是组织中任务的实际执 行者，只有通过具体并且合理的业务流程才能真正的实现 目标。也就是说用户需求描述了用户能使用系统来做些什 么。 系统需求（System Requirement）规定开发人员必 须在产品中实现的软件功能，用户利用这些功能来完成任 务，满足业务需求，行为需求描述的是开发人员需要实现 什么。
2、需求专题讨论会 需求分析员需要经常组织和协调需求专题讨论
会，人们通过协调讨论和群体决策等方法，为具 体问题找到解决方案，并在应用需求上达成共识、 对操作过程尽快取得统一意见。在这种会议中， 参加人员一般包括三种角色： 主持人或协调人：该角色在会议中起着十分关键 的作用，他应该鼓励参会人员积极参与和畅所欲 言，保证会议过程顺利进行。 记录人：该角色需要协助主持人将会议期间所讨 论的要点内容记录下来。 参与人：该角色的首要任务是提出设想和意见， 并激励其他人员产生新的想法。
4、可移植性：指把一个软件系统从一种运行环境移植到另 一个运行环境所花费的工作量的量度。
5、效率：执行功能时的响应时. 间、处理时间和吞吐速度。 比如要求系统需要满足所有用户查询都必须在7秒内完成。
5.3需求获取
构建一个软件系统最困难的部分是确定构 建什么。其他部分工作不会像这部分工作 一样，在出错之后会如此严重地影响随后 实现的系统，并且在以后修补竟会如此的 困难。
IEEE的定义中同时包括了用户的观点（第一条）和开发 者的观点（第二条）。
关于需求还有其他不同的定义，产生这些不同的原因有两 点：一是需求工程的发展过程还不太长，人们的认识还不 够；二是真正的需求实际上是人们的想法，很难给予准确 的定义。
.
5.2需求的类型
1、功能需求（Functional Requirement）Leabharlann Baidu和系统主要工 作相关的需求，即在不考虑物理约束的情况下，用户希望系 统所能够执行的活动，这些活动可以帮助用户完成任务。
第5章 需求获取
.
第五章 需求获取
5.1软件需求的定义 5.2软件需求的类型 5.3需求获取 5.4需求规格说明书 5.5需求验证 5.6需求变更
.
教学目的与要求：
⒈掌握需求的基本概念及类型; ⒉掌握如何进行获取需求; ⒊掌握需求规格说明书； 4.掌握需求验证； ⒋理解软件需求变更管理。
教学重点：
.
5.2需求的类型
1.2.2非功能性需求
除了功能需求外，软件需求还包含非功能需求，包括性能需 求、质量属性、对外接口和约束。非功能需求是衡量软件能 否良好运行的定性指标。因此，非功能需求也是非常重要的。 在非功能需求中，质量属性对系统的影响极大，因此在某些 情况下，非功能需求又被用来特指质量属性。
1、可靠性：指在给定的时间内以及规定的环境条件下，软 件系统能完成所要求功能的概率。其定量指标通常用平均无 故障时间和平均修复时间来衡量。
2、可用性：指用户学习和使用软件系统功能的简易程度，也 包括对系统的输出结果易于理解的程度。
3、可维护性：指在软件系统中发现并纠正一个故障或进行一 次更改的简易程度。可维护性取决于理解、更改和测试软件 的简易程度。
.
5.1需求的定义
不同背景的人对需求会有不同的看法，像瞎子摸象一样大 家会站在自己的立场去理解需求，因此需求在软件工程中 没有统一的定义，IEEE对需求的定义为：
1、用户为解决某个问题或达到某个目标而需具备的 条件或能力。
2、系统或系统组件为符合合同、标准、规范或其他正式 文档而必须满足的条件或必须具备的能力。
⒈软件需求的基本概念及类型; ⒉如何进行获取需求; ⒊什么是需求规格说明书以及什么是优秀的需求 规格说明书。 4.需求验证和需求变更管理.。
引言
团队和管理对项目开发很重要，但项目开发的成败取决于是否正 确的进行需求获取。
注：从前有一个人，从魏国到楚国去。他带上很多的盘缠，雇了上好的车， 驾上骏马，请了驾车技术精湛的车夫，就上路了。楚国在魏国的南面，可这 个人不问青红皂白让驾车人赶着马车一直向北走去。路上有人问他的车是要 往哪儿去，他大声回答说：“去楚国！”路人告诉他说：“到楚国去应往南 方走，你这是在往北走，方向不对。”那人满不在乎地说：“没关系，我的 马快着呢！”路人替他着急，拉住他的马，阻止他说：“方向错了，你的马 再快，也到不了楚国呀！”那人依然毫不醒悟地说：“不打紧，我带的路费 多着呢！”路人极力劝阻他说：“虽说你路费多，可是你走的不是那个方向， 你路费多也只能白花呀！”那个一心只想着要到楚国去的人有些不耐烦地说： “这有什么难的，我的车夫赶车的本领高着呢！”路人无奈，只好松开了拉 住车把子的手，眼睁睁看着那个盲目上路的魏人走了。寓言告诉我们，无论 做什么事，都要首先看准方向，才能充分发挥自己的有利条件；如果方向错 了，条件再有利也达不到目的。同样在项目开发中有再好的团队，再好的技 术，如果没有正确的进行需求获取，那么项目不可能成功！
—Fred Brooks
.
5.3.1需求获取的方法
1、面谈 用户面谈是一种十分直接而常用的需求获
取方法，它也经常与其他需求获取技术一 起使用，以便更好地澄清和理解一些细节 问题。需要说明的是，面谈过程应该进行 认真的计划和准备，我们将以小型图书馆 系统的一次面谈举例说明其主要步骤。
.
5.3.1需求获取的方法
3、质量属性（Quality Attribute）：系统完成工作的质量， 即系统需要在一个“好的程度”上实现功能需求。
4、对外接口（External Interface）：系统和环境中其他系 统之间需要建立的接口，包括硬件接口、软件接口、数据库 接口等。
5、约束（Constraint）：进行系统构造时需要遵守的约束， 例如编程语言、硬件设施等。
.
5.2需求的类型
.
5.2需求的类型
1.2.1功能需求 业务需求（Business Requirement）表示组织或客
户高层次的目标。它描述了组织为什么要开发系统，即组 织希望达到的目标。例如实现车辆的有效管理和利用。业 务需求通常来自项目的投资人、购买产品的客户、实际用 户的管理者。 用户需求（User Requirement）就是执行实际工作的 用户对系统所能完成的具体任务的期望。业务需求是由组 织的专门部门提出，但普通用户才是组织中任务的实际执 行者，只有通过具体并且合理的业务流程才能真正的实现 目标。也就是说用户需求描述了用户能使用系统来做些什 么。 系统需求（System Requirement）规定开发人员必 须在产品中实现的软件功能，用户利用这些功能来完成任 务，满足业务需求，行为需求描述的是开发人员需要实现 什么。
2、需求专题讨论会 需求分析员需要经常组织和协调需求专题讨论
会，人们通过协调讨论和群体决策等方法，为具 体问题找到解决方案，并在应用需求上达成共识、 对操作过程尽快取得统一意见。在这种会议中， 参加人员一般包括三种角色： 主持人或协调人：该角色在会议中起着十分关键 的作用，他应该鼓励参会人员积极参与和畅所欲 言，保证会议过程顺利进行。 记录人：该角色需要协助主持人将会议期间所讨 论的要点内容记录下来。 参与人：该角色的首要任务是提出设想和意见， 并激励其他人员产生新的想法。
4、可移植性：指把一个软件系统从一种运行环境移植到另 一个运行环境所花费的工作量的量度。
5、效率：执行功能时的响应时. 间、处理时间和吞吐速度。 比如要求系统需要满足所有用户查询都必须在7秒内完成。
5.3需求获取
构建一个软件系统最困难的部分是确定构 建什么。其他部分工作不会像这部分工作 一样，在出错之后会如此严重地影响随后 实现的系统，并且在以后修补竟会如此的 困难。
IEEE的定义中同时包括了用户的观点（第一条）和开发 者的观点（第二条）。
关于需求还有其他不同的定义，产生这些不同的原因有两 点：一是需求工程的发展过程还不太长，人们的认识还不 够；二是真正的需求实际上是人们的想法，很难给予准确 的定义。
.
5.2需求的类型
1、功能需求（Functional Requirement）Leabharlann Baidu和系统主要工 作相关的需求，即在不考虑物理约束的情况下，用户希望系 统所能够执行的活动，这些活动可以帮助用户完成任务。
第5章 需求获取
.
第五章 需求获取
5.1软件需求的定义 5.2软件需求的类型 5.3需求获取 5.4需求规格说明书 5.5需求验证 5.6需求变更
.
教学目的与要求：
⒈掌握需求的基本概念及类型; ⒉掌握如何进行获取需求; ⒊掌握需求规格说明书； 4.掌握需求验证； ⒋理解软件需求变更管理。
教学重点：
.
5.2需求的类型
1.2.2非功能性需求
除了功能需求外，软件需求还包含非功能需求，包括性能需 求、质量属性、对外接口和约束。非功能需求是衡量软件能 否良好运行的定性指标。因此，非功能需求也是非常重要的。 在非功能需求中，质量属性对系统的影响极大，因此在某些 情况下，非功能需求又被用来特指质量属性。
1、可靠性：指在给定的时间内以及规定的环境条件下，软 件系统能完成所要求功能的概率。其定量指标通常用平均无 故障时间和平均修复时间来衡量。
2、可用性：指用户学习和使用软件系统功能的简易程度，也 包括对系统的输出结果易于理解的程度。
3、可维护性：指在软件系统中发现并纠正一个故障或进行一 次更改的简易程度。可维护性取决于理解、更改和测试软件 的简易程度。
.
5.1需求的定义
不同背景的人对需求会有不同的看法，像瞎子摸象一样大 家会站在自己的立场去理解需求，因此需求在软件工程中 没有统一的定义，IEEE对需求的定义为：
1、用户为解决某个问题或达到某个目标而需具备的 条件或能力。
2、系统或系统组件为符合合同、标准、规范或其他正式 文档而必须满足的条件或必须具备的能力。
⒈软件需求的基本概念及类型; ⒉如何进行获取需求; ⒊什么是需求规格说明书以及什么是优秀的需求 规格说明书。 4.需求验证和需求变更管理.。
引言
团队和管理对项目开发很重要，但项目开发的成败取决于是否正 确的进行需求获取。
注：从前有一个人，从魏国到楚国去。他带上很多的盘缠，雇了上好的车， 驾上骏马，请了驾车技术精湛的车夫，就上路了。楚国在魏国的南面，可这 个人不问青红皂白让驾车人赶着马车一直向北走去。路上有人问他的车是要 往哪儿去，他大声回答说：“去楚国！”路人告诉他说：“到楚国去应往南 方走，你这是在往北走，方向不对。”那人满不在乎地说：“没关系，我的 马快着呢！”路人替他着急，拉住他的马，阻止他说：“方向错了，你的马 再快，也到不了楚国呀！”那人依然毫不醒悟地说：“不打紧，我带的路费 多着呢！”路人极力劝阻他说：“虽说你路费多，可是你走的不是那个方向， 你路费多也只能白花呀！”那个一心只想着要到楚国去的人有些不耐烦地说： “这有什么难的，我的车夫赶车的本领高着呢！”路人无奈，只好松开了拉 住车把子的手，眼睁睁看着那个盲目上路的魏人走了。寓言告诉我们，无论 做什么事，都要首先看准方向，才能充分发挥自己的有利条件；如果方向错 了，条件再有利也达不到目的。同样在项目开发中有再好的团队，再好的技 术，如果没有正确的进行需求获取，那么项目不可能成功！
—Fred Brooks
.
5.3.1需求获取的方法
1、面谈 用户面谈是一种十分直接而常用的需求获
取方法，它也经常与其他需求获取技术一 起使用，以便更好地澄清和理解一些细节 问题。需要说明的是，面谈过程应该进行 认真的计划和准备，我们将以小型图书馆 系统的一次面谈举例说明其主要步骤。
.
5.3.1需求获取的方法