当前位置：文档之家 › 第一讲需求工程导论

第一讲需求工程导论

  • 格式：ppt
  • 大小：2.41 MB
  • 文档页数：74

下载文档原格式

  / 74

合集下载

《需求工程》PPT课件

《需求工程》PPT课件
5
设计活动改变客观世界状 态
6
什么是需求？〔Jackson, 1995〕
领域性质(Domain Property)：无论系统存在与否均存在的应用领域的 性质。
需求(Requirements)：由系统的存在而产生的应用领域性质。 规约描述(Specification)：描述系统为满足需求而应具有的行为。 需求证明的标准(Verification Criteria)：1、运行在某台机器上的程序满
要。是系统或其组成局部为满足某种书面规定〔合同， 标准，标准等〕所要具备的能力。需求将作为系统开 发，测试，验收，提交的依据。 • —— IEEE 610.12, 1990
4
将问题与解决方案分开
• 理解问题
需求获取
• 问题的形式化表示
形式规约，形式建模
• 就问题性质达成共识
验证, 冲突及矛盾消解, 磋商 需求管理– 维护双方的共识
27
• …但风险永不可能降解为零
关于需求的根本观点
• 追求规约的描述会降低性价比 • 需求分析是有开销的 • 不同的工程，性价比的平衡点是不同的 • 问题描述永不可能是固定的 • 变化是无法防止的，因此应纳入方案之
中 • 对变化的处理应定期进展
28
可能的需求来源
• 客户专有需求 • 对于有着明确问题的特定客户，最终客户享有决定权。 • 市场需求 • 对于在市场上广泛出售的产品，营销团队扮演着顾客和
• 适用范围： • 用于获取关于系统用户界面的需求 • 用于检验设计方案的可行性，或探讨系统性能
问题 • 存在的问题： • 用户将原型误认为最终系统
20
• 原型所反映的系统是不全面的〔Loucopal vs. Evolutionary (Thayer & Dorfman, 1997, p10)

《需求工程》课件

《需求工程》课件

06 需求变更处理
需求变更请求
提出变更
当项目干系人提出需求变更时，应详细记录变更请求的 内容、原因和影响。
确认变更
对变更请求进行评估，确认是否需要进行变更，并通知 相关干系人。
变更影响分析
影响范围
分析变更对项目范围、进度、成本和质量等方面的影响。
资源需求
评估实施变更所需的资源，包括人力、物力和财力等。
需求工程
目录
• 需求工程概述 • 需求获取 • 需求分析 • 需求规格说明 • 需求验证与确认 • 需求变更处理 • 需求工程工具与技术
01 需求工程概述
定义与特点
定义
需求工程是一种系统的方法，用于确 定、捕获和验证系统或产品需求，以 满足用户、客户和其他利益相关者的 期望和要求。
特点
需求工程强调与利益相关者的沟通、 需求分析和验证，以确保需求的正确 性、完整性和一致性。它还涉及到需 求管理，以确保需求在整个产品开发 生命周期中得到满足。
需求工程的重要性
A
减少开发时间和成本
准确的需求可以避免开发过程中的返工和变更 ，从而缩短开发时间和降低成本。
提高产品质量
明确和经过验证的需求有助于提高产品的 质量和性能，满足用户和客户的需求。
B
C
增强用户满意度
通过了解和满足用户需求，可以提高用户对 产品的满意度和忠诚度。
降低维护成本
明确的需求有助于降低产品维护和升级的成 本，因为变更可以在开发阶段进行充分的考 虑和规划。
分析文档中的需求
对审查的文档进行分析，提取其中的需求信 息，以便更好地理解项目的需求背景和要求
。
03
需求分析
需求分类与优先级排序
需求分类是将收集到的原始需求按照一定的标准进行分类的过程，优先级排序则 是根据需求的紧急程度、重要性等因素对需求进行排序。

需求工程复习要点

需求工程复习要点

2020
第10章需求的组织——需求获取中的模型驱动方法
模型驱动方法是一类以定义 明确的模型为理论基础，依据模 型指导和组织活动开展的需求工 程方法。需求获取的常见模型驱 动方法有3种： ① 面向目标的方法。 ② 基于场景的方法。 ③ 基于用例的方法。 场景是用户为了达到某个 目标，需要和软件系统发生交 互的行为序列。 场景方法在需求工程中的 应用主要有3种：1组织需求获 取得到的信息。2帮助进行详 细的需求分析3. 结合面向目标 的方法，指导需求获取活动的 开展 用例是在系统（或者子系统 或者类）和外部对象的交互当中 所执行的行为序列的描述。 用例之间的关系主要有： 包含（Include）、扩展（Extend） 和泛化（Generalization）三种。
1212
第 5章
确定项目的前景与范围
5.4 前景与范围文档
业务需求、高 层次解决方案和系 统特性都应该被定 义到项目前景与范 围文档之中。
1313
第 6章
6.1 涉众
涉众分析与硬数据采样
6.5 硬数据
文档资料被称为硬数据 1. 定量硬数据: ① 数据收集表 ② 统计报表
所有能够影响软件系 统的实现，或者会被实现后 的软件系统所影响的个人和 团体。 1. 用户 2. 客户 3. 开发者 4. 管理者 5. 领域专家 6. 政府力量 7. 市场力量
2222
第12章 过程建模
过程建模是结构化分析方法 的典型技术。 过程建模使用的主要技术有： ⑴ 上下文图 ⑵ 数据流图 ⑶ 微规格说明 ⑷ 数据字典 电梯控制系统的DFD创建实例： ⑴ 创建上下文图 ⑵ 发现并建立DFD片段 ⑶ 根据DFD片段组合产生0层图 ⑷ 功能分解，产生N层图 ⑸ 定义原始过程的逻辑说明 ⑹ 定义数据流和数据存储的数据 说明

第1章.需求工程导论

第1章.需求工程导论

内容
课时 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
备注
延续教学 见实验报告
延续教学 见实验报告 延续教学
见实验报告 延续教学 见实验报告
需求工程中的标准模板 期末考试
第1章. 需求工程导论
主要内容
1.
1. 2.
软件的需求问题
软件的发展 软件生产状况调查
2. 3. 4.
需求问题的原因分析 需求工程 需求工程师
8
教材目录

第三部分 需求分析



第11章 需求分析概述 第12章 过程建模 第13章 数据建模 第14章 面向对象建模 第15章 需求规格说明 第16章 需求验证 第17章 需求管理 第18章 需求工程的过程管理（*） 第19章 需求工程中的项目管理 （*）
9

第四部分 需求的文档化和验证
草图分析 需求分析 DFD/ERD
应用为中心 形式化方法
需求分析 面向对象
软件膨胀
基本业务处理， 应用处理
应用软件产品
50's
60's
70's
90's
19
1.1软件的发展 ——90年代的发展
机器为中心
指令码、汇编语言 BIOS 批量事务处理、计算性工作
应用为中心
3GL, OOL OS, Virtual Machine 基本业务处理，应用处理
2
课程体系

先修课程：计算机基础、编程语言 专业核心课程群的龙头：《软件需求工程》、 《软件设计与体系结构》、《软件测试与质量 》、《软件过程与管理》 软件2013级教学大纲

3
教材

第一章需求工程导论

第一章需求工程导论

第一章需求工程导论1.软件开发中碰到的需求问题的现象是什么？答：（1）用户参与度不够。

（2）高层管理支持力度不够。

（3）没有清晰的需求说明。

（4）没有清晰的目标和前景。

（5）期望不切合实际。

（6）需求变化影响。

（7）增加了无用的额外功能。

2.在需求处理当中要注意哪些非技术性因素，为什么？答：（1）需求处理的任务：需求处理的任务主要是发现问题并解决问题。

现实是问题的发生地，软件系统是人们应对问题的手段。

但是单纯的软件系统是不能解决问题的。

它只有和现实之间形成一种有效的互动才能解决问题。

（2）需求处理的手段：建模与分析技术是进行需求处理的主要手段，这些技术本身都是概念性的，不依赖于某些特殊的应用环境条件。

可以被广泛的应用于各种应用场景。

（3）需求处理的过程：试图单纯的通过技术的应用建立一个一致完整的需求模型是不太可能的。

因为在现实中，因涉众的不同立场而产生的利益冲突的场景非常常见。

这些冲突是根本无法通过技术手段所能解决的。

3.解释需求分析与需求工程之间的联系答：“需求工程”就是利用工程化的手段进行需求处理，以保证需求处理的正确进行，而“需求分析”是需求处理中的核心活动，他用一些形式化或半形式化的语言进行知识的分析，但是建立需求工程还离不开需求分析。

4.解释软件工程与系统工程之间的联系，这种联系对需求工程的工作有何影响？答：（1）系统工程通常是指计算机引入某一现实系统，并用他来改变现实系统的运作方式，达到一个理想效果的过程。

而且系统工程中除了含有处理系统的软件工程之外，还包括硬件工程和人力工程。

因此，在系统工程中，虽然应该重点关注软件工程部分的内容，但并不能完全以软件为中心来看待和处理整个系统。

（2）影响：系统需求开发的主要目的是获得整个系统的期望目标，包含功能特性和非功能特性。

因此需要判定系统的涉众，采集他们的目标与要求研究系统的环境确定系统的要求，并进行一些整体性的分析。

5.需求工程包括哪些活动？软件开发活动当中为什么要重视需求工程？答：需求工程包括（1）需求开发（2）需求管理。

第1章.需求工程导论

第1章.需求工程导论

失败项目的影响要素
影响指数
不完整的需求说明
13.1％
缺少用户输入
12.4％
缺乏资源
10.6％
不切实际的期望
9.9％
缺乏高层管理支持
9.3％
需求变化
8.7％
缺乏计划
8.1％
额外的无用功能
7.5％
缺乏IT管理
6.2％
技术能力不足
4.3％
其他
9.9％
1.2 90年代的软件生产状况调查 —— 影响因素[Standish Group 1995]
需求因素
用户参与（用户输入） 高层管理支持 清晰的需求说明 切合实际的期望 清晰的目标和前景 需求变化 额外的无用功能
综合来看，需求因素
对成功项目的影响指数为53.9％ 对问题项目的影响指数为55.6％ 对失败项目的影响指数为60.9％
1.2 90年代的软件生产状况调查 ——ESPITI，1996
单纯通过技术的运用来建立一个一致、完整的需求模型是 不太可能的
面对冲突要能够分析社会原因和组织机构方面的原因，引导 涉众进行利益协商
2.2 需求问题的技术原因分析
结构化分析和面向对象分析具有一定的先天缺 陷
编程 －>设计－>分析 设计和编程都有构建高质量（健壮性、可维护性、
适应性等等）软件的共同目标，而且使用相同的概 念和组织机制保证了从设计到编程的平滑过渡，所 以，它们在设计领域的应用也取得了成功 但是需求分析除了拥有构建高质量软件的目标之外， 还有一个更加重要的目标是理解现实
80 60 40 20
0 需求
设计
编码 编码测试 验收测试 运行
代价

第1章 需求工程概要

第1章 需求工程概要

2018/10/25
8
1.3软件需求的分类

软件需求间的层次关系
目标需求
业务需求
功能需求
非功能需求
约束与限制
2018/10/25
9
1.3软件需求的分类

示例 下面我们通过与文字处理系统相关的部分 需求来说明需求的分类 。
1. 目标需求：用户使用系统能有效地纠正文档中的拼写错误，并且系统能满 足用户的业务要求以及提高用户的工作效率。 2. 业务需求：当找到文档中的拼写错误时，通过一个可供选择的单词表，并 在选择单词表中的某一个单词后替换掉原来的单词。 3. 功能需求：查找文档中的单词，并高亮度地显示出错的单词。用对话框显 示可供选择的单词表。实现整个文档范围内的替换。 4. 非功能需求：检查单词的速度快，准确率要求达到99％，系统的有效性和 可靠性要高等。 5. 约束与限制：文件内部格式要与word系统一致。开发平台为Linux系统， 以及使用C语言等。
2018/10/25
14
1.5需求工程

1. 2.
任务
确定待开发的软件系统的用户类，并获取他们的需求信息。 分析用户的需求信息，并按软件需求的类型分类这些需求 信息，同时也区别出不是需求的信息。 根据软件需求信息建立软件系统的逻辑模型或需求模型， 并确认非功能需求和约束条件及限制。 根据收集的需求信息和逻辑模型编写需求规格说明及其文 档。 评审需求规格说明。 当需求发生变更时，对需求规格说明及需求变更实施进行 管理。
不完整的需求； 缺乏用户的参与； 不实际的客户期望； 需求和需求规格说明的变更； 提供许多不必要的功能。
2018/10/25
3
1.1需求工程的重要性

示例 伦敦股票交易项目TAURUS 。 原因：缺乏健壮的需求规格说明而继续进 行系统实现。

【免费下载】 需求工程-MBADOC

【免费下载】 需求工程-MBADOC

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

[编辑] 需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。

后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。

随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。

人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

80年代中期，形成了软件工程的子领域——需求工程(requirement engineering,RE)。

进入90年代以来，需求工程成为研究的热点之一。

从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物——《Requirements Engineering》。

一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups)，并开始开展工作。

需求分析是介于系统分析和软件设计阶段之间的桥梁。

一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。

良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

[编辑] 需求工程(RE)可分为 1.系统需求工程（如果是针对由软硬件共同组成的整个系统） 2.软件需求工程（如果仅是专门针对纯软件部分）。

《需求工程》课件

《需求工程》课件
《需求工程》PPT课件
需求工程是一项关键的软件工程领域，旨在有效地获取、分析和管理软件系 统的需求。本课件将介绍需求工程的核心概念、方法和实践，并探讨其在软 件开发和项目管理中的重要性。
什么是需求工程？
需求工程是一个跨学科的领域，涉及到识别、分析、规范和验证软件系统的需求。它旨在确保开发的软件满足 用户和利益相关者的期望和需求。
2 非功能需求
描述系统应具备的性能、可靠性、安全性等方面的特性。
3 用户故事
以用户的视角叙述需求，具有用户愿望和期望的特点。
用户需求的获取方法
访谈
与用户和利益相关者进行面对面 的谈话和讨论，获取需求信息。
调查问卷
通过编制问卷并广泛分发，获取 大量用户的意见和需求。
情境分析观察用户在实际环源自中使用系统 的行为和需求。需求分析的步骤和技术
1
需求分类
将需求按照功能、优先级等进行分类和组织。
2
需求建模
使用UML、用户故事地图等工具，建立需求模型和关系。
3
需求验证
借助原型、模拟和验证工具，检查需求的正确性和可行性。
需求规格说明的编写
需求规格说明是一份详尽而准确的文档，描述了软件系统的功能、性能和约 束条件，为开发人员提供指导和参考。
需求工程的发展历程
1
1970s
早期需求工程方法的诞生，主要关注需求获取和需求分析的基本概念。
2
1980s
需求工程方法逐渐成熟，开始关注需求规格说明和需求验证的方法和工具。
3
1990s
需求工程的方法论得到进一步发展，加强了与软件开发和项目管理的整合。
需求工程的流程与方法
需求获取
通过与利益相关者沟通和访谈，收集并理解用 户的需求。

需求工程(第一讲)需求工程原理_

需求工程(第一讲)需求工程原理_

– 完全失败
• 29.5%的大公司项目被取消， • 中型和小型公司中被取消的项目分别占37.1%和21.6%。
项目成功/失败因素分析（95年 项目成功/失败因素分析（95年）
成功的因素 用户参与 行政管理支持 明确的需求陈述 适当的计划 实际的期望 更小的项目基础 可胜任的开发人员 物主身份 清楚的想象和目标 开发人员努力专心工作 其他 15.9% 13.9% 13.0% 9.6% 8.2% 7.7% 7.2% 5.3% 2.9% 2.4% 13.9% 为什么有问题 缺乏用户输入 不完整的需求和规格说明 变化的需求和规格说明 缺乏行政支持 技术上不胜任 缺乏资源 不现实的期望 不清楚的目标 不现实的时间框架 新技术 其他 12.8% 12.3% 11.8% 7.5% 7.0% 6.4% 5.9% 5.3% 4.3% 3.7% 23.0% 失败的原因 不完整的需求 缺乏用户参与 缺乏资源 不现实的期望 缺乏行政支持 变化的需求和规格说明 没有计划 不再需要它 缺乏IT管理 技术上的失误 其他 13.1% 12.4% 10.6% 9.9% 9.3% 8.7% 8.1% 7.5% 6.2% 4.3% 9.9%
软件需求工程: 软件需求工程: 原理和方法
金芝 中国科学院数学与系统科学研究院 zhijin@
内容
• 教学安排 • 课程目的和背景 • 教学大纲和主要内容 • 参考书目
教学安排
• 每星期1×3小时的课（13周），其中：
1. 2月20日:软件需求工程原理 2. 2月27日:软件需求工程过程 需求工程概述 3. 3月6日:文献综述 4. 3月13日:软件需求建模基础 5. 3月20日:面向目标的方法 6. 3月27日:面向主体和意图的方法 7. 4月3日:基于情景的方法 代表性方法 8. 4月10日:问题框架方法 9. 4月24日:基于领域建模的方法 10.5月8日:文档驱动的方法 11.5月15日:课程设计 12.5月22日:面向方面的方法,需求工程展望(非功能性需求) 13.5月29日:课程总结和答疑

需求工程第一讲概述

需求工程第一讲概述
❖ 该产品的屏幕图象应如附件XX所示，菜单项单击应按附 件YY的规定动作
精选ppt课件
17
功能需求的种类
❖ 功能性需求—系统应该做什么。 ❖ 非功能性需求—系统的特定特性或者约束。
也就是为如何实现这些功能需求设定约束。
精选ppt课件
18
举例—ATM机
❖ 功能性需求
1）ATM系统应该验证插入的ATM卡的有效性。 2）ATM系统应该验证客户输入的个人身份号的有效性。 3）ATM系统应该对于任何ATM卡在任意24小时内只能 取款不超过$250进行限制。
❖ 缺乏软件开发和维护的正确方法以及忽视软件开 发过程的质量控制乃是最为关键的原因。其中软 件开发和维护方法的不正确性主要体现在：
1）忽视软件开发前期的需求分析； 2）开发过程缺乏统一的、规范化的方法论的指导； 3）文档资料不齐全或不准确； 4）忽视与用户之间、开发组员之间的交流； 5）忽视测试的重要性； 6）不重视维护或由于上述原因造成维护工作的困难。
❖ 非功能性需求
1）ATM系统应该采用C++编写。
2）ATM系统和银行通信应该采用256位加密。
3）ATM系统应该在3秒内验证ATM卡。
4）ATM系统应该在3秒内验证个人身份号的有效性。
精选ppt课件
19
需求工程过程
❖ 需求工程过程是用来导出、确认和维护系 统需求文档的一组结构化活动
▪ 需求获取 ▪ 需求建模与需求分析 ▪ 需求规格说明 ▪ 需求验证与确认 ▪ 需求管理
❖ 作为审查者评估用户界面。
❖ 进行可用性测试，尝试用新的用户界面执行任务。
❖ 作为项目管理委员会的成员。
精选ppt课件
14
需求的层次
❖ 业务需求（目标需求）

需求工程讲稿(第一讲)

需求工程讲稿(第一讲)

需求工程金芝中国科学院数学与系统科学研究院zhijin@本讲内容♦课程目的和背景♦教学和考试方式♦教学大纲和主要内容课程的目的♦了解需求工程中的研究和实践的现状⏹需求工程在软件和软件工程中的地位和角色⏹需求工程中当前常用的技术、方法和工具♦选择一种或多种需求工程技术，获得对这些技术的实践经验♦理解需求工程的基本本质♦获得对在需求工程领域进行进一步研究的背景知识⏹对需求工程研究的方法学的观点⏹该领域当前的研究的观点和方向⏹对相关文献的了解教学和考试方式♦每星期1 3小时的课（13个星期），其中：⏹1~2次文献阅读和课程设计⏹1次课程设计报告♦考试和评分⏹30%课堂学习、讨论、课程设计报告等⏹70%课程设计报告为什么需要需求工程？♦工程：有用的人工制品的构建，强调最终产品的实用性和目的性（而不是创造性，对比与艺术）♦需求：构造任何人工制品之前，首先要弄清楚的是——意图（为什么需要它）♦其它大部分工程学科都不需要需求工程♦软件工程的特殊性：如何配置通用的机器去实现特定的目的（产品是无形的，但是是有目的的）软件工程的特殊性带来对软件的意图的理解上的困难：软件问题往往包含了最复杂的难题现实世界也没有对之进行任何物理上的约束需求工程有多重要？♦需求工程是软件工程的根基，项目规模的大小决定错误的代价♦失败项目的例子：⏹Performing Rights Society（演出权益协会）, PROMS项目，花费1100万英镑之后被放弃（1992年）。

其中糟糕的需求工程是项目失败的一个主要因素，包括未能以常人能够理解和检查的形式表达软件需求。

⏹Wessex Regional Information Systems Plan（地区信息系统）, RISP项目，花费了4300万英镑之后被放弃（1990年）。

其主要原因包括缺乏对RISP项目范围的清晰定义。

⏹London Stock Exchange（伦敦股票交易）, TAURUS项目，花费了7500万英镑后被取消（1993年）。

需求工程第一讲-概述

需求工程第一讲-概述

v v
v
v v v v
需求问题。

v
v
v
事出必有因，如果能先看到自己的不是，答案就会不一样。

！
v
v
v v
v
v
v
v
义)
v
v
v
分析)
v v
v v
v
1）忽视软件开发前期的需求分析；
2）开发过程缺乏统一的、规范化的方法论的指导；
3）文档资料不齐全或不准确；
4）忽视与用户之间、开发组员之间的交流；
5）忽视测试的重要性；
6）不重视维护或由于上述原因造成维护工作的困难。

v
v
“可靠的需求工程过程”是v
v
v需求的主要症状与本质分析v不同软件项目的需求视图
信息系统
v
v业务事件为中心
v Report为中心
v v
v
v
v
v v
v模型为中心
v决策模型为中心
v v v
v v v
ØØØ。

需求工程期末复习

需求工程期末复习

第一章：需求工程导论1.需求工程定义：是所有需求处理活动的和，它收集信息、分析问题、整合观点、记录需求并验证其正确性,最终反映软件被应用后与其环境互动形成的期望效应。

2.需求工程的基本活动：1）需求开发：需求获取，需求分析,需求规格说明，需求验证2）需求管理3.1）需求获取的目的是从项目的战略规划开始建立最初的原始需求;2）需求分析的目的是保证需求的完整性和一致性；3）需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来；4）需求验证的首要目的是保证需求及其文档的正确性，即需求正确的反映了用户的真实意图；另一个目标是通过检查和修正，保证需求及其文档的完整性和一致性；5）需求管理的主要工作是跟踪后继阶段中的需求实现与需求变更情况，确定需求得到了正确的理解并被正确的是想到了软件产品中。

4.软件需求规格说明定义：软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。

第二章：需求基础5.软件系统能够与问题域进行交互和相互影响的原因在于,软件系统中的某些部分对问题域中的某些部分具有模拟特性。

6.需求分类：1）功能需求：业务需求，用户需求,系统需求2）性能需求3）质量属性4）对外接口5）约束第三章：（不考）第四章：需求获取概述7.需求工程需要获取的内容主要有三种：1）需求2）问题域描述3）环境与约束8.需求获取信息的主要来源:1）涉众2）硬数据3）相关产品4）重要文档5）相关技术标准和法规9.获取信息的方法：1）传统方法:问卷调查,面谈,文档分析，文档检查，需求剥离2）集体获取方法：头脑风暴,专题讨论会，JAD，JRP3）原型4）模型驱动方法:基于场景，基于用例5）认知方法:任务分析，协议分析6）基于上下文的方法：观察,民族志，话语分析10.常见的组织方式是依照系统特性，确定系统的边界，建立上下文图或系统用例图，然后按照遍历上下文图和系统用例图的方式开展获取活动.第五章：确定项目的前景和范围11.前景：描述了产品的作用以及最终的功能，它将所有涉众都统一到一个方向上。

  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
课程介绍


课程安排 课程的目的和背景 教学大纲和主要内容 参考书目
课程安排




每周4*50分钟（8周）其中 第一周（9月5号上午）需求工程的基本知识一 第二周（9月12号上午）需求工程的基本知识二 第三周（9月19号上午）需求工程的获取技术 第四周（9月26号上午）需求工程的建模技术一 第五周（10月3号上午可能放假）需求建模技术 二，课程设计指导 第六周（10月10号）需求管理技术 第七周（10月17号）主要的需求分析方法介绍 第八周（10月24号）复习考试

d, 31.1%
, 16.2%
150 100 100 100 100
预期值 实际值
Challen ged, 52.7%
50 0 费用 时间
61
功能
1.2 90年代的软件生产状况调查 —— Standish Group 1995



大公司开发项目的平均成本是232.2万美元， 中等公司是133.1万美元，小型公司是43.4 万美元 大约31％的项目在完成之前被取消，52.7 ％的项目成本是原来预算的189% 大公司9%按预算交付，小公司16%按预算 交付
1.2 90年代的软件生产状况调查 —— 影响因素[Standish Group 1995]
成功项目的影响要素 影响指数
用户参与
高层管理支持 清晰的需求说明 正确的项目计划 切合实际的期望 细化的项目里程碑 员工能力 主人翁精神 清晰的目标和前景 努力工作 其他
15.9％
13.9％ 13.0％ 9.6％ 8.2％ 7.7％ 7.2％ 5.3％ 2.9％ 2.4％ 13.9％
1.1软件的发展 ——90年代的发展
机器为中心
指令码、汇编语言 BIOS 批量事务处理、计算性工作
应用为中心
3GL, OOL OS, Virtual Machine 基本业务处理，应用处理
企业为中心
4GL, CBD Middleware EAI, BPR, ERP, ...
50's
60's
90's
EAI:企业应用集成，CBD:基于组件的开发
1.2 90年代的软件生产状况调查 ——Standish Group 1995

365家公司的8380个项目
成功项目Success：在预计的时间之内，在预算的成本之下，完成 预期的所有功能 问题项目Challenged：已经完成，软件产品能够正常工作，但在 生产中或者超支，或者超期，或者实现的功能不全 失败项目Impaired：因无法进行而被中途撤销，或者最终产品无 法提交使用 250 222 Success Impaire 200 189
需求变化
缺乏计划 额外的无用功能 缺乏IT管理 技术能力不足 其他
8.7％
8.1％ 7.5％ 6.2％ 4.3％ 9.9％
1.2 90年代的软件生产状况调查 —— 影响因素[Standish Group 1995]

需求因素




用户参与（用户输入） 高层管理支持 清晰的需求说明 切合实际的期望 清晰的目标和前景 需求变化 额外的无用功能
对成功项目的影响指数为53.9％ 对问题项目的影响指数为55.6％ 对失败项目的影响指数为60.9％

综合来看，需求因素

1.2 90年代的软件生产状况调查 ——ESPITI，1996

欧洲软件协会ESI 欧洲软件过程改进培训计划项目ESPITI 17个国家的超过3800个组织
主要问题 60 50 40 30 20 10 0
需求管理 文档制作 软件测试 需求规格说明 文档 项目管理 编码
次要问题
不是问题
%
1.2 90年代的软件生产状况调查 ——需求问题的典型案例[Bray2002]





PROMS（演出权益协会）,11M￡,1992,未能以常人 能理解和检查的形式表述软件需求，软件规格说明也 考虑不周（与客户沟通的问题） RISP（西萨克斯地区信息系统计划）, 43M￡ ,1990, 缺少清晰的项目范围定义（需求的边界问题） TAURUS(伦敦股票交易), 75M￡(1.4B￡), 1993,未能 协调不一致的需求（不一致需求的管理问题） LASDS(伦敦救护车服务派遣系统), 1992,社会服务领 域糟糕的需求分析（需求不清晰） ATC(空中交通控制系统), 1.8B￡,1998-2001,缺乏健 壮的需求规格说明（需求没有搞清楚就匆忙开始工作 )

获得对目前代表性需求工程方法和技术的 一些实践经验
预备知识

软件工程

软件开发过程 基本的软件建模思想 基于逻辑的方法


基本的形式化建模手段

命题逻辑 谓词逻辑 简单的模态逻辑

基本状态变迁系统

应用软件开发的工程实践经验
参考书目


软件需求工程原理和方法，金芝编写科学 出版社 需求分析与系统设计 LESZEK.A 马素霞 等 译
经典文献
1. 2. 3. 4. 5. 6.
7. 8.
9. 10.
11.
12.
13.
14. 15.
16. 17.
Davis, A., A Taxonomy for the Early Stages of the Software Development Life Cycle, Journal of Systems and Software, 8(4): 297-311. 1988 Pohl, K., The Three Dimensions of Requirements Engineering. In: Rolland, C.; Bodart, F.; Cauvet, C. (Eds.) Proceedings of the 5th Conference on Advanced Information Systems Engineering. Lecture Notes in Computer Science 22: 275-292, Springer Verlag, 1993. Davis, A. M., Software Requirements: Objects, Functions and States, Prentice Hall, 1993. Flowers S., Software Failure: Management Failure, New York: Wiley, 1996. Grady, Jeffrey O., System Requirements Analysis, Mcgraw-Hill, 1993 Gunter, Carl A., Gunter, Elsa L., Jackson, M. and Zave, P., A Reference Model for Requirements and Specifications. IEEE Software 17(3), 2000 Jackson, M., Software Requirements and Specifications, Addison Wesley/ ACM Press, 1995 Loucopoulos, P., and Karakostas, V., System Requirements Engineering, McGraw-Hill Book Company Europe, 1995 Jackson, M., The meaning of requirements, Annals of Software Engineering 3: 5-21, 1997 Zave, P., Classification of Research Efforts in Requirements Engineering. ACM Computing Surveys, 29(4): 315-321, 1997 Zave, P., and Jackson, M., Four Dark Corners of Requirements Engineering, ACM Trans. Softw. Eng. Methodol. 6(1): 1-30, 1997 Ian Sommerville and Peter Sawyer, Requirements Engineering: A Good Practice Guide.Chichester, England: John Wiley&Sons, 1997 Kotonya, G., and Sommerville, Ian, Requirements Engineering: Processes and Techniques. John Wiley & Sons Ltd, 1998. Robertson, S., and Robertson, J., Mastering the Requirements Process, Addison-Wesley. 1999. Nuseibeh B, and Easterbrook S., Requirements engineering: A roadmap. Proc. of the 22nd Int'l Conf. on Software Engineering, Future of Software Engineering Track: 35-46. ACM Press, 2000. Bray, Ian K., An Introduction to Requirements Engineering, Addison-Wesley, Reading, MA, 2002 Davis, Alan M., Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House Publishing, 2005