功能清单，称作Function list。如何传统的配置表（Feature list）变化到功能清单（Function list）
从上图描述的配置表和功能清单发现：
1，功能类的配置可以直接被功能表采用（上面表述中3，功能类），而参数类、零件类和系统类的配置是功能实现的物理基础和约束条件，上图的功能表中，冒号后面是功能实现需要的物理实体零件或能达到的参数。
2，为了体现出功能是零件的作用，功能的名称需要用能够表达整车、系统或零件所发挥的作用来进行命名，例如xxx控制等，而不能以零件或系统直接进行命名。
为什么现在的车型，甚至项目开发过程中，主流的方式，依然还是以传统的配置表（Feature list）来展示呢？
一来，在用户领域，传统车辆的用户形成的惯性和粘性，依然会以配置对比来评价车辆。而不会想到功能层级。而且大多数人更倾向于看得见，摸的着的东西作为评价标准。而非体验类的感觉。例如，一辆车动力性能，驾驶性能，并不是单纯的看配置表就能对比的出来的。——俗称堆料。
二来，在开发领域，车型配置表单（Feature list）的定义始终是各大车企，尤其是合资品牌车企产品战略部门管理的核心职责。无论调研逻辑是否成立，只要有配置表单（Feature list），那就有数据，可量化，易达成……简单的说，更加容易管控各个部门的目标，绩效，交付物。
功能清单的结构
当前的整车功能清单会区分为主功能和子功能，对于主功能和子功能的区分。
主功能
场景来看，完成一个用户的主场景动作，如用户完成座椅调节，满足自己的乘坐需求；
部件来看，基于一个较为完整的部件系统，如座椅这个完整的系统；
子功能
场景来看：完成用户的一个细分场景需求，如座椅的前后调节；
部件来看，至少基于一个主要零部件及上下游的关联零部件，如座椅的前后调节电机、开关、显示屏等。
Use case
一个子功能的实现，有输入、判断、输出等几个步骤，输入可以是软开关、硬开关等，执行中会有防玩，功能失效等情况，这些都是形成use cases的主要考量项，如上述座椅的调节，前后调节，可以用软开关、可以用硬开关，可以语音，执行过程中，用户打断调节、调节电机堵转等，这些都会形成一个子功能下的不同use case。
子功能的最小单位必须是必须是一个完整的给用户服务的场景，一个单独的执行动作，或者一个交互显示内容，只是一个子功能下的case内容，不能设定为一个子功能。
通过主功能、子功能、UC的三层分级后，需要达到主功能清单基本保不变，子功能清单也基本保持不变，UC可以按照项目的新需求便捷调整。既主功能清单基本可以覆盖所有车型而不做改变，子功能可以覆盖同平台车型不做改变，UC可以覆盖一款车型及其衍生车型不做改变。
随着整车功能数量的增多，SOA（面向服务的软件架构）兴起，从功能需求可以直接连接到产品原子化服务能力，更多场景模式的出现，功能清单的结构也会逐渐重构。
功能清单和整车其他清单的关系
销售配置表，工程配置表，功能清单，BOM清单，功能增长表等，这些名称都是整车开发中常用的一些清单
通过上面这几个清单，基本上就能把整车开发串起来了，这些清单，本质上都是管理工具。
功能设计
功能设计一般分为2个阶段，
第一阶段：从无到有，此阶段是在开发当前整车产品不具备的功能，此阶段基本不符合当前国内整车开发情景，因此很快进入第二阶段
第二阶段：优化设计，在这个阶段，核心是竞品对标，针对竞品功能对标，有以下几个个关键点：
1、说明书，获得对标车辆的说明书，并对要对标对功能的使用说明和注意事项等详细的阅读；
2、对标场景设计，详细设计对标场景，设计详细的体验Case,基本上可以寻找功能体验细节。
3、对标车辆选择，当前建议，新势力的如特斯拉、蔚来，传统豪华品牌如奔驰、宝马，以及大众等车。你会发现针对这些场景，不同品牌的会有很多不错的考虑。如奔驰是通过踩两脚制动激活Auto Hold，特斯拉是大力出奇迹。另外奔驰可以通过再次踩制动释放Auto Hold，看似反人类的设计却在下坡堵车的场景下给你最安心的操作。如果不知道这个设计，没关系，特斯拉非常人性的在坡道上会提醒你“可以通过踩制动释放Auto Hold。“
4、人员选择，新手、老手、男士、女士、不同年龄段等，每个人的经历和关注度都不一样，发现的点基本也不一样。
来源：谈思实验室 作者：CSDN@Johnny 周
