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

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

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

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

1一些有關需求的感觸

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

1.1 不太容易搞明白的需求

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

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

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

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

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

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

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

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

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

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

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

1.2 需求值得反復澄清

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

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

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

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

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

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

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

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

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

圖1 需求的簡單分類

1.3.1 非技術類

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

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

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

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

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

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

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

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

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

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

1.3.2 技術類

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

(1) 功能類

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

(2) 非功能類

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

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

2需求收集與整理

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

2.1 外部需求收集

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

圖2 外部需求來源

2.1.1 法律法規(guī)

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

在這里需要特別關注的有兩個方面：

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

2.1.2 行業(yè)標準

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

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

2.1.3 市場趨勢

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

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

2.1.4 整車需求

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

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

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

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

2.1.7 項目需求

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

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

2.2 外部需求整理

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

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

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

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

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

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

3需求分析與分解

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

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

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

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

3.1.1 特性與功能

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

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

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

 圖4 特性（feature）與功能（function）的關系

3.1.2 特性的類別

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

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

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

(1) 底層

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

(2) 應用層

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

(3) 其他

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

3.1.3 特性拆分的思路

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

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

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

3.1.4 特性拆分的責任人

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

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

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

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

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

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

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

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

3.3.1 為什么要分解？

可以從兩個層面來看。

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

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

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

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

3.3.2 怎么分解？

對應兩個原因，我們可以引出分解各領域需求的兩個依次遞進的方法，以軟件為主要討論對象。

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

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

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

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

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

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

3.4 需求的文檔化

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

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

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

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

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

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

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

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

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

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

(1) 需求自身描述

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

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

圖9 需求描述的典型形式

(2) 需求ID

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

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

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

(4) 需求驗證方式

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

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

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

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

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

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

4.1 需求實現(xiàn)

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

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

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

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

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

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

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

4.2 需求測試

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

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

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

圖11 需求的逐級測試過程

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

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

但這不是抱著負面的觀點來看待這種現(xiàn)象的，如果不分輕重緩急，每個項目都要精細化地維護需求文檔，很有可能造成的結(jié)果就是進度的延期、成本的溢出，乃至項目的失敗。就像考試里只完美地做了一道題，最終還是不及格。可是，世間最難之事不在于，知不知道完美是什么，而是如何把握分寸。我們進一步做一些思考、探索。

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

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

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

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

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

5.3 靈活追溯

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

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

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

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

5.4 依賴專家

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

5.5 多開會

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

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

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

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

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

6State of the Art

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

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

想了很多種方式，但還是選擇將其翻譯為“當前技術水平”。

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

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

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

6.1 心理預期

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

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

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

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

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

6.2 高技術水平

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

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

文學性語言上，我們可以為這兩個要點匹配兩個虛一點的詞：“與時俱進”和“引領潮流”。

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

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

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