基础与框架
第一章 动机
一、软件密集型系统
- 定义：一个系统的功能和（或）质量的核心部分是通过软件实现的
信息系统：对信息或数据进行收集、存储、转换、处理。
嵌入式软件密集型系统：软件和硬件密切地集成在一起。
- 面临的问题：
基于软件的创新
日益增加的复杂性
降低成本的压力
更短的开发时间
更高的质量要求
二、需求工程的意义
- 需求缺陷
e.g 伦敦救护车服务计算机辅助调度系统（LAS）
在开发后期一处需求缺陷的成本很高
- 组织上下文中的需求工程
第二章 需求
一、需求的定义
IEEE 610.12-1990 标准将术语需求定义为：
用户解决某个问题或者达到某个目标所需要的条件或能力
一个系统或系统组建为了实现某个契约、不标准、规格说明或其他需要遵循的文件而必须满足的条件或拥有的能力
对上述条件或能力的文档化表示
文档化的需求被称为“需求制品”
二、需求类型
- 功能性需求
系统应该向用户提供的功能。
功能性需求通常使用三个互补但部分重叠的视图进行文档化：数据视图、功能视图和行为视图。
- 质量需求
质量需求定义了一个系统或组件、服务或功能的质量特性。
（1）类型
用户关心：
可用性
效率
灵活性
完整性
互操作性
可靠性
健壮性
易用性
开发者关心：
可维护性
可移植性
可复用性
可测试性
（2）非功能性需求
非功能性需求很多时候在描述不明确的功能性需求，或者一个质量需求。
非功能性需求经常掩盖不明确的功能性需求，并导致了对所期望的系统属性做不明确的解读。
- 约束
约束是一种限制了系统开发方式的组织或技术要求。
影响系统的约束：
C1：市消防部门要求门市部终端的尺寸不能超过120cm（长）×90cm（宽）× 20cm（深）。
影响开发过程的约束：
C2：系统必须使用Rational 统一进行开发。
三、问题和解决方案
整体的系统设想→做什么？
详细的需求过程→怎么做？
双高峰模型：说明了需求定义和体系结构设计之间的双向交互作用。
需求工程和体系结构设计之间的交互作用
双高峰模型将需求求工程和体系结构设计之间的交互关系描述为需求和体系结构的螺旋过程，并伴随着粗粒度制品逐渐转化为更细粒度的制品。
高抽象层次上的需求制品被用来定义初始的系统体系结构。体系结构设计决策引发对初始的粗粒度需求的修改和精化。这又一次导致了对系统体系结构的修改和精化。
结论：大部分需求在描述的时候都伴随着脑海中考虑的解决方案。
第三章 持续的需求工程
一、系统分析
系统分析：对一个现有系统或者过程进行分析的基础上定义一个新系统需求的各种不同的方法。
传统系统分析：功能、数据、行为来定义。这三种试图互补且互相重叠。
分析方法：结构化分析方法（structured analysis,SA）、本质系统分析（Essential Systems Analysis）、现代结构化分析（Modern Structured Analysis）
- 结构化分析方法
结构化分析使用数据流图来描述系统功能以及每个功能的输入和输出数据流。
当前状态分析：记录+文档化
期望状态定义：指出潜在改进。
- 本质系统分析
本质（essence）：
系统的本质
真实需求是系统必须拥有以满足其目标的一种特征或能力，无论系统如何实现。我们将一个系统真实需求的完整集合称为系统本质或本质需求。
实现系统的技术由两种部件类型组成：
执行活动的处理器
存储并为处理器提供数据的容器
系统对应物（Incarnation of a system）：
所有用来实现系统的本质活动和存储器的事物的总和就是系统对应物.
本质模型的优势：
更稳定
更小
无设计限制
现有系统和新系统没有明显的不同
对系统本质和对应物的区分的基本原则独立于系统开发所使用的过程或方法，因此可以应用于一般的开发过程和方法。例如：
V模型
V-Model XT
敏捷方法
Rational统一过程
二、需求工程的持续性
两种持续的需求工程的质量层次：
需求工程作为跨生存周期的活动
需求工程作为跨项目和跨产品的活动
第四章 需求工程框架
一、目标：在上下文中建立愿景
期望（vision）：精确地定义所期望的改变的本质
清晰可定义的目标
二、框架
组成：
-
系统上下文
主体刻面
使用刻面
IT系统可免
开发刻面
-
三个核心需求工程活动
抽取
文档化
协商
-
两项横切活动
确认活动
管理活动
-
需求制品
目标
场景
面向方案的需求
三、四个上下文刻面
- 定义
主体刻面：包含了系统上下文中与系统相关的对象与事件。
换言之，与这些主体刻面中的对象和时间相关的信息必须在系统中加以表示。
例子：测量车速的软件衡量抽象对象“速度”
主体刻面包含了一些影响系统中对象和时间相关信息表示的方面，力图禁止或限制软件密集型系统对某类数据进行记录的法规，限制所记录数据精确性或数据更新频率的法规。
使用刻面：一个软件密集型系统由人或其他系统使用从而达成一个目标或完成某项具体任务。包含了与人或其他系统对本系统的使用相关的所有方面。
例如：已存在的各种使用目标、期待的工作流、具有各种特性的不同用户组、具有不同接口的各种交互模型，以及限制或影响系统使用的法规和标准。
IT系统刻面：待开发的系统最终要被部署在现有IT基础设施上。IT系统可免由运行与技术环境的所有方面构成，包括那些定义了如何使用各种技术与运行环境的约束或指南的仿真和策略。
例如，通信协议，软件平台预定义的一组操作系统。
开发刻面：包含了与系统开发过程相关的上下文方面，包括过程准则与约束、开发工具、质量保障方法、成熟度模型、质量认证，以及其他确保软件密集型系统质量（如安全性、保密性）的数段或技术。
例如：某项标准可能要求特定的测试准则。
- 逻辑关系
软件密集型系统需要现世界中对象（主体刻面）表示，系统使用现有的技术（IT系统刻面中）实现其数字化表示。
系统根据定义的功能处理所表示的信息，通过某种接口将处理后结果展现给用户体现了IT系统刻面的和使用刻面的关系。
系统用户将对系统输出进行解读，并将其与主体刻面中的现实世界对象联系起来。
开发刻面和其他三个刻面都存在关系。
四、三个核心活动
- 需求工程的三个维度
内容维度：被用来理解所获取的系统需求。
共识维度：与相关涉众就已知需求理解取得共识的程度相关。
-
文档化维度：采用各种文档化/规格说明格式对系统需求进行文档化和规约描述。
笔记梗概、即时陈述、手工绘图→建模语言和模板
需求工程的目标：
需求工程是一个协作式的、不断迭代以及增量的过程，旨在确保：
（1）所有相关的需求都在所需要的细节层次上得到了清晰的了解和理解。
（2）在相关涉众见建立起对于系统需求的充分认识。
（3）所有需求都依照文档化/规格说明格式进行了文档化和规约描述。
- 核心活动
文档化：依照文档化/规格说明格式进行了文档化和规约描述
几类规范：
总体文档规范：用于记录所有信息，例如访谈、会议安排、关于系统上下文的决策、原理信息
文档规范：适用于需求工程过程的各个阶段所定义的每一项需求，保证需求文档质量。一般用于协商或者验证。
规约规范：适用于软件规格说明中所包含的所有需求。旨在保证需求规约描述的质量。
抽取：改进对需求的理解，在内容维度上取得进展。
协商：满足不同涉众的要求和期望。
五、两个横切活动
- 确认
需求制品的确认：发现需求的缺陷。
核心活动的确认：目的是检查活动的执行符合过程规约或者活动规约。
系统上下文考虑因素的确认：确认需求工程是否按照期望的方式对系统上下文进行了考虑。
- 管理
-
需求制品的管理
确定需求优先级
需求的持久化保存
需求的配置管理
需求的变更管理
活动的管理：包含对需求工程活动的规划和控制。
系统上下文的观察：识别上下文变更。
- 五个活动之间的关系
互相影响：比如
附加需求的抽取
遗漏需求的发现
规格说明中需求的移除
六、三种需求制品
需求制品：被文档化的需求。
- 目标
定义：关于系统的目的、属性或者使用的意图。
含有指示性，表达了对于系统的期望和要求。
G1：系统应该自动引导驾驶员到达指定地点。
G2：响应时间比先前系统至少降低20%。
目标刻画涉众的意图，对系统愿景精化为系统将实现的目的。
目标和解决方案无关。
- 场景
定义：场景描述了一个目标（或一组目标）被满足或者未被满足的具体实例。它提供一个或多个目标的具体细节。一个场景通常定义了一系列为满足目标而执行的交互步骤，并将这些交互步骤和系统上下文联系起来。
自动刹车操作 场景
Carl正驾驶汽车以毎小时50英里的速度在高速公路上行驶。Peter驾驶另一辆车在Carl前方 行驶，Peter开始刹车减速，当Carl发现Peter在减速后，Carl也踩下了刹车踏扳。此时Carl的车 载系统检测到与前方车辆的距离已不在安全距离内，因此向驾驶员发出警告。接着，两辆车的距 离继续拉近。此时，为了帮助驾驶员，车载系统会启动自动全刹车，并通知Carl开启了自动全 刹车。当两辆车之间的距离停止减少后，系统会中止全刹车动作。但是，系统会继续控制Carl 车辆的速度，直到与前车之间的距离拉大到安全距离，然后终止此次动作并通知Carl。
- 面向方案的需求
定义了数据流图、功能视图和行为视图，此外还包括质量需求以及约束。
