第一讲需求工程导论
合集下载
《需求工程》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)
设计活动改变客观世界状 态
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章.需求工程导论
内容
课时 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章.需求工程导论
失败项目的影响要素
影响指数
不完整的需求说明
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章 需求工程概要
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
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
[编辑] 需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。
后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。
随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。
人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。
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.软件需求工程（如果仅是专门针对纯软件部分）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 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
课程安排 课程的目的和背景 教学大纲和主要内容 参考书目
课程安排
每周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