SEII-2
02-需求基础
需求工程
所有需求处理活动的总和。它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终描述出软件被应用后与其环境互动形成的期望效应。
主要任务：
- 需求工程必须说明软件系统将被应用的应用环境及其目标，说明用来达成这些目标的软件功能，也即要同时说明软件需要“做什么”和“为什么”需要做。
- 需求工程必须将目标和功能反映到软件系统当中，映射为可行的软件行为，并对软件行为进行准确的规格说明。
- 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标和功能随着时间演化的变动情况。
活动：
需求开发过程模型：
需求获取的方法：
- 面谈
- 集体获取方法
- 头脑风暴
- 原型
需求分析的内容：
一、边界分析
- 定义项目的范围
- 系统边界的定义要保证系统能够和周围环境形成有效的互动
- 系统用例图通常被用来定义系统的边界
二、需求建模
- 建模是为展现和解释信息而进行的抽象描述活动
- 常用的技术包括类图、顺序图、状态图等建模技术
需求
定义：
- 用户为了解决问题或达到某些目标所需要的条件或能力；
- 系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；
- 对⑴或⑵中的一个条件或一种能力的一种文档化表述。
作为一种期望，需求通常被表述为“系统应该…”、“在…时，系统应该…”、“用户可以通过系统…”等
需求规格的定义
软件产品的方案描述，它以软件产品的运行机制为主要内容。
它不是需求但实现需求，不是问题域但需要与问题域互动
规格说明要以关注对外交互的方式描述软件解决方案，它既需要从软件产品的角度而不是用户的角度进行描述，又不能太多地涉及软件产品的内部构造机制。
需求的层次性
业务需求
系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统
为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature）
参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision）
特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）
用户需求
执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么
可能来自直接用户，也可能来自间接用户（通用软件的销售人员和售后支持人员）
对所有的用户需求，都应该有充分的问题域知识作为背景支持
特性
- 模糊、不清晰（允许适度的用形容词和副词）
- 多特性混杂 （功能和非功能的混杂）
- 多逻辑混杂 （一个任务需要多次系统交互才能完成）
系统需求
用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节
描述了开发人员需要实现什么
将用户需求转化为系统需求的过程是一个复杂的过程：首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
从功能需求的层次性看需求开发：
需求的分类
需求谱系：
需求的分类：
功能需求（Functional Requirement）：
和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功
能需求主要表现为系统和环境之间的行为交互。性能需求（Performance Requirement）：
系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
质量属性（Quality Attribute）：
系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
对外接口（External Interface）：
系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
约束
进行系统构造时需要遵守的约束，例如编程语言、硬件设施等