写在前面
本文从全局出发，分析在智能汽车产品开发中，应该从哪些维度做好需求设计。本文的理论性较强，具有一定的抽象性，但对产品开发人员，尤其是团队的领导者、需求提出与管理者、流程制定者，具有很大的参考价值。
考虑到本文内容的全面性和逻辑性，特整理全文内容导图，便于读者更好地理解。
汽车进入智能化时代，无论是用户还是厂商，都不再满足于简单的功能，而是对智能汽车提出了更高的需求，直接导致产品的效果和系统的复杂度增加。相应地，研发体系也会发生明显的变化，从以往的简单分工升级为一套多部门协作的复杂分工体系，如图1所示。可见，智能汽车时代的产品开发效果和研发体系，都源于需求，无论是新技术、新平台，还是新团队、新流程，都是需求变化的结果。
智能汽车作为复杂的系统，包含多个模块和多项功能：智能驾驶、智能座舱、智能网联、智能服务、智慧充电……因此需求也是复杂的，呈现出多样化、层级化、系统化的特点，不是传统汽车时代三言两语能说清的。因此，做好需求设计，对于智能汽车的最终产品效果，起到决定性作用，从源头上决定一款产品的好坏，以及研发部门的效率。
那么，如何做好需求设计呢？怎样保证研发过程的事半功倍呢？需求设计应该从哪些方面展开呢？本文将从九个维度，对需求设计过程进行深入地解读。
1 完备性设计
对需求考虑得不够完备，是需求设计时很容易出现的问题。智能汽车的需求来源广泛，呈现出多样性和复杂性，如果不能从全局出发，系统性地梳理各类需求，很容易导致需求遗漏，主要表现为忽视了部分利益相关方。
需求完备性设计之一，就是要考虑到所有的利益关联方，他们会从不同的角度提出各种需求。通常来说，利益关联方分为客户和其他利益关联方，这里的客户并不是狭义的甲方概念，而是指研发流程中的上下游关系，上游应该是下游的客户。
由于客户的需求是推进产品开发的主线，所以把客户的需求称为主干需求，把其他利益关联方的需求称为旁支需求。根据研发流程，客户是分层级的，所以主干需求也是分层级的，主要包括产品需求、系统需求、以及领域需求（如软件、硬件等）。其中系统需求还可以进一步分层，形成整机需求、子系统需求、零部件需求等。
一般情况下，主干需求不容易被遗漏，但是旁支需求往往会被忽略，造成需求设计不完备。各级主干需求的利益关联方及其旁支需求分析如下：
产品需求的利益关联方及旁支需求
终端用户，即最终使用产品的人，主机厂的终端用户是消费者，供应商的终端用户是主机厂或上级供应商。终端用户的需求主要是用户体验好、产品有亮点和先进性、功能完整、性价比高、保证质量、保障交付周期等。
销售团队，负责产品推广和销售，需要产品具备一定的展示功能，并相对竞品来说有明显的优势。
物流团队，负责产品的运输和交付，需要产品易于包装，不易损坏，有一定的运输环境适应性。
生产团队，负责产品的制造和组装，需要产品能支持产线测试、写入序列号、在线匹配等功能。
售后团队，负责产品的售后支持和维护服务，需要产品能支持客户投诉反馈、在线和远程诊断、数据采集回传等功能。
回收/报废团队，负责产品的回收和报废处理，需要产品能够一键清除敏感信息、支持回收SN号等。
系统需求的利益关联方及旁支需求
系统工程师，需要系统是模块化的，功能可以扩展，并且系统资源容易扩容。
集成工程师，需要功能调用和通讯交互可Trace，资源开销可以动态监控，系统故障是可以监控和记录的。
集成测试工程师，需要系统支持测试接口、Log、存写故障码等相关的测试功能。
功能安全工程师，基于整机、子系统、零部件的需求与设计文档，完成功能安全分析，并结合Safety Goal明确FSR（Functional Safety Requirements, 功能安全需求）和TSR（Technical Safety Requirements，技术安全需求）。
配置管理工程师，完成各项目和产品的配置化，需要系统支持共性及个性需求的参数化管理。
研发的各专业领域，如软件、硬件、结构等，同样存在各自的利益关联方，在此就不一一展开了。
以上，就是需求设计时要考虑的利益关联方，以及各自的需求。在需求设计时，必须完整地按层级去考虑每个利益关联方的需求，做到不重复不遗漏，以保证需求的完备性。
2 结构化设计
需求混乱、条理不清晰、难以理解，是常见的现象。复杂的需求如果不能做到结构化，将很难被理解，更不用说传递和落地。在开发过程中，经常遇到大篇幅的、没有主次之分、没有区分颗粒度的需求条目，不仅无法进行分析和理解，有时甚至会相互冲突。
功能的结构化设计，可以从优先级、层级、主次（功能&非功能）、颗粒度、依赖关系等方面开展，通过结构化，让需求的可读性提高，更容易被理解，也方便开展评审及后期的分工、开发和维护工作。
2.1 优先级
需求的优先级决定了开发工作的先后顺序，应该是首先要考虑的。需求的优先级首先体现为需求的重要性，可以通过MosCow方法和Kano模型来确定。
MosCow方法将需求分为必须（Must）、应该（Should）、可以（Could）和不会（Won't）等4类：Must需求是项目成功的必要条件，如果缺失，会导致项目无法交付；Should需求虽然不是项目成功的绝对必要条件，却是重要的，如果资源允许，应该尽量实现；Could需求是可选的，能够提升产品的用户体验或附加价值，但不影响项目成功，属于增值的需求；Won't需求在当前的版本中不会实现，但可能在未来版本中考虑。
MoSCoW方法可以让团队清晰地了解并沟通各项需求的优先级，确保关键需求得到优先实现，同时合理安排资源，最终交付符合用户需求的高质量产品。
Kano模型将需求分为基本需求、绩效需求和魅力需求：基本需求的优先级最高，是指客户认为理所当然、必须满足的需求，是一票否决项；绩效需求的优先级次高，是客户明确表达的需求，也是竞争优势的来源，会直接影响客户的满意度和产品的竞争力；魅力需求的优先级最低，是客户没有明确提出但会给客户带来惊喜的需求，是超出客户期望的需求，能够从感观上赢得客户的好感。
Kano模型可以让团队全面识别并满足客户的需求，从而在竞争中获得优势。基本需求是必不可少的，绩效需求是竞争力的体现，而魅力需求则能带来惊喜和额外的客户忠诚度。
除重要性外，在实际项目中，需求的优先级还需要考虑实现的成本。通常使用四象限法，即需求优先级矩阵，将需求进行分类和排序，对重要性与成本进行综合权衡后，得出最终的需求优先级顺序。
四象限法根据重要性和实现成本，将需求分为四个象限，如图2所示。对应地，需求按顺序可以分为：①重要性高-实现成本低，此类需求应该优先实现，是优先级最高的需求；②重要性高-实现成本高，此类需求需要重点关注，必要时考虑分阶段实现；③重要性低-实现成本低，此类需求可以实现，但优先级较低；④重要性低-实现成本高，此类需求的优先级最低，应该最后实现。
需要注意的是，需求的优先级不是固定的，会根据项目的进展和客户的反馈发生变化，需要进行动态调整。比如，座舱的分区空调需求，可能在过去是魅力需求，但现在已经发展成绩效需求甚至基本需求了。
2.2 层级
需求的层级是结构化设计的重要方面。前面在解读需求的完备性设计时，已经介绍了需求的层级，分为产品需求、系统需求和领域需求，其中系统需求进一步分为整机需求、子系统需求、零部件需求等。在此，就不过多赘述了。
2.3 主次
这里的主次，与前文所讲的需求优先级不同，指的是需求存在功能性需求和非功能性需求，功能性需求是主要需求，非功能性需求是次要需求。
功能需求描述的是系统直接实现的功能，是产品能够达成的效果，如语音交互功能、城市NOA功能等；非功能需求指功能以外的需求，一般包括：客户的指标性属性，比如主干需求的性能、可用性、安全性、可扩展、可维护等性能；其他利益关联方的需求，比如展示、产线测试、售后诊断等、易于集成等。
2.4 颗粒度
颗粒度描述了需求所包含的功能集，根据功能的体量，可以把需求按颗粒度分为功能组需求、主功能需求、子功能需求、原子功能需求、基础功能需求和用例需求。
功能组需求，是对多个关联功能集合的需求，通常用于对系统中的各种功能分类和组合。功能组是功能的高层次分类，能够覆盖或部分覆盖某个完整的产品或系统。功能组内的各项功能具有逻辑上的关联或共同目标，如智驾功能组、座舱功能组等。
主功能需求，描述了系统中具有独立完整性的主要功能模块，通常是实现系统核心业务或主要用途的关键功能。主功能作为系统的核心功能，直接关系到客户的主要需求，在逻辑上可以独立存在，一般会包含多个子功能，如高阶L2功能NOA包含基础L2功能LCC、ILC等。
子功能需求，描述的是主功能的各组成部分，支持实现主功能的具体任务。子功能是对主功能的细化，处理特定的任务或步骤，如NOA的变道子功能。
从可复用的角度，子功能需求可以进一步抽象出原子功能需求和基础功能需求。
原子功能（Atomic Function）是最小的、不可再分的功能单元，具备最大程度的通用性和复用性。基础功能（Basic Function）由原子功能组成，以实现更复杂的操作，并具备一定的通用性和复用性。
原子功能和基础功能是系统中最基本、最核心的功能，通常是其他高级组合功能的基石，一般包括基础服务、数据服务、业务服务等，可以在多个场景和用例中被重复使用。
用例需求中的用例即通常所说的case，包括系统用例和功能用例。系统用例描述的是用户与系统之间的交互过程，可以跨越多个功能模块，体现用户在完成某个目标时与系统的交互时序。功能用例描述的是某个功能或子功能在特定场景中的完整服务过程，包括事件驱动的触发条件、交互步骤和响应行为等，聚焦于单一功能或子功能的详细实现，描述功能在事件驱动下的响应流程和交互细节。
2.5 依赖关系
需求的结构化，不仅要让需求之间相互独立、便于管理，也应该充分考虑各类需求之间的相互依赖关系。需求的依赖关系是支撑产品开发，尤其是敏捷开发的重要内容，产品的每轮迭代，都需要按优先级和依赖关系合理安排任务。
通常的做法是在需求条目表上，增加依赖属性，与其他需求条目产生映射关系。在前文提到的需求中，原子功能需求和基础功能需求，是依赖关系中比较底层的需求。
以上是需求的结构化设计时需要考虑的维度，结构化实现地越好，需求就越容易被快速理解并层层传递，越能保证最终的产品效果。结构化不仅是需求设计的核心工作，也是一个团队整体技术能力的重要体现，需要给予充分的重视。
3 抽象化设计
面对多变的市场需求和终端用户需求，产品开发过程应该具备灵活应变的能力，这就对需求的抽象化设计提出了要求。实际项目中，需求难以复用、维护、扩展和修改，是经常遇到的现象，而系统的抽象化设计，正是让需求经历组件化、抽象化、模板化、参数化和插件化的梳理，让需求的适配性更强。
组件化是指遵循组合功能、基础功能和原子功能的原则，让需求在尺度上有清晰的层次关系和组合关系，实现可复用。
抽象化是指提取需求的共性，做好类型、属性、行为和接口抽象，让系统更加灵活，更加易于扩展。比如，车→汽车→SUV→具体某品牌某型号SUV。
模板化类似于可抄的标准答案，集成了很多设计与规范，为需求提供多种模板，方便快速构建实例。
参数化是指通过参数配置，实现功能的灵活定制而无需修改代码，增强系统的可维护性。
插件化是将原子功能、基础功能设计成插件的过程，在需要时可以加载到高级功能中，让系统可以方便地扩展功能，增强系统的灵活性。
大部分情况下，需求并不是一蹴而就的，而是在产品开发过程中不断的打磨调整，例如增加新的功能、调整参数配置等，因此需求应该高度抽象化、组件化、可扩展，增加开发流程的灵活性和可维护性。
4 规格化设计
需求的规格化是指将客户的需求转化成清晰、详细、可操作的规格说明，以便团队能够准确地理解并实现这些需求，促进各利益相关方对需求达成一致。需求规格化有利于消除歧义和误解，以确保需求传递的一致性，便于产品验证，最终提高项目的成功率；也有利于为产品开发提供明确的目标，减少沟通成本，提高开发效率。
具体来说，需求的规格化设计，主要应该做到以下几点：
清晰性：对需求的描述应明确、具体，避免模糊和歧义，尤其不能有模棱两可的描述。
一致性：各需求之间应保持一致，各需求之间的依赖关系也应该合理布局，避免相互冲突和重复。
可操作性：需求应足够详细，这样才能容易操作，进而指导具体的开发工作和产品实现。
定量化：需求不能只是定性的描述，还应有定量的参数化要求，有客观的量化数据描述。
场景化：需求应基于具体的场景，而不是泛泛而谈，场景包括工作环境、系统状态和前置条件等因素。场景化是系统和功能用例化的前提，是让需求容易理解的重要方式。场景与功能是相对独立的，因此场景管理可以独立于功能管理体系，因为同一个场景可以支持多个功能，例如ACC的多个场景，在LCC中也同样会出现；智能语音交互的部分场景，在智能车控中也会存在。另外，场景是有频率属性的，即高频场景与低频场景，应该优先聚焦常见的高频场景对应的需求。
技术指标打合：需求的各项技术指标必须充分打合，达成一致后再释放，才能保证需求的合理性与可行性，技术指标可以参考历史项目、同系列产品、行业标准、法律法规等内容。
总而言之，从多个方面做好需求的规格化设计，可以确保需求清晰、详细且可操作，从而指导团队准确地实现用户需求，提升项目的成功率。需求的规格化不仅能提高需求的质量和可管理性，还能增强系统的可维护性和扩展性。
5 规范化设计
如果需求的条目不规范，那么即使需求的内容没问题，也会由于表达形式的原因，导致描述不统一，难以理解，沟通成本高等问题。
需求的规范化设计主要是对需求用例进行规范化的编写，从而提高需求文档的清晰度和一致性，统一描述语言，降低沟通成本，提高开发效率。规范化的需求用例应该包括状态和条件、功能、动作、信号、数据等关键要素。下面列举几个模板，示例如何让需求变得规范化。
周期性功能需求模板：在【状态和条件】下，【功能】会周期性地执行【动作】，并周期性地输出【信号】，同步【数据】。
信号响应需求模板：在【状态和条件】下，【功能】收到【信号】时，会做出【响应动作】，并输出【信号】。
故障响应需求模板：在【状态和条件】下，收到【功能】的【故障信号】时，会做出【响应动作】，并输出【信号】。
6 极限工况管理
在需求设计和验证中，管理好极限工况，是确保系统稳定性与可靠性的重要环节。极限工况主要包括极端环境条件、高负载、高工时以及故障状态。
需求的极限工况管理，具体措施包括确定极限工况、定义阈值范围、制定差异策略、进行边界测试、压力测试和故障注入测试等。这些措施可以帮助开发团队预见并应对可能的挑战，从而提高产品的整体质量和用户满意度。
确定极限工况，主要从以下几点考虑：环境条件，如高温、低温、高湿度等；负载条件，如高并发用户访问、大数据处理等；工时条件，如长时间连续运行；故障条件，如网络中断、电力故障、硬件故障等。
定义阈值范围和策略，指明确每种极限工况中的具体参数和阈值范围。例如，电池包在-20°C到50°C的环境温度下应能正常工作，-25°C到-20°C可以开机，-25°C以下不能开机。
边界测试，测试的是系统在极限阈值附近的表现，确保系统的功能在极值边界内仍然正常。例如，电池包在50°C高温下的电压、电量和功率输出稳定性等。
压力测试，是模拟高负载条件，测试系统在高并发访问或大数据处理时的性能和稳定性。
故障注入测试，即人为引入故障，测试系统在故障时的容错和恢复能力。
7 冲突管理
系统的复杂性导致需求不可避免的会出现冲突，主要包括系统内部的需求条目之间的冲突和系统对外部环境造成的影响。系统内部需求冲突会影响系统的稳定性和性能，如系统状态冲突、算力不足、温升太高等；系统对外部的影响一般是违反法规约束或对外界环境产生影响，如噪声、电磁污染、空气污染等。
系统内部冲突
资源冲突，即不同功能模块或进程争夺有限的系统资源（如内存、CPU时间、带宽等），可能导致性能下降或系统崩溃。
功能冲突，指系统的不同功能需求之间存在矛盾，例如一个模块需要高安全性措施，而另一个模块可能需要快速响应，两者难以兼顾。
数据一致性冲突，指多个模块对同一数据进行读写操作时，出现数据不一致的问题。
时间冲突，即系统中的不同任务需要在相同时间段内完成，但资源有限导致无法同时满足所有任务的需求，导致任务延迟或失败。
优先级冲突，指系统中不同任务的优先级设置不合理，导致重要的任务得不到及时处理，影响系统的整体性能和稳定性。
温升冲突，指两个应该同时运行的功能都会导致发热严重，温度大幅上升，导致功能不能同时运行。
状态冲突，指两个功能需要在不同的系统状态下运行，当同时运行时，需要决策系统状态如何切换。
系统对外部环境的影响
法规约束，即系统的某些功能行为违反法规政策或行业标准，例如数据的收集与处理违反隐私保护法规。
环境影响，指系统的运行对环境造成负面影响，如噪声、电磁污染等。
伦理问题，即系统的设计和运行涉及伦理问题，比如著名的火车决策问题，选择压死1个还是5个。
冲突问题管理
在实际项目中，可以通过以下方法，来管理和解决需求的冲突问题，确保系统的性能表现、稳定性与合规性。
需求优先级排序，即与利益相关者沟通，明确需求的优先级，确保关键需求得到优先满足。
资源分配优化，指通过合理的资源分配策略，尽量减少资源冲突，提升系统整体性能。
优化架构设计，通过在系统设计阶段充分考虑潜在的需求冲突，通过模块化设计、松耦合等方法优化系统架构，以降低冲突风险。
法规和伦理审查，即在系统设计和开发过程中，从法规和伦理角度进行全面审查，确保系统符合相关法律和伦理标准。
持续监控和反馈，指在系统运行过程中，持续监控系统性能和外部影响，及时调整并优化系统，以解决出现的冲突。
8 投资管理
投资管理是对项目资源的管控，根据不同的需求，合理地分配资源，避免出现资源不足导致项目延期等情况。项目资源包括人力、BOM、预算、时间等因素，通常应综合考虑需求的必要性和新颖性，来决策项目资源的投资组合。
必要性就是前文提到的，通过Kano模型将需求分为基本需求、绩效需求和魅力需求；新颖性则表示需求的创新程度和独特性，分为全新需求、优化需求、可模仿需求和复用移植需求。
全新需求是完全新创的功能或产品，提供了市场上尚不存在的解决方案或产品体验。优化需求是对现有功能或产品的改进与优化，以提升性能、用户体验或效率，集中在改进现有技术或功能。可模仿需求是指借鉴或模仿竞争对手产品的功能或特性，快速填补产品的短板，跟随市场趋势，实施难度不大。复用移植需求是将现有功能或代码移植到新的平台或产品中，或在不同项目之间复用已有的技术，需要一定的移植集成和调参工作。
根据必要性和新颖性对需求进行分类和管理，能够在资源有限的情况下，优先支持具有更高价值的需求，以提升产品的市场竞争力和用户体验。
9 双向追溯及变更管理
需求在上下游之间层层传递，其双向追溯和变更管理也是十分重要的，否则难以保证需求的一致性，不仅不利于问题分析时查找根因，也很难在需求变更时分析影响范围。
双向追溯及变更管理对于需求设计的重要意义在于，能够确保需求的完整性、一致性、透明度和可追溯性，增强团队的协作性，加快需求变更和产品迭代的节奏，也便于需求验证与项目风险管理。
需求的双向追溯与变更管理，涉及到固定的流程，以及需求管理的工具，具体如下：
双向追溯，应该让每个需求都有唯一的标识符（需求ID），需求之间，尤其是低阶需求与高阶需求之间，可以通过需求ID互相索引。其中，从低阶的具体功能用例、测试用例追溯到其来源的高阶需求，是向上游追溯；从高阶需求追溯到其分解需求、功能实现和测试用例，是向下游追溯。
变更管理
变更管理的流程，主要包括变更请求、变更批注、变更实施和变更验证，每一步又都可以细分为2个阶段。
变更请求分为提交阶段与评审阶段，即任何变更请求都应通过正式的流程提交，并记录在案；然后由项目团队和利益相关者共同评审变更请求，评估其影响和可行性。
变更批准分为评估阶段与批准阶段，即对变更的影响包括成本、时间、风险等，进行详细评估；然后由项目管理层或专门的变更控制委员会进行批准，并记录在需求管理工具中。
变更实施分为计划阶段与执行阶段，即制定需求变更的实施计划，包括具体任务、责任人和时间进度；再按照计划执行变更，并确保所有相关文档和工具同步更新。
变更验证分为测试阶段与验证阶段，即对变更进行测试，确保其满足需求且未引入新的问题；并验证变更是否达到预期效果，然后记录验证结果。
需求管理工具可以帮助团队更好地管理和跟踪需求，尤其是变更的进展，常用的需求管理工具有JIRA、Confluence等。另外，需求管理工具还可以提供必要的版本控制功能，通过Git、SVN等版本控制系统来管理需求文档与代码；通过版本控制，可以追溯到每次变更的具体内容、时间和责任人，确保需求变更的透明性和可追溯性。
另外，还可以通过定期会议的方式，如需求评审会议、变更评审会议等，做好需求同步与变更同步工作，保证关联方能够及时同步更新需求信息。
结语
智能汽车的需求设计是一项复杂的系统性工程，需要从多个层面综合开展。本文所提出的需求设计方法，涵盖了需求设计的九个维度，兼具前瞻性、系统性和可落地性，相信会给开发人员带来一定的帮助，在提升产品效果的同时，也极大地提高开发效率。
本文提到的需求设计方法不是一成不变的，应该根据具体的公司、团队及项目情况，灵活裁剪，组合应用，从而最大程度地发挥出需求设计的作用。
作者：TANK
来源： 汽车电子与软件
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
