軟件定義汽車（Software Defined Vehicles, SDV）這個話題，已經算是老生常談了。尤其是汽車新四化技術不斷發展的這幾年，軟件定義汽車這個話題在不同的場合被人們提及和重申。當然，也有一些文章、一些人群表示了不同的觀點，認為該表述有些以偏概全、夸大其詞的意味。那實際情況又是什么樣的呢？可能很多人是會有一些疑問，比如：為什么是軟件定義汽車？軟件如何定義汽車？誰來定義軟件？

其實對于前兩個問題業內已經有較為普遍的共識：汽車產業經過上百年的發展，發動機、底盤、懸架、座椅、車身這些傳統的部分已經很難在做出什么新花樣了，與之對應的投入也逐漸減少。而在軟件相關開發成本上加大投入，需求量也在不斷擴大。決定未來汽車的是以人工智能為核心的軟件技術，而不再是汽車的馬力大小，是否真皮沙發座椅，機械性能好壞。因此，軟件定義汽車是大勢所趨，即通過軟件來表達汽車這一產品的很多特性、功能、服務成為一種趨勢。

圖 單車平均代碼長度變化

今天筆者最想分享的是前面提到的第三個問題：既然軟件定義汽車，那究竟誰來定義軟件？

這里不賣關子，先直接亮明筆者的觀點：軟件定義汽車，需求定義軟件。為什么呢？下面是筆者的一些拙見。

為什么是“需求”？

在這里先講一個筆者親歷的故事：在筆者從業的最開始幾年一直埋頭研究算法，然后搭建模型（主要基于simulink）,最后基于快速原型系統上車驗證。當時的工作狀態是真的好：自己搞算法調研、自己設計算法、用simulink搭建模型實現、再通過快速原型設備上車進行驗證……實現自己想要功能時，真的是發自內心的自豪和開心。每天早上上班真的想趕緊去公司向領導匯報昨天的成果，那種狀態真的是好極了！但是這種狀態有一天被改變了。

一次團隊從GM挖來一位資深的汽車動力學控制的專家，當時筆者負責運動控制模塊的算法出現了一點棘手的問題需要解決。那位專家剛來的第一天領導便安排這位專家與我進行了溝通，簡單的寒暄之后我們的聊天進入正題。那位專家問出了第一個問題：咱們現在的需求是什么，有文檔嗎？面對這個問題有些不知所措，因為當時我們的開發似乎沒有什么明確的需求，只是想到哪做到哪。

其實在此之前看到過一篇mathwork高級應用工程師董淑成的文章，是關于MBD（基于模型的開發）開發的，里面講到汽車的“V”流程開發，講到了系統需求、軟件需求，如何進行單元測試、集成測試以及如何形成開發工作的閉環反饋。

展開來說，如果你的團隊完全是嚴格按照“V”進行正向開發的話，當系統需求分析沒有完成或沒有通過集體評審的話，是無法進行系統架構設計的。但是，實際中真的是這樣嗎？當然不是，這種完全一步一個腳印，按部就班的開發過程在實際中幾乎是不存在的，受到項目周期的約束和版本快速迭代的壓力，很多工作往往都是同步進行，交叉開展的。舉個例子：當系統工程師把系統需求分析搞完并編寫出初版“***系統需求文檔”時，即便這個時候文檔并未完成評審和釋放，架構師也可以開始進行架構設計了，在后面需求評審中如有某些變化架構設計可以基于變化進行相應的微調即可，這樣不斷迭代循環完成設計。這是需求的在”V”流程中左側過程的意義，當然也是對于軟件開發的意義。

再來看”V”流程右側的測試過程，在這一過程中是對左側工作成果的確認和驗證，也就是保證“開發做了正確的事和正確的做了事”。對于不同層級的測試過程，都需要基于需求去展開測試，測試工程師的測試用例不是憑空捏造和主觀臆斷的，而是有理有據的。有多少條需求，就要針對這些需求設計相應的測試用例來驗證它。當然，并不是有N條需求就對應N條測試用例，有可能一個需求需要多個測試用力來驗證，這就是測試覆蓋度。因此，在“V”流程的右側工作過程中仍然離不開“需求”，軟件開發正確與否測試人員直接是看不出來的，必須要基于你的需求文檔來逐條驗證才行。所以有的時候工程師往往會出現“補文檔”的情況。單從“補文檔”這一非正規操作來看，就足以說明需求必不可少，就更不要說嚴格按照正向研發流程展開的軟件產品開發工作了。所以，當上面那位專家提出那個問題的時候，我再一次意識到了需求的重要性。

隨著對”V”流程的不斷理解，加之在后面的工作、培訓以及與不同層次的人的溝通中對需求這一概念的不斷理解，慢慢認識到需求才是開發的源頭、邊界、目標，需求才是核心。因此，才有了我開始的回答。在產品開發中，很多時候會忽略需求的重要性而過于強調某項技術。實際技術是為產品服務的，而產品又是由需求來定義的。回到我們的問題：誰來定義軟件？如果回答不是需求那還能是什么呢？在汽車嵌入式系統開發流程中，從系統需求到子系統需求到硬件需求、軟件需求，這一過程既是設計與開發的過程，又是需求不斷細化和深入的過程。任何一個工作過程都是在上一層需求的基礎上展開開發，如果某一工作過程偏離、超出甚至脫離了上一層的需求，哪這一工作將出現極大風險并失去意義，進而對整個產品開發造成巨大損失。

以上是筆者一些粗淺的觀點和認識。既然需求如此之重要，那如何進行需求開發呢？

需求怎么定義

談到到需求開發，筆者立馬想起自己在工作中認識的一位外國朋友Chakri。他是一位來自印度的軟件工程專家，是他讓筆者第一次較為系統的了解需求開發。第一次與他交流時，我用極其貧瘠的英文詞匯和他展開對話。但我令我驚奇的是他總能第一時間理解我想表達的內容，并給與回答和補充。那次交流使我對需求開發有了全面且系統的認識，并從此開啟了我的“正規”開發之路。

說到需求開發，就必須了解需求工程。需求工程包括兩部分工作過程：需求開發和需求管理。

需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特征和相關約束，形成需求文檔（需求規格說明書），并對用戶不斷變化的需求演進給予支持。

對于需求管理我們先不展開，因為它涉及到一些項目管理的內容，這里主要講需求開發。

在進行需求開發時，對于一個產品或系統而言，需求是分不同層級的。一般來說分：業務需求、用戶需求和系統需求，系統需求往下細分又可以分為不同的子系統需求。對于自動駕駛系統開發來說，子系統需求一般包含：硬件需求和軟件（應用軟件）需求。硬件需求通常指的是對域控制器的需求，用于指導、約束、定義控制器的開發；軟件需求指的是對感知、定位、預測、規劃、控制等模塊整體的需求，用于指導、約束、定義軟件系統的開發。

這里的軟件需求一定是對于整個系統的需求而不是對某個模塊而言的。為什么去這樣強調，原因是在需求開發時需求工程時很容易混淆需求邊界，導致將系統需求、子系統需求、模塊需求混為一談。理解需求層級邊界的一個很好理解解釋就是在定義某一層需求時將這個系統或模塊看作是一個黑盒子，只關心它對外提供什么功能或服務，而不要關心它是如何實現的。拿系統需求開發中的簡單例子，如：“在不具備換道條件時，系統應控制車輛保持在車道中心行駛”。這里我們暫且不去細究這條需求描述的準確性，單從“黑盒”理念（暫且這兒叫）來看，這條需求是符合的。到這里我們可以得出一個結論：在不同層級需求開發的過程中其實就是在定義這個系統（子系統、模塊）的功能、特性、邊界。

說完了需求分層理論，這里再聊一個更重要的東西：需求的特性。換句話說就是什么樣的需求才是規范的需求，優秀的需求。這一點對于需求開發者、對于研發工程師，甚至對于每一個產品相關的人員來說都很重要。通常來說需求應具備以下特性：

①　完整性：完整描述每項需求的功能

②　正確性：經過用戶和用戶代理人的審閱

③　可行性：在已知能力和約束條件中實現

④　必要性：每項需求功能都隱私用戶正真需要的

⑤　無歧義：對所有讀者只有一種一致的解釋

⑥　無交叉重疊：在不同的需求功能中沒有重復的內容

⑦　可驗證性：可以設計測試方法來監察

⑧　正確的詳細層次：不同需求層次的結構要清晰

⑨　劃分優先級 ：提供了實現優先的次序

⑩　與實現無關性：與后續的設計開發如何實現無關

用來自GM專家的話說：需求開發的精細程度要達到每條需求對應這一行代碼。這句話我仍然記憶猶新。

說了這么多，我們拿兩個常見的feature來看一下需求是如何定義的。

從以上的需求列表中我們可以看到，雖然這是系統級的需求，但很大程度上這些需求已經對軟件的設計進行一定程度定義和約束。那進一步的如果到達模塊級的需求講把軟件模塊的功能和邊界定義的很清楚。我們再來再來看幾個軟件模塊的需求：

Req1:橫向控制模塊應輸出目標方向盤轉角作為控制量。

Req2:橫向控制模塊應將最終輸出的目標轉角值限制在[-500,500]度以內。

Req3:橫向控制模塊應將目標轉角的變化率限制在[-300,300]度每秒以內。

Req4:橫向控制模塊應對目標轉角進行低通濾波處理以消除信號抖動。

看到上面的這幾條需求是不是已經很細化了，基本上達到了需求的最理想狀態：每一條需求可以對應一行代碼。沒錯，需求寫到這個程度已經很不錯了，這樣軟件代碼是不會存在無緣無故的多寫和少寫的。這就是需求定義軟件的真諦！

換句話說，只要需求寫清楚了，那么產品也就清楚了、軟件也就清楚了，最終不管是用什么算法、什么語言去開發其結果都是可預見的。