2020-12-28 A001-186-2636

个人作业
姓名：***
班级：18软6

第一章需求工程导论

1.1软件生产中的需求问题

无论是实践者的切身体会，还是各种调查数据，都明确指出需求问题是当前软件开发面临的 主要问题之一。在这些导致需求问题的原因当中，一个最为重要的原因是：未能很好地理解和掌握“应用” 型软件的模拟特性以及由此而产生的一系列影响和要求。
软件的模拟特性来源于其知识载体的特性：软件在运行中表现岀来的特性、行为应该和应用 的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件 “模拟”了现实。软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。当然，软件对现实世界的“模拟”并不是机械和被动的。在投入使用之后，它也会通过相应 的对外接口对其周围环境产生必要的影响，并进一步帮助人们解决现实世界中遇到的问题。只是它必须以准确的现实理解为基础，在现实的制约之下对外施加影响，进而解决问题。
软件可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。专业用户通常以软件为中心开展工作，工具软件是他们的主要手段，因此面向专业用户的纯工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。普通用户利用软件的目的通常仅限于解决一些实际问题，软件仅仅是一种辅助性的手段，因 此面向普通用户的纯工具型软件以功能的有用性为首要成功标准，应用型软件在“模拟”现实的基础之上接收用户的请求，协助用户完成任务，它正确工作的 基础是具有“模拟”性。应用型软件一般以普通用户为应用对象，因此也要求具有使用的方便性。
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求问题的产生。主要有非技术性和社会性因素重视不足，传统需求分析方法的缺陷，软件规模的日益扩大，需求问题的高代价性等原因。

1.2需求工程

需求工程是软件工程的一个分支，它关注软件系统所应实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。需求工程有以下3个主要任务：
需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制 和约束，即要同时说明软件需要“做什么”和“为什么”需要做。
需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试、 用户手册编写等很多后续软件开发阶段的工作基础。
现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和 约束在软件产品族中的演化和分布情况进行综合考虑与处理。
需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特 性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需求验证4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在需求开发活动之后，保证所确定的需求能够在后续的项目活动中有效地发挥作用，保证各种活动的开展都符合需求要求。
1.基本活动
需求工程为了完成其任务,需要执行一系列的任务，具体如图1-1所示。

图1-1
系统化的需求工程将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到重要作用。系统需求开发又被称为需求工程的早期阶段(early phase)。软件需求开发相应被称为需求工程的后期阶段(late phase) 0计算系统工程通常是指将计算机引入某一现实系统，并用它来改变现实系统的运作方式，达到一个理想效果的过程。在计算系统工程中，软件通常具有重要的作用，但系统工程中除了含有处理软件的软件工程之外，还包括硬件工程和人力工程。
人们很早就认识到需求工程的重要性，最为困难的概念性工作便是编写详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时，这也是一旦有错最终将会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
有些特定问题的具体特性掩盖了需求工程的重要性。常见的情况有两类：问题广为人知，问题小而简单。
需求工程的复杂性体现在以下几个方面：处理范围广泛，涉及诸多参与方，处理内容多样，处理活动互相交织，处理结果要求苛刻等。
1.3需求工程师
需求工程师是涉众和开发者之间的桥梁。
需求工程师一切工作的核心就是扮演好桥梁作用：在面对涉众时，需求工程师就是后续软件开发者的代理，负责设计软件方案以满足涉众的各项需求；在面对后续软件开发者时，需求工程师就是涉众的代理，准确地将各项需求告知开发者。
因为要代表开发者为涉众提供软件解决方案，所以需求工程师必须熟练掌握软件开发方法与技术，保证设计出来的软件解决方案既是可行的又是成本效益比有效的。
需求工程师还要代表涉众把他们的想法准确地告知开发者，所以需求工程师必须要有非常精确的表达能力，尤其是文档化能力。需求工程师要从涉众那里得到他们的想法并转化为开发者需要的知识，所以需求工程师必须有非常好的交流沟通能力以了解涉众的想法，必须要有抽象建模与分析的能力以准确定义涉众的想法。

第二章需求基础

2.1需求的定义

需求是需求工程中一个非常难以准确定义和解释的概念。
IEEE的定义中同时包括了用户的观点（第一种条件和能力）和开发者的观点（第二种条件和能力），它强调了“需求”的两个不可分割的方面：需求是以用户为中心的，是与问题相联系的；需求要被清晰、明确地写在文档上。

2.2满足需求就是解决问题

需求源于问题，要准确理解需求，就必须明确它与问题的关系。解决问题、改善现实、满足用户期望的条件与能力就是需求。
问题域是需求的背景，要理解需求就必须先理解问题域。问题域的背景信息又被称为问题域特性o与需求相区别的是，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的引入而发生改变。需求是一种对未来的期望，是可以打折、部分满足甚至不予满足的；而问题域特性是既定现实，可以改善但不能忽视，更不能违背的。
解系统是问题的解决手段，并不是问题的产生地，所以解系统并不是问题域的一部分。解系统与问题域之间存在可以互相影响的接口，以实现交互活动。
需求工程师要注意区分用户与软件开发人员在关注点上的不同：用户关注于问题域，软件开发人员更关注解系统。需求是用户对问题域中的实体状态或事件的期望描述，
解系统的核心是软件解决方案和解决方案在通用计算机上的实现。虽然解决方案及其实现都关注于软件系统本身，但相互间也有所不同。解决方案描述的是软件系统与问题域交互的过程，侧重于软件系统中与外界交互的部分。实现部分则主要是软件内部的组成元素、结构关系、 物理实现等软件系统的构造要素。需求工程所关心的仅仅是解决方案，不涉及软件的实现细节。
在需求开发过程中，问题域中的用户提出问题与需求。需求工程师接收用户问题与需求，分析问题域背景，建立软件解决方案，并将解决方案传递给后续软件开发者。软件开发者负责将软 件解决方案变为软件实现。在整个工作衔接中，需求是用户与需求工程师的协作基础，解决方案是需求工程师与软件开发者的协作基础。
问题域与解系统能够形成互动的基础是解系统部分模拟了问题模拟并操纵共享现象是软件系统满足需求最直接的方法，但有些情况下软件系统也会使用间接的方法解决问题：软件系统操纵共享现象影响问题域的一部分,然后利用问题域内在的规律性自动影响另一部分。
域,[Jackson 1995b]将这种模拟性称为共享现象 o模拟是指其中一方仿制另一方的信息。解系统与问题域模拟的交互性其实是由人在意识中强制建立的。共享现象就是解系统所模拟的问题域部分，该部分在两个系统中同时存在。
考虑问题解决和需求满足的方法时，成本是重要的因素。如果成本能够接受，就尽量使用直接的方式解决，如果成本太高，就可以折中使用间接方式解决。
间接解决方式也提醒需求工程师，考虑到问题域内的规律性，在设计解决方案时要防止解系统的引入在问题域中引发未预见的连锁反应，这种反应可能会使解决方案无法达到预期目的，甚至造成不良的负面效应。
防止未预见的连锁反应尤其要关注间接特性。间接特性不会与解系统直接交互，不会受到解系统的直接影响，但是却可能因为连锁反应而受到影响。
需求规格说明主要包括两部分（如图2-2所示）：对共享现象（模型）的描述和对系统对共享现象所施加的操作的描述。这也是软件系统中最为核心的两个部分：数据与功能。
如果拥有描述明确的问题域特性E和定义良好的系统行为S,就可以很容易地发现将系统应用到问 题域后会产生的效果。这种效果如果符合预期的需求X,那么系统就是满足人们需要的系统。所以需求工程的目的就是根据E,构建S,使得E和S的联合 作用效果符合需求R：E,SJR。
从这里可以发现需求工程的困难之处：①不存在描述明确的Eo，②不存在确定的针对S的评估标准R。③根据问题域特性和系统行为推测系统应用效果是简单的推理过程，即E,S—R 是简单的，但根据问题域特性和期望的系统应用效果构建系统行为的过程是困难的，E,R=S是一个创造性的过程。
这些困难也恰好说明了需求工程的主要工作：①进行需求开发，确定用户的期望效果R; ②研究问题背景，描述问题域特性E；③构建解系统，描述解系统行为S,使得E,S—R°。

2.3需求和问题都有层次性

问题和期望粒度不同的现象被称为需求的不同抽象层次。需求最为常见的 抽象层次有3层：①业务需求，针对整个业务的期望。②用户需求 ，针对具体任务的期望，如R8。③系统级需求，针对用户与系统一次交互的期望。
业务需求是抽象层次最高的需求，是系统建立的战略岀发点，表现为高层次的目标,它描述了组织为什么要开发系统。业务需求可验证的数值指标是通过研究问题域的背景资料得出的。
为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性o高层次的解决方案及系统特性指出了系统建立的方向，参与各方必须就它们 达成一致，以建立一个共同的前景，保证涉众朝着同一个方向努力。以支持业务需求的满足为衡量标准，系统特性说明了系统为用户提供的各项功能，它限定了系统的范围,定义良好的系统特性可以帮助用户和开发者确定系统的边界。
用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求主要来自系统的使 用者——用户。在有些情况下，系统的直接用户不可知，如通用的软件系统或社会服务领域的软件系统等，所以用户需求也可能来自间接的渠道。
用户的任务可以有粒度不同的抽象表述，大的任务可以包含（分解为）小的任务。在实践中，用户需求到底使用哪个粒度与抽象层次要依据软件系统的复杂度而定。
需求工程师需要根据用户的需求整理完整的问题域知识。
业务需求描述了系统的目标与效益，适合决策者；用户需求描述了具体任务，适合用户。适合软件开发者的需求层次是系统级需求，它关注的是软件系统的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供响应。
系统级需求比用户需求更加详细和准确，包含更多的技术细节。对于开发人员来说，系统级需求对功能的定义更准确，每一条系统级需求恰好就是开发人员需要完成的一个设计决策。
为了节省开发时间，在实际开发中有些开发者更愿意使用用户需求而不是系统级需求作为后续开发的基础。
一个软件系统的系统级需求集合定义了相应业务需求及用户需求的解决方案，构成了需 求规格说明的主体部分。解系统及其需求规格说明都是不属于现实的，是人们为了解决问题而构建的，所以系统级需求无法直接从现实中得到。相比之下，业务需求直接或间接地来源于决策者，用户需求直接或间接地来源于用户，而系统级需求就只能通过技术加工获得。
技术加工过程被称为需求分析，其源对象是用户需求及相关的问题域知识，处理方式是利用分 析方法、技术建立需求分析模型，并基于需求分析模型将用户需求及问题域知识转化为系统 级需求。将用户需求转化为系统级需求是一个复杂的活动，详细情况请参见本书的需求分析 部分。
功能需求的3个不同抽象层次之间有紧密的联系。在3个不同层次的功能需求中，业务需求具有明显的目的 性和较高的抽象性，比较容易获取和确认。所以需求开发往往从获取业务需求开始。有了业务需求之后，就可以确定系统的 最终目标和努力方向，进而指导具体的需求获取活动，发现用 户需求。用户需求经过明确和细化的处理，可以转化为系统级 需求。从另一个角度讲，系统开发者理想中的需求是系统级需求，因 为开发者可以直接将系统级需求映射为系统行为，进行设计和开发。但是因为系统级需求是无法直接或间接从现实中获取的，所 以开发者只能退而求其次——获取用户需求，并通过分析活动将 其转化为系统级需求。随之而来的另一个问题是，用户需求的获取过程非常复杂，涉及众多参与者和诸多问题， 要成功地获取用户需求，首先要协调参与者的立场和问题的范围，而这只能通过对业务需求 的处理进行解决一根据业务需求，协调涉众的立场，限定问题的范围，指导用户需求的获取过程。

2.4需求的分类和表述

分类的目的是为了区别对待，否则分类就失去了意义。需求分类是为了将需求划分为需要 区别对待的不同类型，每种类型会被文档化到不同的部分，服务于不同的读者、不同的目的。
广泛意义上的需求谱系:
要解决一个问题，人们需要将软件、硬件和人力资源联合起来，这种联合的形式被称为系统 工程，包括软件工程、硬件工程和人力资源管理。
从严格的意义上来说，项目需求与过程需求都不能算是需求，因为它们并不是用户对问题解 决的期望，而是用户对软件开发活动本身的要求。硬件需求与其他需束也不属于用户对问题解 决的期望，而是为了让软件能够成功运营而需要适应的环境与活动。但是在文档化需求的材料 中，经常会出现项目需求、过程需求、硬件需求和其他需求，因为它们对需求工程师及开发者正确 理解软件需求甚至整个产品具有极其重要和不可缺少的作用，所以它们经常出现在需求文档中(一般位于非主体部分，如需求文档的开头或末尾部分)，供项目管理者和系统工程师阅读。
严格意义上的软件需求分类:
从严格意义上讲，软件需求是直接或间接关系到软件系统功能的期望。根据不同的分类标 准，可以将需求分成不同的种类。在各种需求分类中最常见的是［IEEE 1998］的分类,［IEEE 1998］将需求分成下列几个类别。
①功能需求(functional requirement):和系统主要工作相关的需求，即在不考虑物理约束的 情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现 为系统和环境之间的行为交互。
②性能需求(performance requirement):系统整体或其组成部分应该拥有的性能特征，如 CPU使用率和内存使用率等。
③质量属性(quality attribute)：系统完成工作的质量,即系统需要在一个“好的程度”上实现 功能需求，如可靠性程度和可维护性程度等。
④对外接口 (external interface):系统和环境中其他系统之间需要建立的接口，包括硬件接 口、软件接口和数据库接口等。
⑤约束(constraint):进行系统构造时需要遵守的约束，如编程语言和硬件设施等。
除了上述5种明确的软件需求类别之外,［IEEE 1998］还指出项目中也可能会出现逻辑数据 需求等其他特殊类型的需求。
除功能需求之外的其他4种类别需求又被统称为非功能需求。 在非功能需求中质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指 质量属性。
功能需求是软件系统需求中最常见和最重要的需求，同时也是最为复杂的需求。
通常一个软件系统的绝大部分需求都是功能需求。虽然在类别划分上功能需求只是5种类 别之一，但在比例上功能需求有可能占所有需求的90%以上。进行这样不均衡比例的划分，是因 为功能需求的处理方式是一致的。
功能需求是一个软件产品得以存在的原因，是软件系统能够解决用户问题和产生价值的基 础，也是整个软件开发工作的基础。所有开发者都需要了解功能需求。在复杂的系统中功能需 求数量太多，所以需要将它组织为多个独立部分，然后按照分工原则由不同的开发者来处理不同 的部分。
在大规模软件系统中，因为其功能需求比较复杂，所以它是最需要按照3个抽象层次进行展 开的需求类别，也就是说功能需求的开发要围绕“目标-任务-交互”。
[IEEE 1990]对性能的定义是：一个系统或其组成部分在限定的约束下，完成其指定功能的 程度，如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的 功能。性能需求的定义要适合于运行环境。给出一个合适的量化目标是非常关键的，但同 时也是非常困难的。更加常见的方法是在限定性能目标的同时给出一定的灵活性)或 者给出多个不同层次的目标要求。
质量属性的概念:
在软件系统的开发和使用过程中，人们很自然地关注系统的功能，它是系统能够为用户提供 帮助的第一要素。但成功的软件系统除了满足功能需求之外，还需要满足更多的要求，如易于使 用和少出错等。
功能需求是用户对软件系统的显式要求，用户在软件系统创建之前就可以清晰地向开发者 表达这种要求。而非功能需求属于隐式要求，用户在软件系统创建之前无法清晰地告诉开发者 他们希望该系统具备什么样的非功能性特征。
成功的软件系统必须满足显式的及隐含的各种要求。系统为满足显式的及隐含的要求而需 要具备的要素称为质量。
为了度量一个系统的质量，人们通常会选用系统的某些质量要素进行量化处理，建立质量特 征，这些特征称为质量属性。
为了更好地根据质量属性描述和评价系统的整体质量，人们从很多质量属性的定义中选择 了一些能够相互配合、相互联系的特征集，它们被称为质量模型。
质量属性应该和功能需求一样得到足够的重视。真实的现实系统中，在决定系统的成功或 失败的因素中，满足非功能属性往往比满足功能需求更为重要°在设计开始之初就确定质量属性要求 非常重要，而且对越复杂的系统越为重要。
1.常见的质量属性需求
(1)可靠性(reliability)
可靠性是指在规定时间间隔内和规定条件下，系统或部件执行所要求功能的能力。
(2)可用性(availability)
可用性指软件系统在投入使用时可操作和可访问的程度，或能实现其指定系统功能的概率。
(3)安全性(security)
安全性是指软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意的， 也可能是无意的。
(4)可维护性(maintainability)
可维护性指为排除故障、改进质量或适应环境变化而修改软件系统或部件的容易程度，包括 可修改性和可扩展性。
(5 )可移植性(portability)
可移植性指系统或部件能从一种硬件或软件环境转换至另外一种环境的特性。
(6)易用性(usability)
易用性指与用户使用软件所花费的努力及其对使用的评价相关的特性。
对于解系统而言，问题域中的其他软件系统也属于问题域的一部分，且为一个比较特殊的部 分。因此用户有权对解系统和其他系统之间的软硬件接口提出要求。解系统的对外接口也是一 种重要的需求。
对系统之间的软硬件接口需要说明以下内容(如需求IR1所示)：
•接口的用途；
•接口的输入输出；
•数据格式；
•命令格式；
·异常处理要求。
用户界面在有些情况下也会被视为系统的对外接口，被作为一种重要的需求。
约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。因为不受解系统的影 响，所以从解决问题的角度来看约束不会要求解系统为其进行专门的设计。但是如果解系统不 满足约束，那就意味着问题域并不能够提供解系统要求的运行环境，解系统将无法在问题域内成 功地部署和运行。因此，约束是在总体上限制了开发人员设计和构建系统时的选择范围。
常见的约束主要有以下几种。
①系统开发及运行的环境（如Constraint-1 ）o包括目标计算机、操作系统、网络环境、编程 语言和数据库管理系统等。
Constraint-1:系统要能够在Windows和Linux两种操作系统上运行。
②问题域内的相关标准（如Constraint-2） o包括法律法规、行业协定和企业规章等。
Constraint-2：系统的保密性能要符合*XX法律第XXX条的要求。
③商业规则。用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选 择范围。
④社会性因素。文化、信仰等社会性因素。
实践中，需求文档还常常会文档化其他类型的需求，如安装需求0R1、培训需求0R2和数据 需求等，其中数据需求较为常见。
0R1：在安装系统时，要初始化用户和商品库存等重要数据。
0R2：系统投入使用时，需要对用户进行为期一周的集中培训。

2.5优秀需求的特性

1.完备性
优秀的需求是完备(complete)的，它不需要做更多的扩展就可以充分说明用户需要的系统 功能。完备性的判断标准是：需求是否描述了开发人员设计和实现这项功能所需的所有信息。 只有完备的需求在开发中才可能被独立出来，单独对待。在需求开发过程中，对于不清晰的信息 可以标记为TBD ( To Be Determined,待确定)，但在需求开发结束之前，所有的TBD都必须被 解决。
2.正确性
每一项需求都必须正确描述所需要的系统功能，要真实反映用户的意图，所以需求的正确性 又常被称为真实性（real）。需求的正确性只有提出需求的人才能加以判断，所以需求在传递给 开发人员之前，必须请需求的提出者予以确认。
3.可行性
需求必须能够在系统及其运行环境的已知条件和约束下实现。用户无法判断需求的技术可 行性，所以需求的可行性是由开发人员进行检査的。在检查的过程中，开发人员可能需要进行一 定的分析和研究，而不是单纯地凭借经验和直觉。对于难以判断的需求，必要时要通过开发原型 来加以验证。
不可行的需求又被称为不切实际的期望(unrealistic expectations),是实践中常见的需求定义 问题，而且它在很大程度上影响着项目的成败。
4.必要性
每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之 后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的 资源。
5.无歧义
需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应 该有而且只能有一种解释，即需求无歧义。

6.可验证
需求应该是可验证的，也就是说通过分析、检查、模拟或测试等方法能够判断需求是否被满 足。如果需求不可验证，就无法判断完成的系统是否满足了该需求，开发人员也无法去选择一个 能够实现该需求的方法。

第三章需求工程过程

3.1需求工程活动

需求获取是从人、文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需 求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来 “发现”需求。
在需求获取中，需求工程师通常需要执行的任务包括以下几方面。
1.收集背景资料
2.获取问题与目标，定义项目前景与范围
3.识别涉众，选择信息的来源
4.选择获取方法，执行获取，获取功能与非功能需求
5.记录获取结果
需求分析的主要工作是通过建模来整合各种信息，以使人们更好地理解问题。同时，需求分 析工作还会为问题定义一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分 析还需要检査需求中存在的错误、遗漏和不一致等各种缺陷，并加以修正。
在需求分析阶段，需求工程师主要的任务包括以下几方面。
1.背景分析
2.问题分析、目标分析、业务分析，确定系统边界
3.软件需求建模
4.细化需求
5.确定优先级
6.需求协商
获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用 户需求文档（或用例文档），系统级需求被写入需求规格说明。
需求工程师在这个阶段的主要工作包括以下几方面。
1.定制文档模板
2.编写文档
为了尽可能地不给设计、实现、测试等后续开发活动带来不必要的影响，需求规格说明文档 至少要满足下面几个标准：
•文档内每条需求都正确、准确地反映了用户的意图。
•文档记录的需求集在整体上具有完整性和一致性。
•文档的组织方式和需求的书写方式具有可读性和可修改性。
需求验证阶段的主要任务包括以下两方面。
1.执行验证
2.问题修正
在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工 作“需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。所以，在需求 开发结束之后，还需要有一种力量保证需求作用的持续、稳定和有效发挥，需求管理就是这样的 一个管理活动。需求管理会进行变更控制，纳入和实现合理的变更请 求，拒绝不合理的变更请求，控制变更的成本和影响范围。
在企业界的实践中，需求变更被认为是导致项目失败的两个主要原因之一。
需求管理阶段的主要任务包括以下几方面。
1.建立和维护需求基线集
2.建立需求跟踪信息
3.进行变更控制

3.2需求开发过程是迭代和并发的

为软件开发的一个阶段，需求开发与软件开发一样存在着大量的不确定 性，甚至是软件开发中不确定性最多的一个阶段，所以需求开发与软件开发一样都应该是 迭代的。
需求开发不仅是迭代的，而且它的两个重要活动——需求获取与需求分析——还是交织的。 需求获取与需求分析是需求开发中的两个主体活动，它们共同构成一个学习过程。

3.3实践方法的应用

在工程领域中，如果能够建立比较完整的知识体系，那么就可以在知识体系的指导下进行规 律性和系统化的生产。
相反，在完全没有形成知识认知的全新工程领域中，就只能纯粹依赖生产 者的个人才智来进行工作。也有介于上述两种情况之间的工程领域：它们还没有形成完整的知 识体系，所以无法实现大工业化的生产方式；同时这些工程领域又经过了相当时间的探索，从生 产者大量的个人行为中总结出了一些有效的工作方式和行为方法。这些有效的工作方式和行为 方法虽然比较琐碎和孤立，和知识体系的要求还有很大的距离，但是它们却能够很好地帮助人们 更快更好地进行工程实践，所以被称为实践方法（practice；又被称为原则,principle）。
实践方法是人们能够从陌生的知识领域中得到的最早的知识片段和知识形式。
经过长期的实践，人们在需求工程领域发现和创造了很多用于处理这些需求工程细节的方 法和经验，其中一些取得了显著的成功，被人们所广泛接受。因此，需求工程师的一项重要工作 就是理解业界好的实践，并将它们成功地应用到组织的需求工程过程当中去。

3.4需求开发过程实例

近些年比较受欢迎的敏捷软件开发方法强调原则与实践，而不是固定的过程模型，这一特点 在需求工程中也有体现。［Cao 2008］在调査中发现敏捷软件开发方法主要通过7个实践完成需 求开发：
•面对面的交流胜过写规格说明文档；
・迭代式需求工程；
・将需求划分优先级做到极限；
•通过持续规划管理需求变更；
•原型法；
•测试驱动开发；
-用户评审会议与验收测试。

3.5需求开发过程与软件工程过程的相互影响

需求开发过程之所以对后续软件开发过程有重要影响，并不仅仅是因为它的结果制 品——需求一是后续开发过程的工作基础，更要认识到需求开发过程中还会产生很多正 性信息
如果单纯从产生软件 需求规格这个任务来看，这些正性信息都是不必要的，但它们对后续软件开发过程的影响 则是明显的。也就是说，为了让整个软件开发团队的工作能够更加顺利，需求工程师需要完成很多看上去似乎不属于其本职工作的任务，这就是“团队”的含义。

心得体会及内容建议：

从系统开发工作看，在需求分析中花费更多的精力是非常值得并且必要的。需求分析的质量决定了整个软件的质量。没有做好需求分析，没有一分好的需求规格说明书是很难展开后续的软件开发工作的。需求分析的唯一角度是用户，而不是其他。所以，我们作为软件开发者，更应系统学习和熟练掌握软件需求分析与建模的方法，提高自身的专业能力，以避免在软件开发的过程中遇到相关问题而导致难以进行开发甚至无法开发。课本对什么是需求工程以及需求工程的相关内容都做了详细的描述，理论内容占绝大部分，书中也采用了许多例子，还是比较容易理解的。
关于应有内容的建议，我认为本书对于实践部分描述过少，理论的东西太多，比较枯燥，让人难以理解消化。

名词解释：

[1]统一建模语言(UnifedModelingLanguage.UML):一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具，独立于任何具体程序设计语言。
[2]问题域(problem domain ):解决问题必须涉及的事件和事物
[3]问题域特性(problem domain feature) :问题域的背景信息

参考文献：

[1]骆斌、丁二玉. 《需求工程—软件建模与分析（第2版）》高等教育出版社 2015.2 P3-72