系列文章目录
系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】
系统架构设计专业技能 · 软件工程之需求工程
一、 需求工程概述
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
需求工程（Requirement Engineering，RE） 是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。
需求工程由需求获取、需求分析、形成需求规格（或称为需求文档化）、需求确认与验证、需求管理5个阶段，如图：
软件需求规格说明书（Software Requirement Specification，SRS）
SRS具体包括功能需求、非功能需求和约束。约束包括设计约束和过程约束。批准的SRS是需求开发和需求管理之间的桥梁。
需求管理
需求管理是一个对系统需求变更、了解和控制的过程，包括变更控制、版本控制、需求跟踪等活动。
二、 需求开发（主线、目标）
2.1 需求分类
- 需求分类
（1）业务需求：业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。
（2）用户需求：用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求
（3）系统需求：系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- 质量功能部署QFD
它是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
（1）基本需求：也叫常规需求，用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（2）期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
（3）意外需求：意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
2.2 需求获取
| 方法 | 特点 |
|---|---|
| 收集资料 | 把与系统有关的、对系统开发有益的信息收集起来。 |
| 阅读历史文档 | 对收集数据性的信息较为有用。 |
| 用户访谈 | 1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑。 |
| 问卷调查 | 用户多，无法—一访谈，成本低。 |
| 现场观摩 | 针对较为复杂的流程和操作。 |
| 参加业务实践 | 有效地发现问题的本质和寻找解决问题的办法。 |
| 联合需求计划(JRP) | 高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。 |
| 情节串联板(原型法) | 一系列图片，通过这些图片来讲故事。 |
| 抽样调查/采样 | 基于数理统计，降低成本，快速获取。 样本大小=a*(可信度系数/可接受的错误)2注:a一般取0.25 |
-
用户访谈
用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。 -
问卷调查
问卷调查与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。但是问卷调查最大的不足就是缺乏灵活性，其他缺点还有：
① 双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信息，用户也没有机会立即澄清对问题有含糊或错误的回答。
② 用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。
③ 调查表不利于对问题进行展开的回答，无法了解一些细节问题。
④ 回答者的数量往往比预期的要少，无法保证用户会回答问题或进一步说明所有问题。 -
抽样调查/采样
抽样调查/采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。采样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，不仅加快了数据收集的过程，而且提高了效率，从而降低了开发成本。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。
但是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和已有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较高的水平和丰富的经验。 -
联合需求计划（JRP）
JRP是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6～18人，召开时间为1～5小时。
JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：
① 在JRP实施之前，应制订详细的议程，并严格遵照议程进行。
②按照既定的时间安排进行。
③尽量完整地记录会议期间的内容。
④在讨论期间尽量避免使用专业术语。
⑤充分运用解决冲突的技能。
⑥会议期间应设置充分的间歇时间。
⑦鼓励团队取得一致意见。
⑧保证参加JRP的所有人员能够遵守事先约定的规则。
2.3 需求分析
需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
需求分析的任务：
（1）绘制系统上下文范围关系图
（2）创建用户界面原型
（3）分析需求的可行性
（4）确定需求的优先级
（5）为需求建立模型
（6）创建数据字典
（7）使用QFD（质量功能部署)
2.3.1 结构化分析方法 - SA
结构化分析方法SA的核心是数据字典。围绕这个核心有三个层次的模型，分别是数据模型，功能模型，行为模型（状态模型）。
结构化分析的步骤，如下：
（1）分析业务情况，做出反映当前物理模型的数据流图（Data Flow DiagramDFD）。
（2）推导出等价的逻辑模型的DFD。
（3）设计新的逻辑系统，生成数据字典和基元描述。
（3）建立人机接口，提出可供选择的目标系统物理模型的DFD。
（5）确定各种方案的成本和风险等级，据此对各种方案进行分析。
（6）选择一种方案。
（7）建立完整的需求规约。
结构化分析方法SA是数据流和控制流，常用手段是数据流图（DFD）和数据字典。
2.3.1.1 SA - 数据字典DD
数据字典是需求分析建立模型的核心。是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。
数据字典有4类条目：数据流、数据项、数据存储和基本加工。包括了数据元素，数据结构，数据流，加工逻辑和外部实体。如下图：
2.3.1.2 SA - 数据流图DFD
数据流图DFD是用数据流图表示功能模型，DFD说明系统所完成功能，从数据传递和加工的角度，利用图形符号通过逐层细分描述系统的各个部件的功能和数据在他们之间传递的情况，来说明系统所完成的功能。如下图：
其中，DFD还会有“顶层DFD图”和“0层DFD图”。
如上图，有如下几种“图元”描述：
另附一个错误的DFD图，如下：
如上图错误：
加工3.1.2有输入但是没有输出，称之为“黑洞”。
加工3.1.3有输出但没有输入。称之为“奇迹”。
加工3.1.1中输入不足以产生输出，我们称之为“灰洞”。
2.3.1.3 SA - 状态转换图STD
用状态转换图表示行为模型，STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出做为特定事件的结果将执行哪些动作。如下图：
2.3.1.4 SA - E-R图/实体联系图
ER图主要描述实体属性，以及实体之间的关系。另外，ER模型是结构化时代的模型与产物，在面向对象和UML中是没有的。如下图：
什么是弱实体？
举例说明：在人事管理系统中，职工子女的信息就是以职工的存在为前提的，子女实体是弱实体，子女与职工的联系是一种依赖联系。所以，职工是实体，也可以成为强实体。
强实体与弱实体的联系只能是1：1或1：N。
2.3.2 面向对象的分析方法 - OOA
相关的几个概念
| 对象 | 属性[数据] + 方法[操作] + 对象ID/标识ID |
|---|---|
| 类[详细见下] | 实体类/控制类/边界类 实体类：往往和数据库有对应的关系，是不是数据类型 控制类：衔接实体类和边界类的类 边界类：在一个系统的边界上和外部进行沟通的类 这三个类似于MVC模型之间的关系，它们的思想是一样的 |
| 继承与泛化 | 复用机制，它是一种紧耦合。因为当父类变的时候子类不得不变。继承是对已有实例 |
| 封装 | 隐藏对象的属性和实现细节仅对外公开接口 |
| 多态 | 不同对象收到同样的信息产生不同的结果 |
| 接口 | 一种特殊的类，它只有方法定义没有对方法的实现 |
| 重载 | 一个类可以有多个同名的参数类型不同的方法。函数同名但参数不一样是其特点 |
| 消息和消息通信 | 消息是异步通信的 |
| 覆盖与重写 | 子类的同名方法覆盖父类的同名方法 |
| 组合与聚合 | 聚合关系：汽车部件和整车的关系（整体与部分生命周期不同） 组合关系：部门与公司的关系。公司倒闭的话部门也完完（整体与部分生命周期相同） |
OOA大致上遵循如下5个基本步骤：
（1）确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
（2）确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
（3）确定主题：主题是指事物的总体概貌和总体分析模型。
（4）确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
（5）确定方法：方法是在收到消息后必须进行的一些处理方法:方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。
2.3.2.1 OOA - UML
OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。
UML基本构造块之事物【重要组成部分】
| 事务 | 描述 |
|---|---|
| 结构事物 | 最静态的部分，包括类，接口，协作用例，活动类，构件和节点 |
| 行为事物 | 代表时间和空间上的动作，包括消息，动作次序，连接 |
| 分组事物 | 看成是个盒子，如包和构件 |
| 注释事物 | UML模型的解释部分。描述，说明，和标注模型的元素 |
UML基本构造块之关系【把事物紧密联系在一起】
| 关系 | 描述 |
|---|---|
| 依赖关系 | 一个事物发生变化影响另一个事物，包含关系和扩展关系都属于依赖 |
| 泛化关系 | 特殊一般关系，特殊元素的对象可替换一般元素的对象 |
| 关联关系 | 描述了一个链，链是对象之间的连接 |
| 实现关系 | 接口与类之间的关系，一个类指定了由另一个类保证执行的契约 |
UML基本构造块之图【多个相互关联的事物的集合】
| 图 | 描述 |
|---|---|
| 静态图 | 结构图 |
| 类图 | 描述一组类，接口协作和它们之间的关系。 |
| 对象图 | 描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。 |
| 构件图 | 也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。 |
| 部署图 | 表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。 |
| 制品图 | 描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。 |
| 包图 | 将某些类放入“包”中，通过包图来组织业务概念图。 |
| 组合结构图 | 展示该部分内容“内部”参与者的配置情况。这个图不常用。 |
| 动态图 | 行为图 |
| 用例图 | 系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。 |
| 顺序图 | 强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。 |
| 通信图 | 也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。 |
| 定时图 | 消息跨越不同对象或角色的实际时间。交互图的一种。 |
| 交互概览图 | 活动图与顺序图的结合。这个图不常用。 |
| 活动图 | 类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。 |
| 状态图 | 从某个物品的状态是如何变化的角度来展示流程。 |
UML规则
是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。
UML公共机制
是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。
UML中的概念
- 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
- 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
- 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
- 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
- 用例：是描述一系列的动作，产生有价值的结果。
- 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
- 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
2.3.2.2 OOA - UML 4+1视图
现有的UML，再有的UML视图
UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。
“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。
“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。
2.3.2.3 OOA - 用例模型与分析模型
在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。
2.3.2.4 需求分析工具
2.3.2.4.1 使用用例建模系统需求
用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。
用例建模促进并鼓励了用户参与，具有如下优点：
- 提供了捕捉功能需求的工具。
- 有助于将系统分解为更易于管理的小块。
- 提供了与用户以及其他关心系统的关联人员进行交流的工具。
- 辅助估计项目范围、投入和进度。
- 提供了需求跟踪的工具。
- 提供了确定数据对象或实体的起点。
- 提供了设计用户和系统接口的功能规格说明。
为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。
1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：
- 对架构设计的重要影响。
- 容易实现但包含重要功能。
- 包含有风险、时间紧迫或复杂的功能。
- 需要大量的研究或者新的、有风险的技术。
- 包含主要的业务功能。
- 将增加或者减少费用。
2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：
- 系统事件及其状态的图形化表述有利于对系统功能的理解。
- 有助于确定遗漏的用例。
- 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。
2.3.2.4.2 数据建模与分析
数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。
数据建模的系统概念：
- 实体
- 属性（数据类型、域、默认值）（键）
- 关系
如何构造数据模型？
- 获取实体。
- 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
- 基于键的数据模型：确定每个实体的键。
- 泛化层次体系：父实体、子实体。
- 具有完整属性的数据模型。
- 分析数据模型：规范化（第一范式、第二范式、第三范式）。
- 将数据需求映射到地点：数据–地点–CRUD矩阵。
2.3.2.4.3 过程建模
过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。
过程建模的系统概念：
- 外部代理：常见的同义词包括外部实体。
- 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
- 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
- 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。
如何构造过程模型：
- 构造上下文数据流图：0号数据流图。
- 构造系统功能分解图。
- 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
- 事件分解图：把事件处理过程增加到分解图中。
- 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
- 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
- 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。
2.3.2.4.4 面向对象分析与建模
面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。
2.4 需求定义（形成需求规格）
需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。
严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。
原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。
2.5 需求确认与验证
需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：
（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。
需求验证包括了需求评审和需求测试。
需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。
需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。
三、 需求管理（支持，保障）
在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
3.1 定义需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。
3.2 需求的状态
在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。
3.3 需求变更管理
CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。
3.4 需求变更管理过程
（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。
常见的需求变更策略：
（1）所有需求变更必须遵循变更控制过程。
（2）对于未获得批准的变更，不应该做设计和实现工作。
（3）变更应该由项目变更控制委员会决定实现哪些变更。
（4）项目风险承担者应该能够了解变更的内容。
（5）绝不能从项目配置库中删除或者修改变更请求的原始文档。
（6）每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。
3.5 需求风险
带有风险的做法有：①无足够用户参与。②忽略了用户分类。③用户需求的不断增加。④模凌两可的需求。⑤不必要的特征。⑥过于精简的SRS。⑦不准确的估算。
变更产生的原因：①外部环境的变化。②需求和设计做的不够完整。③新技术的出现。④公司机构重组造成业务流程的变化。
3.6 需求跟踪
SRS中的每个软件配置项的需求到其涉及的系统（或子系统）需求都要具有双向可追踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。