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

• [需求工程流程 ¹概述](/specification/req-flow-guide.html)
• [利益相关者 ²需求定义流程](/specification/req-flow-strs.html)
• 需求分析流程
• [需求工程活动 ³](/specification/req-flow-activity.html)
• [需求管理 ⁴](/specification/req-flow-management.html)

本文是第三部分:需求分析流程

目的

需求分析流程的目的是将利益相关者对所需服务的需求驱动视图转化为可以提供这些服务的所需产品的技术视图。此流程构建了未来系统的表示，该系统将满足利益相关者的要求，并且在约束允许的范围内，并不意味着任何特定的实现。它会产生可衡量的系统要求，从供应商 ⁵的角度来看，这些要求指定了系统需要具备哪些特性以及在多大程度上才能满足利益相关者的要求。

结果

成功实施需求分析流程的结果是：

• 产品所需的特性、属性以及功能和性能要求解决方案已指定。
• 指定影响系统架构设计的约束及其实现方法。
• 实现系统需求与利益相关者需求的完整性和可追溯性。
• 定义验证系统要求是否得到满足的基础。

活动和任务

项目应根据与需求分析流程相关的适用组织政策和程序实施以下活动和任务。

定义系统要求

此活动包括以下任务：

1. 根据要提供的行为和属性定义系统的功能边界。
   注：这包括系统的刺激及其对用户和环境行为的响应，以及对系统与其操作环境之间所需交互的分析和描述，这些交互包括界面约束，如机械、电气、质量、热、数据和程序流。这确定了在其边界上以定量形式表达的预期系统行为。

   在定义系统需求之前，可以通过与利益相关者建立系统（或服务）的边界条件来最大限度地减少范围问题。影响边界条件的三个因素是：组织、环境和约束。

2. 定义系统需要执行的每个功能。
   注 1:这包括系统（包括其操作员）执行该功能的要求有多高、系统能够执行该功能的条件、系统开始执行该功能的条件以及系统停止执行该功能的条件。

   注 2:功能执行条件可能包括对系统所需状态和操作模式的参考。系统需求在很大程度上取决于拟议系统特性的抽象表示，并可能采用多种建模技术和视角来对所需的系统需求提供足够完整的描述。

随着对系统各个功能和元素之间的相互作用和接口的理解不断加深，需求是通过性能和有效性分析、权衡研究、设计开发、接口定义和成本/收益评估的结合而产生的。同样，对于系统而言，识别和评估重用先前存在的需求的机会非常重要。这包括识别提供类似功能或能力的现有系统、适用于新系统的特定功能或能力以及可重用程度的信息。

注：有关需求重用的更多指导，请参阅 ISO/IEC 26551,软件和系统工程 ‐ 产品线需求工程和管理的工具和方法。

3. 定义由利益相关者的要求引入的或不可避免的解决方案限制的必要实施约束。
   注：这包括从系统结构更高层次的设计中分配的实施决策。

   在制定一套系统要求和架构设计之前，与利益相关者一起验证约束条件并确保这些约束条件得到充分理解且正确无误非常重要。除了运营场景和要求之外，实施约束条件也可能来自外部驱动因素，例如运营环境中的接口系统、支持系统或监管要求。

4. 定义能够评估技术成果的技术和使用质量措施。
   注：这包括定义与利益相关者要求中确定的每项有效性衡量指标相关的关键绩效参数。分析和审查关键绩效指标 ⁶，以确保满足利益相关者的要求，并确保识别与任何不合规相关的项目成本、进度或绩效风险。ISO/IEC 15939 提供了识别、定义和使用适当指标的流程。ISO/IEC 9126 系列标准提供了相关的质量指标。

   技术指标用于洞察系统或系统元素在实现需求中指定的技术参数方面的进展。这些包括性能指标 (MOP) 和技术性能指标 (TPM)。MOP 是一种表征与系统操作有关的物理或功能属性的指标。MOP 是在操作环境条件下测量的。TPM 是一种用于评估设计进度、性能要求合规性以及关键性能参数的技术风险的指标。有关这些方面的更多信息，请参阅 ISO/IEC 26702 和 ISO/IEC TR 24748‐2。使用质量指标用于确定产品是否满足指定用户的需求，以便在现实系统环境中的特定使用情境中以有效性、生产力、安全性 ⁷和满意度实现指定目标。

5. 根据风险识别或系统关键性确定系统要求和功能，这些要求和功能与健康、安全、保障、可靠性、可用性和可支持性等关键质量相关。
   注：这包括安全考虑因素的分析和定义，包括与操作和维护方法、环境影响和人员伤害有关的考虑因素。它还包括指定每个安全相关功能及其相关的安全完整性（以必要的风险降低来表示），并将其分配给指定的安全相关系统。使用有关功能安全的适用标准，例如 IEC 61508 和环境保护标准，例如 ISO 14001。分析安全考虑因素，包括与敏感信息、数据和材料的泄露和保护有关的考虑因素。使用适用的安全标准定义与安全相关的风险，包括但不限于管理、人员、物理、计算机、通信、网络、排放和环境因素。

再次强调，需要记录每项需求的来源和基本原理。应更新和维护可追溯性，以记录正式系统需求（包括派生需求）如何满足利益相关者的需求和目标并达成利益相关者的协议。

规范是需求的集合。它们描述了产品、材料的基本技术要求以及确定这些要求是否得到满足的标准。作为需求分析流程的一部分，重要的需求规范可能包括：

• 系统需求规格
• 软件需求规格说明

记录系统需求和软件需求的好处包括：

• 它为采购方或供应商之间就产品功能达成的协议奠定了基础（在市场驱动的项目中，用户输入可能由营销部门提供）。
• 它强制在设计开始之前对需求进行严格的评估，并减少后期的重新设计。
• 为估算 ⁸产品成本、风险和进度提供了现实的基础。
• 组织可以使用该规范来制定验证和确认计划。
• 它为向新用户或新操作环境部署产品提供了明智的基础。
• 为产品的提升提供了基础。

分析和维护系统需求

此活动包括以下任务：

1. 分析系统需求的完整性，确保每个需求、需求对或需求集具有整体的完整性。
   注：检查每个系统需求陈述，以确保其唯一、完整、明确、与所有其他需求一致、可实施和可验证。在完整的系统需求集中识别并解决缺陷、冲突和弱点。分析得出的系统需求，以确认其完整、一致、可实现（考虑到当前技术或技术进步知识）并以适当的详细程度表达。有关良好需求的属性和质量的更多详细指导，请参阅ISO/IEC 26702:2007《系统工程流程应用和管理的 IEEE 标准》。

再次强调，对于系统需求，验证需求是否表述良好非常重要。审查所有需求，以确定良好需求和良好需求集的特征。
如果已确定现有或遗留系统的系统需求可重复使用，则应根据适用性、可行性、可用性、质量、成本效益、价值和时效性等因素对它们进行分析。在重复使用需求时，应仔细检查重复使用的需求与相关系统的特定需求之间的一致性，以确保一致性。

注：有关需求重用的更多指导，请参阅 ISO/IEC 26551,软件和系统工程 ‐ 产品线需求工程和管理的工具和方法。

ISO/IEC 15288 的“计划验证”流程应用于需求验证 ⁹的定义、规划和执行(ISO/IEC 15288:2008(IEEE Std 15288‐2008),子条款 6.4.6.3 a)。除了验证需求之外，以下活动还涉及对单独和整体需求的验证，以正确表达利益相关者的需求。

2. 将分析后的需求反馈给适用的利益相关者，以确保指定的系统需求充分反映利益相关者的要求，以满足需求和期望。
   注：已确认它们是对利益相关者要求的必要且充分的响应，以及对其他流程（特别是架构设计）的必要且充分的输入。

需求验证可确保利益相关者的需求已正确转换为系统需求。可以使用各种技术，包括利益相关者评审、原型设计 ¹⁰、建模和模拟、概念建模和形式建模。适当的技术可能因利益相关者的特征而异，因此可能需要采用多种技术来确保考虑到所有利益相关者。

利益相关者评审 ¹¹是一种常用技术，用于验证可以轻松实现的需求。利益相关者评审涉及与包括关键利益相关者在内的小组一起对需求进行分析，以确定系统需求是否完整、正确且一致，是否反映了利益相关者需求的意图。通常会制定检查表来协助评审，以确保已考虑并记录所有适用类别的需求。

原型通常用于引出需求、验证系统需求的解释、澄清或检查需求属性以及识别任何遗漏的需求。原型的优点在于，它们为利益相关者的评估和输入提供了更丰富的背景，它们可以更容易地解释假设，并且可以提供有用的反馈，说明它们为什么是错误的。例如，与文本描述或图形模型相比，动画或静态原型可以更好地理解用户界面的动态行为。但是，也有一些缺点。这些包括开发原型的成本、潜在的错误假设和不合理的期望以及低保真度原型的质量问题。当充分理解原型的用途时，可以使用适当的原型保真度级别来实现有效的早期需求审查和验证。保真度和构建质量应基于原型的用途。

建模和模拟可用于协助利益相关者验证需求。建模和模拟的优势在于它们可以展示相互作用，并在结果不符合利益相关者预期时进行敏感性分析。

概念建模 ¹²是另一种可用的技术。其目的是帮助理解问题，而不是启动解决方案的设计。因此，概念模型包括问题域中的实体模型，这些模型配置为反映其现实世界的关系和依赖关系。可以开发几种类型的模型。这些包括数据和控制流、状态模型、事件跟踪、用户交互、对象模型、系统上下文模型等。影响模型选择的因素包括：

• 问题的性质：某些类型的应用要求对某些方面进行特别严格的分析。例如，控制流和状态模型对于实时系统可能比对于信息系统更重要。
• 专业知识：采用供应商有经验的建模符号或方法通常更有成效。但是，采用由工具更好地支持的符号、作为流程要求强加的符号或简单地“更好”的符号可能是适当或必要的。
• 收单机构的流程要求：收单机构可能会采用特定的符号或方法。这可能与前一个因素相冲突。
• 方法和工具的可用性：即使符号或方法更适合特定类型的问题，但如果没有得到培训和工具的充分支持，也可能无法得到广泛接受。
• 形式化建模使用基于离散数学的符号，并且可追溯到逻辑推理，它已在某些专业领域产生了影响。形式化建模可能由收购方或标准强制实施，也可能为某些关键功能或元素的分析提供令人信服的优势。

3. 证明系统需求和利益相关者需求之间的可追溯性。
   注：保持系统需求和利益相关者需求之间的相互可追溯性，即所有可实现的利益相关者需求都由一个或多个系统需求满足，并且所有系统需求都满足或有助于满足至少一个利益相关者需求。系统需求保存在适当的数据存储库中，以便追溯利益相关者的需求和架构设计。

需求跟踪涉及恢复需求来源并预测需求的影响。可追溯性应包括接口需求。跟踪是执行覆盖率分析（以确保设计中满足所有利益相关者的要求，并且每个低级要求都是合理的）、合规性分析（记录利益相关者的要求已得到满足）和需求变更时的影响分析的基础。需求应该是可追溯的：

• 到较低级别的需求（例如，利益相关者到系统到元素，最终到硬件和软件需求）
• 架构设计（例如逻辑或物理）
• 系统元素（例如，实现要求的软件和硬件元素）
• 验证/测试满足该要求的实体，以及任何支持模型和分析。

需求还应可向上追溯到激发它的需求和利益相关者（例如，从软件需求追溯到它有助于满足的系统需求）。对于从贸易或设计研究中得出的需求，这些派生需求应可追溯到它们所来自的研究，而该研究应可追溯到它所依据的高级需求。双向可追溯性是一种可用于以下目的的技术：

• 提高从系统级到最低级别的系统元素；
• 允许跟踪需求开发 ¹³和分配以及相关措施，例如需求覆盖率、合规性和复杂性；
• 提供记录和审查需求层之间关系的方法，捕捉设计的某些方面；
• 支持将来更容易的维护和变更系统实施。

4. 在整个系统生命周期内维护系统需求集以及相关的基本原理、决策和假设。

需求应受配置控制。与需求一起记录的辅助信息可能包括每项需求的概要理由、决策、假设和变更历史，以及需求分类信息。再次强调，使用需求管理工具有助于维护需求可追溯性和配置控制的繁琐而复杂的项目。

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