概念定义是一组系统工程 (SE) 活动，其中 仔细检查了问题空间以及业务或企业和利益相关者的需求和要求。 这些活动被分组并描述为通用过程，其中包括任务分析和利益相关者的需求和要求。 概念定义在 利益系统(SoI) 的任何正式定义被开发之前就开始了。

任务分析 侧重于业务或企业的需求和要求——即定义存在的问题或机会（在通常称为问题空间或问题情境中），以及了解所选对象的约束和边界系统部署时（通常称为解决方案空间）。利益相关者需求和要求 过程从 利益相关者的角度探索和定义潜在解决方案的操作方面，独立于任何特定解决方案。 在这两个概念定义活动中，业务或企业决策者和其他利益相关者描述 解决方案应该完成什么为什么 需要它。 两者为什么 以及在考虑如何 解决问题之前需要回答什么 （即，将实施哪种类型的解决方案）以及如何 定义和开发解决方案。

如果需要新的或修改过的系统，则执行系统定义活动来评估系统。 请参阅生命周期流程和企业需求 ，以获取有关从概念定义中解决的业务或企业和利益相关者抽象级别到系统定义中解决的系统和系统元素抽象级别的需求和需求转换的更多详细信息。

概念定义活动的具体活动和顺序以及它们与任何系统的生命周期活动的参与，特别是与系统定义活动的紧密集成，将取决于所使用的生命周期模型的类型。 有关这些关系的并发、迭代和递归性质的进一步讨论，请参阅生命周期过程的应用。

主题

SEBoK 的每个部分都分为知识领域 (KA)，这些知识领域是具有相关主题的信息分组。 KA 依次被划分为主题。 本 KA 包含以下主题：

• 业务或任务分析
• 任务工程
• 利益相关者的需求和要求

有关第 7 部分中包含的案例研究和小插曲以及第 3 部分中涵盖的主题的映射， 请参阅文章实施示例矩阵。

概念定义活动

在概念定义下讨论了两项主要活动：任务分析和利益相关者需求和要求的定义：

1. 任务分析开始了潜在 SoI 生命周期的迭代，它可以解决问题或实现开发新产品、服务或企业的机会。 这些活动帮助业务或企业决策者定义问题空间，识别利益相关者，开发初步的操作概念，并区分限制解决方案空间的环境条件和约束。 换句话说，任务分析采用企业能力差距或机会，并以提供概括在所谓的“业务或任务需求”中的共同理解的方式定义问题/机会。 然后使用业务或任务需求来产生一组清晰、简洁和可验证的业务需求。
2. 利益相关者需求和要求活动在 整个生命周期中与利益相关者一起工作，以引发和捕获一组需求、期望、目标或目标，以获得对问题或机会的期望解决方案，称为“利益相关者需求”。 利益相关者需求用于产生一组清晰、简洁和可验证的利益相关者需求。 利益相关者的需求和要求以能够表征解决方案备选方案的方式识别和定义利益相关者的需求和要求。

任务分析获取业务和利益相关者的需求和要求，并将分析从问题空间向下传递到解决方案空间，包括概念、任务、边界或上下文，以便可以从备择方案。 任务分析 主题中的图 1 描述了这种交互。 在概念定义过程中产生的产品和工件然后在系统定义中使用。

SEBoK 第 2 部分讨论了系统思维 如何适用于概念定义的不同方面。 特别是， 根据问题类型或解决方案类别使用硬系统 和软系统方法的组合在识别和理解中讨论 综合可能的解决方案中的问题和机遇 以及自上而下和自下而上方法之间的对比 。

问题定义解决方案的驱动因素：推与拉

问题定义和解决方案设计相互依赖。 应开发解决方案以适当地应对明确定义的问题。 问题定义应限制在解决方案空间中可行的范围内。系统分析动用于提供问题和解决方案之间的联系。

有两种范式驱动完成概念定义的方式： 推 和 拉 。 拉动 范式基于为已识别的 问题或差距提供解决方案，例如防御或基础设施缺失的任务能力。 推动 范式基于 创建解决方案以解决感知到的机会，例如对部分人口有吸引力的预期产品或服务的出现（即当前市场是否存在）。 这可能会影响其他生命周期过程，例如验证和确认，或在某些商业领域中进行的 alpha/beta 测试。

由于系统通常以推和拉的混合方式集成现有系统元素和新系统元素 ，因此通常最好将自下而上的方法与自上而下的方法结合起来，以考虑到遗留元素，以及识别服务和功能必须提供这些信息以定义适用的接口要求和约束。 这在 生命周期过程中的应用进行了讨论。

业务或任务分析

设计任何相关利益系统(SoI)的出发点是了解潜在问题或机会所在的社会经济和技术背景。然后，企业战略目标和利益相关者需求、期望和需求代表了从业务或企业决策者的角度来看的问题或机会，同时也考虑了用户、收购方和客户的观点。

任务分析(MA)是更大的一组概念定义活动的一部分—— 一组系统工程活动，在这些活动中，业务或企业和利益相关者的问题空间和需求被仔细检查。这发生在开发任何正式的(SoI)定义之前，但可能需要在整个生命周期中重新审视。事实上，Concept Definition的活动决定了企业战略目标和业务需求是否将由新系统、对现有系统的更改、服务、操作更改或其他一些解决方案来处理。MA活动集中于确定解决方案的主要目的(它的“任务”)，而利益相关者需求和需求活动则探索利益相关者在完成任务时希望拥有什么能力，并可能包括解决方案某些方面性能的一些细节。MA经常与利益相关者需求和需求活动一起迭代执行，以更好地理解问题(或机会)空间，以及解决方案空间。

目的和定义

MA 的目的是了解任务/市场问题或机会，分析解决方案空间，并启动可以解决问题或利用机会的潜在解决方案的生命周期。 MA 是一种与需求、能力差距或机会和解决方案相关的战略或运营分析，可应用于任何为其业务目标发展战略的组织。

MA，在某些称为 市场分析或业务分析的领域中，是对企业内运营问题或机会的识别、表示和评估。 问题空间中任务或业务功能的定义框架解决方案，无论是从直接应用到任务或业务功能方面，还是从结果解决方案的上下文方面来看。

MA 用于定义需要（或期望）的操作动作，而不是硬件/软件功能； 也就是说，它专注于定义问题空间，而不是解决方案空间。 MA 从业务愿景和运营概念 (ConOps) (IEEE. 1998) 以及包括使命（或业务职能）在内的其他组织战略目标和目标开始。 MA的主要产品是业务或任务需求，由初步生命周期概念支持——包括初步采购概念、初步运营概念（OpsCon）、初步部署概念、初步支持概念和初步退役概念. 然后将业务或任务需求详细说明并正式化为业务或任务需求。

MA 可能包括数学分析、建模、仿真、可视化和其他分析工具，以表示预期任务并确定如何最好地实现需求/目标。 MA 评估替代方法，以确定哪种方法最能支持利益相关者的需求（在物资和非物资解决方案备选方案中，也称为产品解决方案和服务/运营解决方案）。 因此，MA 定义问题空间并使用由企业目标驱动的质量属性约束来分析解决方案空间备选方案。

原理和概念

任务分析和作战概念

MA 以及术语 ConOps 和 OpsCon 在美国和英国的国防和航空航天组织中广泛用于分析和定义系统的预期运行方式，以及主要运行或运行场景的预期执行方式。 它们考虑了已识别场景的战略、运营和战术方面。 ANSI/AIAA G-043A-2012 (ANSI 2012) 确定术语“操作概念”和“操作概念”通常可以互换使用，但指出存在重要区别，因为它们都有不同的目的并用于满足不同的目的. ConOps 处于组织层面，由企业管理层准备并由业务管理层细化：

在组织层面，ConOps 解决了领导层运营组织的预期方式。 它可能指使用一个或多个系统（如黑匣子）来转发组织的目标和目的。 ConOps 文档描述了组织对业务内的整体运营或一系列运营的假设或意图，涉及要开发的系统、现有系统和可能的未来系统。 该文件经常体现在长期战略计划和年度运营计划中。 ConOps 文档作为组织指导未来业务和系统的整体特征的基础。 (ISO/IEC 2011)

ConOps 通知 OpsCon，OpsCon 由业务管理在任务分析活动中起草，并由利益相关者在 利益相关者需求和要求 活动中细化：

系统 OpsCon 文档描述了系统将做什么（而不是如何做）以及为什么（基本原理）。 OpsCon 是面向用户的文档，从用户的角度描述了待交付系统的系统特性。 OpsCon 文档用于向收购方、用户、供应商和其他组织要素传达整体的定量和定性系统特征。 (ISO/IEC 2011)

需要注意的是，OpsCon 有一个运营重点，应该得到其他概念的开发支持，包括部署概念、支持概念和退役概念。

为了确定适合不断发展的企业能力的技术解决方案，系统工程 (SE) 领导者与企业领导者和运营分析师互动以了解：

• 企业 ConOps 和未来的使命、业务和运营 (MBO) 目标；
• 作战概念和目标的特征（即约束、任务或作战场景、任务、资源、风险、假设和相关任务或作战）；
• 当前如何执行具体任务或行动以及在这些领域存在哪些差距。

然后，他们在概念上探索并从备选的候选解决方案中进行选择。 这种交互确保了对问题空间和解决方案空间的全面理解。 备选的候选解决方案可以包括满足需求的各种方法，以及优化特定特性的方法的变体（例如，使用不同的卫星轨道参数分布来最大化覆盖或事件，同时最小化卫星数量） . 分析、建模和仿真以及贸易研究被用来选择替代方法（NDIA 2010）。

任务分析、ConOps 和 OpsCon 的概念也用于工业部门，例如航空管理和航空运输、医疗保健系统以及具有调整定义和/或术语的空间，例如操作概念、使用概念和/或技术概念. 例如，“任务分析”是用来描述卫星轨道的数学分析，以确定如何最好地实现太空任务的目标（ESA 2008）。

在业务领域，MA 通常主要作为市场分析进行。 维基百科将市场分析定义为一个过程：

. . . 研究特殊行业内特殊市场的吸引力和动态。 它是行业分析的一部分，而这又是全球环境分析的一部分。 通过所有这些分析，可以确定公司的机会、优势、劣势和风险。 最后，在优势、劣势、机会和威胁 (SWOT) 分析的帮助下，将定义公司的适当业务战略。 市场分析也称为市场记录调查，用于为公司的计划活动提供信息，特别是围绕库存、采购、劳动力扩张/收缩、设施扩张、资本设备购买、促销活动等决策公司的其他方面。 （维基百科贡献者，2012）

在任何使用这些概念的地方，很明显它们基于基本概念，例如操作模式（或系统状态）、 场景 （操作）、企业级 ConOps 和系统级操作概念、功能等. 关于ConOps和操作概念的更多解释，请参考 系统和软件工程-需求工程 （ISO/IEC 2011）； 有用的信息可以在附件 A，“系统操作概念”和附件 B，“操作概念”（ISO/IEC 2011）中找到。

作为企业战略发展一部分的使命分析

大多数企业会定期根据其使命、愿景和定位重新评估其战略以实现其目标。 图 1 显示了企业战略开发和概念定义的交互，包括 MA 和利益相关者的需求和要求 活动，这些活动以迭代的方式参与，以充分开发战略并定义未来的能力和解决方案。

图 1. 企业战略和概念开发（Roedler 2012）。经 Garry Roedler 许可使用。 所有其他权利均由版权所有者保留。

随着企业发展战略，有必要对企业的每个要素进行支持性 MA 或战略分析，以确定实现未来目标的准备情况。 该分析检查当前状态以识别与目标实现相关的任何问题或机会，并帮助企业充分理解和定义问题空间。 该分析检查外部环境和接口以寻找影响和趋势，以及内部企业以衡量其能力和价值流差距。 此外，可以执行优势、劣势、机会和威胁 (SWOT) 分析。 随着问题空间的定义，利益相关者的需求也被定义并转化为利益相关者的需求，从而定义了所需的解决方案。 这些需求包括满足客户和任务需求的需求、企业核心流程和能力的未来状态，以及支持这些流程和能力绩效的推动因素。 最后，MA 再次参与检查解决方案空间。 确定跨越潜在解决方案空间的候选解决方案，从简单的操作更改到各种系统开发或修改。 应用各种技术来分析候选者，了解它们的可行性和价值，并选择最佳替代品。 确定跨越潜在解决方案空间的候选解决方案，从简单的操作更改到各种系统开发或修改。 应用各种技术来分析候选者，了解它们的可行性和价值，并选择最佳替代品。 确定跨越潜在解决方案空间的候选解决方案，从简单的操作更改到各种系统开发或修改。 应用各种技术来分析候选者，了解它们的可行性和价值，并选择最佳替代品。

过程方法

进程的活动

在 MA 过程中需要执行以下主要活动和任务：

1. 查看并了解企业使命、愿景和 ConOps。
2. 识别并定义与战略未来发展相关的任何差距和机会：
   1. 检查当前状态以识别与目标实现相关的任何问题或机会，包括现有系统的任何缺陷。
   2. 分析实际政治、经济、社会、技术、环境和法律 (PESTAL) 因素的背景，同时研究成本和有效性、安全和安全改进、性能改进或现有系统缺乏、市场机会、监管等敏感因素变化、用户的不满等。外部、内部和 SWOT 分析也应包括在内。 出于技术考虑，适当的 架构框架 表示，例如美国国防部架构框架 (DoDAF) 操作视图 (DoD 2010)、Zachman 框架（第 1 和 2 行） (Zachman 2008) 和开放组架构框架 (TOGAF) 架构开发方法 (ADM) （The Open Group 2010）在执行任务分析和利益相关者需求和要求时，阶段 A 和 B 应包含在概念定义中。
   3. 定义使命、业务和/或运营问题或机会，及其背景和任何关键参数，而不关注解决方案。
3. 检查和评估解空间：
   1. 确定主要利益相关者（客户、用户、管理部门、法规等）。
   2. 识别高级操作模式或状态，或潜在用例。
   3. 确定跨越潜在解决方案空间的候选解决方案，从简单的操作更改到各种系统开发或修改。
   4. 识别可能满足操作或功能修改需求的现有系统、产品和服务。
   5. 推断可能需要哪些潜在的预期服务。 SoI 是一种潜在的但尚不存在的产品、服务或企业。 此外，解决方案可以是运营变更或现有产品或服务的变更。
4. 执行适当的建模、仿真和分析技术，以了解备选候选解决方案的可行性和价值。 从这些服务和用例中建模或仿真操作场景，并通过与利益相关者和主题专家的审查来丰富它们。
5. 定义基本的运营概念或市场战略，和/或业务模式。
   1. 从之前建模的操作场景和操作模式中，推断和表达操作概念或技术概念的用法。
   2. 收集和丰富需求、期望、场景和约束。
   3. 在任何提议的市场战略或业务模式的背景下验证任何潜在 SoI 的使命。
6. 评估备选方案集并选择最佳备选方案。
   1. 对替代品进行贸易研究以区分替代品。
7. 提供有关可行性、市场因素和替代方案的反馈，以用于完成企业战略和进一步行动。
8. 定义初步部署概念、初步支持概念和初步退役概念。

任务分析工件

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

• 对企业 ConOps 的修订建议；
• 初步操作概念文件或输入；
• 任务分析和定义报告（可能包含修改任务的建议）；
• 一组业务需求；
• 初步生命周期概念（初步运行概念、初步部署概念、初步支持概念和初步退役概念；
• 系统分析 工件（例如，用例图、上下文图、序列/活动图、功能流程图）；
• 贸易研究结果（替代品分析）；
• 市场研究/分析报告；
• 一组业务（或任务）需求（通常包含在业务需求规范中）。

方法和建模技术

MA 使用多种技术，例如：

• 用例分析；
• 运营分析；
• 功能分析；
• 技术文件审查；
• 贸易研究；
• 造型;
• 仿真;
• 原型设计；
• 研讨会、访谈和问卷调查；
• 市场竞争评估；
• 基准测试； 和
• 组织分析技术（例如，优势、劣势、机会、威胁（SWOT 分析）和产品组合）。

实际考虑

任务分析和营销分析遇到的主要缺陷如表 1 所示。

表 1. 任务分析的主要缺陷。 （SEBoK 原创）

表 2 展示了经过验证的任务分析和营销分析实践。

表 2. 任务分析经过验证的实践。 （SEBoK 原创）

任务工程

本文描述了任务工程的新兴概念，特别是美国国防部正在实践的任务工程。任务工程与系统的系统(SoS)密切相关，因为大多数任务是通过多个系统的协调和互操作性来完成的。本文定义了任务工程，描述了任务工程中涉及的系统工程活动。

任务工程的定义

任务工程描述了系统工程在任务规划、分析和设计中的应用，其中任务是利益的系统。任务工程分析任务目标和线程，分析可用的和新兴的操作和系统能力，并设计一个任务架构来实现任务目标(Gold, 2016)。因此，任务工程必须同时考虑操作、技术和采运问题及其集成，以便设计出实现任务目标的解决方案(Van Bossuyt等，2019年)。最后，“任务”一词通常用于军事环境，而大多数任务工程是用于军事系统的。但是，这个术语及其所描述的过程和知识可以应用于空间任务或其他任务领域。

任务几乎总是由多个系统执行，协调它们的行动并共享数据。我们称之为任务导向系统(SoS)。理想情况下，以任务为导向的SoS可以由作战指挥官迅速构思、组装和部署，以对直接威胁做出反应。

定义和原则

任务描述了系统将做什么以及这样做的目的。 使命宣言描述了吉卜林的“六个诚实的仆人”——谁、什么、何时、何地、为什么，有时如何（Kipling 1902）。 该任务为定义有效性措施和制定作战概念（CONOPS）提供了背景。

任务由完成一项或多项操作活动的操作节点完成。 操作节点可以是组织、个人或系统。 操作活动是将一个或多个输入转换为输出或改变系统状态的操作。 系统通过执行操作活动来提供能力。

任务工程活动

以下是任务工程的主要活动：

任务能力分析和定义 ——工程师分析问题场景以确定需要哪些能力并为任务制定 CONOPS。

任务线程定义 ——工程师分析端到端的操作活动集。 起点是对运营活动、它们的排序以及它们之间的信息流进行建模。 对于军事系统，任务线程通常是一个杀伤链，描述了从搜索威胁到参与威胁的活动顺序。

权衡分析 ——工程师开发完成任务的替代方案，并进行贸易研究以确定给定资源和可用时间的最佳替代方案。

任务架构 ——工程师开发一个操作架构，描述能力、操作活动、操作节点和其他相关元素来模拟任务。

需求工程 ——工程师从能力分析、CONOPS 和任务线程中确定功能和非功能需求。 工程师将需求分配给操作节点。 在许多情况下，操作节点中的系统可能需要工程来满足要求。

互操作性分析 ——完成任务的系统之间的互操作性必须发生在操作和技术层面（Giachetti et al. 2019）。 操作互操作性描述了系统协调其活动以支持任务线程完成的能力。 技术互操作性描述了系统交换数据的能力，同时考虑到数据的及时性和质量。 互操作性分析对系统产生额外的要求。

面向任务的 SoS 实施 ——面向任务的 SoS 必须通过设计和开发新系统、修改现有系统和/或修改条令、政策、程序和其他非物质手段来实施，以帮助完成任务。

任务验证和确认 ——工程师验证交付的系统是否满足要求，并验证系统是否满足任务目的和利益相关者的需求。

利益相关者的需求和要求

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

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

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

本主题描述了利益相关者需求和需求的定义，其中涉及引发利益相关者需求并确定其优先级所需的活动，并将这些需求转化为一组已定义的利益相关者需求。 定义问题或要解决的问题、确定开发新解决方案的机会或改进 利益系统 (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 原创）