在这个知识领域，我们介绍了以下关键原则：生命周期、生命周期模型和生命周期过程。描述了一个通用的 SE 范式；这构成了讨论更详细的生命周期知识的起点。。

话题

SEBoK 的每个部分都分为知识领域 (KA)，这些知识领域是具有相关主题的信息分组。 Kas 反过来又分为主题。 本 KA 包含以下主题：

• 通用生命周期模型
• 应用生命周期过程
• 生命周期流程和企业需求

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

生命周期术语

生命周期 一词 是工程学从自然科学中借来的。 它用于描述单个有机体在其生命中所经历的变化，以及多个有机体的生命如何相互作用以维持或进化种群。 我们在工程中以相同的方式使用它来描述感兴趣系统 (SoI) 实例的完整生命周期； 以及多个此类实例的托管组合，以提供使利益相关者满意的功能。

生命周期模型确定了特定 SoI 经历的主要阶段，从开始 到 退役 。生命周期模型通常在开发项目中实施，并与管理规划和决策制定高度一致。

通用系统工程范式

图 1 确定了任何 SE 工作的总体目标，即： 对利益相关者价值的理解； 选择需要解决的具体需求； 将该需求转化为系统（满足需求的产品或服务）； 以及使用该产品或服务为利益相关者提供价值。 该范式是根据第 2 部分中讨论的系统方法的原则开发的，用于为 SEBoK 第 3 部分和第 4 部分中的 KA 奠定基础。

在图 1 的左侧，有识别出的 SoI 形成了一个系统分解结构。 SoI 1 被分解为其基本元素，在这种情况下也是系统（SoI 2 和 SoI 3）。 这两个系统由 未进一步细化 的 系统元素组成。

在图 1 的右侧，每个 SoI 都有一个相应的生命周期模型 ，该模型由填充了流程的阶段组成。 这些过程的功能是定义要执行的工作和要产生的相关工件。 在基于模型的方法中，这些工件被捕获在代表 SoI 的系统模型中。 请注意，为满足需求而定义的一些要求分布在 SoI 1 生命周期的早期阶段，而另一些则指定给 SoI 2 或 SoI 3 的生命周期。系统的分解说明了基本概念 递归 根据 ISO/IEC/IEEE 15288 标准定义； 标准被重新应用于每个 SoI (ISO 2015)。 需要指出的是，需求可能被分配给不同的系统元素，这些元素可能被集成在三个 SoI 中任何一个的不同生命周期阶段； 然而，它们一起形成了一个有凝聚力的系统。 例如，SoI 1 可能是由底盘、电机和控制器组成的简单车辆，SoI 2 可能是嵌入式硬件系统，Sol 3 可能是软件密集型接口和控制系统。 在这里停止 当分阶段执行 SE 过程时，迭代（术语表）通常需要在阶段之间进行（例如，在系统定义的连续细化中或在提供现有系统的更新或升级时）。 在过程和阶段中执行的工作可以在 任何感兴趣的系统的生命周期内以及多个生命周期之间以并发方式执行。

该范例为理解通用 SE（见第 3 部分）以及将 SE 应用于第 4 部分中描述的各种类型的系统提供了一个基本框架。

通用的生命周期模型

正如在生命周期过程简介中的一般生命周期范例中所讨论的，每个利益相关的系统(SoI)都有一个相关联的生命周期模型。下面的通用生命周期模型适用于单个SoI。SE通常必须跨许多此类生命周期模型的定制实例进行同步，以完全满足大众的需求。在生命周期模型中描述了解决这个问题的更复杂的生命周期模型。

通用系统生命周期模型

没有一个单一的“一刀切”的系统生命周期模型可以为所有项目情况提供具体的指导。 图 1 改编自（Lawson 2010、ISO 2015 和 ISO 2010），提供了一个通用生命周期模型，该模型形成了预先指定、进化、顺序、机会主义和并发生命周期过程的最常见版本的起点。 该模型被定义为一组阶段，在这些阶段中执行技术和管理活动。 这些阶段由 决策门 终止，关键利益相关者决定是否进入下一阶段，保持在当前阶段，或者终止或重新确定相关项目的范围。

这些阶段的详细定义在下面的词汇表中提供， 并在后续文章中以各种其他方式提供。

概念定义阶段从主角(个人或组织)决定将资源投资于新的或改进的工程系统。开始时，一组利益相关者同意需要对工程系统环境进行更改，并探索是否可以开发新的或修改的 SoI，其中生命周期收益值得投资生命周期成本。活动包括：制定运营理念和商业案例；确定关键利益相关者及其所需的能力；在关键利益相关者之间协商利益相关者的要求并选择系统的非开发项目（NDI）。

系统定义阶段开始于关键利益相关者确定业务需求和利益相关者要求已充分定义，以证明提交必要的资源以足够详细地定义解决方案选项以回答概念定义中确定的生命周期成本问题并提供基础适当的系统实现。活动包括开发系统架构；定义和商定系统要求的级别；制定系统级生命周期计划并执行系统分析，以说明最终系统定义的兼容性和可行性。过渡到系统实现阶段可以导致单通道或多通道开发。

应该注意的是，上面的概念和系统定义活动描述了系统工程师在执行系统工程时执行的活动。如应用于工程系统的系统方法中所讨论的，在提出问题情况或机会与描述一个或多个可能的系统解决方案之间存在非常强的并发性. 其他相关的定义活动包括：高风险项目的原型设计或实际开发，以展示系统可行性的证据；与业务分析师合作或执行任务有效性分析，以提供可行的业务案例以实现；对已实现的系统进行修改，以改进其生产、支持或利用。这些活动通常会在系统生命周期中发生，以处理系统演化，特别是在多通道开发下。这在生命周期模型知识领域 中有更详细的讨论。

系统实现阶段开始于关键利益相关者认为 SoI 架构和可行性证据的风险足够低，可以证明投入必要的资源来开发和维持初始运营能力 (IOC) 或一次性开发完整运营能力（FOC）。活动包括：建设发展要素；将这些元素相互整合并与非发育项目 (NDI) 元素整合；元素的验证和确认以及它们的集成；并为同时进行的生产、支持和利用活动做准备。

系统生产、支持和利用 (PSU)阶段开始于关键利益相关者决定 SoI 生命周期的可行性和安全性处于足够低的风险水平，从而证明投入生产、部署、支持和利用所需的资源是合理的系统在其预期的生命周期内。生产、支持和利用的生命周期可能不同。在生产完成后，市场支持通常会继续，用户通常会继续使用不受支持的系统。

系统生产涉及制造 SoI 的实例或版本以及相关的售后备件。它还包括生产质量监控和改进；产品或服务接受活动；和持续的生产过程改进。它可能包括低速率初始生产 (LRIP)，以使生产过程成熟或促进继续保持生产能力以应对未来的需求高峰。

系统支持包括各种类型的维护：纠正（针对缺陷）、自适应（针对与独立发展的相互依赖系统的互操作性）和完善（针对增强性能、可用​​性或其他关键性能参数）。它还包括热线和响应者，用于用户或紧急支持以及所需消耗品（燃气、水、电力等）的供应。它的边界包括一些灰色区域，例如小系统增强与更大的互补性新添加的开发之间的边界，以及在增量或进化开发中早期部署的增量的返工/维护之间的边界。系统支持通常在系统生产终止后继续。

系统利用 包括运营商、管理员、公众或利益系统层次结构中高于它的系统在其上下文中使用 SoI。 它通常在系统支持终止后继续。

当系统版本或元素过时或不再经济支持而逐步执行 ， 因此对其内容进行处置或回收。 越来越多的负担得起的考虑使系统重新定位成为一种有吸引力的选择。

应用生命周期模型

图1仅显示了通过SoI生命周期各个阶段的单步方法。在生命周期模型知识领域，我们讨论了现实世界企业及其驱动因素的例子，包括技术和组织方面的。这些已经导致了一些记录在案的方法，用于对生命周期阶段排序，以处理提出的一些问题。生命周期模型KA总结了一些增量的和进化的生命周期模型，包括它们的主要优点和缺点，并讨论了选择最适合的方法的标准。

在图1中，我们列出了对每个阶段的成功完成至关重要的关键技术和管理活动。这是说明每个阶段的目标并指示过程如何与这些阶段相结合的一种有用的方法。在考虑如何规划资源、里程碑等时，这一点非常重要。然而，注意到过程活动的执行并没有划分到特定的生命周期阶段是很重要的(Lawson 2010)。在应用生命周期过程中，我们讨论了关于生命周期模型中过程活动之间相互关系本质的一些观点。一般来说，技术和管理活动是按照通用生命周期范例中描述的并发、迭代和递归的原则应用的。

生命周期过程的应用

通用生命周期模型描述了一组生命周期阶段及其关系。在定义它时，我们描述了对每个阶段的成功至关重要的一些技术和管理活动。虽然这种活动到阶段的联系很重要，但我们也必须认识到这些活动之间的贯穿生命的关系，以确保我们采用系统方法。

系统工程、技术和管理活动定义在一组生命周期过程中。这些活动紧密相关，使我们能够描述它们之间的关系。在本主题中，我们将讨论关于生命周期模型中流程活动之间相互关系性质的许多观点。

一般来说，技术和管理活动是根据通用系统工程范例中描述的并发、迭代和递归的原则来应用的。这些原则在某种程度上重叠，可以被视为对确保我们能够采取整体系统方法的相同基本需要的相关观点，同时允许对我们的活动进行某种结构和顺序。下面展示的视图应该被视为不同SE作者展示这些重叠思想的方法的示例。

生命周期过程术语

过程

过程是为了达到某一特定目的而采取的一系列行动或步骤。流程可以由人或机器执行，将输入转换为输出。

在SEBoK中，过程以多种方式解释，包括:技术、生命周期、业务或制造流程过程。第3部分的很多部分都是按照技术过程(例如设计、验证)来构建的;然而，生命周期模型也描述了许多高级的程序生命周期序列，它们称之为过程(例如，rational统一过程(RUP)等)。

第4部分:系统工程的应用和第5部分:启用系统工程利用了与服务和企业操作相关的过程。

系统工程生命周期过程定义了跨一个或多个阶段执行的技术和管理活动，以提供作出生命周期决策所需的信息;并在必要时支持跨其生命周期模型的利益系统(SoI)的实现、使用和维护。生命周期模型和流程活动之间的关系可以用来描述SE如何应用于不同的系统上下文。

需求

需求是需要或想要的东西，但并非在所有情况下都是强制性的。要求可能指的是产品或过程特征或约束。对需求的不同理解依赖于过程状态、抽象级别和类型(例如功能、性能、约束)。随着时间的推移，单个需求也可能有多种解释。

需求存在于具有多个抽象级别的企业或系统的多个级别。这包括从最高级别的企业能力或客户需求到最低级别的系统设计。因此，需求需要在它们所应用的实体级别的适当细节级别上定义。请参阅生命周期过程和企业需求这篇文章，以获得关于跨概念定义和系统定义从企业到最低系统元素的需求和需求转换的进一步详细信息。

架构

体系结构是指系统的组织结构，系统可以在不同的上下文中定义。建筑设计是设计结构的艺术或实践。查看下面关于使用逻辑和物理体系结构模型级别来定义相关系统和系统元素的进一步讨论;并支持需求活动。

架构可以申请系统产品、企业或服务。例如，第3部分主要考虑系统工程师创建的产品或服务相关的体系结构，但是企业体系结构描述了组织的结构。第5部分:启用系统工程以比跨组织使用的IT系统更广泛的方式解释企业架构，IT系统是架构的一个特定实例。

框架与架构密切相关，因为它们是表示架构的方式。有关定义和示例，请参阅架构框架。

其他流程

以下提到了其他一些生命周期过程，包括系统分析、集成、验证、验证、部署、操作、维护和处置;它们在系统实现和系统部署与使用知识领域中进行了详细讨论。

生命周期过程并发

在通用生命周期模型中，我们列出了对成功完成每个阶段至关重要的关键活动。 这是说明每个阶段目标的有用方式，并指示流程如何与这些阶段保持一致。 这在考虑如何规划资源、里程碑等时可能很重要。但是，重要的是要注意流程活动的执行没有划分到特定的生命周期阶段（Lawson 2010）。

图 1 显示了技术和管理流程贯穿整个生命周期的简单说明。 该图直接建立在应用于工程系统的系统方法中描述的“驼峰图”原则之上。

图 1：生命周期阶段和流程之间的一般关系（根据 Lawson 2010 修改）

此图上的线条表示通用生命周期中每个流程的活动量。 活动的高峰（或驼峰）代表流程活动成为阶段主要焦点的时期。 这些峰值之前和之后的活动可能代表由过程焦点引起的贯穿整个生命周期的问题，例如，维护约束在系统需求中的表现可能性有多大。 这些考虑有助于在每个阶段保持更全面的观点，或者它们可以代表前瞻性规划，以确保完成未来活动所需的资源已包含在估计和计划中，例如验证所需的所有资源都已到位或可用。 确保以可实现的方式实施此驼峰图原则，

生命周期过程迭代

迭代的概念适用于生命周期模型中的生命周期阶段，也适用于流程。 下面的图 2 给出了与概念和系统定义相关的生命周期过程中的迭代示例。

图 2. 与系统定义相关的流程迭代示例（Faisandier 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。

对问题或机会的探索与一个或多个可行解决方案的定义之间通常存在紧密的联系； 请参阅 工程系统的系统方法 。 因此，本例中的相关过程通常会以迭代的方式应用。 这些过程之间的关系在系统定义KA 中进一步讨论。

下面的图 3 给出了其他生命周期过程之间的迭代示例。

图 3. 系统实现。（SEBoK 原创）

此示例中的迭代与图 1 中所示的流程结果的重叠相关。它们允许考虑跨流程问题以影响系统定义（例如，考虑可能的集成或验证方法可能使我们考虑故障模式或添加数据收集或监控元素进入系统）或者它们允许风险管理和通过生命规划活动来识别未来活动的需要。

这些过程之间的关系在系统实现和系统部署使用中进一步讨论。

生命周期过程递归

SoI 的全面定义通常使用分解层和 系统元素来实现。 图 4 展示了系统分解结构的基本模式。

图 4. Sol系统的分层分解（Faisandie 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。

在每个分解层和每个系统中，系统定义过程都是递归应用的，因为“系统”的概念本身就是递归的； SoI、系统和系统元素的概念基于相同的概念（参见第 2 部分）。 图 5 显示了生命周期过程的递归示例。

图 5. 层上流程的递归（Faisandie 2012）。Sinergy'Com 授予的许可。所有其他权利均由版权所有者保留。

解决方案综合的系统方法

上面的部分给出了关于 SE 生命周期过程如何相关以及这如何影响其应用的不同观点。 解决方案综合 在第 2 部分中描述为采用系统方法 来创建解决方案的一种方式。 一般来说，合成是自上而下和自下而上方法的混合，如下所述。

自上而下的方法：从问题到解决方案

在自上而下的方法中，概念定义活动主要集中在理解问题、问题空间内的操作需求/要求，以及限制解决方案和限制解决方案空间的条件。 概念定义活动确定任务上下文、 任务分析以及新的或修改后的系统（即 SoI）在该上下文中实现的需求，并解决利益相关者的需求和要求。

系统定义活动根据 概念定义的结果考虑一个或多个解决方案的功能、行为、时间和物理方面。系统分析考虑了所提出的系统解决方案的优缺点，包括它们如何满足概念定义中建立的需求，以及相对成本、时间尺度和其他开发问题。 这可能需要进一步细化概念定义，以确保所有与特定解决方案架构相关的遗留关系和利益相关者都已在利益相关者要求中得到考虑。

概念定义和系统定义之间的迭代结果定义了所需的系统解决方案及其关联的问题上下文，用于一个或多个解决方案实施的 系统实现、系统部署和使用以及产品和服务生命周期管理 。 在这种方法中，问题理解和解决方案选择活动在系统开发和设计的前端部分完成，然后在任何最终解决方案系统的整个生命周期中根据需要进行维护和改进。 自上而下的活动可以是顺序的、迭代的、递归的或进化的，具体取决于生命周期模型。

自下而上的方法：解决方案的演变

在某些情况下，概念定义活动决定了发展现有能力或向现有系统添加新能力的需要。 在概念定义期间，评估满足需求的替代方案。 然后引导工程师重新考虑系统定义，以便在产品或服务生命周期期间修改或调整某些结构、功能、行为或时间属性，以适应不断变化的使用环境 或改进现有解决方案。

逆向工程通常是必要的，以使系统工程师能够（重新）表征感兴趣系统 (SoI) 或其元素的属性。 这是确保系统工程师在开始修改之前了解 SoI 的重要步骤。 有关系统定义的更多信息，请参阅 系统定义文章。

出于分析目的或（重新）使用设计架构 中的现有元素，自下而上的方法是必要的 。 使用环境的变化或改进的需要会促使这一点。 相反，自上而下的方法通常用于定义与问题或一组需求相对应的初始设计解决方案。

解决方案合成

在大多数实际问题中，自下而上和自上而下的方法的结合提供了由需求驱动的创新解决方案思维和由现有事物驱动的受限和务实思维的正确组合。 这通常被称为“中间”方法。

作为最实用的方法，综合具有使生命周期专注于整个系统问题的潜力，同时允许探索描述可实现解决方案所需的重点细节水平； 有关更多信息， 请参阅 合成系统解决方案。

生命周期过程和企业需求

通用生命周期模型描述了从实现结果的需求到实现新的或修改的工程系统的建议的简单转换。这就形成了在该利益体系（SoI）的生命周期中投入时间、金钱和其他资源的决策基础。这一转变中涉及的SE活动有很大一部分涉及不同级别和类型的需求。

需求和生命周期

在生命周期的概念定义阶段，当企业确定需要的新功能时，业务或任务分析开发反映问题空间观点的高级策略和需求集(可以表示为任务或业务需求)。随着解决方案空间的探索和解决方案类的特征化，开发涉众需求并将其转换为涉众需求(从用户的角度)。在确定了解决方案类并寻求了特定的解决方案之后，在生命周期的系统定义阶段，涉众需求被转换为系统需求(从解决方案的角度)。由于系统定义递归地定义了解决方案的较低级别的细节，需求是用较低的抽象级别定义的。在最高级别上，理想的需求是与实现无关的，因此不是特定于一个解决方案，允许一系列可能的解决方案。在最低的层次上，需求陈述可能变得更加特定于所选的解决方案。

概念定义进一步描述了业务或企业以及涉众的需求和要求。它讨论了如何将业务或企业的新功能定义为理解问题空间的一部分。它还讨论了涉众需求的开发，以及从用户的角度将其转换为需求。

系统定义有对需求及其类型的进一步描述(例如，系统需求、涉众需求、派生需求)。它讨论了不同的过程角色/状态、层次和需求的性质如何应用于对需求的理解。

将企业需求转变为需求

需要和需求可以存在于多个层次上，用于描述这些层次的术语将因应用程序域和服务于它们的企业而不同。这使得将一般的SE生命周期流程与它们关联起来变得困难。Ryan(2013)提出了一个通用模型(见图1)，在该模型中，某种类型的企业形成了将战略意图转化为系统定义的焦点。在企业观中，企业领导制定企业战略、概念和计划;一种业务管理视图，在这种视图中，业务管理派生业务需求和约束，并形式化它们的需求;业务操作视图，涉众在其中定义他们的需求和需求。在系统视图中，定义了一个工程系统，如果需要，扩展到系统元素的较低级别的视图。注意，一个工程系统可能包含许多元素，包括产品、人员和过程。可以创建系统体系结构，以定义这些元素如何一起为组织启用所需功能的逻辑和物理视图。

图 1. 将需求转化为需求 (Ryan, 2013) 由 M. Ryan 授予许可。 所有其他权利均由版权所有者保留。

在下面的讨论中，Ryan 进一步定义了一组通用术语来定义需要和要求的级别，并将它们与通用组织角色相关联。 有关此一般描述如何映射到不同应用程序上下文或组织结构的讨论，请分别参见 第 4 部分和 第 5 部分 。

图 1 中的各种视图称为层。 在最高层，企业有许多指导其未来的战略。 例如，在上面的插图中，系统起源于运营概念(ConOps) 或战略业务计划 (SBP)，它传达了领导层关于现有系统和待定系统的组织运营的意图。发达。 在这一层，ConOps 或 SBP 用“品牌”来定义企业，并建立使命宣言和相应的目标和目标，清楚地说明企业前进的原因和战略。

业务或任务分析流程以组织的任务或愿景声明、由 ConOps 或 SBP 传达的目标和目的开始。 业务管理使用此指南来定义业务需求，主要以生命周期概念的形式，捕获业务管理的采购、开发、营销、运营、部署、支持和退役的概念。 然后使用这些概念来定义该层的特定需求。

生命周期概念中包含的业务需求被详细阐述并形式化为业务需求，这些需求记录在业务需求规范 (BRS) 或业务需求文档 (BRD) 中。 将业务需求转化为业务需求的过程称为任务分析或业务分析。

一旦业务管理层满足了他们的需求和要求，他们就会将它们传递给业务运营层。 在这里，利益相关者需求和要求 (SNR) 定义流程使用 ConOps 或 SBP 以及生命周期概念中包含的概念作为指导。 需求工程师 (RE) 或业务分析师 (BA) 通过结构化流程从业务运营层引导利益相关者，以获取利益相关者的需求——以精炼的 OpsCon 或类似文档和其他生命周期概念的形式（参见图 1）。 RE 或 BA 使用结构化流程来引出特定需求，如用户故事、用例、场景、系统概念或操作概念中记录的那样。 如需进一步讨论作战概念和作战概念文件及其相互作用，

然后将利益相关者的需求转化为一组正式的利益相关者要求，这些要求记录在利益相关者要求规范 (StRS) 或利益相关者要求文档 (StRD) 中。 这种转变是由一个定义明确、可重复、严格且记录在案的需求分析过程指导的。 这种需求分析可能涉及使用功能流程图、时间线分析、N2 图、设计参考任务、建模和模拟、电影、图片、状态和模式分析、故障树分析、故障模式和影响分析以及贸易研究。 在某些情况下，这些需求分析方法可以使用作为高级逻辑架构的一部分创建的视图。

在系统层，在系统需求定义过程中，StRS 中的需求然后由 RE 或 BA 转换为 系统需求，并记录在系统需求规范 (SyRS) 或系统需求文档 (SyRD) 中。 与前面的过程一样，RE 或 BA 使用与上述相同的需求分析方法来定义需求，完成需求到需求的转换。 在每一层，产生的需求都将被记录、同意、基线化，并置于配置管理之下。 如上所述，系统需求分析也可以链接到适当的逻辑和物理架构，非正式地或在共享配置控制下。 请注意，一些组织可能会为为满足业务需求而开发的多个系统中的每一个系统准备单独的生命周期概念。

一旦一组需求在一个层被记录、同意和基线化，它们将向下传递到下一层，如图 1 所示。在下一层，需求是需求转换过程的结果在该层以及从前一层的需求分解或派生的结果。 因此，许多 SyRS 或 SyRD 要求可以从 StRS 或 StRD 分解（即，由其要求明确）或衍生（即，由其要求隐含）。 在子系统或系统元素层也是如此，其中许多子系统或系统元素需求可以分解或从 SyRS 或 SyRD 派生。 在所有情况下，对于图 1 所示的每一层， 这组需求可以追溯到分解或派生它们的前一层的需求。 这个过程继续到下一层系统元素。

需求的表达方式因这些层而异，因此表达它们的规则也不同。 随着需求的开发——以及解决方案的设计——通过抽象层，我们期望需求陈述变得越来越具体。 在最高级别上，理想的要求并不特定于特定的解决方案，而是允许一系列可能的解决方案。 在最低级别，需求陈述将完全针对所选解决方案。 需要注意的是，某一层的需求形式可能不适用于另一层。 例如，在业务管理层，可能要求所有产品都是“安全的”。 虽然这是一个糟糕的系统要求，但它适用于业务管理层。 在下一层，业务运营， 定义“安全”的要求会更少，更详细。 这些要求适用于所有产品线。 在系统层，将为该特定系统制定更具体的安全要求。 然后，这些要求将分配给下一个较低层的系统元素。