软件需求管理

前言

首先想现在这里写下一点自己关于这门课的理解吧，先对这门课有一个整体的认识
一个软件从开始到消亡一共会经历以下三个步骤

由图我们不难看出，软件需求是在软件开发之前的一个步骤，主要用于解决系统究竟要做什么的问题
但是用户由于种种原因，往往对于需求的描述无法做到非常清淅
因此就需要一种科学的工程化方法来获取需求，这就是软件需求管理存在的意义
接下来我们将系统的看一看这门课的知识

第一节、第二节思维导图：

1.需求工程导论

这一章我们将介绍需求工程的一些前置知识，主要包括软件工程导论中的部分知识和软件需求概述

1.1软件工程导论部分知识

1.1.1软件开发的五种常用模型

1.1.1.1瀑布模型

传统瀑布模型的开发流程如下图所示

但是在实际的开发过程中，往往前一阶段的任务会存在误差，需要调整
因此就有接下来这种实际的瀑布模型

由于以上开发模式，不嫩总结出瀑布模型的优缺点

优点：
瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。一种文档驱动的模型
严格规定必须提交的文档，交出的所有产品必须是经过验证（审查）
缺点：
实际项目很少按照该模型给出的顺序进行，用户常常难以清楚地给出所有需求，需等到系统开发完成
几乎完全依赖书面的规格说明，可能导致无法满足用户需要，只适用于项目开始时需求已确定的情况

1.1.1.2快速原型模型

在用户不能完整、明确的给出需求说明的时候，开发者往往会先建立一个原型与用户讨论，从而精确得到用户需求的一种方法

可以理解为是一种应用与瀑布模型中需求分析中的一种方法

建造某些原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。

优点：
不带反馈环
本质是快速
基本是线性顺序进行
用途是获知用户真实需求
减少较大的返工
减少后续犯错的可能性
缺点：
为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。
开发过程不便于管理。

1.1.1.3增量模型

是一种渐进地开发逐步完善的软件版本的模型。早期实现用户的基本需求，并提供给用户评估的平台

优点：
在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。
整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。
优先级最高的服务首先交付，项目失败的风险较低。
缺点：
在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。
多个构件并行开发，具有无法集成的风险。

考虑使用增量模型需要注意一下问题：
慎重考虑使用渐增模型的情况：
不能充分理解客户需求或客户需求有可能迅速发生变化；
事先拟采用的技术迅速发生变化；
客户突然提出一些新的功能需求；
长时期内仅有有限的资源保证（开发人员和资金）。

考虑使用渐增模型的情况：
需要在尽短的时间内得到系统基本功能的演示或使用；
各版本都有中间阶段产品可提供使用；
系统可以被自然地分割成渐增的模式；
开发人员与资金可以逐步增加。

1.1.1.4螺旋模型

螺旋模型=瀑布模型+快速原型+风险分析

优点：
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
减少了过多测试或测试不足带来的风险。
维护和开发之间并没有本质区别。
缺点：
风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大。
主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险。
随着迭代次数的增加，工作量加大，软件开发成本增加。

1.1.1.5面向对象的模型（喷泉模型）

典型的面向对象生命周期模型。主要用于支持面向对象开发过程。
体现了软件创建所固有的迭代和无间隙的特征。
活动之间存在重叠和无缝过渡。

1.1.2结构化和面向对象

结构化: 先调查，再彻底分析、了解问题并规划，最后实现整个系统。（从功能和流程的角度考虑）
面向对象: 先调查，并将问题细化（根据不同的类和对象以及他们之间的联系），最后根据这些内在联系实现整个系统。（从对象的角度考虑）

1.1.3统一软件开发过程

特点： 软件开发是迭代过程，是由Use Case（用例）驱动的，以架构设计为中心的增量迭代模型。

统一开发过程四个阶段：初始、细化、构建、移交
统一开发过程六个核心工作流：业务建模、需求、分析与设计、测试、实现、部署

1.2软件需求概述

需求的定义： （正在构建的）系统必须符合的条件或具备的功能或能力
软件需求的定义：
1、用户需解决某一问题或达到某一目标所需的软件功能。
2、系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。

2.需求工程

2.1需求工程的基本活动

红字部分是要点（记住）

2.2需求基线

需求工程主要分成了需求开发和需求管理两部分

需求开发和需求管理之间的界限就是所谓的需求基线

需求基线定义：已经通过正式评审和批准的需求规格说明活产品
需求基线意义：是软件需求开发和软件需求管理的界限

2.3需求工程的两个时期

需求工程主要分为系统需求开发和软件需求开发两部分

由图不难看出
系统需求开发之前需要进行需求获取和需求分析
在软件工程阶段，需求工程需要在设计编码测试之前完成

2.4需求工程的特性

需求工程的特性主要体现在两个方面，一个是必要性一个是复杂性

2.4.1必要性

软件开发是这样一个工程问题
==利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的 ==

计算机应用于现实世界的广泛性
新的问题和新的解决方案
定义问题就是需求工程的任务

2.4.2复杂性

处理范围广泛
现实世界和计算机世界
涉及诸多参与方
客户、用户、领域专家、需求工程师、软件开发者、系统维护者等
处理内容多样
功能需求、非功能需求 、环境及其约束
处理活动互相交织
需求开发的各项活动虽然在理论上具有顺序处理的特性，但在实际执行过程中往往是迭代和互相交织的
处理结果要求苛刻
正确性、完整性和一致性

3.需求理论基础

基于上一章节，我们已经对需求的概念等知识有了基本的认识，本节内容将更为详细的讲解需求到底是个什么东西

3.1需求的类型

3.1.1需求的层次性（需求的三个层次）

按照层次来分类，需求主要分为业务需求、用户需求、系统需求三个部分

3.1.1.1业务需求

业务需求主要来源于决策者
是系统的目标和效益
主要表现为系统的解决方案和系统特性
论述为什么开发软件或者系统（why）
形成的文档为 前景和范围文档 （非常重要）

3.1.1.2用户需求

用户需求的主要来源是用户
是系统需要提供的具体任务
主要表现为问题域的知识
描述用户使用系统都能做到些什么事（what）
形成的文档为用例说明文档 （非常重要）

3.1.1.2系统需求

系统需求主要来源于软件开发者
是软件系统的行为
主要表现为系统分析模型
描述开发人员如何设计具体的解决方案来实现用户需求
形成需求规格说明文档 （非常重要）

3.1.2严格意义上的软件需求分类

严格意义上的软件需求可以分为功能需求和非功能需求两类

3.1.2.1功能需求

和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务
功能需求主要表现为系统和环境之间的行为交互

3.1.2.2非功能需求

1.性能需求
系统整体或系统组成部分应该拥有的性能特征
例如：速度、容量、吞吐量、载负、实时性、CPU使用率、内存使用率等。

2.质量属性
系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求
例如：功能性、可靠性、可用性、可维护性、课移植性、效率等。

3.对外接口
系统和环境中其他系统之间需要建立的接口
包括硬件接口、软件接口、数据库接口等等。

4.约束
进行系统构造时需要遵守的约束、
例如：运行环境、相关标准、社会因素、编程语言、硬件设施、将来可能提出的要求等

3.2需求工程的路线（了解）

3.3优秀需求的特性

3.3.1完整性

不需要做更多的扩展就可以充分的说明用户所需要的系统功能
每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息
系统应该允许被扩展
系统的调度算法应该允许被扩展。

3.3.2正确性（真实性）

真实的反映用户的意图
必须请需求的提出者予以==确认 ==

3.3.3可行性

由开发人员进行检查
需要进行一定的分析和研究，而不是单纯的凭借经验和直觉
必要的时候要通过开发原型来加以验证
不可行的需求被称为不切实际的期望。

3.3.4必要性（精确性）

简洁、清晰
确认每一项需求都是满足用户的业务需求所必需的。——不遗漏也不画蛇添足，刚刚好。

3.3.5无歧义

每一项需求都应该有而且只能有一种解释
定义一个可以共同理解的词汇表（Glossary）

3.3.6可验证

通过分析、检查、模拟或者测试等方法能够判断需求是否被满足
不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要

4.需求工程过程

了解了需求的基本概念之后，接下来讲讲需求工程的主要过程

4.1需求工程过程

需求工程过程是系统开发当中需求开发活动的集成，它的模版是产生一个能够在用户环境下解决用户业务问题的系统方案

需求工程的具体流程在需求工程的基本活动中已经讲到过了
这里主要的流程上的区别就是加上了反馈的过程

在整个软件工程体系中需求主要工程的过程描述如下图所示

4.2需求工程的活动

将上一节讲过的需求工程过程细化到每一步，逐步讲解每一步都需要作什么

4.2.1需求获取

需求获取是从人、文档或者环境当中获取需求的过程
需求工程师必须要利用各种方法和技术来“发现”需求
需求获取和需求分析是交织在一起的

在需求获取的过程中由如下子活动：
收集背景资料
定义项目前景和范围
选择信息的来源
选择获取方法，执行获取
记录获取结果

4.2.2需求分析

为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案

需求分析主要由如下子活动
背景分析
确定系统边界（用例图，上下文图）
需求建模（DFD数据流图、ERD实体关系图、STD状态转换图，类图等）
需求细化（用户需求->系统需求）
确定优先级 （功能取舍；评估和调整适应需求，满足市场和业务目标的变化）
需求协商（需求工程师发现需求冲突，组织用户协商解决）

4.2.3需求规格说明

业务需求被写入项目前景和范围文档
用户需求被写入用户需求文档（或者用例文档）
系统需求被写入需求规格说明

4.2.4需求验证

执行验证（同级评审、原型或模拟）
问题修正 （伴随问题跟踪）

4.2.5需求管理

建立和维护需求基线集 （版本控制，变更记录）
建立需求跟踪信息 （双向：前向和后向）
进行变更控制（建立过程、策略，评估和落实）

4.3需求工程的并发和迭代性

理论上需求分析模型的复杂度应随着获取内容的逐渐积累而线性上升，事实上是总体上升趋势中伴随着间歇性的下降。下降的过程可以理解为知识重构过程。
即实际的需求开发过程是获取-分析-重构的不断交织和迭代的过程。

5.需求获取概述

需求获取是确定和理解不用用户类的需要和限制的过程，是软件工程的主题

需求获取阶段主要产生的文档：
1.前景和范围文档
2.用例说明文档（假设需求分析时采用面向对象方法）

软件需求或许是往往是非常困难且易出错的，因此我们需要科学的分析方法来确定需求，这就是本节要描述的东西

5.1需求的非平凡性

5.1.1.用户和开发人员的背景不同，立场不同

首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够和用户进行有效沟通的粗略的知识框架

默认（Tacit）知识现象
默认知识：表达着看来简单认为不值得专门进行解释或提及的知识。
**利用有效的获取方法与技巧（角色扮演、观察等）**来发现并获取默认知识

5.1.2.普通用户缺乏概括性、综合性的表述能力

普通用户的知识结构就相对局限于一些具体的业务细节

善于表达具体业务的细节问题
专家用户的知识结构因其渊博性而具有概括性和广泛性

能够回答概括性和综合性的问题
开发人员在与用户接触之前就先行确定获取的内容主题，然后设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望。

5.1.3.用户存在认知困境

潜在（Latency）知识
发觉潜在知识，主动创造需求。

用户越俎代庖
用户提出的不是需求，而是解决方案
注意保持业务领域和解决方案的区分界限
用户固执的坚持某些特征和功能
分析用户的深层目的，找到隐藏在背后的需求

5.1.4.缺乏用户参与

对系统的用户以及用户的替代源等相关涉众进行分析

5.2需求获取的过程（了解）

研究背景，创建初始框架
获取问题，建立前景和范围文档
分析涉众，选择信息来源
确定获取内容和主题，建立系统边界，设置场景
采用适合的方法和技术进行获取，分析用户更高层次的目标，理解用户意图
记录结果，写出项目前景和范围文档

5.3需求获取活动的要点

5.3.1获取内容

1.需求
系统期望达到的目标，来源于用户的观点、看法、目标或者问题

2.问题域描述
现实世界的业务运行状况

3.环境与约束
限制解系统部署的环境和条件

5.3.2获取来源

5.3.2.1涉众（主要讲解涉众分析的步骤）

涉众的定义：所有能够影响软件系统的实现，或者会被实现后的软件系统所影响的个人和团体。
常见的涉众有：用户、客户、开发者、管理者、领域专家、政府力量、市场力量、维护人员

涉众分析的概念：为系统找寻并理解关键涉众的过程

在涉众分析中，主要讲解涉众分析的步骤和每个步骤的需要注意的东西

涉众识别（发现所有关键类别，识别方法）

涉众类别的认为与外界交互活动属于项目范围，服务与系统目标（业务需求）

进行涉众识别的过程中需要对涉众类别进行细分，并且需要在涉众群体中发现比较关键的涉众，最后涉众的群体不是一成不变的，应该在任务完成后保证适当的关注

涉众的识别方法有一下三步：
1、先膨胀在收缩
2、检查列表
3、涉众网络

涉众描述

主要描述一下几方面内容
涉众、主要目标、态度、主要关注点、约束条件

涉众评估

进行涉众评估主要需要一下三个方面
优先级评估（重要性）
风险评估
共赢分析

优先级评估（重要性）——两种方法 User/Task矩阵 和 power/interest分布图

顾名思义，进行涉众优先级评估的目的就是确定涉众的优先级

具体有一下两种操作的方法

User/Task矩阵
给出一个例子如下

用户群体的数量级越大，目标涉众的优先级越高

power/interest分布图

由图可以直观的看出的看出参与者的优先级是最高的

风险评估 power/attribute分布图

进行风险评估的目标是分析涉众的态度，化解涉众的风险

主要应用的评估方法是建立power/attribute分布图

通过对不同风险涉众的分析达到
化解涉众风险策略 （合适的项目策略）
提高环境设定者提高关注度，向参与者转化
消除强反对者的反对原因，将他们变为强支持者

共赢分析 Stakeholder/Issue关系图

建立涉众类别与所关注问题的关联，进行冲突发现
如果涉众所关注的问题与项目整体存在冲突，则需要调整折中，甚至重新进行可行性分析

进行共赢分析的主要方法是Stakeholder/Issue关系图

如果某个Stakeholder-Issue关系上所寄予的期望与项目的业务需求无法保持一致，那么它关联的涉众就在该Issue的问题上和项目整体目标存在冲突

如果Stakeholder/Issue关系图中某个Issue所关联的不同关系标识有互相冲突的期望，那么就意味着它所关联的涉众在该Issue上存在需求冲突

涉众代表选择

对于涉众的选择我们应当尽量保证科学，减少采样带来的误差

这里讲解两种常用的涉众选择方法

代表采样（涉众明确时，对于每种涉众选择合适的代表）

完整采样: 每种涉众类别都有自己的代表

态度积极: 愿意提供帮助

数量适中
太少 : 个人看法倾轧群体共同看法
太多: 达成一致困难
代表数量的准确数字要视项目的上下文环境来确定, 一般6-10

比例恰当（代表的个人特征保持恰当的比例分布）
计算机技能
业务技能

用户替代源（涉众不明确时，选择与用户联系密切且有经验的人作为涉众代表）

因为业务关系而和用户频繁接触的人 ，能够代替他们发表看法

涉众参与需求开发（软件系统）的参与策略

事先安排好代表们的参与时间、强度和内容，让代表们在合适的时间参与合适的工作

如果采用的是敏捷开发与极限编程，就需要用户参与需求开发和软件系统开发的整个过程

5.3.2.2硬数据

硬数据的定义：在研究现有系统时，需求工程师获取事实，理解问题域所依赖的文档资料。

定量硬数据

经过仔细设计、具有严格要求的格式化文档。
例如：数据收集表格、统计报表

定性硬数据

定性的硬数据大都采用自然语言进行文本描述，利用起来代价较大
例如：整个组织的描述文档、业务指导文档、业务备忘

硬数据的采样方法

1.随机抽样
随机地采样数据
2.分层抽样
考虑系统的分层，从每一层中随机抽取一个样本

5.3.2.3相关产品

5.3.2.4重要文档

5.3.2.5相关技术标准和法规

5.3.3获取方法

传统方法

问卷调查、面谈、硬数据分析、文档检查、需求剥离等

集体获取方法

头脑风暴（Brainstorming）、专题讨论会（Workshop）、联合应用开发JAD、联合需求计划JRP等

原型

适用于需求模糊和不确定性较大的情况

模型驱动方法

定义明确的模型，确定所收集的信息类型，模型建立和完善的过程就是进行需求获取的过程
面向目标的方法、基于场景的方法、基于用例的方法

认知方法

以认知的方式获取用户无法表达的潜在知识
任务分析（Task Analysis）、协议分析（Protocol Analysis）等

基于上下文的方法

通过分析用户的行为得到信息
观察、民族志（Ethnography）和话语分析（Conversation Analysis）

5.3.4获取过程（了解）

5.3.4.1防止遗漏

务必让所有的涉众都表达出自己的意见。
不要以抽象和模糊的需求作为结束。对抽象和模糊的需求，要进行细化，让真正的需求显露出来。
使用多种方法表达需求信息。利用不同的分析技术为相同的需求进行建模，通过分析不同的关注点，考察需求是否完整。
注意检查边界值和布尔逻辑。

5.3.4.2结束获取活动的判断条件

用户想不出更多的用例；
用户想出的新用例都是导出用例（通过其他用例的结合可以推导出该用例）；
用户只是在重复已经讨论过的问题；
新提出的特性、需求等都在项目范围之外；
新提出的需求优先级都很低；
用户提出的新功能都属于后继版本，而非当前版本

5.3.5获取结果

获取笔录、录音录像（Elicitation Notes）

用户需求、问题域知识和约束
可能具有组织差、冗余、遗漏、自相矛盾等诸多问题
可以包括文字记录、录音、摄像等各种形式

正式文档（项目前景和范围文档、用例文档）

项目前景和范围文档
用例文档

6.确定项目的前景和范围

6.1确定项目前景和范围的活动

1.定义项目前景文档
描述产品是用来描述产品的作用，最终的功能。它使所有的涉众都从共同认同的项目前景出发，理解和描述问题域及需求

2.定义项目范围文档
指出当前项目是要解决的产品是长远规划中的哪一部分。它为项目划定了需求的界限

6.2问题分析

6.2.1明确问题

明确问题就是在不同涉众之间对问题达成共识

要想明确一个问题首先必不可少的就是描述问题，只有将一个问题能够描述的清楚才可以进行以下的步骤，明确完问题之后需要对问题的明确性进行分析，然后发现问题背后的问题

描述问题

描述问题是在涉众之间获取认同

主要使用如下表格的形式进行问题的描述

判断问题的明确性

对于问题描述是否明确主要有一下两种判断因素
1、易于理解
2、能指明解决的方向

发现问题背后的问题

对于不明确的问题，我们直接咨询涉众是第一选择，利用收集的资料和业务数据是第二选择，必要时需要使用一些简单的问题分析技巧

发现问题背后的问题当然还包括发现问题更深层次的问题
我们可以使用鱼骨图列出所有可能的原因，然后请用户确认

如果用户无法确定则搜集数据构建帕累托图进行分析

6.2.2发现业务需求

每一个明确、一致的问题都意味着涉众存在一些相应的期望目标，即业务需求。

我们需要用一个标准化格式来定义业务需求

6.2.3定义解决方案及系统特性

确定高层次的解决方案

确定高层次的解决方案的思想是发现各种可行的高层次解决方案，分析不同方案的业务优势和代价，然后通过和涉众的协商，选定其中一个

描述方式为

确定系统特性和解决方案的边界

系统特性的定义：解决方案需要具备的功能特征，即系统特性，即满足解决方案的系统应当具备哪些功能。

特性：
对一系列内聚的相互关联的需求、领域特征和规格的总称。
通常，一个特性内聚于一个目标与任务，反映了系统与外界一次有价值的完整互动过程。

确定解决方案的约束

解决方案的约束影响设计师、程序员等后续开发者的工作决策，需要重视又被忽视的因素

约束主要有一下几种

6.3建立系统边界

系统边界的定义是系统与环境交互的界限

定义系统边界的意义是可以明确系统需要满足的与外界的交互行为，从而从宏观上界定了系统的功能概要。

得到系统边界的方法是将所有问题的解决方案进行综合，就可以得到整个解系统的功能和边界

6.3.1面向对象——用例图

6.3.2结构化——上下文图

6.4项目前景和范围文档

内容：业务需求、高层次解决方案和系统特性
撰写人：需求工程师
文档负责人：投资负责人、执行主管或其他类似角色
结构：

7.面谈

顾名思义，面谈就是面对面交谈，是获取需求的重要方法之一

7.1面谈中的问题

7.1.1问题的类型

开放式问题

被会见者对答复的选择可以是开放和不受限制的
适用于面谈的前期

优点：
让被会见者感到自在；
会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；
提供丰富的细节；
对没采用的进一步的提问有启迪作用；
让被会见者更感兴趣；
容许更多的自发性；
会见者可以在没有太多准备的情况下进行面谈。
缺点：
提此类问题可能会产生太多不相干的细节；
面谈可能失控；
开放式的回答会花费大量的时间才能获得有用的信息量；
可能会使会见者看上去没有准备。

封闭式问题

答案有基本的形式，被会见者的回答是受到限制的
适用于面谈的后期

优点：
节省时间；
切中要点；
保持对面谈的控制；
快速探讨大范围问题；
得到贴切的数据
缺点：
使得被会见者厌烦；
得不到丰富的细节；
出于上述原因，失去主要思想；
不能建立和面谈者的友好关系。

其他类型的问题

（1）探究式问题：目的是深究答复
为什么？
你能举个例子吗？
你能详细描述一下吗？

（2）诱导性问题：引导被会见者按会见者所想来回答，答复有偏向性
“你和其他经理一样，都同意把财产管理计算机化，是吗”

（3）双筒问题：一个问题包含两个独立的内容，效果差
“每天你通常会做什么决策，你是怎样做的？”

（4）元问题：关于面谈本身的问题，对实施需求有很大帮助
我的问题看起来相关吗？
你的回答正式吗？
你是回答这些问题的最佳人选吗？
我问了太多的问题吗？
我还应该见什么人？

7.1.2问题的组织

金字塔型

漏斗型

菱型

7.2面谈的过程

7.2.1准备面谈

阅读背景资料
确定面谈主题和目标
选择被会见者
准备被会见者
确定问题和类型

7.2.2主持面谈

记录的内容：
（1）事实和问题（主要）
（2）被会见人的观点
（3）被会见者的感受
（4）组织和个人目标

记录的方式
（1）笔录
（2）录音和摄像

7.2.3处理面谈结果

复查面谈记录

整理出内容要点，进行分类
总结面谈信息
评估面谈中所得到的信息

完成面谈报告

7.3面谈的类型

7.3.1结构化面谈

安全按照事先的问题和结构来控制面谈

7.3.2半结构化面谈

事先需要根据面谈内容准备面谈的问题和面谈结构，但在面谈过程当中，会见者可以根据实际情况采取一些灵活的策略

7.3.3非结构化面谈

没有事先预定的情况下就开展某个主题的面谈
甚至会在没有太多事前准备的情况下就直接到访被会见者的工作地，就某个主题开展会谈
会见者和被会见者谈话的主题可能非常广泛，而且每个主题都不会非常深入
也可能在非结构面谈中仅就某个特殊的主题进行深入的讨论

7.4面谈的优点和局限

优点

开展条件较为简单，经济成本低
获取信息广泛，能获得包括事实、问题、被会见者观点、被会见者态度和被会见者信仰等
容易建立好友关系，需求工程师可以和涉众（尤其是用户）建立相互之间的友好关系
提高涉众的项目参与热情。通过参与面谈，被会见者会产生一种主动为项目做出贡献的感觉

局限

面谈比较耗时，时间成本较高
地理位置分散难以实现
需求工程师压力比较大，面谈的成功较高的依赖于需求工程师的人际交流能力
在会见者不了解的情况下难以开展

8.原型

帮助需求工程师及早解决需求的不确定性：
创新性产品，它们的基本需求是潜在的，有着很大的不确定性；
产品的用户对相关类别的产品没有经验，产品的细节需求存在着不确定性；
用户在完成工作的方式上仍然存在障碍，产品在整体方案的可行性上存在着不确定性；
用户在清晰说明他们的需求方面存在困难，这些相关的需求是有着不确定性的需求；
需求工程师在理解用户的需求上存在困难，在澄清和理解之前，这些需求存在着不确定性；
需求的可行性值得怀疑，即具体需求的可满足性存在着不确定性。

8.1应用原型的必要性

概念：原型是一个系统，它内化了（capture）一个更迟系统（later system）的本质特征

描述原型的方式包括书面描绘、场景叙述、情节串联图板、幻灯演示、动画模拟、屏幕快照和程序代码等

原型的优点：
及时、有力的响应用户需求的变化；
减少返工；
帮助控制不完整需求所带来的风险；
可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤；
减少开发成本，提高经济效益；
增加开发者之间的交流，帮助确定技术解决方案的可行性；
有效的识别风险和解决风险，帮助进行风险管理；
提高用户在软件开发中的参与程度。

8.2原型的类别

8.2.1按照使用方式分类

(1)演示原型（presentation prototype），如Demo
主要被用在启动项目阶段
目的是让用户相信应用系统的开发是可行的

(2)严格意义上的原型（prototype proper）
主要被用在需求分析阶段
用来阐明用户界面或者系统功能的某些特定方面

(3)试验原型（breadboard prototype）
主要被用在构建系统阶段
帮助开发者澄清他们所面对的一些和系统构建相关的技术问题

(4)引示系统原型（pilot system prototype）
会被用在系统开发的各个阶段
用作最终系统的构建核心，在后续的开发中被不断增强

8.2.2按照开发方式分类

1.探索式（exploratory） 开发的原型为废弃式原型
以缺陷需求开始继而不断调整和修正需求的原型开发方式
需求不确定程度高，且不确定方面来自于需求方面

2.实验式（experimental） 开发的原型为抛弃式原型
以清晰的用户需求和模糊的实现方法、实现效果、可行性开始，明确需求的可行性和技术实现方案
需求不确定程度高，且不确定方面来自于技术细节方面

3.演化式（evolutionary） 开发的原型为演化式式原型
以清晰的原型化需求和项目积累下来的原型资产为开始被不断传递和不断增强的原型资产将成为最终的软件系统
需求不确定程度低

8.2.3按照构建技术分类

水平原型方法（horizontal prototyping）
它仅仅实现选定功能所有层次中的某些特定层次
要把注意力集中在概括性需求和工作流问题上，处理范围较大，但并未实现所涵盖的功能
需求获取水平原型关注的常见层次：人机交互、功能与任务和实现。
1.人机交互关注用户使用时的感觉体验。重点在于原型的界面外观。
2.功能与任务原型关注用户的任务。原型能带来哪些工作与任务。
3.实现原型关注特定功能实现的技术细节。原型开发的功能实现方法，验证方法技术的可行性和观察用户对原型的反应。

垂直原型方法（vertical prototyping）
它会触及到选定功能实现的所有层次
要保证真实实现它的各种功能，考虑所有技术细节

8.2.4按照介质分类

8.2.5按照表现分类

故事版是交互性介于静态画面和动态程序之间的一种原型表现形式，它能够表现场景式的互动。

8.3原型方法过程

（1）确定原型需求
为什么开发原型，拥有的起点是什么？期望的结束标准是什么？

（2）原型开发
依据原型的需求特点和开发目的，以最低的成本建立初始原型

（3）原型评估
对上一阶段原型进行评估，根据评估者的反馈判断原型是否满足结束标准。评估者一般是用户和开发者

（4）原型修正
如果已经建立的原型达到了目的，就结束原型方法的过程；否则根据评估者反馈的不足进行原型调整，调整完成后准备再次进行原型评估。

8.4原型方法的风险

缺点：复杂性使它在减少风险的同时也引入了新的风险
1.最大的风险是成本失控。原型开发工作投入太多的工作，使得开发团队消耗了过多的时间和过大的成本 。
2.第二个风险是给客户造成错误印象。涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求。
3.用户过多关注原型的非功能需求，容易忽略功能特性
4.可能会掩盖一些用户假设，这些将会无从发现。

9.观察和文档审查

9.1观察的情境适用性

常见的观察方法

（1）采样观察：传统、简单的方法，它根据明确的目的选取特定的时间段或特定的事件进行观察。

（2）民族志：长期、浸入式的观察方法。

（3）话语分析：对用户之间的交谈行为的观察。观察和分析交谈中的交互方式或特定话语形式的内部结构来发现和获取信息

（4）协议分析：对用户任务的观察。要求观察对象一边执行任务，一边大声解释执行任务时产生的各种想法。

（5）任务分析：专门针对人机交互行为进行的观察。

观察的情境性（了解）

情景性：某些事件与具体环境联系起来才能被理解。
情景性的重要性质：
1.突现——事件是集体成员集体促成的，所以需要将所有的成员互动联系起来才能理解这些事件。
2.局部——事件及其解释只有在特定的上下文环境下才能得以成立。
3.暂时——对事件的解释会受到活动演进过程的影响，用户的解释可能仅仅是对以前类似事件的解释。
4.涉身——特定的参与者对周围环境的感知方式会从根本上影响事件的解释。
5.开放——仅仅依据现有信息无法在总体上对事件的原理给出一个最终和完整的解释。用户无法对事件形成全面和准确的解释，对事件的解释保持开放，从而可以进一步进行完善。
6.模糊——对事件的解释往往不能至及其精确的程度，而是基于一些潜在的知识进行展开。

9.2观察方法的应用

9.2.1采样观察

9.2.2民族志

优点
能够得到信息的深度理解
能够让真实世界的社会性因素可见化
打破人们已有的一些错误假设和错误观念

缺点
耗时
调研结果很难传递到开发过程，抽取知识困难

注意事项
应该定期的记录发现
尽快的记录可能会在观察过程中发生的面谈
定期的复查和更新自己的想法
海量数据的应对策略 （总结，索引，分类）

9.3文档审查方法的应用

文档审查是传统的专门针对文档进行的需求获取活动。
它的主要获取对象包括相关产品（原有产品或竞争产品）的需求规格说明、硬数据和客户的需求文档（委托开发的规格说明、招标书）

10.需求分析概述

10.1需求分析的根本任务

10.1.1建立分析模型

建立分析模型的目标：达成开发者和用户对需求信息的共同理解

建立分析模型包括：
分解系统，抽象出本质
达成信息的共同理解
分析的活动主要包括识别、定义和结构化

10.1.1.1模型

模型的概念：模型是对事物的抽象，是对系统进行思考和推理的一种方式

建模的目标：建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易

建立模型的方法

抽象：找到本质特征

分解：简化降低复杂性

投影：模型描述（多视点方法）

视点：将系统中既交织共存又相对独立的不同内容拆解成不同的组成部分。每一个视点都是独立的模型存在，用独立的模型语言和表述方法来进行描述
多视点：所有视点的模型描述集成起来，就是对原有复杂系统的模型描述

建立模型的好处

降低应用的复杂性；
更深刻的理解信息；
更好的记忆细节；
更好的与其他开发人员进行交流；
更好的与用户以及其他涉众进行交流；
为维护和升级提供文档

10.1.1.2两个世界与三种模型

两个世界：现实世界和计算世界

计算模型（不是个需求建模）

特征：基于计算科学建立的，具有形式化的特征，信息的描述具有明确化、准确化和确定化的特征

不适合需求建模的原因：
缺乏和软件实现相关的技术细节
用户无法理解

业务模型（不适合需求建模）

特征：使用了业务描述的方式，具有非形式化特征

不适合需求建模的原因：
业务模型元素的选取和定义上具有不准确、不确定和模糊化的特征

分析模型（适合做需求建模）

特征：
介于计算模型和业务模型二者之间的模型形式
使用了计算模型的组元形式
在组元的表现上采用了业务模型的表现方式

适合原因：
不像计算模型那么严谨
比业务模型更严格

10.1.1.3模型的表述

三要素

语法：使用规则——怎样使用模型的元素，并且以什么方式组织、连接或关联这些元素；
语义：特定模型元素所具有的含义；
语用：模型元素的上下文，以及影响该模型元素意义的约束和假定

分析模型

语用复杂
语义丰富
语法严格同时又不太复杂

需求建模

先依据获取的问题域信息建立初步的模型。

然后分析用户需求，对模型进行调整，得到一个中间形式的模型形式。

对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。

需求分析和目标

10.1.2建立解决方案

集中关注问题的计算特性（数据、功能、规则）

10.2需求分析技术

结构化技术

数据建模
实体关系图(ERD)Entity Relationship Diagram
过程建模
数据流图(DFD)Data Flow Diagram
上下文图Context Diagram
微规格说明Mini-Specification
数据字典Data Dictionary
行为建模
状态(转换)图/矩阵State (Transition) Diagram/Matrix
过程/数据关系建模
功能实体矩阵Function/Entity Matrix
信息工程方法
功能分解图Function Decomposition Diagram
过程依赖图Process Dependency Diagram

面向对象技术

用例图Use-Case Diagram
活动图Activity Diagram
类图Class Diagram
状态图State Chart Diagram
交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram
对象约束语言Object Constraint Language

综合运行需求分析技术

如何为各个视角选择需求分析技术？
每一种需求分析技术都有自己的特点，具有在应用上的独特性

如何实现它们之间的配合？
只有通过多种需求分析技术的有机结合与集成才能充分的描述复杂应用

10.3需求分析方法

传统分析(1950’s)

没有固定方法
缺乏结构、不可重复、不可测量,冗长、混乱、偏颇、无结构

结构化分析(late 1980’s)

传统结构化分析 (late 1960’s),现代结构化分析 (late 1970’s)
以数据流动为中心，以DFD为核心技术，辅助ERD…

信息工程 (late 1980’s)
以数据知识结构为基础，ERD为核心技术，辅助DFD，STD, FDD,…

面向对象分析(1990‘s)

以对象为中心，以UML（类图）为核心技术

10.4前期需求阶段的建模与分析

针对问题世界的分析和针对计算世界的分析

前期需求阶段和后期需求阶段

面向目标的分析（Goal Oriented Analysis）

通过关注前期需求阶段—项目的前景与范围定义活动进行目标分析

面向问题域的分析（Problem Domain Oriented Analysis）

面向问题域，关注问题的理解和建模

领域分析（Domain Analysis）

代价很高！！！！

领域分析的职责是发现、分析并定义可复用的需求。
领域：应用的集合
产品族：来自于同一应用领域并具有共性特征的产品。对产品的开发应当尽可能的实现复用。
产品线：以软件复用为核心建立产品族的方法。

产品线的开发方法分为两个部分：
领域工程与应用工程
领域工程负责分析、设计和建立可复用的软件物件
应用工程以此为基础，建立最终产品。

企业建模（Enterprise Modeling）

主要用来理解组织的结构、行为规则、目标、重要成员的任务与职责、操纵的数据等等。

企业建模利用企业的目标、任务、策略、资源等来刻画组织的行为，并依此来发现组织开发系统的目的，建立系统的业务需求

10.5需求分析的活动

10.5.1前期需求分析的活动

以问题域为关注点的分析

包括的活动：背景分析；问题分析；目标分析；业务分析；确定系统边界

10.5.2后期需求分析的活动

后期需求阶段分析活动：发生在获得需求信息之后的分析活动

包括的活动：需求建模；需求细化；确定需求优先级和需求协商

过程描述（了解）

需求细化

需求细化的根本：是将从问题域和业务任务角度描述的用户需求转换为从软件和技术角度描述的系统级需求

细化内容：
（1）需要将用户需求细化
用户需求以任务为单位的，但一个任务完成可能需要多次交互。
（2）需要补充隐含因素
将从问题域信息补充到系统需求中，这些需要补充的信息就是隐含因素。
（3）非功能需求也需要随着功能需求的细化而细化
（4）会发现新的细节需求
这些细节往往是用于约束和限定解决方案的手段。
（5） 在足够具体时停止。
足够具体意味着需求已经得到了充分的理解，并且开发者已经可以着手为其进行方案设计了。

需求的记录：
标识符（ID），每一条需求都应该能够通过ID唯一的标识自己。
源头（Source），要能够回溯到需求的源头，例如特定的涉众。
理由（Rational），需求被提出的目的。
优先级（Priority），详细情况见下一节。
成本（Cost），预估的实现成本。
风险（Risk），实现该需求的过程中可能带来的风险。
可变性（Volatility），将来发生变化的可能性。

确定需求的优先级

1.需要确定优先级的情况：
（1）一个项目的资源有限
（2）项目采用分阶段的开发方式，第一阶段应交付最重要和最紧急的需求
（3）项目的开始阶段，无法明确和保证最终满足所有用户需求

2.确定优先级的常用方法
（1）累计投票：按需求得到的总分值确定优先级
（2）区域划分：评价优先级的常见特征：

重要性。需求的不可或缺程度。
紧急性。需求的时间紧迫程度。
惩罚性。忽略需求会导致的惩罚程度。
成本。实现需求的代价。
风险。需求实现中可能产生的风险程度。

Top-N
每次迭代开始之前，由评价人选择他们认为最重要的N个需求。N的取值是不受明确限制的，真正受限制的是Top-N个需求的实现代价总和。

需求协商

需求协商活动包括：对目标冲突的处理、对需求细节冲突的处理

关键：
涉众之间的人际互动
需求协商三原则：
（1）明确冲突的因素，避免情绪上的冲突
（2）明确冲突的解决空间
（3）确定最佳解决方案

11.需求规格说明

11.1需求规格说明概述

需求获取的目标是得到用户的需求——收集需求信息
需求分析的目标是更深刻的理解用户的需求——界定能够让用户满意的解决方案和准则
需求规格说明的目标是定义用户的需求——准确描述其需求和解决方案

需求规格说明文档的撰写流程如下图：

11.2需求规格说明文档

编写需求规格说明的必要性：
1.更好的传递软件系统的需求信息和解决方案给所有的开发者
2.拓展人们的知识记忆能力
除必要性以外，编写需求规格说明可以带来的其他好处：
1.作为合同协议的重要部分
2.作为项目开发活动的一个重要依据
3.发现和减少可能的需求错误，减少项目的返工，降低项目的工作量
4.作为有效的智力资产

常见的需求说明文档主要有以下几种：

以上不同类型的文档主要有一下区别：
需求文档的名称不同
需求文档的内容不同
需求文档内容的组织方式不同
需求文档内容的表达方式不同
需求文档的用途和作用不同
在联系需求时使用的辅助性文档不同

项目的前景和范围文档被视为属于用户的文档，主要包括的内容有问题域信息、解决方案、需求，内容较为抽象，具有概括性的特点
招标活动是基于用户需求文档进行的
大多数系统开发项目都是以系统需求规格说明文档为基础签约的

软件需求规格说明文档是对整个系统功能分配给软件部分的详细描述。
对系统规格说明的细化和详细说明会产生软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档，都是开发文档。

需求规格文档的作者和读者有：项目管理者、设计人员和程序员、测试人员、文档编写人员、维护人员、培训人员、律师

典型开发活动片段：

信息描述语言的3种类别：
非形式化（文本为主）
半形式化（图形为主）
形式化（数学公式为主）

11.3模版的选择与裁剪

11.4文档写作技巧

指导原则：
写作是一门艺术
文档化的目标是交流

内容组织：
所有内容位置得当
引用或强化，但不重复

表达方式：
形式依赖于内容
使用系统的表达方式

细节描述：
定义术语表或数据字典时应避免的问题有
术语不一致
“方言”问题
错误术语和冗余术语
避免干扰文本
避免歧义词汇

11.5优秀需求规格说明文档的特性

完备性

标准（当且仅当）
描述了用户的所有有意义的需求，包括功能、性能、约束、质量属性和对外接口。
每一条需求都是完备的。
定义了软件对所有情况的所有实际输入（无论有效输入还是无效输入）的响应。
为文档中的所有插图、图、表和术语、度量单位的定义提供了完整的引用和标记。
正确的前景和范围

一致性

细节的需求不能同高层次的需求相冲突，例如系统需求不能和业务需求、用户需求互相矛盾
同一层次的不同需求之间也不能互相冲突

根据重要性和稳定性分级

建立需求的优先级

可修改

标准
它的结构和风格使得人们可以对其中任一需求进行容易地、完整地、一致地修改，同时还不会影响文档现有的结构和风格

文档的可修改性要求：
有着条理分明并且易于使用的组织方式，包括目录、索引和显式的交叉引用。
没有重复冗余。
独立表达每个需求，而不是和其他需求混在一起。

可跟踪

标准
它包含的每个需求的来源是清晰的，并且存在一种机制使在未来的开发工作中引用该需求是可行的。

分为：
1.后向跟踪（Backward traceability）
能找到需求的来源，例如和更早期文档的显式关联。
2.前向跟踪（Forward traceability）
能找到需求所对应的设计单元、实现源代码和测试用例等，它要求每个需求都要有唯一的标识或者可供引用的名称

11.6需求规格说明的实践调查

不编写正式的需求规格说明文档的原因：
1.时间压力，用非正式文档替代
2.迭代式开发，每次迭代是完成本次需求的正式需求规格说明，最后在整合成完整版本

12.需求验证

12.1验证与确认

需求验证主要有两层含义：
1.验证：正确得到需求
2.确认：得到正确的需求

1. 需求验证：以正确的方式建立需求
需求集是正确的、完备的和一致的；
技术上是可解决的；
它们在现实世界中的满足是可行的和可验证的。

2.需求确认：建立的需求是正确的
每一条需求都是符合用户原意的
系统验证：正确的建立系统
系统能够在预期的环境中正确的执行设定的功能。
系统确认：建立的系统是正确的
建立的系统是符合系统需求和系统设计的

验证贯穿于整个软件生命周期，静态分析和测试的两个主要手段

12.2需求验证

需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动

12.3需求验证方法

12.3.1评审

由作者之外的其他人来检查产品问题的方法
是主要的静态分析手段
原则上，每一条需求都应该进行评审

12.3.2原型与模拟

用于静态方法力所不及的复杂需求

涉及到复杂的动态行为时
成本较高

12.3.3开发测试用例

用于功能测试，测试用例可以尽早开发

为需求类开发测试用例也可以被看成一个有效的需求验证方法
无法测试的需求并非绝对有问题

排斥性需求和全局非功能性需求通常无法定义测试用例

12.3.4用户手册编制

用户手册主要包含以下内容：
1.验证功能需求：对软件系统功能和实现的描述
2.验证项目范围：对系统没有实现的功能的描述
3.验证异常流程需求：问题和故障的解决
4.验证环境与约束需求：系统的安装和启动

12.3.5利用跟踪关系※

业务需求（系统特性）=>用户需求（业务、任务）=>系统需求（分析模型）
逐步细化的关系
如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。软件需求规格说明文档描述的是系统级需求，被用来进行需求验证

系统需求=>用户需求=>业务需求
如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。

12.3.6自动化分析

在一致性、正确性方面，自动化的工具检查一直是研究者的关注目标

强的限制前提：用形式化方法书写软件需求规格说明文档

12.4问题修正※

1.需求澄清
（1）理解偏差：重新进行分析工作
（2）分析遗漏：重新分析和文档化这部分信息
（3）表达不当：重新以合适的方式表达

2.发现缺失需求
重新执行需求获取等一系列工作

3.解决需求冲突
协商解决

4.修正不切实际的期望
项目调整与需求协商

12.5需求验证的实践调查

需求验证是重要的
需求验证是容易被忽视的
需求验证的方法是多样的
评审和原型最为广泛

13.需求管理

13.1需求管理

13.1.1需求管理意图

需求的影响力
整个后续的产品生命周期 VS 需求开发阶段
需求规格说明文档
后续的开发工作都应该以软件需求规格说明文档的内容为标准和目标来进行
需求管理能够做到
在需求开发之后的产品生命周期当中保证需求作用的有效发挥
保证软件质量

13.1.2需求管理作用

（1）增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解，将需求基线纳入项目的知识管理
增强了项目涉众对需求（尤其是复杂需求）的掌握。
（2）增进了项目涉众之间的交流
减少了可能的误解和交流偏差。
（3）减少了工作量的浪费，提高了生产力
需求管理能够更加有效的处理需求的变更
（4）准确反映项目的状态，帮助进行更好的项目决策
需求跟踪信息能够更加准确的反映项目的进展情况
（5）改变项目文化，使得需求的作用得到重视和有效发挥
使得项目涉众认识到需求在项目工作中的重要性

13.1.3需求管理任务

交流涉众需要什么；
将需求应用、实施到解决方案；
驱动设计和实现工作；
控制变更；
将需求分配到子系统；
测试和验证最终产品；
控制迭代式开发中的变化；
辅助项目管理

13.1.4需求管理活动

13.2需求基线

是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求集合

需求基线的主要描述内容有软件需求（需求基线的关键内容）+和软件需求相关的描述信息，如：
标识符（ID），为后续的项目工作提供一个共同的交流参照。
当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础之上。
源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求的源头。
理由（Rational），提供需求产生的背景知识。
优先级（Priority），后续的项目工作可以参照优先级进行安排和调度。
状态（Status），交流和具体需求相关的项目工作状况。
成本、工作量、风险、可变性（Cost、Effort、Risk、Volatility），为需求的设计和实现提供参考信息，驱动设计和实现工作。

13.3需求跟踪

主要目的是：避免在开发过程或者演化过程中与需求基线不一致或者偏离的风险

需求跟踪是以软件需求规格说明文档为基线，在向前和向后两个方向上，描述需求以及跟踪需求变化的能力。

1.前向跟踪是指被定义到软件需求规格说明文档之前的需求演化过程
向需求的跟踪：说明涉众的需要和目标产生了哪些软件需求
从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标

2.后向跟踪是指被定义到软件需求规格说明文档之后的需求演化过程
从需求向后跟踪：说明软件需求是如何被后续的开发物件支持和实现的
向需求的回溯：说明各种系统开发的物件是因为什么原因（软件需求）而被开发出来的

13.3.1用途

需求的后向跟踪可以帮助项目管理者：
评估需求变更的影响；
尽早发现需求之间的冲突，避免未预料的产品延期；
可以收集没有被实现的需求，并估算这些需求需要的工作量；
发现可以复用的已有组件，从而降低新系统开发的时间和精力；
明确需求的实现进度，跟踪项目的状态。

需求的后向跟踪可以帮助客户和用户：
评价针对用户需求的产品的质量；
可以确认成本上没有（昂贵的）镀金浪费；
确认验收测试的有效性；
确信开发者的关注点始终保持在需求的实现上。

需求跟踪中针对具体需求的设计方案选择、设计假设条件以及设计结果等信息可以帮助设计人员：
验证设计方案正确的满足了需求；
评估需求变更对设计的影响；
在设计完成很久之后仍然可以理解设计的原始思路；
评估技术变化带来的影响；
实现系统组件的复用；

需求跟踪信息还可以帮助维护人员：
评估某一个需求变化时对其他需求的影响；
评估需求变化时对实现的影响；
评估未变化需求对实现变更的允许度。

13.4需求变更控制

需求的变化是正当和不可避免的，包括：
问题发生了改变
环境发生了改变
需求基线存在缺陷

13.5需求管理的实践调查

13.5.1需求变更

变更发生的事件越迟，影响越大
新增（Added）需求影响最大——影响最大的变更类型
缺陷修复是最为频繁的变更类型
范围蔓延是常见的风险因素

13.5.2需求管理工具

通用的文本处理器（Word Processor）和电子表格（Spreadsheet）使用最为广泛