利益相关者的需求和要求 代表业务或企业运营级别的那些人的观点，即 用户 、 收购方 、客户 和其他 利益相关者与问题（或机会）相关时的观点，作为解决方案的一组需求，可以在定义的环境中提供利益相关者所需的服务。 使用企业级生命周期概念（请参阅 业务或任务分析 详细信息）作为指导，利益相关者通过结构化的过程来引出利益相关者的需求（以一套完善的系统级生命周期概念的形式）。 利益相关者的需求被转化为一组已定义的利益相关者需求，可以以模型、包含文本需求陈述的文档或两者的形式记录。

利益相关者需求在系统工程中扮演着重要角色，因为它们：

• 形成 系统需求活动的基础。
• 形成系统验证和利益相关者接受的基础。
• 作为 集成和 验证 活动的参考。
• 作为技术人员、管理人员、财务部门和利益相关者社区之间的沟通工具。

本主题描述了利益相关者需求和需求的定义，其中涉及引发利益相关者需求并确定其优先级所需的活动，并将这些需求转化为一组已定义的利益相关者需求。 定义问题或要解决的问题、确定开发新解决方案的机会或改进 利益系统 (SoI)必须在开始定义利益相关者需求和需求所需的活动之前开始。 这意味着使用新的或修改的任务、操作或能力的初始上下文已经被表现（参见 业务或任务分析 ）。在系统定义期间详细考虑系统需求. 在实现两者之间的一致性之前，以上任何一项都不能被认为是完整的，正如可追溯性 所证明的那样，可能需要多次迭代。

目的和定义

利益相关者需求和需求定义活动的目的是引出一组与企业新任务或更改任务相关的清晰简洁的需求 （有关识别和定义任务或运营的信息，请参见任务分析(MA)），并将这些利益相关者的需求转化为可验证的利益相关者需求。

利益相关者可能会从愿望和期望开始，这些愿望和期望可能包含难以用于 SE 活动的模糊、模棱两可的陈述。 必须注意确保将这些愿望和期望合并为一组清晰简洁的需求陈述，这些陈述可用作系统定义的起点。 然后，这些需求陈述将需要进一步澄清，并 在一组利益相关者需求中翻译成更 面向工程的语言，以实现正确的架构定义和需求活动。 例如，一种需要或期望，例如， 为了停车 而轻松 操纵汽车 ，将在一组利益相关者的需求 中转化为一个陈述，例如， 增加汽车的驾驶性能 ， 减少操纵力 ， 辅助驾驶 ， 保护车身免受冲击或刮擦 等。

为了清楚地描述利益相关者需要和需求的活动，下面使用了典型企业中涉及的业务团队和角色的通用视图。t这包括业务管理和业务运营等团队；和包括需求工程师和业务分析师在内的角色。 有关这些角色的概述以及它们如何跨典型企业的各个层实现利益相关者和业务需求，请参阅 生命周期流程和企业需求。

原理和概念

识别利益相关者

SoI 的利益相关者在整个生命周期中可能会有所不同。 因此，为了获得一整套需求和后续需求， 在识别利益相关者或利益相关者类别时 考虑生命周期模型的所有阶段非常重要。

每个系统都有自己的生命周期，通常包括概念、开发、生产、运营、维持和退役等阶段（有关更多信息，请参阅 生命周期模型）。 对于每个阶段，必须确定对未来系统感兴趣的所有利益相关者的列表。 目标是获取每个利益相关者对系统生命周期每个阶段的观点，以便整合一套完整的利益相关者需求，这些需求可以优先排序并尽可能详尽地转化为利益相关者需求集。 表 1 提供了利益相关者的示例。

表 1. 基于生命周期阶段的利益相关者识别。 （SEBoK 原创）

确定利益相关者的需求

一旦业务管理层对他们的需求和需求合理完成感到满意，他们就会将它们传递给业务运营团队。 在这里，利益相关者需求和需求 (SNR) 定义流程使用 ConOps 或战略业务计划 (SBP) 和生命周期概念作为指导。 需求工程师 (RE) 或业务分析师 (BA) 通过结构化流程从业务运营层引导利益相关者，以获取利益相关者的需求——以精炼的 OpsCon（或类似文档）和其他生命周期概念的形式。 RE 或 BA 可以使用完全或部分结构化的过程来引出特定需求，如用户故事、用例、场景、系统概念和操作概念等模型中所述。

确定利益相关者的需求

利益相关者的需求被转化为一组正式的利益相关者需求，这些需求被捕获为模型或作为文本需求记录在和输出中，通常称为利益相关者需求规范 (StRS)、利益相关者需求文档 (StRD) 或类似文件。 这种转变应以定义明确、可重复、严格且记录在案的需求分析过程为指导。 这种需求分析可能涉及使用功能流程图、时间线分析、N2 图、设计参考任务、建模和模拟、电影、图片、状态和模式分析、故障树分析、故障模式和影响分析以及贸易研究。

收集利益相关者的需求和要求

有很多方法可以收集利益相关者的需求和要求。 建议在启发活动中考虑几种技术或方法，以更好地适应各种来源，包括：

• 结构化头脑风暴研讨会
• 访谈和问卷
• 技术、运营和/或战略文件审查
• 模拟和可视化
• 原型制作
• 造型
• 验证和 确认过程的 反馈，
• 审查 系统分析过程的结果 (ISO/IEC 2015)
• 质量功能部署 (QFD) - 可在需求分析期间使用，是一种部署“客户声音”的技术。它提供了一种将客户需求转化为需求的快速方法。（Hauser 和 Clausing 1988）
• 用例图 (OMG 2010)
• 活动图（OMG 2010）
• 功能流程图（Oliver、Kelliher 和 Keegan 1997）

从利益相关者需求的捕获到利益相关者需求的定义

需要几个步骤来了解利益相关者需求的成熟度并了解如何改进该成熟度。 图 1 展示了 需求的循环， 因为它可以从 Shoji Shiba 教授和 Noriaki Kano 教授的作品和课程中推断出来，并在此处适用于系统工程 (SE) 目的。

图 1. 需求周期（Faisandie 2012）。 Sinergy'Com 授予的许可。 所有其他权利均由版权所有者保留。

图 1 显示了工程周期中涉众需求和系统需求的步骤和位置。 以下是每个阶段需求的解释（Faisandie 2012）； 为了说明这一点，请考虑以下与传染病识别相关的系统示例：

• 真正的需求 是任何感知需求背后的需求（见下文）； 它们受人们生活环境的制约。 例如，一般需求可能是 轻松识别传染病的能力。 通常，真正的需求似乎是简单的任务。
• 感知需求 是基于一个人意识到某事是错误的，某事是缺乏的，可以进行改进，或者有没有被利用的商业、投资或市场机会。 感知到的需求通常表示为对所考虑操作的使用条件进行分析而产生的有组织的期望列表（请参阅业务或任务分析 ）。 根据上面的传染病示例，真正的需要可能被认为是 在特定情况下（实验室、护理点、医院和/或人类药房）进行医学测试的需要。 由于很少清楚地表达真正的需求，因此将感知需求的丰富知识用作潜在解决方案的基础。 此步骤必须尽可能完整，以涵盖所有使用上下文。
• 表达的需求 源于以一般行动或约束形式的感知需求，并且通常被优先考虑。 在该示例中，如果安全是首要关注点，则 保护操作员免受污染 的明确需求可能优先于其他明确需求，例如 协助执行测试。 在确定表达的需求时，会根据操作场景对预期的任务或服务进行分析。
• 保留的需求 是从表达的需求中选择的。 选择过程使用表达需求的优先级来获得解决方案或使获得解决方案可行。 保留的需求允许考虑 SoI 的潜在解决方案。 这些保留 的利益相关者意图不能作为利益相关者的需求，因为它们通常缺乏定义、分析以及可能的一致性和可行性。 使用运营概念来帮助理解组织层面的利益相关者意图和从系统角度理解系统运营概念，需求工程将利益相关者从最初的意图引导到结构化和更正式的利益相关者需求声明， ISO/IEC/IEEE 29148 系统和软件工程 - 需求工程 （ISO 2011）。 良好需求的特征可以在 (ISO 2011) 中找到。 探索潜在的解决方案必须从这一步开始。 在此步骤中建议的各种解决方案还不是产品，而是描述了满足利益相关者需求的方法。 每个潜在的解决方案都会对潜在的未来 SoI 施加限制。
• 指定需求 ，是利益相关者需求的翻译，代表供应商的观点，牢记潜在的、首选的和可行的解决方案。 特定需求被转化为系统需求。 一致的实践表明，此过程需要通过系统设计层次结构（ISO 2011）与其他生命周期过程并行的 迭代和 递归 步骤。
• 实现的需求 是产品、服务或企业实现的，考虑到每一个特定的需求（因此，保留的需求）。

上面列出的每一类需求都与 SE 过程的一个领域相一致。 例如， 特定需求 需求的开发在系统需求主题中讨论。 有关如何在系统工程过程中使用需求的更多信息，请参阅系统定义 知识领域 (KA)。

利益相关者需求的分类

利益相关者需求的几种分类是可能的，例如 ISO/IEC 29148，第 9.4.2.3 节（ISO 2011）提供了一组有用的分类元素。 利益相关者需求分类的示例包括：服务或功能、操作、接口、环境、人为因素、后勤、维护、设计、生产、验证需求、验证、部署、培训、认证、退役、监管、环境、可靠性、可用性、可维护性、设计、可用性、质量、安全和安保需求。 利益相关者还将面临许多约束，包括：企业、业务、项目、设计、实现和流程约束。

过程方法

进程的活动

在此过程中执行的主要活动和任务包括：

• 识别整个生命周期的利益相关者或利益相关者类别。
• 引出、捕获或整合利益相关者的需求、期望和目标，以及来自任务和业务分析过程的任何约束。
• 细化 OpsCon 和其他生命周期概念（获取概念、部署概念、支持概念和退役概念）。
• 优先考虑利益相关者的需求。
• 将优先考虑和保留的利益相关者需求转化为利益相关者需求。
• 使用系统需求文章 中确定的良好需求的特征来验证每个涉众需求和涉众需求集的质量。
• 与相应的利益相关者代表一起验证每个利益相关者需求的内容和相关性，并提供需求存在的理由（词汇表） 。
• 识别 利益相关者需求可能产生的潜风险（或威胁和危害）（有关更多信息，请参阅风险管理 ）。
• 综合、记录和管理利益相关者的需求和潜在的相关风险。

工件、方法和建模技术

此过程可能会创建多个工件，例如：

• 改进业务需求规范的建议（如有必要）
• 完善的生命周期概念（OpsCon、采购概念、部署概念、支持概念和退役概念）
• 利益相关者需求（以模型或包含文本需求的文档的形式，例如利益相关者需求规范）
• 利益相关者访谈报告
• 利益相关者需求数据库
• 利益相关者需求证明文件（用于可追溯性目的）
• 验证和确认计划草案的输入

这些工件的内容、格式、布局和所有权将根据创建它们的人以及它们将在哪些域中使用而有所不同。 在这些工件和流程的输出之间，活动应该涵盖本文第一部分中确定的信息。

实际考虑

利益相关者需求遇到的主要缺陷如表 3 所示。

表 3. 利益相关者需求的主要缺陷。 （SEBoK 原创）

表 4 列出了符合利益相关者需求的经过验证的实践。

表 4. 利益相关者需求经过验证的实践。 （SEBoK 原创）