MagicGrid方法学习体会（六）：功能、功能分析与W2.功能分析：初始步骤详解

更新日期:2024-05-17 03:48

欢迎关注，共同精进

这一周，花了很多时间搜索整理功能、功能分析的基本概念等;然后才学习了MagicGrid方法问题域白盒视角的W2.功能分析：初始的详细步骤。下面就跟大家分享一下学习成果。

全文近4200字，有点长，但干货满满；关注系统工程、基于模型系统工程的朋友请耐心读完，你一定会有收获。

01

—

功能的概念

1. 功能

功能一词我们经常用，但具体的概念可能都没有认真思考过。

我搜到了几种概念：

事物或方法所发挥的有利作用，效能

物品的使用价值

功能是对象能够满足某种需求的一种属性

功能是一种行为模式，通过此行为，某物实现了它的目的。（牛津英语词典）

前两种概念比较好理解，是我们日常使用的概念。后两种就比较难理解了。

第三个概念如果和前两个概念结合起来会好理解一些，无论是事物、方法还是物品，它既然有作用或价值，那么它本身一定是能满足某种需要的。

举个例子，灯可以发光，这是它发挥的有利作用和被使用的价值；人们可以用灯来照明，灯可以发光的属性/特性满足了人们照明的需求，所以发光就是灯的功能。

这样来看，其实前三个概念本质上是一样的，只是说法不同。第三个概念提到了需求，这与系统工程、MBSE都有关系。

第四个概念，很难简单解释清楚，但可以发现，它和系统设计的四个重要方面之一的“行为”有关，也正好与W.2功能分析所属的系统“行为”有关。我们后面来逐步理解。

2.功能及其载体的关系

按照上面的说法，功能是属于某种事物、方法、物品的；也就是说功能存在载体。

从概念上来说，功能与功能的载体是有区别的。

创立价值工程的美国通用电气公司的拉里·麦尔斯提出：

顾客购买物品时需要的是它的功能，而不是物品本身，物品只是功能的载体。

也就是说，顾客购买商品是在为商品的功能买单。

比如买灯是为了照明，那就是为了发光花钱，而不是为了灯本身花钱；之所以买灯而不是其它商品，是因为灯能发光，可以用来照明。

真是够绕的，但仔细想想还真是这么回事。

根据上面的逻辑来分析，只要功能相同，其实功能载体可以不同，也就是说载体可以更换。

一种功能的实现不可能没有载体，所以功能必须与其载体结合；但是如果某种功能与原来的载体分离了，就可以经过创新将功能与另一种载体结合起来，这样的做法专业上称为功能的载体替代。

还用灯来举例子，一开始人们用油灯，但是有了电之后发明了电灯。油灯、电灯它们的功能都是发光，都可以用来照明，但是功能载体却发生了变化：油灯被电灯替代了。

我想，正是因为功能载体的可替代性，才有了发明创造的可能，才使我们的生活越来越美好。

02

—

价值工程中的功能分析

搜索的资料中，从价值工程的角度对功能分析介绍的比较全面，有助于理解基本概念和厘清思路，所以再做个介绍。

1. 概念

价值工程中的功能分析，是对产品、产品的部件、组件、零件或对一项工程以及工程的细目，有系统的进行功能分析，找出提高其价值途径的一系列活动。

2. 作用

通过对产品的功能、成本的定性和定量分析，确定它们的相互关系，科学地确定产品的必要功能，合理地分配成本，使产品的功能结构更趋合理，为创造和改善方案提供依据。

3. 分析步骤

功能分析的一般步骤：

功能定义

就是用简明、贴切的语言来表达某产品的作用或效用，加深对产品功能的理解，为此后提出功能替代方案提供依据。

通过功能定义，可以准确地掌握用户的功能要求，抓住问题的本质，扩大思考范围，开拓设计思路，深化对功能的理解，为功能评价和创造改进方案奠定基础。

功能定义的语言应简明准确，通常用一个动词加一个名词表述。如梁的功能是传递荷载；隔墙的功能是分隔空间；灯的功能是发光等。

功能整理

就是明确功能范围，搞清楚有哪几个基本功能，这些基本功能要通过什么手段来实现，功能之间的目的和手段的关系是什么。

功能评价

就是找出某一特定功能的最低费用或必需费用，并以这个费用与现实费用的比值作为评价功能的一个指标。功能评价的目的是保证价值工程能有更好的经济效果。

03

—

NASA系统工程中的功能分析

我们学习MagicGrid方法，是学习MBSE，也是在学系统工程，所以还是要详细了解一下系统工程中的功能分析。

但我仅在《NASA系统工程手册》找到了以下内容：

功能分析是用于系统架构开发和功能需求分解的主要方法。

它是确定、描述和关联系统必须执行的功能，以满足系统目标的系统化过程。

功能分析定义和连接系统功能、权衡研究、接口特征和需求原理。

执行功能分析的三个关键步骤如下：

把顶层需求转化为必须完成以实现需求的功能

分解和分派功能到产品分解结构的更低层

确定和描述功能接口和子系统接口

功能分析流程包括分析每个系统需求，以确定为满足需求必须实现的所有功能。

每个确定的功能用输入、输出和接口需求描述。

功能按逻辑顺序安排。

功能分析用于获取功能和性能的需求。

这么来看，在系统工程中的功能分析，是将产品需求转换为功能，与产品分解结构相结合，由产品整体向局部的层层分解和落实的过程、活动。

功能分析的目的，是先实现良好的系统架构，最终是实现设计良好的产品/系统。

应该是功能分析太基础了，所以《INCOSE系统工程手册》中都没有专门提及。在《NASA系统工程手册（第2版）》中已经找不到对功能分析的单独介绍内容了。

04

—

MagicGrid之W2.功能分析

MagicGrid方法书中，对W2.功能分析的说明是：

在这个单元格中，您应该通过分解B2中SoI执行的每个功能来深入分析系统行为。

该单元中的建模包括两个阶段：初始阶段和最终阶段。在W2的初始阶段，由待开发系统执行的顶级功能被分解以表述更详细的系统行为。这有助于识别执行这些功能的功能块，也称为逻辑子系统。要捕获这些子系统，您应该切换到W3。之后，您应该返回到W2并指定哪些子系统负责执行哪些功能。

需要注意的是，深入分析时，功能分解后得到的子功能同样可以分解。分解执行的次数取决于你分析需要解决的问题想要达到的相关粒度级别。从子功能的角度来看，每个分解的子功能都被视为一个功能。

W2单元的初始阶段生成分解的用例场景，也称为白盒场景。

功能分析是使用活动图对用例场景进行不断细化。应为B2.用例中，分配给待开发系统的每个功能创建一个新的活动图。05

—

W2.功能分析：初始的详细步骤

为总结方法、区分工具操作，在对书中例子中W2.功能分析：初始有关的步骤总结的基础上，形成更为具体的、条目化的步骤内容，W2.功能分析：初始的详细步骤及分析结果见下表。

表1 W2.功能分析：初始详细步骤

注：用性质-建模区分纯工具操作

表1 中性质不是建模的详细步骤及其具体内容，构成了功能分析的步骤。

当一个用例场景中待开发系统有多个功能时，对每个功能重复序号2中的后两步，以及序号3的步骤，直至所有功能均完成分析。

当有多个用例场景时，对每个用例场景重复上述步骤，直至所有用例场景的所有功能都完成功能分析及建模。

其中的指定基本场景、使用备用流更新白盒场景这两个详细步骤，是我根据用例场景中的步骤单独增加的；原书中没有这部分内容。

06

—

学习体会

通过学习加深了对功能和功能分析的认识理解，除了上面的总结的体会之外，还有以下几个体会。

1.理解功能即理解需求

MagicGrid方法整体是在解决需求的分解和落实问题，功能分析是其中最关键的方法。

从方法的步骤来理解，功能分析向上承接的是系统用例场景，而系统用例场景来源于对利益攸关者需要的归纳整理，其实就是对问题域中系统使用场景的细化。

向下促进了对待开发系统的子系统识别，推动系统设计逐步深入，并最终走向实现。方法后面的步骤中会随着系统层次逐步深入分析。

功能分析应该是系统设计中最重要的方法。

对系统设计师而言，理解系统功能，也即理解了用户、客户对系统的需求，能够更好的开展系统设计。

2.功能是行为模式，是设计制造系统的目的

书中在这一步骤给出的例子是，针对汽车空调控制系统，假设达到需要温度这一活动的场景包括以下步骤：

• 系统准备

• 加热（如所需温度高于>舱内温度）

• 降温（如所需温度低于<舱内温度）

• 传输数据

• 显示数据

这些步骤是一整套的动作，也可以理解成系统的一整套行为，可以统称为行为模式，而通过行为，就可以实现规定的功能，功能是系统设计或制造产品的目的，所以可以说，系统/产品通过行为，实现了设计和制造它的目的。

这就是对第一节中提到的，“功能是一种行为模式，通过此行为，某物实现了它的目的” 这个概念的理解。

3.功能与功能载体可分离，是需求/功能分析不面向实现的理论基础

在《需求工程》中总是强调，需求分析中要关注系统做什么而不是怎么做，不要过早的深入技术实现细节。

在《NASA系统工程手册》中，关于功能流图的说明中也强调：

功能流图是功能导向的，不是设备导向的。

功能流图确认什么必须发生，而绝不回答功能是如何实现的。

按照我们的传统方法，认为设计就是考虑实现，我在《急于求成已成为做事的固有思维》中就提到，实践中就会遇到这样的质疑。

现在找到了需求分析中将需求与技术实现分开来做的理论依据：功能及其载体在概念上是分离的，功能的载体可以替代。

从概念上将功能和载体分离，可以打开思路、获得更好的解决方案；如果不这样做，功能的分析必然受到载体的限制，无法获得最优方案。

就像我在《福特汽车曾因轻视顾客需求面临危机，就是因为没掌握这一方法！》中，分析的亨利·福特的那句名言一样：

如果当初让我去问顾客他们想要什么，他们只会告诉我：“一匹更快的马。”

如果过早的考虑实现方案，那么只会停留在想到的、已知的马车上，而不会找到汽车这一解决方案。

07

—

写在最后

后面有时间将持续总结、分享MagicGrid方法的其余详细步骤、学习体会，输出实用的MBSE知识。

文章是利用休息时间学习总结的，写作不易，欢迎感兴趣的朋友，转发、分享，或点个在看，帮助传播