本文摘編自《智能汽車電子與軟件：開發(fā)方法、系統(tǒng)集成、流程體系與項(xiàng)目管理》，機(jī)械工業(yè)出版社出版，經(jīng)出版方和作者授權(quán)發(fā)布，轉(zhuǎn)載請(qǐng)標(biāo)明文章來源。

問渠哪得清如許，為有源頭活水來。

需求一定是我們開發(fā)的源頭，甚至是企業(yè)生存的源頭，有需求，才有消費(fèi)，有消費(fèi)，才有盈利。類似地，一旦經(jīng)濟(jì)開始衰退，拉動(dòng)內(nèi)需、刺激消費(fèi)就成為強(qiáng)心針了。

多少扯遠(yuǎn)了，但我想說的是，需求的重要性不可不察。

1一些有關(guān)需求的感觸

作為開發(fā)的出發(fā)點(diǎn)和落腳點(diǎn)，需求引出了很多的思考，也牽絆了太多的感觸。

1.1 不太容易搞明白的需求

簡(jiǎn)單來說，“需求”就是你到底要什么？但想回答這個(gè)問題卻并不簡(jiǎn)單。

在做系統(tǒng)工程師的那些年，也是經(jīng)常被項(xiàng)目經(jīng)理、軟件、算法、硬件、測(cè)試、生產(chǎn)......還有領(lǐng)導(dǎo)，問到這類問題，你到底想要什么，客戶到底想要什么？

多人發(fā)懵并不是偶見的場(chǎng)景，下游客戶不知道自己想要什么，就是我要，系統(tǒng)工程師或需求工程師或產(chǎn)品經(jīng)理等類似角色也常常一樣，不清楚想要什么，客戶要，我也要......所以說啊，需求并不是個(gè)很容易搞清楚的東西。這背后的原因很復(fù)雜，可能會(huì)來自：

描述語(yǔ)言模糊導(dǎo)致理解錯(cuò)誤。需求對(duì)于實(shí)現(xiàn)不完整。需求本身就不可行或不可驗(yàn)。同一需求在不同文檔中描述不一致。提需求的人本身沒想清楚。接需求的人沒有或沒能力聽明白。以為聽明白了但傳遞時(shí)發(fā)現(xiàn)不夠......

舉個(gè)簡(jiǎn)單的例子，客戶說我想加一個(gè)故障碼，這確實(shí)是一個(gè)需求，但如果只是這樣傳遞顯然就會(huì)出現(xiàn)上述情況。

系統(tǒng)工程師會(huì)問加關(guān)于什么故障事件的報(bào)碼、故障碼ID是什么、故障觸發(fā)是否要激活警示燈、故障是否可清除；軟件工程師會(huì)問達(dá)到什么樣的限值觸發(fā)、故障監(jiān)測(cè)周期是多長(zhǎng)時(shí)間、觸發(fā)后如何在內(nèi)存中記錄。

無(wú)論哪個(gè)環(huán)節(jié)沒有弄明白或弄錯(cuò)了，需求的收集、分析、傳遞、理解就會(huì)出現(xiàn)問題。

當(dāng)然，并非要求下游客戶把需求的所有細(xì)節(jié)都講明白，否則客戶自己做就好了，要供應(yīng)商做的意義就減弱了。

所以，在現(xiàn)實(shí)中，下游客戶確實(shí)沒精力、沒能力把自己的需求講得明明白白，要靠上游來澄清。這似乎是個(gè)悖論，怎么提需求一方反倒需要實(shí)現(xiàn)方來講明白需求。

但是，這確實(shí)是一直以來很多OEM與Tier 1的合作模式，OEM很多時(shí)候只給出來一個(gè)模棱兩可的感覺，Tier 1依靠自己的經(jīng)驗(yàn)儲(chǔ)備來告訴OEM你需要什么，并給出推薦方案，OEM無(wú)奈地、稀里糊涂地買著黑盒子。

不過，時(shí)代在變化，OEM也在逐漸深入底層。

1.2 需求值得反復(fù)澄清

還有個(gè)感觸是從管理角度談的，需求非常值得反復(fù)溝通、反復(fù)確認(rèn)、反復(fù)澄清。當(dāng)你覺得對(duì)方的文檔是模棱兩可的或者說的話是有些支支吾吾的，就一定要搞清楚，非常具體地反問，還要用自己的話來描述自己的理解，并寫下來，確保萬(wàn)無(wú)一失。

在實(shí)際經(jīng)驗(yàn)中，能夠清清楚楚地感受到，“墨菲定律”在需求分析中體現(xiàn)得淋漓盡致，覺得可能錯(cuò)，大概率會(huì)錯(cuò)。有個(gè)統(tǒng)計(jì)數(shù)據(jù)是，需求問題會(huì)導(dǎo)致大約40%的軟件bug�？梢�，這種錯(cuò)誤是具有相當(dāng)普遍性的。

我有個(gè)有趣的經(jīng)歷。

之前在對(duì)一個(gè)改款項(xiàng)目進(jìn)行報(bào)價(jià)評(píng)估時(shí)，銷售說的是，這個(gè)項(xiàng)目與上一個(gè)項(xiàng)目基本一樣，工程團(tuán)隊(duì)不必花太多時(shí)間分析，快速參考一下給出成本即可，我們報(bào)價(jià)時(shí)間非常緊張。

聽起來，這個(gè)需求很直白、很明確，而且還讓銷售提供了客戶類似描述的郵件，再加上這個(gè)階段也沒有太多的細(xì)節(jié)可以參考了。按理說，可以寫清楚報(bào)價(jià)背景后直接報(bào)價(jià)了。

不過，出于工程師對(duì)虛詞的敏感，輕輕的“基本”這倆字雖然隱藏在一大堆其他信息里，卻依然刺耳地送進(jìn)了我的耳朵里。至少是考慮到我的工作不返工，我順著這個(gè)“基本”追根究底下去，發(fā)現(xiàn)這個(gè)“基本”是指改某個(gè)標(biāo)定參數(shù)，以往常的經(jīng)驗(yàn)，這個(gè)參數(shù)確實(shí)夠“基本”，但恰好最近發(fā)現(xiàn)了一個(gè)嚴(yán)重bug和這個(gè)標(biāo)定值有關(guān)系，這就涉及一系列的bug修復(fù)、回歸驗(yàn)證、版本升級(jí)等工作，相關(guān)的成本與周期自然不是那么“基本”一樣的。

1.3 需求在性質(zhì)上的維度

往大了說，需求無(wú)所不包，各個(gè)干系人或者叫相關(guān)方期望的一切東西都能稱之為需求，有關(guān)注產(chǎn)品的、有關(guān)注營(yíng)銷的、有關(guān)注錢的、有關(guān)注時(shí)間的、有關(guān)注過程的、有關(guān)注交付的、有關(guān)注生產(chǎn)的......

為了能說明白，我們還是往小了說，從工程的視角看，我們的需求可以粗略分為“非技術(shù)類”和“技術(shù)類”。如圖1所示。

圖1 需求的簡(jiǎn)單分類

1.3.1 非技術(shù)類

那些營(yíng)銷、錢、時(shí)間、過程、交付、生產(chǎn)就是典型的“非技術(shù)類”，這部分我們不做展開。

這里提另一個(gè)非常關(guān)鍵的非技術(shù)類需求——體驗(yàn)感。我們都知道，用戶購(gòu)車的訴求已經(jīng)有了很大的變化，汽車基本素質(zhì)已經(jīng)被普遍實(shí)現(xiàn)，血紅的汽車市場(chǎng)讓人挑得眼睛都花了，于是，最能吸引早就沒有耐心的大家的，就是那種直給的“爽”點(diǎn)，這可能是來自品牌信仰，可能是源于情懷，可能就是說不出來的感覺很好。姑且可以將這類顯得有些細(xì)碎、玄虛的東西稱為體驗(yàn)感。

為了更容易理解，舉個(gè)自己印象比較深刻的例子。

去年夏天，天氣悶熱，于是，在網(wǎng)上買了一臺(tái)某互聯(lián)網(wǎng)性質(zhì)公司的落地扇。送貨上門，拆開有些破損的快遞公司外包裝盒......哎，眼前倒是一亮，映入眼睛的是包裝緊致、塑封完好的外箱，與快遞外盒有明顯反差。以前習(xí)慣于暴力扯開，一腳踩扁后，然后扔到車庫(kù)讓老人賣舊紙箱子，現(xiàn)在倒有點(diǎn)舍不得破壞了。

接著，想想剪刀放在哪里了，準(zhǔn)備拆箱......不至于吧，封口膠帶用了有些類似于快遞文件信封的方式，就是可以直接手動(dòng)撕開，但是，我喜歡。

這個(gè)落地扇是屬于可拆卸式的，需要把各大零件組裝起來，雖然作為理工男還算喜歡組裝，但還是得找說明指導(dǎo)。說明書有的，可懶得看，因?yàn)榉饷嬗袀�(gè)可查看組裝視頻的二維碼。

組裝視頻分多個(gè)，每個(gè)視頻都是一個(gè)環(huán)節(jié)的說明或者組裝步驟，畫面上有重復(fù)播放和下一個(gè)的按鈕，這就不用我反復(fù)地暫�；蛲蟿�(dòng)進(jìn)度條來回看了。首先是解說和動(dòng)效同步的零件清點(diǎn)，說到具體對(duì)象，會(huì)指引位置并放大顯示，幾大部分很容易看得出來。隨后是各個(gè)組裝步驟，零件上清晰的方向標(biāo)識(shí)與物理防錯(cuò)都讓我非常便捷地組裝起來，很多環(huán)節(jié)甚至不需要看視頻，憑直覺就可以。各種螺釘和小扳手都附帶好了，顯然也都是經(jīng)過琢磨的，扳手形狀與尺寸能很好地與對(duì)應(yīng)操作空間適配......

很快就裝好了，取出電源包裝盒，意料之內(nèi)，封口膠帶前端留了一點(diǎn)免粘的部分，不用費(fèi)力地拿指甲摳了。插上風(fēng)扇，慵懶地躺在沙發(fā)上，不知道是不是風(fēng)夠涼，但那個(gè)炎熱的午后，我的心情是有點(diǎn)清爽......

幾百塊錢的小家電，并不具備多么艱深的技術(shù)壁壘，但卻把用戶體驗(yàn)做到了極致，我想，這也是我能在落地扇這里感受到的最大尊重了。

這種常常被汽車工程師忽略的細(xì)碎體驗(yàn)感的東西，包含的不僅僅是常規(guī)意義的工程及工業(yè)設(shè)計(jì)，還有很多美學(xué)、心理學(xué)、社會(huì)學(xué)等各方面的維度。尤其在座艙、智駕這類領(lǐng)域，體驗(yàn)感以及由此而來的用戶時(shí)間與注意力占用是非常關(guān)鍵的評(píng)價(jià)要素，值得我們關(guān)注，也值得我們擴(kuò)充對(duì)需求內(nèi)涵的理解。

1.3.2 技術(shù)類

無(wú)論如何，很大一部分的“非技術(shù)類”還是需要落地在“技術(shù)類”之上，才能在產(chǎn)品上得到體現(xiàn)。“技術(shù)類”還會(huì)分為兩大種：功能類和非功能類。

(1) 功能類

功能類是基本的、直觀的、上層的，定義了產(chǎn)品能做什么，比如，前面講的那個(gè)旋鈕能控制車速。

(2) 非功能類

非功能類是相對(duì)抽象的、底層的，比如，那個(gè)旋鈕的直徑不能超過15mm、耐久性要達(dá)到30萬(wàn)次、速度信號(hào)錯(cuò)誤的功能安全等級(jí)要達(dá)到ASIL D、發(fā)送信號(hào)的周期10ms、能夠診斷針腳短路報(bào)故障碼、硬件限制而讓傳感器的加速度信號(hào)范圍不能超過正負(fù)100g等。

實(shí)際上，自然是無(wú)法區(qū)分得那么清楚。基本上越接近終端用戶直接價(jià)值感知的越屬于功能類，即用戶場(chǎng)景或用戶故事，越接近開發(fā)底層的越屬于非功能類。功能類需求的滿足是讓客戶一次滿意的關(guān)鍵，非功能類需求的滿足則是要讓客戶持續(xù)滿意。

2需求收集與整理

我們是站在一個(gè)類似于ECU這種軟硬一體產(chǎn)品的視角的，這個(gè)整車架構(gòu)下的子系統(tǒng)是我們要開發(fā)和交付的范圍。所以，在開始之前，我們需要收集這個(gè)范圍之外一切或粗或細(xì)的相關(guān)方需求，然后在里面去偽存真，抽取出我們所需要的。

2.1 外部需求收集

一般可能會(huì)涉及法律法規(guī)、行業(yè)標(biāo)準(zhǔn)、市場(chǎng)趨勢(shì)、整車需求、上一級(jí)系統(tǒng)需求、內(nèi)部需求及項(xiàng)目需求，如圖2所示，我們一個(gè)一個(gè)來看。

圖2 外部需求來源

2.1.1 法律法規(guī)

這個(gè)道理是比較容易理解的，我們不能違法，對(duì)應(yīng)來說就是強(qiáng)制性標(biāo)準(zhǔn)。不過，行業(yè)并非剛剛起步，像排放、安全等大量相關(guān)的成熟法律法規(guī)已經(jīng)沉淀到了產(chǎn)品設(shè)計(jì)規(guī)范里，不用每一個(gè)車型都去做這么一件事。

在這里需要特別關(guān)注的有兩個(gè)方面：

第一，最近幾年電動(dòng)車、數(shù)據(jù)安全、網(wǎng)絡(luò)安全、自動(dòng)駕駛、OTA、EDR（Event Data Recorder，事件數(shù)據(jù)記錄系統(tǒng)，即汽車“黑匣子”）等新事物的興起必然會(huì)帶動(dòng)一些國(guó)家法規(guī)的出臺(tái)，需要實(shí)時(shí)關(guān)注。第二，無(wú)論是整車還是零部件經(jīng)常會(huì)涉及出口海外，除了歐盟、北美有些比較知名的準(zhǔn)入要求，其他地方也需要給予關(guān)注，比如，一些政治制裁國(guó)家。這部分大家往往經(jīng)驗(yàn)較少，有可能會(huì)識(shí)別不到。

2.1.2 行業(yè)標(biāo)準(zhǔn)

這里指的是推薦性標(biāo)準(zhǔn)，就是你做也行，不做也沒關(guān)系，至少是沒有誰(shuí)會(huì)直接懲罰你。但是，為什么要說隔行如隔山？很多時(shí)候隔的就是對(duì)行標(biāo)的認(rèn)識(shí)。接著前面一句話的描述，盡管你不做沒人懲罰，但你可能會(huì)失去市場(chǎng)或者無(wú)法和別人兼容。

比如，大家都去做的NCAP（New Car Assessment Program，新車評(píng)估項(xiàng)目，也即新車碰撞測(cè)試）評(píng)星，這個(gè)不是強(qiáng)制的，但市場(chǎng)認(rèn)，你基本也會(huì)去做。再比如，UDS（Unified Diagnostic Services，統(tǒng)一診斷服務(wù)，即標(biāo)準(zhǔn)ISO 14229）協(xié)議也不是法規(guī)，但大家都這么做，你沒必要也基本沒能力重新開發(fā)一套。

2.1.3 市場(chǎng)趨勢(shì)

尤其是這幾年的混戰(zhàn)期，市場(chǎng)方向的把握十分重要，將市場(chǎng)趨勢(shì)融合成需求顯然也十分重要，但是，優(yōu)秀的汽車大產(chǎn)品經(jīng)理太少了。

能夠落地一點(diǎn)的是，收集對(duì)標(biāo)企業(yè)的需求或者拆解對(duì)標(biāo)企業(yè)的車型或產(chǎn)品，以明確自己的方向。其中，在平臺(tái)化產(chǎn)品線的開發(fā)時(shí)，考慮好這部分尤為重要，否則，后續(xù)一系列衍生項(xiàng)目都將面臨失敗。

2.1.4 整車需求

無(wú)論是零部件廠商，還是主機(jī)廠內(nèi)部自研部門，它們都要面對(duì)整車需求，一些整車3D布置、風(fēng)阻、鹽霧、耐久、操縱穩(wěn)定性、動(dòng)力性、NVH、碰撞等要求離軟件遠(yuǎn)了點(diǎn)，一般無(wú)法直接對(duì)應(yīng)，我們直接跳過。

能夠影響到軟件開發(fā)的整車需求，可能會(huì)有EEA、通信矩陣、診斷規(guī)范、刷寫規(guī)范、ICD（Interface Control Document，接口控制文檔）協(xié)議、功能安全需求、網(wǎng)絡(luò)安全需求等各種通用性的標(biāo)準(zhǔn)，也就是所有電子軟件模塊共同遵循的。

2.1.5 上一級(jí)系統(tǒng)需求

由于系統(tǒng)是一個(gè)可不斷被拆分的概念，我們一個(gè)ECU是一個(gè)系統(tǒng)，往上一層ECU協(xié)同傳感器、執(zhí)行器也會(huì)組成一個(gè)系統(tǒng)，比如，車燈控制ECU和整個(gè)車燈系統(tǒng)的概念，或者安全氣囊ECU和被動(dòng)安全系統(tǒng)的概念。

控制器及其中的軟件是要滿足其上一級(jí)系統(tǒng)的需求。這部分的需求就會(huì)具體很多、貼近產(chǎn)品很多，比如，對(duì)于車燈系統(tǒng)而言，根據(jù)彎道路況和特定車速來自動(dòng)調(diào)整車燈的照明方向，可能就是它給車燈ECU的一條需求。

2.1.6 內(nèi)部需求

這里的內(nèi)部不是指ECU內(nèi)部，是指組織內(nèi)部。有一些大一點(diǎn)的企業(yè)，出于成本、合規(guī)、歷史經(jīng)驗(yàn)、安全余量、魯棒性等的考慮，會(huì)有一些內(nèi)部的設(shè)計(jì)準(zhǔn)則來限定產(chǎn)品的設(shè)計(jì)，比如，ECU一般的工作電壓在6.5～16V之間，但可能內(nèi)部設(shè)計(jì)準(zhǔn)則是3～20V都要能正常工作。

此外，有時(shí)候也會(huì)有一些特殊的測(cè)試需求或者生產(chǎn)需求，它們也會(huì)影響到產(chǎn)品開發(fā)。

2.1.7 項(xiàng)目需求

其實(shí)，最后一個(gè)項(xiàng)目需求和前6個(gè)是不屬于同一個(gè)邏輯層次的，這里是針對(duì)特定項(xiàng)目的特定需求而言的，基本是被包含于前6個(gè)的范圍之內(nèi)。我們?nèi)粘５捻?xiàng)目更多是基于某個(gè)前序項(xiàng)目的變更，更多是直接處理這一概念的需求，而不會(huì)那么全面地梳理完整的需求。這就是在這里把它單獨(dú)拿出來的原因。

總之，收集好以上內(nèi)容，大體就獲取到了我們汽車軟件產(chǎn)品所要面臨的外部需求。

2.2 外部需求整理

那么，這時(shí)的需求長(zhǎng)成什么樣子呢？一般是一份份Excel、Word、PPT、PDF之類的文檔，也有可能是不那么規(guī)范的郵件。

這就讓我們現(xiàn)在至少面臨兩個(gè)問題：

一是，大量和自身不相干的需求。比如，一本上百頁(yè)的ECU規(guī)范里涉及自己產(chǎn)品的不足10頁(yè)。二是，這些需求比較凌亂。在實(shí)際工作中，這些需求可能是在時(shí)間倉(cāng)促的報(bào)價(jià)定點(diǎn)期間臨時(shí)獲取的，又或者是隨著開發(fā)的要求不斷要到的。這種情況下，版本老舊、內(nèi)容錯(cuò)誤、標(biāo)準(zhǔn)遺漏都是可能發(fā)生的。

所以，在這里，最好做一件事情，就是對(duì)這些文檔進(jìn)行梳理，梳理點(diǎn)可能會(huì)涉及如下方面。

文檔是不是完整？哪個(gè)是最新的版本？是不是有重復(fù)的文檔？是否有一些容易誤解的地方待澄清？有沒有與本項(xiàng)目不相關(guān)的信息？能不能整理出規(guī)范文檔？某些文檔是不是項(xiàng)目早期已經(jīng)明確拒絕的......

初步確認(rèn)出來可用的部分，而后可以形成一個(gè)匯總表，包含名稱、版本、來源人、釋放日期及存檔位置等。這份匯總后的原始需求列表其實(shí)可以作為一個(gè)配置項(xiàng)來進(jìn)行的管理的，其也可以為下一階段工作提供一個(gè)清爽、完整的輸入。

3需求分析與分解

在拿到這一攬子外部需求后，即便能夠制作一個(gè)清晰的需求列表，顆粒度依然不足以直接用于開發(fā)。我們需要進(jìn)一步地分析，并在我們產(chǎn)品級(jí)系統(tǒng)的范圍內(nèi)分解，如圖3所示。

圖3 需求分析與分解的思路

3.1 基于特性（feature）分解定義產(chǎn)品級(jí)“系統(tǒng)需求”

特性是業(yè)內(nèi)習(xí)慣稱呼的一個(gè)詞。通常，我們會(huì)用它作為牽引來分解、定義產(chǎn)品級(jí)系統(tǒng)需求，但其含義多少有些含糊，有必要先來辨析一下。

3.1.1 特性與功能

特性是一個(gè)相對(duì)小但具備一定完整性的“模塊”，其中可能只涉及軟件，但也可能同時(shí)涉及硬件，一般可以被劃歸到一個(gè)責(zé)任人來負(fù)責(zé)，從需求管到驗(yàn)證確認(rèn)，即特性負(fù)責(zé)人（feature owner）。

稍微注意一點(diǎn)，這里的“特性”要和前面“功能類”需求描述的“功能”有些許區(qū)分，前面?zhèn)戎氐氖敲枋鲂缘墓δ苓壿嫼陀脩魞r(jià)值，這里側(cè)重的是系統(tǒng)這個(gè)“黑箱”的邏輯組成，是分塊實(shí)現(xiàn)“功能類”及“非功能類”需求的工具。

其實(shí)，對(duì)照英文的feature和function之間的差異，會(huì)更容易理解它們的區(qū)別，如圖4所示。

 圖4 特性（feature）與功能（function）的關(guān)系

3.1.2 特性的類別

我們所說的產(chǎn)品級(jí)的“系統(tǒng)需求”，就是將外部需求轉(zhuǎn)化為以各個(gè)特性實(shí)現(xiàn)為目標(biāo)的所有的需求文檔組合，特性可以理解為一個(gè)找到系統(tǒng)需求的工具，如圖5所示。

圖5 外部需求通過特性轉(zhuǎn)化為“系統(tǒng)需求”

這里的系統(tǒng)需求已經(jīng)進(jìn)入到工程層面了，類別上可以按底層、應(yīng)用層和其他來區(qū)分。

(1) 底層

包括COM（通信）、故障處理、電源供應(yīng)、刷新、休眠啟動(dòng)等，相對(duì)底層，更接近硬件，變量不大。

(2) 應(yīng)用層

或者那些導(dǎo)航、胎壓監(jiān)測(cè)、發(fā)動(dòng)機(jī)進(jìn)氣控制、車燈調(diào)節(jié)、充電控制之類應(yīng)用層的部分，個(gè)性化與項(xiàng)目屬性較強(qiáng)，有很多變體，多數(shù)項(xiàng)目是衍生于應(yīng)用層功能的變化、組合。

(3) 其他

可以將一些存儲(chǔ)、加密、負(fù)載、耐久、響應(yīng)時(shí)間的非功能需求作為特性拆分。此外，其他一些不容易區(qū)分的工程需求，也姑且歸為此類，比如，車機(jī)現(xiàn)在是汽車軟件的熱點(diǎn)，UI/UE這類傳統(tǒng)汽車不常見的需求，也需要納入管理。

3.1.3 特性拆分的思路

特性的拆分方式取決于產(chǎn)品的特點(diǎn)、架構(gòu)、適用對(duì)象及組織職責(zé)的劃分等多方面。實(shí)際項(xiàng)目中的方式千差萬(wàn)別，畢竟軟件的混沌讓特性想拆分的初衷不那么容易實(shí)現(xiàn)。不像是機(jī)械產(chǎn)品，按照BOM去拆分一個(gè)個(gè)零部件，基本是清清爽爽的。

總之，大的原則是，系統(tǒng)視角下，盡量不出現(xiàn)責(zé)任劃分不清楚的地帶和每一部分都有人負(fù)責(zé)，即不重疊、不遺漏，如圖6所示。

 圖6 基于特性分解的“系統(tǒng)需求”示意圖

3.1.4 特性拆分的責(zé)任人

實(shí)際上，我們這里忽略了一個(gè)重大的現(xiàn)實(shí)問題，就是第2節(jié)收集的那些散亂的需求顯然不是按照特性清單（feature list）一個(gè)一個(gè)排布的，誰(shuí)去做這個(gè)分解呢？

一般來說，可由系統(tǒng)工程師或擔(dān)當(dāng)類似職能的項(xiàng)目經(jīng)理等技術(shù)統(tǒng)籌角色，來進(jìn)行初步的拆分，并根據(jù)文檔大部分內(nèi)容涉及職能和約定俗成的慣例，來劃分到各個(gè)相對(duì)更專業(yè)的職能角色上，然后完成團(tuán)隊(duì)評(píng)審。

常見的是，系統(tǒng)工程師整體負(fù)責(zé)，由軟件、硬件、測(cè)試或特定特性負(fù)責(zé)人等進(jìn)行支持。這一步的完成會(huì)讓我們得到產(chǎn)品級(jí)的“系統(tǒng)需求”，這也算是從“管理”走向“工程”的一個(gè)標(biāo)志。

另外，在整個(gè)過程中，要有一個(gè)至關(guān)重要的理念——系統(tǒng)“黑箱”（在其他層次的需求分析上，也應(yīng)秉持），就是說我們不去探究系統(tǒng)內(nèi)部的結(jié)構(gòu)，不去思考特性與軟硬實(shí)體的映射關(guān)系，否則，就進(jìn)入設(shè)計(jì)的范疇了。

3.2 源自FMEA、功能安全、預(yù)期功能安全及網(wǎng)絡(luò)安全的需求的分解

對(duì)于涉及FMEA及這3類安全的模塊，需要從另外的路徑分析、分解，并導(dǎo)入到產(chǎn)品開發(fā)需求中，比如，把這些作為外部需求，先按照上一步的思路將其轉(zhuǎn)化為產(chǎn)品級(jí)系統(tǒng)需求后，再進(jìn)入開發(fā)系統(tǒng)。不過，由于這一部分有一整塊的知識(shí)體系，我們這里只留一個(gè)接口，詳細(xì)內(nèi)容會(huì)在原書展開。

3.3 從“系統(tǒng)需求”進(jìn)一步分解為“軟件（組件）需求”

一個(gè)系統(tǒng)級(jí)的需求還需要被分解，我們分別從“為什么”和“怎么做”展開。

3.3.1 為什么要分解？

可以從兩個(gè)層面來看。

(1) “系統(tǒng)需求”的實(shí)現(xiàn)需要不同學(xué)科知識(shí)

第一，汽車軟件產(chǎn)品往往是機(jī)電軟硬多學(xué)科一體化的系統(tǒng)，而系統(tǒng)級(jí)的需求通常就得需要這不同領(lǐng)域共同實(shí)現(xiàn)。不分解、不拆分，則具備完全不同知識(shí)、經(jīng)驗(yàn)的不同領(lǐng)域的工程師無(wú)法執(zhí)行，比如，讓一個(gè)軟件工程師通過代碼去處理發(fā)動(dòng)機(jī)噴油量執(zhí)行層面的精準(zhǔn)，顯然是做不到的。

(2) 同一學(xué)科需要分工協(xié)作

第二，即便是同一學(xué)科領(lǐng)域，該領(lǐng)域也將會(huì)是一個(gè)次級(jí)系統(tǒng)，無(wú)論是出于內(nèi)部精細(xì)化管理，還是供應(yīng)鏈分工的原因，這個(gè)次一級(jí)的系統(tǒng)有時(shí)仍然有必要再進(jìn)行分解，尤其是對(duì)于復(fù)雜系統(tǒng)的軟件部分，可能需要進(jìn)一步拆分為組件。畢竟，萬(wàn)丈高樓平地起，一個(gè)完整的軟件是一個(gè)一個(gè)代碼單元集成而來的。

3.3.2 怎么分解？

對(duì)應(yīng)兩個(gè)原因，我們可以引出分解各領(lǐng)域需求的兩個(gè)依次遞進(jìn)的方法，以軟件為主要討論對(duì)象。

(1) 分解為“軟件需求”

第一，在系統(tǒng)級(jí)需求上識(shí)別與整體軟件相關(guān)的部分，這部分可以作為“軟件需求”，即將整個(gè)軟件作為“黑盒子”。而4.4小節(jié)所講的“系統(tǒng)元素”設(shè)計(jì)也類似于“系統(tǒng)需求”，有時(shí)會(huì)被部分分解為“軟件需求”。

(2) 分解為“軟件組件需求”

第二，對(duì)識(shí)別出來的“軟件需求”進(jìn)一步按其內(nèi)部組件的劃分方式，去分解而形成“軟件組件需求”，即將軟件組件作為“黑盒子”。同樣的，原書4.4小節(jié)所講的“軟件架構(gòu)”設(shè)計(jì)，也會(huì)被部分分解為“軟件組件需求”。

總結(jié)下，“軟件需求”是系統(tǒng)需求或系統(tǒng)元素設(shè)計(jì)中涉及軟件的需求。“軟件組件需求”是對(duì)“軟件需求”的進(jìn)一步分解和基于“軟件架構(gòu)”的設(shè)計(jì)而生成的合集。其中，基于“軟件架構(gòu)”的設(shè)計(jì)而生成的意思是，“軟件組件需求”要定義某一個(gè)組件必須做些什么事，以讓相關(guān)組件能夠達(dá)成預(yù)期目標(biāo)，即組件的交互，也包含接口，這顯然取決于“軟件架構(gòu)”。如圖7所示。

圖7 “系統(tǒng)需求”進(jìn)一步分解為“軟件（組件）需求”

3.4 需求的文檔化

盡管做文檔工作總是讓人詬病，但我們似乎找不到一種別的辦法來代替。

或許一些數(shù)字化工具可以在一定程度上改變其形式并降低工作量，比如，將一部分需求以工具系統(tǒng)里的字段來表示，不再使用傳統(tǒng)意義的office文檔，或者基于模型開發(fā)的模型也是一種需求的形式。

然而，無(wú)論哪種模式都是有一定的局限性的，對(duì)外溝通、對(duì)內(nèi)溝通、信息傳遞、知識(shí)積累、使用成本等都有不同的需求，我們終歸無(wú)法離開落于紙面上的文字。

在這里，我們暫不糾結(jié)其承載形式�？焖訇P(guān)注一下，當(dāng)需求被文檔化時(shí)，要考慮哪些因素。

3.4.1 需求撰寫的底層邏輯——條目化

飯要一口一口吃，事要一件一件辦。需求撰寫的底層方式其實(shí)就是“條目化”，所以，應(yīng)將需求條目化為單一“原子級(jí)”的顆粒度（需求向不同性質(zhì)的下一級(jí)分解不屬此類），而不能通過“和”、“或”之類的詞匯匯總多條需求，然后再一條一條地分析和滿足。

比如，傳感器識(shí)別到異常信號(hào)后需要觸發(fā)DTC并發(fā)出警示音，這時(shí)拆成“什么情況下觸發(fā)DTC”和“收到DTC發(fā)出警示音”會(huì)更清晰。

3.4.2 需求的具體信息或?qū)傩?/p>

當(dāng)我們真正開始敲打鍵盤寫字了，需求該包含什么？如圖8所示。

圖8 一條需求所包含的4條基本信息

(1) 需求自身描述

一條需求本身的文字性描述自然是最主體的信息，我們推薦一個(gè)基本語(yǔ)法結(jié)構(gòu)作為參考。

即“在什么前提條件（邏輯條件或事件發(fā)生或時(shí)間段）下，什么系統(tǒng)（或組件）必須（或應(yīng)該或?qū)��?huì)，英文中常分別用具備法律強(qiáng)制意義的shall、可以有爭(zhēng)論空間的should及一般性描述的will來對(duì)應(yīng)）能夠（或通過什么流程）實(shí)現(xiàn)什么目標(biāo)以及其他細(xì)節(jié)”。這會(huì)反映出前提、主體、強(qiáng)制性、方式及目標(biāo)這些基本信息。如圖9所示。

圖9 需求描述的典型形式

(2) 需求ID

每一條內(nèi)容最好編一個(gè)號(hào)，有一個(gè)對(duì)應(yīng)的ID，以便于其在后續(xù)的傳遞。

(3) 需求狀態(tài)

至少要有需求的狀態(tài)描述，如“被拒絕”“已批準(zhǔn)”“已執(zhí)行”“已驗(yàn)證”等。這樣就很容易跟蹤到需求的具體情況。

(4) 需求驗(yàn)證方式

驗(yàn)證的方式也應(yīng)該被識(shí)別出來，比如，需執(zhí)行測(cè)試或者僅僅評(píng)審即可。這里不需要設(shè)計(jì)具體的用例或形式，但要明確其是可驗(yàn)證的。這其實(shí)也是V模型的關(guān)鍵點(diǎn)——早期就關(guān)注測(cè)試，這也成為其與瀑布模型的典型差異。

一個(gè)無(wú)法被驗(yàn)證的需求將沒有存在的意義，比如，通信性能良好（無(wú)法驗(yàn)證什么是良好）、車機(jī)永遠(yuǎn)不能黑屏（無(wú)法永遠(yuǎn)測(cè)試）、信號(hào)延時(shí)要經(jīng)常少于50ms（無(wú)法判定多頻繁叫經(jīng)常）。

這4點(diǎn)算是基本要素�；�于產(chǎn)品的特點(diǎn)或組織的需要，我們還可以增加其他很多信息，比如，責(zé)任人、優(yōu)先級(jí)、功能安全ASIL等級(jí)、覆蓋范圍（需求是否已經(jīng)被要參考的平臺(tái)或基礎(chǔ)項(xiàng)目執(zhí)行）、是否涉及軟件或算法或硬件（針對(duì)系統(tǒng)需求）、涉及哪個(gè)軟件組件、遺留的開口項(xiàng)、軟件釋放版本等。

當(dāng)一整套需求文檔完善好了之后，我們的需求分析工作算是初步告一段落。在最終結(jié)束前，文檔化還有一個(gè)簡(jiǎn)單卻容易被忽略的東西，就是版本管理，進(jìn)一步的就是打基線完成配置管理，詳見原書3.7節(jié)與3.8節(jié)的描述。

4需求實(shí)現(xiàn)與測(cè)試

在前面，我們站在ECU的視角討論了“外部需求”“系統(tǒng)需求”“軟件需求”和“軟件組件需求”�？墒�，它們?cè)撊绾卧陧?xiàng)目里落實(shí)呢？比較簡(jiǎn)單地分兩個(gè)部分：實(shí)現(xiàn)與驗(yàn)證。因?yàn)楹竺嫘」?jié)會(huì)詳細(xì)介紹這兩部分，所以這里只進(jìn)行概述。

4.1 需求實(shí)現(xiàn)

我們所有“外部需求”要先按照feature區(qū)分的方式，無(wú)遺漏地進(jìn)入“系統(tǒng)需求”，而后“外部需求”就可以暫時(shí)擱置。

接著，“系統(tǒng)需求”會(huì)分兩步走：

一步是分配給包含但不限于“軟件需求”的各領(lǐng)域需求，比如，如果要求我們的控制器能夠?qū)④囁僮R(shí)別到0.1m/s的精度，光將軟件的信號(hào)分區(qū)做細(xì)是不夠的，傳感器硬件首先要能夠支撐這樣的物理精度。在這一步要保證每一條“系統(tǒng)需求”都要被分配（即追溯的概念）給至少一個(gè)領(lǐng)域，或軟件，或硬件，或既軟件又硬件，以確保“系統(tǒng)需求”沒有遺漏。另一步是，基于“系統(tǒng)需求”完成“系統(tǒng)架構(gòu)”及“系統(tǒng)元素”的設(shè)計(jì)，比如，基于模型。這一步存在的理由主要在于，我們針對(duì)這個(gè)系統(tǒng)，需要一個(gè)宏觀層面的規(guī)劃、設(shè)計(jì)、調(diào)度，而非只是分配給底層子領(lǐng)域就能自動(dòng)無(wú)縫配合實(shí)現(xiàn)。

再看“軟件需求”，它也是分兩步走：

一步是分配給“軟件組件需求”。另一步是，基于“軟件需求”完成“軟件架構(gòu)”和基于“軟件組件需求”完成“軟件組件”的詳細(xì)設(shè)計(jì)。

需求實(shí)現(xiàn)過程如圖10所示。

圖10 需求的逐級(jí)實(shí)現(xiàn)過程

4.2 需求測(cè)試

在測(cè)試這里，我們還是一層層往下講，“外部需求”其實(shí)屬于比較繁雜的一類，未必都能有清晰、具體的驗(yàn)證方式，比如，“市場(chǎng)需求”本就具有一定的主觀性，不可能形成規(guī)范的驗(yàn)證形式。

工程意義相對(duì)比較明確的主要是“整車需求”和“上一級(jí)系統(tǒng)需求”，一般是通過整車層面的臺(tái)架環(huán)境測(cè)試、整車環(huán)境測(cè)試、試車場(chǎng)測(cè)試、真實(shí)路試、產(chǎn)線驗(yàn)證以及整車認(rèn)證、型式認(rèn)可（上公告）之類的方式覆蓋，未必會(huì)直接測(cè)試軟件，但可能會(huì)暴露出軟件問題。這個(gè)層面的測(cè)試接近于我們?cè)谠瓡?.1.1小節(jié)提到的“確認(rèn)”，即預(yù)期被滿足。下面的其他測(cè)試則接近于“驗(yàn)證”，即規(guī)范被滿足。

“系統(tǒng)需求”自然就是“系統(tǒng)（需求）測(cè)試”，注意這里只測(cè)試那些不單純屬于軟件、硬件的系統(tǒng)需求，因?yàn)槟切┍蛔R(shí)別出來的為純“軟件需求”將被“軟件（需求）測(cè)試”覆蓋。接下來，還剩一個(gè)“軟件組件需求”，理論上，可以對(duì)應(yīng)到“組件測(cè)試”，但一般會(huì)直接通過“單元測(cè)試”驗(yàn)證詳細(xì)設(shè)計(jì)而覆蓋，如圖11所示。

圖11 需求的逐級(jí)測(cè)試過程

5一個(gè)具體項(xiàng)目的需求管理

這里讓我們從理想走向現(xiàn)實(shí)。對(duì)于一個(gè)具體的、真實(shí)的項(xiàng)目，能夠且有必要按照以上步驟全面、準(zhǔn)確地做完做好的概率趨近于零。按照理論的標(biāo)準(zhǔn)做好需求管理，需要大量的、重復(fù)的、持續(xù)的文檔工作。實(shí)際情況幾乎必然是會(huì)反反復(fù)復(fù)，會(huì)來來回回，會(huì)弄錯(cuò)，會(huì)扯皮，會(huì)沒有追溯，會(huì)更新不及時(shí)，還會(huì)有各種各樣的個(gè)性化操作。

但這不是抱著負(fù)面的觀點(diǎn)來看待這種現(xiàn)象的，如果不分輕重緩急，每個(gè)項(xiàng)目都要精細(xì)化地維護(hù)需求文檔，很有可能造成的結(jié)果就是進(jìn)度的延期、成本的溢出，乃至項(xiàng)目的失敗。就像考試?yán)镏煌昝赖刈隽艘坏李}，最終還是不及格�？墒�，世間最難之事不在于，知不知道完美是什么，而是如何把握分寸。我們進(jìn)一步做一些思考、探索。

5.1 變更驅(qū)動(dòng)下的90%的項(xiàng)目

多數(shù)項(xiàng)目都是衍生項(xiàng)目或變更項(xiàng)目，我們的關(guān)注點(diǎn)在變更的那一部分，所以，這時(shí)會(huì)通過變更請(qǐng)求來驅(qū)動(dòng)后續(xù)一系列的工作。在大量的變更項(xiàng)目中，要做好base（參考項(xiàng)目）選擇、做好復(fù)用分析、做好分支管理，盡量讓需求精簡(jiǎn)，越簡(jiǎn)潔，越容易成功。

5.2 要區(qū)分產(chǎn)品特點(diǎn)

需求做得詳略的分寸，一部分取決于產(chǎn)品特點(diǎn)：

對(duì)于幾乎無(wú)功能安全要求無(wú)關(guān)但關(guān)注體驗(yàn)和快速上市的娛樂系統(tǒng)，可以更敏捷、更靈活一些。經(jīng)過一到兩個(gè)項(xiàng)目的試探，確定是更詳細(xì)還是更簡(jiǎn)略，但最好對(duì)需求和測(cè)試兩端松手的幅度慢一點(diǎn)。底盤、動(dòng)力等高功能安全等級(jí)的模塊仍然需要比較嚴(yán)格的需求管控，但由于這類產(chǎn)品的成熟度已經(jīng)有了相當(dāng)?shù)姆e累，更多的精力可放在集成歷史經(jīng)驗(yàn)的平臺(tái)化的維護(hù)處理上。對(duì)于分支釋放項(xiàng)目，可較大程度地聚焦在變更點(diǎn)觸發(fā)的這條線上。對(duì)于一些域內(nèi)跨模塊或跨域融合的功能系統(tǒng)，要做好接口處需求的澄清與評(píng)審，要做好對(duì)手件需求的協(xié)調(diào)，比如，輔助駕駛、動(dòng)力系統(tǒng)、車身系統(tǒng)、娛樂系統(tǒng)等之間交互信號(hào)的對(duì)齊。

5.3 靈活追溯

需求管理中最頭疼的可能就屬于建立各種鏈接的追溯了，而一個(gè)東西只有被用的時(shí)候才有價(jià)值。追溯就是這樣，常常用不到，偶爾要用到卻又找不到。

從實(shí)用而不是被評(píng)審的角度看，建立起追溯意識(shí)或許比追溯規(guī)整更重要，例如。

在文檔里加一句話、加一個(gè)標(biāo)簽、加一條變更履歷。把相關(guān)需要追溯的需求、架構(gòu)、模型、代碼、測(cè)試報(bào)告放到一個(gè)文件夾里。需求系統(tǒng)里加上某個(gè)可以定位的字段，比如，系統(tǒng)需求涉及哪個(gè)軟件組件。工具的自動(dòng)操作痕跡留存也可以作為一種追溯�；蛘咦屆恳粋�(gè)特性負(fù)責(zé)人決定自己的追溯方式......

總之，追溯要有，但不一定都一樣。這些靈活的探索或可在敏捷實(shí)踐里去嘗試。

5.4 依賴專家

上面我們給了很多分析思路、方法，但那是學(xué)習(xí)理解的過程。真正的工程分析是在腦子里進(jìn)行的，真正在處理一個(gè)復(fù)雜的新需求時(shí)，在工程師的腦子里，不是在對(duì)著需求分析原則和checklist來做的，是全方位調(diào)動(dòng)自己的經(jīng)驗(yàn)、教訓(xùn)、知識(shí)來做一個(gè)相對(duì)主觀的判斷。所以，一般來說，經(jīng)過各個(gè)領(lǐng)域有經(jīng)驗(yàn)的專家的評(píng)審，是對(duì)需求可靠的可靠保證。

5.5 多開會(huì)

需求很主要的一塊工作在于拉齊理解基準(zhǔn)，就是你以為的就是你以為的也是他以為的。定期的需求澄清會(huì)多少帶一定的強(qiáng)制性，以便讓大家面對(duì)面來交流理解。這也是一種推動(dòng)不愛溝通、只愛寫郵件的工程師們加強(qiáng)交互的方式。

5.6 數(shù)字化的必要性

信息化也好，數(shù)字化也罷，整體認(rèn)可度還是比較低。很多年的行業(yè)野蠻生長(zhǎng)，讓人無(wú)法去關(guān)注到這些看上去不怎么直接交付價(jià)值的東西。當(dāng)然，很多需求管理的數(shù)字化軟件也都是被國(guó)外巨頭把控，高昂的購(gòu)買費(fèi)用和持續(xù)的license成本也讓很多中小企業(yè)難以承受。

拋開不夠普及背后的原因，實(shí)際上，在包含需求管理在內(nèi)的開發(fā)活動(dòng)中，數(shù)字化帶來的價(jià)值增值是指數(shù)級(jí)的，數(shù)字化是解決重復(fù)性、繁雜性需求工作的絕佳手段。但這需要工具開發(fā)者和使用者共同摸索，比如，DOORS一直被認(rèn)為是很重的需求工具，可惜的是，其內(nèi)部大量的卻不為人知的自動(dòng)化腳本其實(shí)是可以幫到很多忙的。

無(wú)論如何，工程和管理味道兼?zhèn)涞男枨蠊こ蹋ㄒ舶�含以需求為源頭對(duì)后續(xù)實(shí)現(xiàn)與測(cè)試的拉動(dòng)）是一門實(shí)踐學(xué)科，更好的、更合適的方式都是摸索后印證出來的。

6State of the Art

在需求的章節(jié)加這么一個(gè)主題，或許會(huì)讓人覺得詫異。確實(shí)，它和工程意義上的需求的關(guān)系不大，但我們往深了一層理解，工程需求定義的邊界是什么呢？主機(jī)廠自主地定需求時(shí)該定多高？供應(yīng)商在主機(jī)廠需求之外是否還要考慮些什么？

這個(gè)在外企常用的概念會(huì)引出一個(gè)視角。

想了很多種方式，但還是選擇將其翻譯為“當(dāng)前技術(shù)水平”。

稍微了解下汽車的發(fā)展歷史就會(huì)知道，早期的汽車是如何的古老，時(shí)速十幾公里，坐不了幾個(gè)人，沒有舒適的座椅，沒有安全氣囊，沒有減震器，更別提什么智能化，價(jià)格還貴......但沒有人會(huì)否認(rèn)這些先驅(qū)產(chǎn)品的偉大，當(dāng)時(shí)的消費(fèi)者也不會(huì)對(duì)它們抱太高的期望，因?yàn)槟蔷褪钱?dāng)時(shí)的“當(dāng)前技術(shù)水平”。

這就類似于，在現(xiàn)在，大家不會(huì)過高期待一輛車的自動(dòng)駕駛功能多智能，不會(huì)對(duì)電動(dòng)車?yán)m(xù)航虛標(biāo)的問題大驚小怪，但會(huì)對(duì)一輛車發(fā)生碰撞事故后可能造成巨大損失有心理預(yù)期。

這里面其實(shí)涉及兩個(gè)要點(diǎn)：“心理預(yù)期”和“高技術(shù)水平”，二者也代表了產(chǎn)品的不同層次。

6.1 心理預(yù)期

心理預(yù)期指明了，汽車沒有絕對(duì)安全、沒有絕對(duì)完美、沒有絕對(duì)智能，是否“足夠”取決于消費(fèi)者的普遍期待。

一般是所謂的“普遍接受的技術(shù)規(guī)則”，這些是業(yè)內(nèi)專業(yè)人士知道并認(rèn)為正確的規(guī)則，其執(zhí)行是符合行業(yè)或大眾預(yù)期的，而且它們必須在使用中得到充分證明、廣泛傳播，并且必須經(jīng)受住時(shí)間的考驗(yàn)。例如，這包括遵守強(qiáng)制性法律要求或非強(qiáng)制性但經(jīng)過驗(yàn)證的規(guī)則、程序或通行做法。

不過，對(duì)于汽車而言，即使我們將這些技術(shù)規(guī)則描述為普遍的，但對(duì)于大眾而言，仍然有很高的門檻。近兩年市面上各種失靈的事故屢見不鮮，孰是孰非，一時(shí)難以論定，如果有一定的制度保障，可以將這些內(nèi)部如EDR或開發(fā)數(shù)據(jù)進(jìn)行權(quán)威公正分析，我們通常至少可以知道以下兩個(gè)問題的答案：

廠家的產(chǎn)品表現(xiàn)是否符合自身的工程需求？廠家的技術(shù)方案是否是業(yè)內(nèi)通行的規(guī)范做法？

汽車歷史上很多召回事件就是在大規(guī)模發(fā)酵之后被挖掘出來的。

6.2 高技術(shù)水平

說回兩個(gè)要點(diǎn)的后者，其代表著更高的追求。我們不再滿足于追求工程成熟方案，而是更先進(jìn)的“科學(xué)狀態(tài)”，這描述了最新研究成果認(rèn)為有效的，但可能尚未在實(shí)踐中使用的、可公開訪問的發(fā)現(xiàn)，如論文、專利、報(bào)告等。

特別是對(duì)于新產(chǎn)品或創(chuàng)新解決方案，以及具有高復(fù)雜性的產(chǎn)品，這些可能更加必要。此外，對(duì)于具有高危害可能性的新產(chǎn)品，還是應(yīng)該進(jìn)行自己的研究，而不是簡(jiǎn)單符合當(dāng)前現(xiàn)有技術(shù)狀態(tài)。

文學(xué)性語(yǔ)言上，我們可以為這兩個(gè)要點(diǎn)匹配兩個(gè)虛一點(diǎn)的詞：“與時(shí)俱進(jìn)”和“引領(lǐng)潮流”。

這同時(shí)是State of the Art這個(gè)概念背后對(duì)應(yīng)的價(jià)值。技術(shù)研究、產(chǎn)品開發(fā)需要至少“與時(shí)俱進(jìn)”，這能讓產(chǎn)品不至于被市場(chǎng)直接淘汰；最好是“引領(lǐng)潮流”，這將是賣點(diǎn)、增長(zhǎng)點(diǎn)、引爆點(diǎn)。而落后于State of the Art就會(huì)沒有競(jìng)爭(zhēng)優(yōu)勢(shì)，甚至沒有存在的意義。

識(shí)別清楚并定義好State of the Art很難，需要技術(shù)沉淀，需要?jiǎng)?chuàng)新能力，需要責(zé)任擔(dān)當(dāng)，但這也是我們將需求拔至商業(yè)高度后的核心訴求，而這在智能車時(shí)代尤為突出。

       原文標(biāo)題 : 萬(wàn)字長(zhǎng)文詳解汽車軟件需求開發(fā)與管理