软件工程中的需求管理活动

本文是对IEEE-29148 系统与软件工程-生命周期流程-需求工程的第六章的整理和解读，在原文基础上有做适当润色调整。全文分为五个部分，分别是：

[需求工程流程 ^1^概述](/specification/req-flow-guide.html)
[利益相关者 ^2^需求定义流程](/specification/req-flow-strs.html)
[需求分析流程 ^3^](/specification/req-flow-analysis.html)
[需求工程活动 ^4^](/specification/req-flow-activity.html)
需求管理

本文是第五部分:需求管理

管理概述

需求管理包括记录和维护需求工程活动中不断变化的需求以及相关背景和历史信息的任务。需求管理还建立了定义、控制和发布各级相关系统基准需求的程序。有效的需求管理发生在组织的项目和技术流程的背景下，如 ISO/IEC 15288 和 ISO/IEC 12207 所定义。

需求很少是静态的。虽然从开发管理的角度来看，永久冻结一组需求是可取的，但这几乎是不可能的。应该确定可能发展的需求，并将其传达给采购方和技术社区。可以尽早冻结核心子集的需求。应评估拟议的新需求的影响，以确保维持需求基线 ^5^的初始意图，或采购方理解并接受意图的变更。

在几乎所有情况下，随着生命周期活动的进行，对需求的理解都在不断发展。这通常会导致在生命周期后期对需求进行修订。关于需求工程的理解中最重要的一点可能是，很大一部分需求都会发生变化。这有时是由于分析中的错误，但通常是环境变化的必然结果，例如采购方的运营或业务环境的变化，或系统销售市场的变化。

然而，在生命周期内进行需求变更时应谨慎行事。虽然有些变更是不可避免的，但过多的不受控制的变更可能会导致"需求蔓延"，从而导致成本超支、进度延误、设计错误、买家不满意，甚至取消项目。

变更管理

无论需求变更的原因是什么，认识到变更的必然性并采取措施减轻变更的影响都很重要。变更的管理必须确保提议的变更经过明确的影响评估、审查和批准流程，并应用仔细的需求跟踪和版本管理。因此，需求工程流程不仅仅是一项前端任务，而是贯穿整个生命周期。在一个典型的项目中，需求管理活动会随着时间的推移从引出发展到变更管理。

常用的基线是功能基线、分配基线、开发基线和产品基线。项目配置管理计划中通常会确定用于给定项目的基线以及变更批准所需的相关权限级别。这些基线描述如下：

功能基线与审查的系统要求相对应，包括外部接口描述。
分配的基线对应于经过审查的系统元素需求规范，包括接口需求规范。
开发基线代表生命周期中选定时间点不断发展的系统和系统元素配置。此基线的变更权限通常主要由供应商 ^6^组织拥有。
产品基线与已完成的系统相对应。

配置管理

配置管理流程的目的是建立和维护项目或流程的所有已识别输出的完整性，并使其可供相关方使用。

计划配置管理

此活动包括以下任务：

注：本活动下的任务 1) 未包括在内，因为没有与需求工程相关的具体指导。

识别受配置控制的项目。
注：在适当的情况下，物项通过唯一、持久的标识符或标记进行区分。标识符符合相关标准和产品行业惯例，以便配置控制下的物项可以明确追溯到其规格或等效的书面描述。

系统运行概念和利益相关者、系统和系统元素要求被确定为配置管理规划中配置控制的信息项。

执行配置管理

此活动包括以下任务：

维护具有适当完整性和安全性 ^7^级别的配置信息。

注：这包括考虑配置控制项的性质。配置描述尽可能符合产品或技术标准。确保配置信息允许向前和向后追溯到其他基线配置状态。在指定时间或定义的情况下，整合配置项不断发展的配置状态以形成记录的基线。在配置基线数据中记录基线和相关授权的理由。在系统生命周期内维护配置记录，并根据协议、相关法规或最佳行业实践进行归档。
确保正确识别、记录、评估、批准、合并和验证配置基线的变更。

注：在指定时间或规定的情况下，整合配置项不断变化的配置状态，形成记录的基线。在配置基线数据中记录配置步骤、基线的基本原厲和相关授权。在系统生命周期内维护配置记录，并根据协议、相关法律或最佳行业实践将其归档。管理当前配置状态和所有先前配置状态的记录、检索和整合，以确认信息的正确性、及时性、完整性和安全性。执行审计以验证基线是否符合图纸、接口控制文件和其他协议要求。

随着对运营概念和利益相关者、系统和系统元素要求的更改，需要正式记录这些更改，并将其记录在需求基线中，同时记录配置信息，以识别具体更改和相关理由。应维护需求可追溯性，并可在需求可追溯性矩阵 (RTM) 中记录。应根据项目和组织配置管理流程对需求进行配置管理。

注：ISO/IEC 15288 和 ISO/IEC 12207 的 6.3.5 条款包含有关配置管理的更多信息。

信息管理

信息管理流程的目的是在系统生命周期期间和之后（视情况而定）向指定方提供相关、及时、完整、有效且（如果需要）保密的信息。

计划信息管理

此活动包括以下任务：

注：本活动下的任务 2) 至 5) 未包括在内，因为没有与需求工程相关的具体指导。

定义在系统生命周期内需要管理的信息项，并根据组织政策、协议或法律，在一段规定期限内进行维护。

将系统运行概念文档和利益相关者需求规范、系统需求规范、软件需求规范以及其他系统元素需求规范确定为系统生命周期中需要管理的信息项。

执行信息管理

此活动包括以下任务：

注：本活动下的任务 2) 至 6) 未包括在内，因为没有与需求工程相关的具体指导。

获取已识别的信息项。
注：这可能包括生成信息或从适当的来源收集信息。

随着反映配置基线的操作概念文件和各种需求规范的创建，信息项被提供给指定的权限和职责进行信息管理。随着需求的变化和新基线的创建，修订的信息项被提供给信息管理。需求信息应按照组织的信息管理流程进行管理。

注：ISO/IEC 15288:2008 (IEEE 标准 15288‐2008) 和 ISO/IEC 12207:2008 (IEEE 标准 12207‐2008) 对信息管理有更多详细说明。

要求的测量

测量流程的目的是收集、分析和报告与组织内开发的产品和实施的流程有关的数据，以支持对流程的有效管理，并客观地展示产品的质量。

平面测量

此活动包括以下任务：

注：本活动下的任务 5) 至 7) 未包括在内，因为没有与需求工程相关的具体指导。

描述与测量相关的组织特征。
识别信息需求并确定其优先次序。
选择并记录满足信息需求的措施。
定义数据收集、分析和报告程序。

需求工程作为一门学科，受益于在流程和产品环境中测量需求。可能需要多种测量方法来深入了解需求的信息需求。实践证明，各种测量方法都很有用，包括：

需求波动性在流程环境中，需求波动性可能表明组织的需求工程流程不会将一系列需求汇聚成一个结构良好的集合。在产品环境中，高波动性值可能表明利益相关者未能就系统需求达成共识，从而给生命周期中的后续活动带来重大风险。

其他有用的要求措施包括：
需求趋势
需求变更率和积压
需求验证 ^8^
需求验收
TBD 和 TBR 收尾进度按计划进行。

软件需求用于软件功能规模测量 (FSM) 方法，以协助管理软件项目的诸多方面。FSM 方法分为两部分：用于项目管理以及用于预测和绩效管理。如果 FSM 方法要提供高保真结果，那么从系统需求中准确、完整地分配和推导系统的软件需求非常重要。

注 1: ISO/IEC 14143‐1 提供了 FSM 概念及其用途的详细信息。

注 2: ISO/IEC 15288:2008(IEEE 标准 15288‐2008) 和 ISO/IEC 12207:2008(IEEE 标准 12207‐2008) 的 6.3.7 子条款提供了有关测量流程的附加信息，ISO/IEC 15939 也是如此。

进行测量

此活动包括以下任务：

将数据生成、收集、分析和报告程序整合到相关流程。
收集、存储和验证数据。
分析数据并开发信息产品。
记录并向测量用户传达结果。

最好选择在整个生命周期中数据随时可用的措施。然后可以将数据收集集成到与需求相关的流程中，以便在需求工程进行时定期获取数据和见解。集体审查已分析的需求相关措施，寻找有助于风险管理 ^9^的预测趋势和预测，这也是一种很好的做法。需求测量应按照组织的测量流程进行管理。

本文同步发表在软件需求探索的https://srs.pub/specification/req-flow-management.html

需求工程流程. https://srs.pub/specification/req-flow-guide.html ↩︎
涉众定义与解释. https://srs.pub/theory/stakeholder.html ↩︎
需求分析流程. https://srs.pub/specification/req-flow-analysis.html ↩︎
需求工程活动. https://srs.pub/specification/req-flow-activity.html ↩︎
需求基线：构建项目成功的隐形桥梁. https://srs.pub/theory/baseline.html ↩︎
商业分析中的五十种分析方法和技巧之49-供应商评估. https://srs.pub/babok/gongyingshang-pinggu.html ↩︎
Safety安全性和Security安全性. https://srs.pub/thinking/safety-security.html ↩︎
需求质量验证. https://srs.pub/theory/xu-qiu-zhi-liang-yan-zheng.html ↩︎
软件需求与风险管理. https://srs.pub/theory/ruan-jian-xu-qiu-yu-feng-xian-guan-li.html ↩︎