需求开发和需求管理
本文是以软件项目的生命周期为主线，以需求开发、需求分析、需求规格化、需求评审与确认的时间顺序，讲解软件项目需求开发和需求管理的基本知识点和基本概念，讲述需求开发和需求分析的主流方法，讨论其在实际中的可用性。
本文重要阐述的是一般在需求管理和需求开发中的常见的错误或容易被忽略的问题，例如用户需求与软件需求之间的区别与联系、需求的平衡与优先级设定、需求变更中的“影响度分析”等内容。
1. 前言
1.1. 需求开发和需求管理的重要性
“ 需求开发与需求管理是一个创新与探索的过程，而不仅仅只是收集的过程 。 ”
---Sommerville and Sawyer, 1997
需求开发与需求管理贯穿软件生命周期的本身。如何准确而又快速的捕捉用户的需求？如何平衡不同角色的用户对于系统 / 软件的不同方面的需求？如何协调功能性需求与非功能性需求之间的矛盾？如何有效的分析需求？如何在项目生命周期中保证需求的一致性、完整性与可回溯性？这一系列的问题都对需求分析人员的能力和素质提出了很高的要求。需求开发与需求管理能力的培养成为了摆在软件企业面前的一大课题。
与软件项目有关的“魔鬼数字”：
1.2. 软件项目中需求分类
软件需求主要包括三个方面：功能需求（做什么）、非功能需求（质量属性，譬如说有可维护性，可移植性，可靠性，稳定性等，主要用来体现系统有多棒）与设计约束条件（系统必须满足的条件，譬如说用什么数据库用什么浏览器等）
用户需求：来自相关方的需要，期望，约束等相关方需要经过导出、汇总、解决冲突与规格化之后的结果，将发散的用户需要转化成收敛的用户需求。
产品需求：将用户需求转化成开发者的语言，分解之后的需求，开发者将使用产品需求来指导和规范设计与构建产品的过程。
产品组件需求：关于产品组件的完整的规格化描述，包括功能、性能以及其他需求
三者的关系是：由用户需求转化成软件需求，软件需求再进行任务分解，产生产品组件需求。
1.3. 需求开发与需求管理所包含的主要活动
1.3.1. 需求开发包含的活动如下：
1、关于用户需要、期望与约束条件的抽取、分析、确认和沟通，以获取客户需求进而建立满足各个相关方一致的认识与谅解
2、收集与调和各个相关方的需要
3、建立客户需求
4、开发产品生命周期的需求
5、建立与用户要求相一致的产品与产品组件的需求，将系统需求文档化
1.3.2. 需求管理包含的活动如下：
进行需求分析及评审并建立软件需求基线，管理和控制需求基线及需求变更，保持软件需求和项目计划、工作产品及过程活动的一致性。
1、获取关于需求的一致理解
2、获取关于需求的承诺
3、管理需求的变更
3、维护需求的双向可跟踪性
4、识别工作产品与需求之间的不一致性
1.4. 在需求开发及管理准则
1、通过整理获得需求，从而明确需求来源、确认需求类型（功能需求或非功能需求）、明确需求的优先级，形成《用户需求说明书》，并得到用户的确认。
2、对给定的《用户需求说明书》进行分析以文档化的形式编制《软件需求规格说明书》
《软件需求规格说明书》中每一项需求的描述，都必须确保是正确、最新、完备、必要、可验证、可追踪和可测试的。
3、《软件需求规格说明书》必须通过相关组的评审，相关组包括：开发组、测试组、质量保证组、配置管理组、文档组及个人。只有相关组审批、确认后的《软件需求规格说明书》 ，才能作为项目开发计划以及后续项目工程和管理活动的基础。
4、经过评审确认的《软件需求规格说明书》的任何变更，都应得到控制和管理，一旦需求发生变更，项目计划、过程活动、工作产品等要随之变更与需求变更保持一致，并重新提交相关方和个人复审。
2. 用户需求的开发
需求开发过程中所需要具有的重要品质：倾听和观察（倾听并激发用户需求，观察外部约束条件）
2.1. 用户需求开发的主要难点
问题的清晰度/沟通交流的障碍/知识与技能的局限/人的行为
（用户什么都想要、开发者什么都不敢承诺）
（用户和开发者之间的彼此不信任，沟通交流困难）
2.2. 制定需求调研计划步骤
1、首先需要识别产品开发的相关方，特别是与需求有关的；
2了解需求开发过程中常使用的工具和技术：
（1）访谈（最常使用的工具，访谈前需先根据用户的环境职责以及调查问卷等反馈结果制定需求检查单，执行访谈的时候应避免臆断用户的回答，执行访谈的过程中一定要做记录，并和用户探明相关细节，将一些通用的需求抽象为“需求库“，为项目后期使用，经过沟通在需求上与用户达成一致，最后将文档化的访谈报告让用户确认）
（2）特性清单（针对参与度较高，高度成熟的客户）
（3）问卷调查（将使用到该产品的用户）
（4）相似系统的演示（激发用户需求）
（5）原型（针对基本没需求的，激发用户需求）
3了解相应的工作量、进度和资源方面的需求
4.将需求抽取的计划文档化
5.获取相关方对计划的承诺
2.3. 需求获取的质量取决于
1.分析者的技能和知识
2.分析者与用户的角色互换
3客户所提供的时间以及用户端关于需求都得透明化
2.4. 需求开发所需要具备的知识和技能
倾听/访谈和调研/分析/简化和抽象/观察/书写/组织/建模/人际沟通/创造力/业务领域的知识
客户期望需求分析者能够熟悉自己的业务领域，用业务领域语言来描述，并为客户提供好的概念和备选方案；分析者期望需求能够尽量精确和有针对性，期望附有成本与可行性性分析，提供需求的优先级，提供评审需求的规格说明，提供评审记录以及定期的关于需求变更的沟通
2.5. 需求获取的流程：
3. 需求分析与规格化
3.1. 需求分析概述、目标和内容
3.1.1 概述：
1、提炼、分析和仔细审查已收集到的需求
2、目的在于开发出高质量和具体的需求，以便作出实用的项目估算并进行设计、构造和测试
3、需要从不同的视角检验需求，增加查明错误、消除不一致性、发现遗漏的机率
4、创建分析模型之后，要不断改进，并分析评估其清晰性、完整性和一致性。
5、在用户需求描述(用户需求说明书)和软件设计之间建立桥梁
3.1.2 目标
1、详细描述客户需要什么
2、为软件设计奠定基础
3、定义在软件完成后可以被确认的需求
3.1.3 内容
1、详细的用例文本、用例图、活动图
2、类图、状态图、顺序图
3、数据流程、控制流程、处理说明
3.2. 需求分析流程图
3.3. 需求分析方法
1、面向结构分析法，结合获取的《用户需求说明书》，可采用数据流图等分析模型，把系统功能需求、非功能需求按事件流、数据流分析方式，逐层细化到系统操作及操作数据的存储方式，如数据的输入、输出，并考虑外部接口。结合数据流图和数据字典,详细说明系统功能间的输入、输出、系统活动及约束条件 ,编制需求规格说明书。
2、面向对象分析法，使用UML辅助类图或其他分析方式来分析已获取的系统需求、用例模型、类图、数据字典等。结合图形化分析模型、类图、顺序图、关联图等进行说明，准确描述用户及系统的交互活动 ，编制需求规格说明书。
3、原型法是系统部分实现，为那些模糊的、已经有所了解但定义不明确、理解不透彻的需求建立模型，帮助开发者、客户以及用户更好的理解需求（ 水平原型（例如界面原型），垂直原型（例如可运行的功能原型）、可抛弃原型、进化原型（不可抛弃原型））原型应与需求规格说明书结合使用
4、用户用例（Use Case）
用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至，整个RUP流程都被称作是“用例驱动”(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。
用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor)，这些使用者与被定义系统发生交互;针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为Use Case)，或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。
与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。
基于用例的需求获取步骤
定义项目的视图和范围（用户需求列表）；
- 确定用户类；
- 在每个用户类中确定适当的代表；
- 确定需求决策者和他们的决策过程；
- 选择你所用的需求获取技术；
- 运用需求获取技术对作为系统一部分的用例进行开发并设置优先级；
- 从用户那里收集质量属性和其他非功能需求；
- 详细拟订用例使其融合到必要的功能需求中；
- 评审用例的描述和功能需求；
- 如果有必要，开发分析模型用以澄清需求获取的参与者对需求的理解
- 开发并评估用户界面原型以帮助想象还未理解的需求；
- 从用户中开发概念测试用例；
- 用测试用例来论证用例、功能需求、分析模型和原型；
- 在继续进行设计和构造系统每一部分之前，重复6－13步骤。
用例检查点
- 谁是主要参与者，次要参与者？
- 参与者的目标是什么？
- 做事开始前有什么前提条件？
- 参与者完成的主要工作或功能是什么？
- 按照故事/业务场景所描述的还可能需要考虑什么异常？
- 参与者的交互中有什么可能的变化？
- 参与者将获得、产生或改变哪些信息？
- 参与者必须通知系统外部环境的改变吗？
- 参与者希望从系统获取什么信息？
- 参与者希望得知意料之外的变更吗？
常见用例陷阱
- 太多的用例，注意合适的抽象级别。
- 用例冗余，使用“包含”关系，将公共部分分离出来写到一个单独的用例中。
- 用例中的用户界面设计，用例的重点就是用户使用系统做什么，而不是关心屏幕上是怎么显示的。
- 用例中包含数据定义，比如数据类型、长度、格式和合法值等，这些应当放到数据字典里。
- 试图把每一个需求与一个用例相联系，这是不可能的，需要使用规格说明书编写非功能需求、外部接口需求以及一些不能由用例得到的功能需求。
分析的过程是从关键信息向实现的细节迁移的过程，在创建分析的模型之前需要理解问题，描述模型的信息、功能和行为必须以分层的形式分割描述，为每一项需求记录来由和原因，消除含糊不清的地方
3.4. 需求分析所包含的元素
1、 基于场景的元素——用户角度表现系统 ：用例文本 、用例图 、活动图 、泳道图（带角色的活动图）
2、面向信息流的元素——通过处理函数进行转换 ：数据流图 、控制流图 、处理说明
3.5. 非功能性需求分析
非功能需求主要包括三个方面：好用实用性，硬件方面（除了分析条件与用户场景之外，还需要分析异常条件，以及一些极限条件（破坏性测试）），炫酷的界面
3.6. 需求的平衡与优先级设定
1、将需求分类：将各个需求组成彼此相关的子类
2、发现需求与需求之间的关系
3、检查需求之间的一致性、冗余度和不确定性
4、根据客户的需要建立优先级别
3.7. 需求规格化应注意的问题
1、需求规格说明书必须把包括功能性需求，非功能性需求，设计与约束条件。
2、为了便于阅读和理解需求应进行编号。
3、将系统的需求抽象化为模型来表示，建模可以降低分析和讨论需求变更的时候的成本
（1）数据流图（DFD）：功能视图，描述系统内部及系统与系统外部的信息流
（2）实体—关系图：存储数据视图
（3）状态迁移图：与时间相关的行为视图
3.8. 需求规格说明书的要素：
3.8.1. 正确
需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。
3.8.2 清楚
清楚的需求让人易读易懂，不在于文档的厚度。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：
文档的结构、段落是否乱七八糟？上下文是否不连贯？
文档的语句是否含糊其词、罗里罗嗦？
3.8.3 无二义性
“无二义性” 是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。
为了使需求无二义性，在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。
3.8.4 一致
“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。
3.8.5 必要
《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。
可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。
“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。
“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。
3.8.6 完备
“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。
人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。
不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。
3.8.7 可实现
《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。
“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。
营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被罚款的。
对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。
3.8.9 可验证
《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。
3.8.10 确定优先级
为什么要确定需求的“优先级”？
理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。
人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。
需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。 （用户满意度和不满意度）
3.8.11 阐述“做什么”而不是“怎么做”
《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。
国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。
4. 需求分解与跟踪
4.1. 从用户需求向软件需求的分解
用户需求仅仅只是明确项目范围和边界条件的逻辑上的、虚拟的需求，不一定与待设计开发所完成的任务（软件需求一一对应），但软件需求的全集一定要覆盖了用户需求的集合，否则需求就有遗漏。
4.2. 需求跟踪
需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式：
1、正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
2、逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
4.3. 需求重用
1、关于需求的相关经验的非正式的重用
2、从相关项目组继承的需求规格文档
领域模型、模式
（例子:将钻石从其他共生款式中分离开来的方法适用于大规模的食品加工中将辣椒籽从辣椒中剥离出来）
问题解决模式：特定问题——将问题定义抽象成为问题域——通用问题与——给予对通用问题域研究后的解决方案，与特定的工具盒方法无关——通用的解决方案域——还原特定的工具或方法——特定的解决方案
5.需求的评审与确定
5.1 需求评审的目的
1、尽可能见缝插针的在工作铲平中检出问题
2、对于隐蔽性较强的缺陷的一种验证手段
3、在组织层面上帮助构建技术能力
（团队共享经验，工作产品改进，形成统一的技术标准平台）
4、保证产品质量，长期的问题预防机制
5.2 需求评审的种类
结对编程：两个开发人员不断的评审他们共同的产品，其他同行不参与评审工作产品
同行桌查：只有一个同行坐在作者旁边，评审其工作产品，是典型的非正式评审方法轮差
轮查：同时具有桌查和走读的性质，工作产品被分发给各检视人员，收集其建议和发现的问题。适用于评审人员分布在不同的地域，作者又希望听到多方意见的情况下。
5.2.1. 正规检视会议角色
检视的组织者需要一定的领导技能，在管理确保会议的准入准出条件，确保检视专家的准备度以及执行后续工作
记录员主要负责记录缺陷，对缺陷的类型进行分类，在每一缺陷被识别时要读出已记录的缺陷，在检视会议结束时，要通读已记录的缺陷
讲解员需要熟悉材料，并对其讲解，控制检视速度，在记录员记录的时候放缓速度
检视专家需要具备足够的领域内的知识和经验，能够理解材料并进行单独的检查
作者收集和分发材料，提供一个概览性的说明，必要时与检视专家提出澄清，作者需要站在检视专家的角度审视自己的工作产品
作者不能担当检视的组织者，不适合担当记录的检视的记录员，不建议担当讲解者的角色
5.2.2正规检视流程
计划
1、识别被检视的工作产品
2、识别检视的重点
3、指定检视的日期
4、确认拟邀请的检视专家
5、定义一份项目组级别的评审计划
6、识别关于评审的培训要求
介绍会议
1、当被检视的产品符合准入条件的时候
2、对检视组织者的正式宣布
3、识别检视参加者角色时间与地点
4、向检视参加者分发相关材料
5、组织者将组织介绍会议，供大家浏览被检视的工作产品
6、介绍会议大约10到15分钟
7、在正式的检视会议之前2到6天召开检视会议
预审
1、由所有的检视参加者执行
2、一个单独的会议，或者多轮次会议，每次大约2小时
3、琢磨检查，在桌面检查过程中识别潜在的缺陷
4、填写个人的检视记录
5、预审过程中对于每一位检视专家至少检查一次
评审会议
目标：准备通过协作获得最终的缺陷记录列表
1、由检视的组织者负责控制会议的按时召开以及准备，记录各检视专家在预审过程中所投入的工作量
2、指定的“讲解着”宣读被检视的工作产品，并加以简短的解释
3、当遇到一个潜在的缺陷的时候，检视专家打断宣读
4、就该潜在缺陷展开讨论
5、讨论由组织者控制，只针对产品，不针对人，只针对缺陷不针对解决方案
6、检视的“记录员”记录缺陷
7、组织者宣布检视结束并总结部署（缺陷修复以及缺陷修复后的重新检视）
评审后返工
1、将缺陷与相应的变更之间一致的对照起来
2、由作者执行，由检视组织者或检视专家负责，确保所有的缺陷都得到修正，保证工作产品对下一阶段的适用
5.2.3. 提高检视的有效性
1、使用检视的检查单，但避免过度的依赖检查单
2、检视的会议控制在两小时之内，检视的对象是工作产品
3、对每一个问题的确认不超过五分钟，避免过长时间的讨论
4、给予参会人员足够的准备时间
5.3. 需求评审面临的困难
需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。
需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。
开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。
开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好，但不要将争议变为争吵
人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。
5.4. 管理需求变更
1、建立一个观念：需求变更不可避免
2.需求的基线化
3、建立单一的接受变更的渠道
5.4.1 需求发生变更的起因主要有：
1、随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
2、市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
3、提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
4、需求变更控制的目的： 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的不合理需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。
基本对策：
首先设法通过合同来处理需求变更；
其次设法将需求变更拖延到验收之后（下个版本）；
5.4.2 需求变更控制 （变更申请—审批—执行）
1、变更提出者填写《需求变更申请表》说明变更内容、变更影响范围；
2、提交CCB审批，必要时召开变更评审会议；对于不影响需求基线的小范围的变更，可以由项目经理审批；
3、变更完成后，由验证人和质量保证工程师跟踪验证变更引起相关内容的调整是否正确无误；
4、《需求变更申请表》纳入配置管理。
需求版本控制
为评审通过的软件需求文档确定版本号；每一个经过变更软件需求文档应在修订页中描述其修正版本的历史情况，包括已变更的内容，变更日期，变更人姓名和变更后的版本号；项目经理和质量保证工程师负责检查软件需求文档版本的一致性。
需求跟踪矩阵
在每次需求变更之后，必须更新需求跟踪矩阵；在每个阶段工作完成之后，亦需要更新需求跟踪矩阵。
