A001-185-1203

我对需求分析与建模的认识与应有内容建议
目录
一、 需求工程导论
1.1软件模拟特性 ---------------------------- 2
1.2需求工程简介 ---------------------------- 2
1.3需求工程与系统工程 ---------------------------- 3
1.4需求工程师 ---------------------------- 4
二、需求基础
2.1问题与需求 ----------------------------- 5
2.2需求和问题都有层次性 ----------------------------- 6
2.3需求的分类与表述 ----------------------------- 6
2.4功能需求 ----------------------------- 7
2.5优秀需求的特性 ----------------------------- 8
三、需求工程过程
3.1概述 ----------------------------- 8
3.2需求获取 ----------------------------- 9
3.3需求分析 ----------------------------- 10
3.4需求规格说明 ----------------------------- 11
3.5需求开发过程是迭代和并发的 ------------ 12
3.6需求开发过程与软件工程过程的相互影响 ------------ 12
四、个人建议 ----------------------------- 13
五、附录 ----------------------------- 13

一、 需求工程导论
1.1软件的模拟特性
软件需求工程是当前软件开发面临的主要问题，除此之外，还有模拟特性。然而，导致需求问题的原因当中，一个最为重要的原因是：未能很好地理解和掌握“应用” 型软件的模拟特性以及由此而产生的一系列影响和要求。软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。当然，软件对现实世界的“模拟”并不是机械和被动的。
软件可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。
专业用户通常以软件为中心开展工作，工具软件是他们的主要手段，因此面向专业用户的纯 工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。普通用户利用软件的目的通常仅限于解决一些实际问题，软件仅仅是一种辅助性的手段，因 此面向普通用户的纯工具型软件以功能的有用性为首要成功标准，一些过于复杂的功能反而会 因其灵活性而丧失一定的实用性，进而受到用户的抵制。应用型软件在“模拟”现实的基础之上接收用户的请求，协助用户完成任务，它正确工作的 基础是具有“模拟”性。
软件需求工程是当前软件开发面临的主要问题，除此之外，还有模拟特性。然而，导致需求问题的原因当中，一个最为重要的原因是：未能很好地理解和掌握“应用” 型软件的模拟特性以及由此而产生的一系列影响和要求。软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。当然，软件对现实世界的“模拟”并不是机械和被动的。
软件可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求问题的产生。包括非技术性和社会性因素重视不足、传统需求分析方法的缺陷、软件规模的日益扩大、需求问题的高代价性。

1.2需求工程简介
简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需 求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。
从细节来看，可以定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的 现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时也关注以上因素和准确的软件 行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
通过以上定义可以发现，需求工程有以下3个主要任务。
① 需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功 能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制 和约束，即要同时说明软件需要“做什么”和“为什么”需要做。
② 需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件 行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试、 用户手册编写等很多后续软件开发阶段的工作基础。
③ 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间 的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和 约束在软件产品族中的演化和分布情况进行综合考虑与处理。
需求工程为了完成其任务，还必须进行一系列的活动。需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特 性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需求验证4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在开发活动之后，保证所确定的需求能够在后续的项目活动中有效地发挥作用，保证各种活动的开展都符合需求要求。需求获取的目的是从项目的战略规划开始建立最初的原始需求。需求分析的目的是保证需求的完整性和一致性。需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确 地固定下来。需求验证是需求开发中的最后一个活动。它的首要目的是保证需求及其文档的正确性，即 需求正确地反映了用户的真实意图；它的另一个目标是通过检査和修正，保证需求及其文档的完 整性和一致性。需求管理是对需求开发所建立的需求基线的管理，它在需求基线完成之后正式开始，并在需求工程阶段结束之后继续存在，在设计、测试、实现等后续的软件系统开发中保证需求作用的持续、稳定发挥。

1.3需求工程与系统工程
在系统化的需求工程出现之后，需求处理在整个系统开发中所处的位置也出现了变化。计算系统工程通常是指将计算机引入某一现实系统，并用它来改变现实系统的运作方式，达 到一个理想效果的过程。在计算系统工程中，软件通常具有重要的作用，但系统工程中除了含有 处理软件的软件工程之外，还包括硬件工程和人力工程。硬件工程为计算机在某一现实系统中 的应用提供硬件支持，如网络布局和处理机配置等。人力工程为计算机在某一现实系统中的应 用提供人力资源支持，如维护人员培训、系统管理人员培训和用户培训等。因此，在系统工程中 虽然应该重点关注软件工程部分的内容，但并不能完全以软件为中心来看待和处理整个系统。系统需求开发的主要目的是获得整个系统的期望目标，包含功能特征和非功能特征（如性能 要求等）。为此需要判断系统的涉众，釆集他们的目标与要求，研究系统的环境，确定系统的约 束，并进行一些整体性的需求分析。系统需求开发阶段的需求分析主要是分析系统的成本效率 及系统的组织和行政策略，处理互相依赖、冲突、重叠或不一致的涉众需求，检査并弥补需求缺 失，检查技术储备、外部系统等环境约束。软件开发者的任务就是开发 一个软件系统，将之应用于现实世界，并通过软件系统和现实世界的交互，影响和改变现实世界。 在这个过程中，软件开发者并不是要从物理结构开始针对问题建立一个特定的计算机，而只是描 述所需软件系统的特征和行为，然后通过编程在通用计算机上实现，使之表现出之前所描述的特 征和行为。因此软件开发是这样一个工程问题：利用通用的计算机结构构建一个有用的软件系 统，来满足人们的某些目的。
需求工程的复杂性体现在以下几个方面。
1、处理范围广泛
2、涉及诸多参与方
3、处理内容多样
4、处理活动相互交织
5、处理结果要求苛刻。

1.4需求工程师
在软件开发的各项活动中，需求工程的任务是连接现实世界与计算机世界，将现实世界的知 识内容转化为计算机世界的工作基础，让软件设计、实现、测试等后续的软件开发活动将精力集 中在计算机世界中来。需求工程师是负责完成需求工程主要任务的专门人员，所以他负责衔接 现实世界和计算机世界，简单说就是涉众与开发者之间的桥梁。需求工程师一切工作的核心就是扮演好桥梁作用：在面对涉众时，需求工程师就是后续软件 开发者的代理，负责设计软件方案以满足涉众的各项需求；在面对后续软件开发者时，需求工程 师就是涉众的代理，准确地将各项需求告知开发者。合格的需求工程师需要具备多方面的知识与技能。需求工程师必须熟练掌握软件开发方法 与技术，保证设计出来的软件解决方案既是可行的又是成本效益比有效的。需求工程师还要代表涉众把他们的想法准确地告知开发者，所以需求工程师必须要有非常 精确的表达能力，尤其是文档化能力。当然，最关键的是需求工程师要从涉众那里得到他们的想法并转化为开发者需要的知识，所 以需求工程师必须有非常好的交流沟通能力以了解涉众的想法，必须要有抽象建模与分析的能力以准确定义涉众的想法。还需要掌握交流技能、观察技能、抽象分析与问题解决技能、写作技能、关系协调和团队工作技能等“软技能”。

二、 需求基础
2.1问题与需求
需求源于问题，要准确理解需求，就必须明确它与问题的关系。人们开发软件系统的目的就是希望用它作为解决方案来 解决问题，使得现实改善到期望的状况。解决问题、改善现 实、满足用户期望的条件与能力就是需求。问题在现实世界与软件系统的互动中得到解决。问题域的背景信息又被称为问题域特性。需求工程师要注意区分用户与软件开发人员在关注点上的不同：用户关注于问题域，软件 开发人员更关注解系统。需求工程师扮演着桥梁的作用，一方面使用户不需要了解和关注解 系统(因为用户大多不懂软件开发的专业知识)，另一方面使软件开发者不需要关注问题域， 让软件开发者将精力集中到软件构造工作中。尤其需要注意的是：虽然需求工程师通常是技 术人员，来自于解系统领域，但是他们也必须要懂得如何站在用户的立场，与用户进行基于问 题域的交流。需求开发的最原始出发点就是用户需求，或者需求的源头——问题。解系统的核心是软件解决方案和解决方案在通用计算机上的实现。虽然解决方案及其实现 都关注于软件系统本身，但相互间也有所不同。解决方案描述的是软件系统与问题域交互的过 程，侧重于软件系统中与外界交互的部分。实现部分则主要是软件内部的组成元素、结构关系、 物理实现等软件系统的构造要素。需求工程所关心的仅仅是解决方案，不涉及软件的实现细节。在需求开发过程中，问题域中的用户提出问题与需求。需求工程师接收用户问题与需求，分析问题域背景，建立软件解决方案，并将解决方案传递给后续软件开发者。软件开发者负责将软 件解决方案变为软件实现。在整个工作衔接中，需求是用户与需求工程师的协作基础，解决方案 是需求工程师与软件开发者的协作基础。

2.2需求和问题都有层次性
需求是问题解决的期望，问题是可大可小的，期望自然也是可大可小的。问题和期望粒度不同的现象被称为需求的不同抽象层次。业务需求是抽象层次最高的需求，是系统建立的战略岀发点，表现为高层次的目标,它描述了组织为什么要开发系统。业务需求必须是可验证的，业务需求可验证的数值指标是通过研究问题域的背景资料得出的，为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备 的特性o高层次的解决方案及系统特性指出了系统建立的方向，参与各方必须就它们 达成一致，以建立一个共同的前景，保证涉众朝着同一个方向努力。业务需求描述了系统的目标与效益，适合决策者；用户需求描述了具体任务，适合用户；它 们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统 的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供响应。
一个软件系统的系统级需求集合定义了相应业务需求及用户需求的解决方案，构成了需 求规格说明的主体部分。解系统及其需求规格说明都是不属于现实的，是人们为了解决问题 而构建的，所以系统级需求无法直接从现实中得到。相比之下，业务需求直接或间接地来源 于决策者，用户需求直接或间接地来源于用户，而系统级需求就只能通过技术加工获得。业务需求具有明显的目的 性和较高的抽象性，比较容易获取和确认。所以需求开发往往 从获取业务需求开始。有了业务需求之后，就可以确定系统的 最终目标和努力方向，进而指导具体的需求获取活动，发现用 户需求。用户需求经过明确和细化的处理，可以转化为系统级需求。

2.3需求的分类与表述
需求分类是为了将需求划分为需要 区别对待的不同类型，每种类型会被文档化到不同的部分，服务于不同的读者、不同的目的。从严格的意义上来说，项目需求与过程需求都不能算是需求，因为它们并不是用户对问题解 决的期望，而是用户对软件开发活动本身的要求。硬件需求与其他需束也不属于用户对问题解 决的期望，而是为了让软件能够成功运营而需要适应的环境与活动。但是在文档化需求的材料 中，经常会出现项目需求、过程需求、硬件需求和其他需求，因为它们对需求工程师及开发者正确 理解软件需求甚至整个产品具有极其重要和不可缺少的作用，所以它们经常出现在需求文档中。根据不同的分类标准，可以将需求分成不同的种类。
1、功能需求:和系统主要工作相关的需求，即在不考虑物理约束的 情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现 为系统和环境之间的行为交互。
2、性能需求:系统整体或其组成部分应该拥有的性能特征，如 CPU使用率和内存使用率等。
3、质量属性：系统完成工作的质量,即系统需要在一个“好的程度”上实现 功能需求，如可靠性程度和可维护性程度等。
4、对外接口:系统和环境中其他系统之间需要建立的接口，包括硬件接 口、软件接口和数据库接口等。
5、约束:进行系统构造时需要遵守的约束，如编程语言和硬件设施等。

2.4功能需求
功能需求是软件系统需求中最常见和最重要的需求，同时也是最为复杂的需求。通常一个软件系统的绝大部分需求都是功能需求。功能需求是一个软件产品得以存在的原因，是软件系统能够解决用户问题和产生价值的基 础，也是整个软件开发工作的基础。所有开发者都需要了解功能需求。在复杂的系统中功能需 求数量太多，所以需要将它组织为多个独立部分，然后按照分工原则由不同的开发者来处理不同的部分。
一个系统或其组成部分在限定的约束下，完成其指定功能的 程度，如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的功能。系统为满足显式的及隐含的要求而需 要具备的要素称为质量。质量属性应该和功能需求一样得到足够的重视。真实的现实系统中，在决定系统的成功或 失败的因素中，满足非功能属性往往比满足功能需求更为重要。虽然用户会在和需求工程师交流的过程中表达一些和质量属性相关的想法，但因为他们并 不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的 影响，也无法将他们对软件系统的质量要求细化成一组组可量化的质量属性，所以一般来说，他 们并不能明确地提出对产品质量的期望。
约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。因为不受解系统的影 响，所以从解决问题的角度来看约束不会要求解系统为其进行专门的设计。但是如果解系统不 满足约束，那就意味着问题域并不能够提供解系统要求的运行环境，解系统将无法在问题域内成 功地部署和运行。因此，约束是在总体上限制了开发人员设计和构建系统时的选择范围。

2.5优秀需求的特性
理想情况下，需求应该既是解决用户问题所需要的，又是表述清晰的；既是用户的需要，又是开发者的需要。为此，人们定义了一些优秀需求应该具备的特性，下面是其中比较重要的部分。
1、完备性：优秀的需求是完备的，它不需要做更多的扩展就可以充分说明用户需要的系统功能。
2、正确性：优秀的需求是完备的，它不需要做更多的扩展就可以充分说明用户需要的系统功能。
3、可行性：需求必须能够在系统及其运行环境的已知条件和约束下实现。用户无法判断需求的技术可 行性，所以需求的可行性是由开发人员进行检査的。在检查的过程中，开发人员可能需要进行一 定的分析和研究，而不是单纯地凭借经验和直觉。对于难以判断的需求，必要时要通过开发原型 来加以验证。
4、必要性：每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之 后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的资源。
5、无歧性：需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应 该有而且只能有一种解释，即需求无歧义。

三、 需求工程过程
3.1概述
为了有效地理解用户问题，分析各种可能的系统解决方案，最终产生一个适宜的规格说明文 档，需要将需求开发活动组织成一个系统化和严格的需求工程过程，这是人们随着系统开发的进 展而逐渐认识到的［Siddiqi 1996］。在初期，系统开发的唯一焦点就是编码，此时不论系统大小， 开发都是一个单独的活动——编码。这个时期人们还不认为存在独立的需求开发活动。其后， 随着生命周期模型的引入，对系统开发活动的认知取得重大进展，人们认识到需求开发是系统开 发中的一个独立的阶段，即软件开发生命周期模型的第一个阶段。在此后的进一步发展中，人们 逐渐认识和接受了系统的演化式开发思想，认识到系统的实现往往是开始于一个并非完备的需 求体系，发现需求开发也是一个递进的过程，包含一系列的独立活动。今天，大多数软件专业人 士已经意识到需求工程也有属于它自己的生命周期模型，即存在针对需求开发的需求工程过程， 这个过程又作为系统工程和软件工程的一个子过程部署在系统开发的初期阶段。为了取得对需求的正确和深入理解，系统分析师还需要对获取的结果进行综合与整理，通过 分析保证需求的正确性、完整性和可行性。规格说明文档可能被传递给设计人员、测试人员、项目管理人员等众多系统开发者，因此如 果传递的规格说明文档中存在一些错误或偏差将造成很大的影响。为了尽可能减小不利因素， 尽最大可能产生完善的规格说明文档，就需要在规格说明文档产生之后和传递给相关人员之前 组织进行文档的验证，以尽可能发现文档中的错误和偏差，并进行纠正。

3.2需求获取
需求获取是从人、文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需 求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来 “发现”需求。在需求获取中，需求工程师通常需要执行的任务包括以下几方面。1、收集背景资料：获取的目的是发现用户的问题，并经过需求分析步骤转化为用户的需求。要想和用户就业 务问题进行交流，需求工程师应先具备能够和用户进行交流的知识基础，否则两者之间无法形成 有效的沟通。因此需求工程师需要先收集系统的背景资料以形成一个基础的知识框架，如企业 的业务状况等。如果需要对背景资料进行非常深入的了解（如进行产品线开发），就需要应用相 关的需求分析方法（如领域分析等）对收集的资料进行整合与处理，当然这是需求分析的任务。
2、获取问题与目标，定义项目前景与范围：有了一定的知识框架之后，需求工程师就可以通过收集数据和文档观察环境，了解用户的需 要、期望和关注点，综合推定用户在业务中所遇到的高层次问题。用户解决高层次问题的期望即 为系统的业务需求，也是系统要达到的目标。
3、识别涉众，选择信息的来源：需求获取的主要目的在于获取用户需求，了解用户在完成任务时遇到的问题与期望。获 取有效用户需求的前提是能够正确理解用户的问题，所以针对每个获取的需求都要同时获取 相关的问题域特性，在问题域特性充足的情况下，需求才能够正确体现用户的意图。问题域 特性往往包含很多细节，要清晰地描述这些细节非常困难。所以简单地向用户提问“你需要 系统为你做什么？ ”是无法达到预期目的的，需求工程师需要运用多种获取方法和技巧才能完 成任务。
4、选择获取方法，执行获取，获取功能与非公能需求：需求获取的主要目的在于获取用户需求，了解用户在完成任务时遇到的问题与期望。获 取有效用户需求的前提是能够正确理解用户的问题，所以针对每个获取的需求都要同时获取 相关的问题域特性，在问题域特性充足的情况下，需求才能够正确体现用户的意图。问题域 特性往往包含很多细节，要清晰地描述这些细节非常困难。所以简单地向用户提问“你需要系统为你做什么？”是无法达到预期目的的，需求工程师需要运用多种获取方法和技巧才能完 成任务。
5、记录获取结果：需求获取阶段产生的主要成果有业务需求、项目前景和范围、用户需求以及问题域特性。它们都需要被及时记录下来。

3.3需求分析
需求分析的主要工作是通过建模来整合各种信息，以使人们更好地理解问题。同时，需求分 析工作还会为问题定义一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分 析还需要检査需求中存在的错误、遗漏和不一致等各种缺陷，并加以修正。在需求分析阶段，需求工程师主要的任务包括以下几方面。
1、背景分析：系统是作为用户业务问题的解决方案得以被开发的，但仅靠系统本身无法帮助用户达成目 标，它必须和部署的环境形成互动才能解决用户的问题。所以，在进行系统开发，尤其是需求开 发时，研究系统所将要部署的环境无疑具有重要意义。而且通过对环境的分析和理解，还可以帮 助需求工程师形成一个关于用户业务的知识框架，这又进一步有利于需求工程师在细节的需求 获取活动中形成和用户的有效交流。背景分析就是研究系统环境的一个任务。
在多数情况下，系统的环境较为清晰和简单，因此进行背景分析并不需要太大的投入和太复 杂的手段。但在规模较大系统的开发中，系统环境往往难以梳理，这时就需要使用一些专门的分 析方法，如领域分析和企业建模等。
2、问题分析、目标分析、业务分析，确定系统边界：在获取系统的问题、目标、前景、范围之后，要使用问题分析、目标分析、业务分析等分析方法 与技术对它们进行处理，并基于这些处理明确其解决方案，定义系统的边界。系统边界之内定义 的是系统需要对外提供的功能，系统边界之外标识的是对系统有功能要求的外部实体或者对系 统有所限制的环境要素。
3、软件需求建模：建模是为展现和解释信息而进行的抽象描述活动。模型由一些基本元素和元素之间的关系 组成，它含有丰富的语义。和文本化的自然语言相比，模型能够在有限的空间内表述更加严谨、 准确和高密度的信息。
4、细化需求：用户需求往往具有模糊、歧义等诸多不利的特征，这使得它们很难被加以评估和验证。所以 很有必要在系统模型的帮助下发现更多的细节，并依此将用户需求转化为一些具有良好粒度和 特性的细节需求，即系统级需求。
5、确定优先级：用户对系统往往有许多需求，而且这些需求并不是处于同等重要的地位，因此需求工程师需 要根据其重要程度为需求设定优先级。这些优先级对多版本系统的功能分布和后续开发活动中 的功能取舍非常重要，尤其是在开发资源非常有限甚至不足的情况下。
6、需求协商：在分析中有时会发生不同用户间的需求冲突，这种情况下用户各自的需求都是合理的，但却 不可能在系统中同时被加以实现。无法同时实现的原因有可能是不同用户的需求互相敌对，不 可调和，也可能是因为系统实现的资源有限，无法二者兼顾。

3.4需求规格说明
获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用 户需求文档（或用例文档），系统级需求被写入需求规格说明。需求工程师在这个阶段的主要工作包括以下几方面。
1、定制文档模板：开发团队通常都会在其内部为各种需要编写的文档维护一些文档模板，需求规格说明文档 也不例外。模板为记录功能说明和其他与需求相关的信息提供了统一的结构。
2、编写文档：有了定制的文档模板，就可以开始编写需求文档了。在编写过程中一方面要选择最准确的 表达方式，另一方面又要注意保证文档的良好结构和易读性。通常，人们会同时使用模型语言 （图形、表达式等）和自然语言（文本）两种表达方式，用模型语言来保证信息传递的准确性，用模 型后附加的文本描述保证文档的可读性。

3．5需求管理
在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工 作“需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。所以，在需求 开发结束之后，还需要有一种力量保证需求作用的持续、稳定和有效发挥，需求管理就是这样的 一个管理活动。需求管理阶段的主要任务包括以下几方面。
1、建立和维护需求基线集：建立良好的配置管理，对需求基线进行版本控制，是进行有效需求管理的前提和基础。
2、建立需求跟踪信息：需求的可跟踪性要求以系统级需求为出发点进行双向跟踪：一是后向跟踪,即跟踪系统级需求被设计、实现为哪些制品，并回溯每个设计、实现制品是 为哪些需求存在的；二是前向跟踪,即回溯每个系统级需求是为支持哪 些用户需求及业务需求存在的，并跟踪每个业务需求、用户需求是如何被转化为系统级需求的。
3、进行变更控制：考虑到现实世界的多变性，一个成功的项目在一致的需求基线建立之后仍然应该积极接受 来自外界的需求变化请求，并做出及时调整与反馈。

3.5需求开发过程是迭代和并发的
从需求工程各项活动的内容来看，需求开发活动似乎可以遵循“需求获取-> 需求分析一需求 规格说明T需求验证”的路线顺序执行，并成功地产生有效的成果文档。但正如软件开发过程的 瀑布模型一样，实践者们很快就发现这个线性顺序的过程可以用于解释需求开发中的活动内容， 却无法用于组织成功的需求开发。

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

四、
个人建议：书本的理论概述过多，内容冗余，例子也不多，不容易理解，看久了会觉得枯燥无味，建议多增加一些例子，减少大篇大篇的文字。

五、
附录：需求工程——软件建模与分析 （第2版）