本文摘编自《智能汽车电子与软件：开发方法、系统集成、流程体系与项目管理》，机械工业出版社出版，经出版方和作者授权发布，转载请标明文章来源。
问渠哪得清如许，为有源头活水来。
需求一定是我们开发的源头，甚至是企业生存的源头，有需求，才有消费，有消费，才有盈利。类似地，一旦经济开始衰退，拉动内需、刺激消费就成为强心针了。
多少扯远了，但我想说的是，需求的重要性不可不察。
1一些有关需求的感触
作为开发的出发点和落脚点，需求引出了很多的思考，也牵绊了太多的感触。
1.1 不太容易搞明白的需求
简单来说，“需求”就是你到底要什么？但想回答这个问题却并不简单。
在做系统工程师的那些年，也是经常被项目经理、软件、算法、硬件、测试、生产......还有领导，问到这类问题，你到底想要什么，客户到底想要什么？
多人发懵并不是偶见的场景，下游客户不知道自己想要什么，就是我要，系统工程师或需求工程师或产品经理等类似角色也常常一样，不清楚想要什么，客户要，我也要......所以说啊，需求并不是个很容易搞清楚的东西。这背后的原因很复杂，可能会来自：
描述语言模糊导致理解错误。需求对于实现不完整。需求本身就不可行或不可验。同一需求在不同文档中描述不一致。提需求的人本身没想清楚。接需求的人没有或没能力听明白。以为听明白了但传递时发现不够......
举个简单的例子，客户说我想加一个故障码，这确实是一个需求，但如果只是这样传递显然就会出现上述情况。
系统工程师会问加关于什么故障事件的报码、故障码ID是什么、故障触发是否要激活警示灯、故障是否可清除；软件工程师会问达到什么样的限值触发、故障监测周期是多长时间、触发后如何在内存中记录。
无论哪个环节没有弄明白或弄错了，需求的收集、分析、传递、理解就会出现问题。
当然，并非要求下游客户把需求的所有细节都讲明白，否则客户自己做就好了，要供应商做的意义就减弱了。
所以，在现实中，下游客户确实没精力、没能力把自己的需求讲得明明白白，要靠上游来澄清。这似乎是个悖论，怎么提需求一方反倒需要实现方来讲明白需求。
但是，这确实是一直以来很多OEM与Tier 1的合作模式，OEM很多时候只给出来一个模棱两可的感觉，Tier 1依靠自己的经验储备来告诉OEM你需要什么，并给出推荐方案，OEM无奈地、稀里糊涂地买着黑盒子。
不过，时代在变化，OEM也在逐渐深入底层。
1.2 需求值得反复澄清
还有个感触是从管理角度谈的，需求非常值得反复沟通、反复确认、反复澄清。当你觉得对方的文档是模棱两可的或者说的话是有些支支吾吾的，就一定要搞清楚，非常具体地反问，还要用自己的话来描述自己的理解，并写下来，确保万无一失。
在实际经验中，能够清清楚楚地感受到，“墨菲定律”在需求分析中体现得淋漓尽致，觉得可能错，大概率会错。有个统计数据是，需求问题会导致大约40%的软件bug。可见，这种错误是具有相当普遍性的。
我有个有趣的经历。
之前在对一个改款项目进行报价评估时，销售说的是，这个项目与上一个项目基本一样，工程团队不必花太多时间分析，快速参考一下给出成本即可，我们报价时间非常紧张。
听起来，这个需求很直白、很明确，而且还让销售提供了客户类似描述的邮件，再加上这个阶段也没有太多的细节可以参考了。按理说，可以写清楚报价背景后直接报价了。
不过，出于工程师对虚词的敏感，轻轻的“基本”这俩字虽然隐藏在一大堆其他信息里，却依然刺耳地送进了我的耳朵里。至少是考虑到我的工作不返工，我顺着这个“基本”追根究底下去，发现这个“基本”是指改某个标定参数，以往常的经验，这个参数确实够“基本”，但恰好最近发现了一个严重bug和这个标定值有关系，这就涉及一系列的bug修复、回归验证、版本升级等工作，相关的成本与周期自然不是那么“基本”一样的。
1.3 需求在性质上的维度
往大了说，需求无所不包，各个干系人或者叫相关方期望的一切东西都能称之为需求，有关注产品的、有关注营销的、有关注钱的、有关注时间的、有关注过程的、有关注交付的、有关注生产的......
为了能说明白，我们还是往小了说，从工程的视角看，我们的需求可以粗略分为“非技术类”和“技术类”。如图1所示。
图1 需求的简单分类
1.3.1 非技术类
那些营销、钱、时间、过程、交付、生产就是典型的“非技术类”，这部分我们不做展开。
这里提另一个非常关键的非技术类需求——体验感。我们都知道，用户购车的诉求已经有了很大的变化，汽车基本素质已经被普遍实现，血红的汽车市场让人挑得眼睛都花了，于是，最能吸引早就没有耐心的大家的，就是那种直给的“爽”点，这可能是来自品牌信仰，可能是源于情怀，可能就是说不出来的感觉很好。姑且可以将这类显得有些细碎、玄虚的东西称为体验感。
为了更容易理解，举个自己印象比较深刻的例子。
去年夏天，天气闷热，于是，在网上买了一台某互联网性质公司的落地扇。送货上门，拆开有些破损的快递公司外包装盒......哎，眼前倒是一亮，映入眼睛的是包装紧致、塑封完好的外箱，与快递外盒有明显反差。以前习惯于暴力扯开，一脚踩扁后，然后扔到车库让老人卖旧纸箱子，现在倒有点舍不得破坏了。
接着，想想剪刀放在哪里了，准备拆箱......不至于吧，封口胶带用了有些类似于快递文件信封的方式，就是可以直接手动撕开，但是，我喜欢。
这个落地扇是属于可拆卸式的，需要把各大零件组装起来，虽然作为理工男还算喜欢组装，但还是得找说明指导。说明书有的，可懒得看，因为封面有个可查看组装视频的二维码。
组装视频分多个，每个视频都是一个环节的说明或者组装步骤，画面上有重复播放和下一个的按钮，这就不用我反复地暂停或拖动进度条来回看了。首先是解说和动效同步的零件清点，说到具体对象，会指引位置并放大显示，几大部分很容易看得出来。随后是各个组装步骤，零件上清晰的方向标识与物理防错都让我非常便捷地组装起来，很多环节甚至不需要看视频，凭直觉就可以。各种螺钉和小扳手都附带好了，显然也都是经过琢磨的，扳手形状与尺寸能很好地与对应操作空间适配......
很快就装好了，取出电源包装盒，意料之内，封口胶带前端留了一点免粘的部分，不用费力地拿指甲抠了。插上风扇，慵懒地躺在沙发上，不知道是不是风够凉，但那个炎热的午后，我的心情是有点清爽......
几百块钱的小家电，并不具备多么艰深的技术壁垒，但却把用户体验做到了极致，我想，这也是我能在落地扇这里感受到的最大尊重了。
这种常常被汽车工程师忽略的细碎体验感的东西，包含的不仅仅是常规意义的工程及工业设计，还有很多美学、心理学、社会学等各方面的维度。尤其在座舱、智驾这类领域，体验感以及由此而来的用户时间与注意力占用是非常关键的评价要素，值得我们关注，也值得我们扩充对需求内涵的理解。
1.3.2 技术类
无论如何，很大一部分的“非技术类”还是需要落地在“技术类”之上，才能在产品上得到体现。“技术类”还会分为两大种：功能类和非功能类。
(1) 功能类
功能类是基本的、直观的、上层的，定义了产品能做什么，比如，前面讲的那个旋钮能控制车速。
(2) 非功能类
非功能类是相对抽象的、底层的，比如，那个旋钮的直径不能超过15mm、耐久性要达到30万次、速度信号错误的功能安全等级要达到ASIL D、发送信号的周期10ms、能够诊断针脚短路报故障码、硬件限制而让传感器的加速度信号范围不能超过正负100g等。
实际上，自然是无法区分得那么清楚。基本上越接近终端用户直接价值感知的越属于功能类，即用户场景或用户故事，越接近开发底层的越属于非功能类。功能类需求的满足是让客户一次满意的关键，非功能类需求的满足则是要让客户持续满意。
2需求收集与整理
我们是站在一个类似于ECU这种软硬一体产品的视角的，这个整车架构下的子系统是我们要开发和交付的范围。所以，在开始之前，我们需要收集这个范围之外一切或粗或细的相关方需求，然后在里面去伪存真，抽取出我们所需要的。
2.1 外部需求收集
一般可能会涉及法律法规、行业标准、市场趋势、整车需求、上一级系统需求、内部需求及项目需求，如图2所示，我们一个一个来看。
图2 外部需求来源
2.1.1 法律法规
这个道理是比较容易理解的，我们不能违法，对应来说就是强制性标准。不过，行业并非刚刚起步，像排放、安全等大量相关的成熟法律法规已经沉淀到了产品设计规范里，不用每一个车型都去做这么一件事。
在这里需要特别关注的有两个方面：
第一，最近几年电动车、数据安全、网络安全、自动驾驶、OTA、EDR（Event Data Recorder，事件数据记录系统，即汽车“黑匣子”）等新事物的兴起必然会带动一些国家法规的出台，需要实时关注。第二，无论是整车还是零部件经常会涉及出口海外，除了欧盟、北美有些比较知名的准入要求，其他地方也需要给予关注，比如，一些政治制裁国家。这部分大家往往经验较少，有可能会识别不到。
2.1.2 行业标准
这里指的是推荐性标准，就是你做也行，不做也没关系，至少是没有谁会直接惩罚你。但是，为什么要说隔行如隔山？很多时候隔的就是对行标的认识。接着前面一句话的描述，尽管你不做没人惩罚，但你可能会失去市场或者无法和别人兼容。
比如，大家都去做的NCAP（New Car Assessment Program，新车评估项目，也即新车碰撞测试）评星，这个不是强制的，但市场认，你基本也会去做。再比如，UDS（Unified Diagnostic Services，统一诊断服务，即标准ISO 14229）协议也不是法规，但大家都这么做，你没必要也基本没能力重新开发一套。
2.1.3 市场趋势
尤其是这几年的混战期，市场方向的把握十分重要，将市场趋势融合成需求显然也十分重要，但是，优秀的汽车大产品经理太少了。
能够落地一点的是，收集对标企业的需求或者拆解对标企业的车型或产品，以明确自己的方向。其中，在平台化产品线的开发时，考虑好这部分尤为重要，否则，后续一系列衍生项目都将面临失败。
2.1.4 整车需求
无论是零部件厂商，还是主机厂内部自研部门，它们都要面对整车需求，一些整车3D布置、风阻、盐雾、耐久、操纵稳定性、动力性、NVH、碰撞等要求离软件远了点，一般无法直接对应，我们直接跳过。
能够影响到软件开发的整车需求，可能会有EEA、通信矩阵、诊断规范、刷写规范、ICD（Interface Control Document，接口控制文档）协议、功能安全需求、网络安全需求等各种通用性的标准，也就是所有电子软件模块共同遵循的。
2.1.5 上一级系统需求
由于系统是一个可不断被拆分的概念，我们一个ECU是一个系统，往上一层ECU协同传感器、执行器也会组成一个系统，比如，车灯控制ECU和整个车灯系统的概念，或者安全气囊ECU和被动安全系统的概念。
控制器及其中的软件是要满足其上一级系统的需求。这部分的需求就会具体很多、贴近产品很多，比如，对于车灯系统而言，根据弯道路况和特定车速来自动调整车灯的照明方向，可能就是它给车灯ECU的一条需求。
2.1.6 内部需求
这里的内部不是指ECU内部，是指组织内部。有一些大一点的企业，出于成本、合规、历史经验、安全余量、鲁棒性等的考虑，会有一些内部的设计准则来限定产品的设计，比如，ECU一般的工作电压在6.5～16V之间，但可能内部设计准则是3～20V都要能正常工作。
此外，有时候也会有一些特殊的测试需求或者生产需求，它们也会影响到产品开发。
2.1.7 项目需求
其实，最后一个项目需求和前6个是不属于同一个逻辑层次的，这里是针对特定项目的特定需求而言的，基本是被包含于前6个的范围之内。我们日常的项目更多是基于某个前序项目的变更，更多是直接处理这一概念的需求，而不会那么全面地梳理完整的需求。这就是在这里把它单独拿出来的原因。
总之，收集好以上内容，大体就获取到了我们汽车软件产品所要面临的外部需求。
2.2 外部需求整理
那么，这时的需求长成什么样子呢？一般是一份份Excel、Word、PPT、PDF之类的文档，也有可能是不那么规范的邮件。
这就让我们现在至少面临两个问题：
一是，大量和自身不相干的需求。比如，一本上百页的ECU规范里涉及自己产品的不足10页。二是，这些需求比较凌乱。在实际工作中，这些需求可能是在时间仓促的报价定点期间临时获取的，又或者是随着开发的要求不断要到的。这种情况下，版本老旧、内容错误、标准遗漏都是可能发生的。
所以，在这里，最好做一件事情，就是对这些文档进行梳理，梳理点可能会涉及如下方面。
文档是不是完整？哪个是最新的版本？是不是有重复的文档？是否有一些容易误解的地方待澄清？有没有与本项目不相关的信息？能不能整理出规范文档？某些文档是不是项目早期已经明确拒绝的......
初步确认出来可用的部分，而后可以形成一个汇总表，包含名称、版本、来源人、释放日期及存档位置等。这份汇总后的原始需求列表其实可以作为一个配置项来进行的管理的，其也可以为下一阶段工作提供一个清爽、完整的输入。
3需求分析与分解
在拿到这一揽子外部需求后，即便能够制作一个清晰的需求列表，颗粒度依然不足以直接用于开发。我们需要进一步地分析，并在我们产品级系统的范围内分解，如图3所示。
图3 需求分析与分解的思路
3.1 基于特性（feature）分解定义产品级“系统需求”
特性是业内习惯称呼的一个词。通常，我们会用它作为牵引来分解、定义产品级系统需求，但其含义多少有些含糊，有必要先来辨析一下。
3.1.1 特性与功能
特性是一个相对小但具备一定完整性的“模块”，其中可能只涉及软件，但也可能同时涉及硬件，一般可以被划归到一个责任人来负责，从需求管到验证确认，即特性负责人（feature owner）。
稍微注意一点，这里的“特性”要和前面“功能类”需求描述的“功能”有些许区分，前面侧重的是描述性的功能逻辑和用户价值，这里侧重的是系统这个“黑箱”的逻辑组成，是分块实现“功能类”及“非功能类”需求的工具。
其实，对照英文的feature和function之间的差异，会更容易理解它们的区别，如图4所示。
图4 特性（feature）与功能（function）的关系
3.1.2 特性的类别
我们所说的产品级的“系统需求”，就是将外部需求转化为以各个特性实现为目标的所有的需求文档组合，特性可以理解为一个找到系统需求的工具，如图5所示。
图5 外部需求通过特性转化为“系统需求”
这里的系统需求已经进入到工程层面了，类别上可以按底层、应用层和其他来区分。
(1) 底层
包括COM（通信）、故障处理、电源供应、刷新、休眠启动等，相对底层，更接近硬件，变量不大。
(2) 应用层
或者那些导航、胎压监测、发动机进气控制、车灯调节、充电控制之类应用层的部分，个性化与项目属性较强，有很多变体，多数项目是衍生于应用层功能的变化、组合。
(3) 其他
可以将一些存储、加密、负载、耐久、响应时间的非功能需求作为特性拆分。此外，其他一些不容易区分的工程需求，也姑且归为此类，比如，车机现在是汽车软件的热点，UI/UE这类传统汽车不常见的需求，也需要纳入管理。
3.1.3 特性拆分的思路
特性的拆分方式取决于产品的特点、架构、适用对象及组织职责的划分等多方面。实际项目中的方式千差万别，毕竟软件的混沌让特性想拆分的初衷不那么容易实现。不像是机械产品，按照BOM去拆分一个个零部件，基本是清清爽爽的。
总之，大的原则是，系统视角下，尽量不出现责任划分不清楚的地带和每一部分都有人负责，即不重叠、不遗漏，如图6所示。
图6 基于特性分解的“系统需求”示意图
3.1.4 特性拆分的责任人
实际上，我们这里忽略了一个重大的现实问题，就是第2节收集的那些散乱的需求显然不是按照特性清单（feature list）一个一个排布的，谁去做这个分解呢？
一般来说，可由系统工程师或担当类似职能的项目经理等技术统筹角色，来进行初步的拆分，并根据文档大部分内容涉及职能和约定俗成的惯例，来划分到各个相对更专业的职能角色上，然后完成团队评审。
常见的是，系统工程师整体负责，由软件、硬件、测试或特定特性负责人等进行支持。这一步的完成会让我们得到产品级的“系统需求”，这也算是从“管理”走向“工程”的一个标志。
另外，在整个过程中，要有一个至关重要的理念——系统“黑箱”（在其他层次的需求分析上，也应秉持），就是说我们不去探究系统内部的结构，不去思考特性与软硬实体的映射关系，否则，就进入设计的范畴了。
3.2 源自FMEA、功能安全、预期功能安全及网络安全的需求的分解
对于涉及FMEA及这3类安全的模块，需要从另外的路径分析、分解，并导入到产品开发需求中，比如，把这些作为外部需求，先按照上一步的思路将其转化为产品级系统需求后，再进入开发系统。不过，由于这一部分有一整块的知识体系，我们这里只留一个接口，详细内容会在原书展开。
3.3 从“系统需求”进一步分解为“软件（组件）需求”
一个系统级的需求还需要被分解，我们分别从“为什么”和“怎么做”展开。
3.3.1 为什么要分解？
可以从两个层面来看。
(1) “系统需求”的实现需要不同学科知识
第一，汽车软件产品往往是机电软硬多学科一体化的系统，而系统级的需求通常就得需要这不同领域共同实现。不分解、不拆分，则具备完全不同知识、经验的不同领域的工程师无法执行，比如，让一个软件工程师通过代码去处理发动机喷油量执行层面的精准，显然是做不到的。
(2) 同一学科需要分工协作
第二，即便是同一学科领域，该领域也将会是一个次级系统，无论是出于内部精细化管理，还是供应链分工的原因，这个次一级的系统有时仍然有必要再进行分解，尤其是对于复杂系统的软件部分，可能需要进一步拆分为组件。毕竟，万丈高楼平地起，一个完整的软件是一个一个代码单元集成而来的。
3.3.2 怎么分解？
对应两个原因，我们可以引出分解各领域需求的两个依次递进的方法，以软件为主要讨论对象。
(1) 分解为“软件需求”
第一，在系统级需求上识别与整体软件相关的部分，这部分可以作为“软件需求”，即将整个软件作为“黑盒子”。而4.4小节所讲的“系统元素”设计也类似于“系统需求”，有时会被部分分解为“软件需求”。
(2) 分解为“软件组件需求”
第二，对识别出来的“软件需求”进一步按其内部组件的划分方式，去分解而形成“软件组件需求”，即将软件组件作为“黑盒子”。同样的，原书4.4小节所讲的“软件架构”设计，也会被部分分解为“软件组件需求”。
总结下，“软件需求”是系统需求或系统元素设计中涉及软件的需求。“软件组件需求”是对“软件需求”的进一步分解和基于“软件架构”的设计而生成的合集。其中，基于“软件架构”的设计而生成的意思是，“软件组件需求”要定义某一个组件必须做些什么事，以让相关组件能够达成预期目标，即组件的交互，也包含接口，这显然取决于“软件架构”。如图7所示。
图7 “系统需求”进一步分解为“软件（组件）需求”
3.4 需求的文档化
尽管做文档工作总是让人诟病，但我们似乎找不到一种别的办法来代替。
或许一些数字化工具可以在一定程度上改变其形式并降低工作量，比如，将一部分需求以工具系统里的字段来表示，不再使用传统意义的office文档，或者基于模型开发的模型也是一种需求的形式。
然而，无论哪种模式都是有一定的局限性的，对外沟通、对内沟通、信息传递、知识积累、使用成本等都有不同的需求，我们终归无法离开落于纸面上的文字。
在这里，我们暂不纠结其承载形式。快速关注一下，当需求被文档化时，要考虑哪些因素。
3.4.1 需求撰写的底层逻辑——条目化
饭要一口一口吃，事要一件一件办。需求撰写的底层方式其实就是“条目化”，所以，应将需求条目化为单一“原子级”的颗粒度（需求向不同性质的下一级分解不属此类），而不能通过“和”、“或”之类的词汇汇总多条需求，然后再一条一条地分析和满足。
比如，传感器识别到异常信号后需要触发DTC并发出警示音，这时拆成“什么情况下触发DTC”和“收到DTC发出警示音”会更清晰。
3.4.2 需求的具体信息或属性
当我们真正开始敲打键盘写字了，需求该包含什么？如图8所示。
图8 一条需求所包含的4条基本信息
(1) 需求自身描述
一条需求本身的文字性描述自然是最主体的信息，我们推荐一个基本语法结构作为参考。
即“在什么前提条件（逻辑条件或事件发生或时间段）下，什么系统（或组件）必须（或应该或将会，英文中常分别用具备法律强制意义的shall、可以有争论空间的should及一般性描述的will来对应）能够（或通过什么流程）实现什么目标以及其他细节”。这会反映出前提、主体、强制性、方式及目标这些基本信息。如图9所示。
图9 需求描述的典型形式
(2) 需求ID
每一条内容最好编一个号，有一个对应的ID，以便于其在后续的传递。
(3) 需求状态
至少要有需求的状态描述，如“被拒绝”“已批准”“已执行”“已验证”等。这样就很容易跟踪到需求的具体情况。
(4) 需求验证方式
验证的方式也应该被识别出来，比如，需执行测试或者仅仅评审即可。这里不需要设计具体的用例或形式，但要明确其是可验证的。这其实也是V模型的关键点——早期就关注测试，这也成为其与瀑布模型的典型差异。
一个无法被验证的需求将没有存在的意义，比如，通信性能良好（无法验证什么是良好）、车机永远不能黑屏（无法永远测试）、信号延时要经常少于50ms（无法判定多频繁叫经常）。
这4点算是基本要素。基于产品的特点或组织的需要，我们还可以增加其他很多信息，比如，责任人、优先级、功能安全ASIL等级、覆盖范围（需求是否已经被要参考的平台或基础项目执行）、是否涉及软件或算法或硬件（针对系统需求）、涉及哪个软件组件、遗留的开口项、软件释放版本等。
当一整套需求文档完善好了之后，我们的需求分析工作算是初步告一段落。在最终结束前，文档化还有一个简单却容易被忽略的东西，就是版本管理，进一步的就是打基线完成配置管理，详见原书3.7节与3.8节的描述。
4需求实现与测试
在前面，我们站在ECU的视角讨论了“外部需求”“系统需求”“软件需求”和“软件组件需求”。可是，它们该如何在项目里落实呢？比较简单地分两个部分：实现与验证。因为后面小节会详细介绍这两部分，所以这里只进行概述。
4.1 需求实现
我们所有“外部需求”要先按照feature区分的方式，无遗漏地进入“系统需求”，而后“外部需求”就可以暂时搁置。
接着，“系统需求”会分两步走：
一步是分配给包含但不限于“软件需求”的各领域需求，比如，如果要求我们的控制器能够将车速识别到0.1m/s的精度，光将软件的信号分区做细是不够的，传感器硬件首先要能够支撑这样的物理精度。在这一步要保证每一条“系统需求”都要被分配（即追溯的概念）给至少一个领域，或软件，或硬件，或既软件又硬件，以确保“系统需求”没有遗漏。另一步是，基于“系统需求”完成“系统架构”及“系统元素”的设计，比如，基于模型。这一步存在的理由主要在于，我们针对这个系统，需要一个宏观层面的规划、设计、调度，而非只是分配给底层子领域就能自动无缝配合实现。
再看“软件需求”，它也是分两步走：
一步是分配给“软件组件需求”。另一步是，基于“软件需求”完成“软件架构”和基于“软件组件需求”完成“软件组件”的详细设计。
需求实现过程如图10所示。
图10 需求的逐级实现过程
4.2 需求测试
在测试这里，我们还是一层层往下讲，“外部需求”其实属于比较繁杂的一类，未必都能有清晰、具体的验证方式，比如，“市场需求”本就具有一定的主观性，不可能形成规范的验证形式。
工程意义相对比较明确的主要是“整车需求”和“上一级系统需求”，一般是通过整车层面的台架环境测试、整车环境测试、试车场测试、真实路试、产线验证以及整车认证、型式认可（上公告）之类的方式覆盖，未必会直接测试软件，但可能会暴露出软件问题。这个层面的测试接近于我们在原书2.1.1小节提到的“确认”，即预期被满足。下面的其他测试则接近于“验证”，即规范被满足。
“系统需求”自然就是“系统（需求）测试”，注意这里只测试那些不单纯属于软件、硬件的系统需求，因为那些被识别出来的为纯“软件需求”将被“软件（需求）测试”覆盖。接下来，还剩一个“软件组件需求”，理论上，可以对应到“组件测试”，但一般会直接通过“单元测试”验证详细设计而覆盖，如图11所示。
图11 需求的逐级测试过程
5一个具体项目的需求管理
这里让我们从理想走向现实。对于一个具体的、真实的项目，能够且有必要按照以上步骤全面、准确地做完做好的概率趋近于零。按照理论的标准做好需求管理，需要大量的、重复的、持续的文档工作。实际情况几乎必然是会反反复复，会来来回回，会弄错，会扯皮，会没有追溯，会更新不及时，还会有各种各样的个性化操作。
但这不是抱着负面的观点来看待这种现象的，如果不分轻重缓急，每个项目都要精细化地维护需求文档，很有可能造成的结果就是进度的延期、成本的溢出，乃至项目的失败。就像考试里只完美地做了一道题，最终还是不及格。可是，世间最难之事不在于，知不知道完美是什么，而是如何把握分寸。我们进一步做一些思考、探索。
5.1 变更驱动下的90%的项目
多数项目都是衍生项目或变更项目，我们的关注点在变更的那一部分，所以，这时会通过变更请求来驱动后续一系列的工作。在大量的变更项目中，要做好base（参考项目）选择、做好复用分析、做好分支管理，尽量让需求精简，越简洁，越容易成功。
5.2 要区分产品特点
需求做得详略的分寸，一部分取决于产品特点：
对于几乎无功能安全要求无关但关注体验和快速上市的娱乐系统，可以更敏捷、更灵活一些。经过一到两个项目的试探，确定是更详细还是更简略，但最好对需求和测试两端松手的幅度慢一点。底盘、动力等高功能安全等级的模块仍然需要比较严格的需求管控，但由于这类产品的成熟度已经有了相当的积累，更多的精力可放在集成历史经验的平台化的维护处理上。对于分支释放项目，可较大程度地聚焦在变更点触发的这条线上。对于一些域内跨模块或跨域融合的功能系统，要做好接口处需求的澄清与评审，要做好对手件需求的协调，比如，辅助驾驶、动力系统、车身系统、娱乐系统等之间交互信号的对齐。
5.3 灵活追溯
需求管理中最头疼的可能就属于建立各种链接的追溯了，而一个东西只有被用的时候才有价值。追溯就是这样，常常用不到，偶尔要用到却又找不到。
从实用而不是被评审的角度看，建立起追溯意识或许比追溯规整更重要，例如。
在文档里加一句话、加一个标签、加一条变更履历。把相关需要追溯的需求、架构、模型、代码、测试报告放到一个文件夹里。需求系统里加上某个可以定位的字段，比如，系统需求涉及哪个软件组件。工具的自动操作痕迹留存也可以作为一种追溯。或者让每一个特性负责人决定自己的追溯方式......
总之，追溯要有，但不一定都一样。这些灵活的探索或可在敏捷实践里去尝试。
5.4 依赖专家
上面我们给了很多分析思路、方法，但那是学习理解的过程。真正的工程分析是在脑子里进行的，真正在处理一个复杂的新需求时，在工程师的脑子里，不是在对着需求分析原则和checklist来做的，是全方位调动自己的经验、教训、知识来做一个相对主观的判断。所以，一般来说，经过各个领域有经验的专家的评审，是对需求可靠的可靠保证。
5.5 多开会
需求很主要的一块工作在于拉齐理解基准，就是你以为的就是你以为的也是他以为的。定期的需求澄清会多少带一定的强制性，以便让大家面对面来交流理解。这也是一种推动不爱沟通、只爱写邮件的工程师们加强交互的方式。
5.6 数字化的必要性
信息化也好，数字化也罢，整体认可度还是比较低。很多年的行业野蛮生长，让人无法去关注到这些看上去不怎么直接交付价值的东西。当然，很多需求管理的数字化软件也都是被国外巨头把控，高昂的购买费用和持续的license成本也让很多中小企业难以承受。
抛开不够普及背后的原因，实际上，在包含需求管理在内的开发活动中，数字化带来的价值增值是指数级的，数字化是解决重复性、繁杂性需求工作的绝佳手段。但这需要工具开发者和使用者共同摸索，比如，DOORS一直被认为是很重的需求工具，可惜的是，其内部大量的却不为人知的自动化脚本其实是可以帮到很多忙的。
无论如何，工程和管理味道兼备的需求工程（也包含以需求为源头对后续实现与测试的拉动）是一门实践学科，更好的、更合适的方式都是摸索后印证出来的。
6State of the Art
在需求的章节加这么一个主题，或许会让人觉得诧异。确实，它和工程意义上的需求的关系不大，但我们往深了一层理解，工程需求定义的边界是什么呢？主机厂自主地定需求时该定多高？供应商在主机厂需求之外是否还要考虑些什么？
这个在外企常用的概念会引出一个视角。
想了很多种方式，但还是选择将其翻译为“当前技术水平”。
稍微了解下汽车的发展历史就会知道，早期的汽车是如何的古老，时速十几公里，坐不了几个人，没有舒适的座椅，没有安全气囊，没有减震器，更别提什么智能化，价格还贵......但没有人会否认这些先驱产品的伟大，当时的消费者也不会对它们抱太高的期望，因为那就是当时的“当前技术水平”。
这就类似于，在现在，大家不会过高期待一辆车的自动驾驶功能多智能，不会对电动车续航虚标的问题大惊小怪，但会对一辆车发生碰撞事故后可能造成巨大损失有心理预期。
这里面其实涉及两个要点：“心理预期”和“高技术水平”，二者也代表了产品的不同层次。
6.1 心理预期
心理预期指明了，汽车没有绝对安全、没有绝对完美、没有绝对智能，是否“足够”取决于消费者的普遍期待。
一般是所谓的“普遍接受的技术规则”，这些是业内专业人士知道并认为正确的规则，其执行是符合行业或大众预期的，而且它们必须在使用中得到充分证明、广泛传播，并且必须经受住时间的考验。例如，这包括遵守强制性法律要求或非强制性但经过验证的规则、程序或通行做法。
不过，对于汽车而言，即使我们将这些技术规则描述为普遍的，但对于大众而言，仍然有很高的门槛。近两年市面上各种失灵的事故屡见不鲜，孰是孰非，一时难以论定，如果有一定的制度保障，可以将这些内部如EDR或开发数据进行权威公正分析，我们通常至少可以知道以下两个问题的答案：
厂家的产品表现是否符合自身的工程需求？厂家的技术方案是否是业内通行的规范做法？
汽车历史上很多召回事件就是在大规模发酵之后被挖掘出来的。
6.2 高技术水平
说回两个要点的后者，其代表着更高的追求。我们不再满足于追求工程成熟方案，而是更先进的“科学状态”，这描述了最新研究成果认为有效的，但可能尚未在实践中使用的、可公开访问的发现，如论文、专利、报告等。
特别是对于新产品或创新解决方案，以及具有高复杂性的产品，这些可能更加必要。此外，对于具有高危害可能性的新产品，还是应该进行自己的研究，而不是简单符合当前现有技术状态。
文学性语言上，我们可以为这两个要点匹配两个虚一点的词：“与时俱进”和“引领潮流”。
这同时是State of the Art这个概念背后对应的价值。技术研究、产品开发需要至少“与时俱进”，这能让产品不至于被市场直接淘汰；最好是“引领潮流”，这将是卖点、增长点、引爆点。而落后于State of the Art就会没有竞争优势，甚至没有存在的意义。
识别清楚并定义好State of the Art很难，需要技术沉淀，需要创新能力，需要责任担当，但这也是我们将需求拔至商业高度后的核心诉求，而这在智能车时代尤为突出。
原文标题 : 万字长文详解汽车软件需求开发与管理
