1.1 需求的定义
从用户的角度看，需求是用户为了解决问题或达到某些目标所需要的条件或能力。
从开发者的角度看，需求是系统或系统部件为了满足合同，标准，规范或其他正式文档规定的要求而需要具备的能力或条件。
1.2 基本概念的区分（问题，需求，问题域，解系统）
1.2.1 问题域与解系统
当现实状况与人们的期望产生了差距，就产生了问题。
要解决问题，就要改变现实中某些实体的状态或其状态的演进顺序，使其达到期望的状态和理想的演进顺序。
这些实体和状态构成了问题解决的基本条件，称为该问题的问题域。
软件系统通过影响问题域，能够帮人们解决问题，称为解系统。
1.2.2 共享现象
软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对于问题域的某些部分具有模拟性。
换句话说，软件系统含有问题域中某些部分的模型（数据模型，对象模型，处理模型等等），因此，问题域的某些信息可以和模型中的信息建立映射关系，这些通过映射建立的共同信息，就是问题域和解系统的共享现象。
1.2.3 问题域特性
问题域是自治的，它有自己的运行规律，而且这些规律不会因为解系统的引入而发生改变。
需要关注的问题域特性：间接特性，约束和假设，社会性因素。
1.2.4 规格说明
规格说明是解系统为满足用户需求而提供的解决方案，规定了系统的行为特征。
主要包括：（1）对于共享现象的描述 （2）系统对共享现象施加操作的描述。
1.3 需求的层次性（功能需求）
功能需求表现为三个层次：业务需求（Business Requirement），用户需求（User Requirement），系统需求（System Requirement）。
1.3.1 业务需求
系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统。
BR1:实现车辆的同意管理和有效使用。
1.3.2 用户需求
执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统具体帮助用户做些什么。
UR1：在需要使用车辆时，用户需要填写一个车辆使用申请单，然后等待申请单的反馈信息，并根据反馈信息使用车辆。
在实际工作中，用户需求通常会涉及问题域知识，例如UR1,需要补充问题域知识PD1：
PD1:申请单的内容包括：。。。申请单的反馈内容包括。。。。
1.3.3 系统需求
系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么。
将用户需求转化为系统需求的过程是一个复杂的过程
首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型；
然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。
该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。
1.4 需求的常见类型
【IEEE1998】将需求分为五类：
（1）功能需求（Functional Requirement）
（2）性能需求（Performance Requirement）
（3）质量属性（Quality Attribute）
（4）对外接口（External Interface）
（5）约束（Constraint）
