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

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

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

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

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

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

1.1 不太容易搞明白的需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1 需求的簡單分類

1.3.1 非技術(shù)類

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

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

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

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

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

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

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

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

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

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

1.3.2 技術(shù)類

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

(1) 功能類

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

(2) 非功能類

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

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

2需求收集與整理

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

2.1 外部需求收集

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

圖2 外部需求來源

2.1.1 法律法規(guī)

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

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

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

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

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

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

2.1.3 市場趨勢

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

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

2.1.4 整車需求

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

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

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

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

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

2.1.6 內(nèi)部需求

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

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

2.1.7 項目需求

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

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

2.2 外部需求整理

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

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

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

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

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

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

3需求分析與分解

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

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

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

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

3.1.1 特性與功能

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

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

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

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

3.1.2 特性的類別

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

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

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

(1) 底層

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

(2) 應(yīng)用層

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

(3) 其他

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

3.1.3 特性拆分的思路

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

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

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

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

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

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

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

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

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

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

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

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

3.3.1 為什么要分解？

可以從兩個層面來看。

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

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

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

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

3.3.2 怎么分解？

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

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

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

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

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

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

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

3.4 需求的文檔化

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

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

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

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

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

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

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

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

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

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

(1) 需求自身描述

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

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

圖9 需求描述的典型形式

(2) 需求ID

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

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

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

(4) 需求驗證方式

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

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

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

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

4需求實現(xiàn)與測試

在前面，我們站在ECU的視角討論了“外部需求”“系統(tǒng)需求”“軟件需求”和“軟件組件需求”�？墒�，它們該如何在項目里落實呢？比較簡單地分兩個部分：實現(xiàn)與驗證。因為后面小節(jié)會詳細(xì)介紹這兩部分，所以這里只進(jìn)行概述。

4.1 需求實現(xiàn)

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

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

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

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

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

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

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

4.2 需求測試

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

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

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

圖11 需求的逐級測試過程

5一個具體項目的需求管理

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

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

5.1 變更驅(qū)動下的90%的項目

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

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

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

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

5.3 靈活追溯

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

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

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

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

5.4 依賴專家

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

5.5 多開會

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

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

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

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

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

6State of the Art

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

這個在外企常用的概念會引出一個視角。

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

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

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

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

6.1 心理預(yù)期

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

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

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

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

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

6.2 高技術(shù)水平

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

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

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

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

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

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