基于功能的系统工程方法 - 系统工程手册-系统生命周期的过程与活动指南-夸领域系统工程方法

1.1 方法概述

FBSE过程是迭代的，即使在系统生命周期的一个阶段内也是如此。功能架构从顶层开始，作为一组在适用的需求文档 ¹或规范中定义的功能，每个功能都分配了功能、性能和限制要求（在极端情况下，顶层功能就是系统本身，所有要求都分配给它）。如图9.3所示，功能架构的下一个较低层次被开发和评估，以确定是否需要进一步分解。如果需要，那么这个过程将通过一系列层次进行迭代，直到功能架构完成。

FBSE应该迭代进行：

• 依次定义满足更高级功能需求所需的更低级功能，并定义替代的功能需求集。
• 通过需求定义，确定任务和环境驱动的性能，并确保满足更高层次的需求。
• 传递性能要求和设计约束
• 通过建筑和设计，完善产品和流程解决方案的定义

在过程的每个级别，可以考虑和评估每个功能的替代分解和分配，并选择一个版本。在所有功能都被识别后，建立分解子功能的所有内部和外部接口。这些步骤如图9.4所示。

FBSE检查一个定义的功能，以识别完成该功能所需的所有子功能；所有使用模式都必须包含在分析中。这项活动进行到支持所需架构和设计工作的深度。已识别的功能需求被分析以确定实现父级需求所需的低级功能。系统必须执行的每个功能都被识别并根据分配的功能、性能和其他限制要求进行定义。然后，每个功能被分解为子功能，分配给该功能的要求也分别被分解。这个过程不断迭代，直到系统完全分解为基本子函数，每个最低级别的子函数是完全、简单且独特地由其需求定义。在此过程中，每个功能和子功能之间的接口以及与外部世界的接口都被充分定义。

已识别的子功能被安排在功能架构中，以展示它们之间的关系和接口（内部和外部）。功能需求应按其逻辑顺序排列，以便低级功能需求被视为高级需求的一部分。功能应定义其输入、输出和功能接口需求（内部和外部），并从开始到结束条件可追溯。还必须分析时间关键需求。

应依次为每个功能要求和接口建立性能要求，从最高到最低级别。然后将上层性能要求向下流动并分配给下层子功能。必须确定并分配作为某个功能或一组功能前提的定时要求。结果要求集应在可测量的术语中定义，并具有足够的细节以用作设计标准。性能要求应从当前功能架构的最低级别开始，通过分析它们被分配的方式，追溯到它们旨在支持的更高层次的要求。所有这些类型的产品要求也必须得到验证。

请注意，虽然性能要求可以在功能分解 ²的每个级别进行分解和分配，但有时需要经过多个级别才能分配性能要求。此外，有时需要开发替代的功能架构并进行权衡研究以确定首选方案。在每次迭代中FBSE，评估替代分解，并定义所有接口。

FBSE的产品可以采取各种形式，具体取决于项目的特定阶段和用于开发功能架构的特定技术。以下是FBSE生成的一些关键输出：

1. 输入-处理-输出（IPO）图——与特定系统分解级别相关的数据流 ³的顶层图。此图描绘了系统的所有输入和输出，但不显示任何分解。
2. 行为图——描述使用指定时间序列、并发性、条件、同步点、状态信息和性能的构造来指定系统级刺激响应的行为。
3. 控制流图——描绘系统或软件程序可能执行的所有操作序列的集合。控制流图有几种类型，包括方框图、流程图和状态转换图。
4. 数据流图（DFDs）——提供系统必须执行的每个行为之间的相互连接。所有输入到行为标识符和所有必须生成的输出都被识别，以及每个必须访问的数据存储。每个DFD都必须进行检查，以验证其与IPO图或更高级别的DFD的一致性。
5. 实体关系（ER）图——描绘一组实体（例如，功能或架构元素）及其之间的逻辑关系。
6. 功能流程块图（FFBDs）——关联输入和输出，并提供一些关于系统功能之间流程的见解。
7. 功能建模的集成定义（IDEF）图——通过顺序输入和输出流显示功能之间的关系。过程控制进入每个表示的功能的顶部，而进入底部的线则显示功能所需的支持机制。
8. 数据字典 ⁴——提供数据流和数据的标准定义的文档。元素、文件等作为跨开发组织通信的辅助工具。
9. 模型——系统相关特征的抽象，用作理解、沟通、设计和评估系统的手段。它们在系统构建之前以及在验证或使用过程中被使用。
10. 模拟结果——当提供一组受控输入时，系统模拟输出的行为或操作类似于SOI。

功能分解活动的目标是开发一个满足系统所有功能需求的FFBD层次结构。然而，请注意，这个层次结构只是功能架构的一部分。直到所有的性能和限制要求被适当地分解并分配到层次结构的元素中，如前所述，架构才算完整。

应制定层次结构中每个功能的描述，包括以下内容：

1. 它在网络中的位置（例如，FFBD或IDEF0/1图），描述了它与同一级别其他功能的相互关系。
2. 分配给它的功能需求集，定义了它的作用
3. 其内部和外部的输入和输出

这些不同的输出描述了功能架构。没有一个首选的输出可以支持这个分析。在许多情况下，需要其中的几个来理解功能架构和系统架构中可能存在的风险。使用多个格式可以对分析过程进行”检查和平衡”，并有助于在整个系统设计团队中进行沟通。