侵權(quán)投訴
訂閱
糾錯(cuò)
加入自媒體

萬(wàn)字長(zhǎng)文詳解汽車(chē)軟件需求開(kāi)發(fā)與管理

2024-07-30 11:17
水輕言
關(guān)注

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

問(wèn)渠哪得清如許,為有源頭活水來(lái)。

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

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

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

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

1.1 不太容易搞明白的需求

簡(jiǎn)單來(lái)說(shuō),“需求”就是你到底要什么?但想回答這個(gè)問(wèn)題卻并不簡(jiǎn)單。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不過(guò),出于工程師對(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ì)上的維度

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

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

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

1.3.1 非技術(shù)類(lèi)

那些營(yíng)銷(xiāo)、錢(qián)、時(shí)間、過(guò)程、交付、生產(chǎn)就是典型的“非技術(shù)類(lèi)”,這部分我們不做展開(kāi)。

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

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

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

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

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

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

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

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

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

1.3.2 技術(shù)類(lèi)

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

(1) 功能類(lèi)

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

(2) 非功能類(lèi)

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

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

2需求收集與整理

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

2.1 外部需求收集

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

圖2 外部需求來(lái)源

2.1.1 法律法規(guī)

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

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

第一,最近幾年電動(dòng)車(chē)、數(shù)據(jù)安全、網(wǎng)絡(luò)安全、自動(dòng)駕駛、OTA、EDR(Event Data Recorder,事件數(shù)據(jù)記錄系統(tǒng),即汽車(chē)“黑匣子”)等新事物的興起必然會(huì)帶動(dòng)一些國(guó)家法規(guī)的出臺(tái),需要實(shí)時(shí)關(guān)注。第二,無(wú)論是整車(chē)還是零部件經(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),就是你做也行,不做也沒(méi)關(guān)系,至少是沒(méi)有誰(shuí)會(huì)直接懲罰你。但是,為什么要說(shuō)隔行如隔山?很多時(shí)候隔的就是對(duì)行標(biāo)的認(rèn)識(shí)。接著前面一句話的描述,盡管你不做沒(méi)人懲罰,但你可能會(huì)失去市場(chǎng)或者無(wú)法和別人兼容。

比如,大家都去做的NCAP(New Car Assessment Program,新車(chē)評(píng)估項(xiàng)目,也即新車(chē)碰撞測(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ī),但大家都這么做,你沒(méi)必要也基本沒(méi)能力重新開(kāi)發(fā)一套。

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

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

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

2.1.4 整車(chē)需求

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

能夠影響到軟件開(kāi)發(fā)的整車(chē)需求,可能會(huì)有EEA、通信矩陣、診斷規(guī)范、刷寫(xiě)規(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),比如,車(chē)燈控制ECU和整個(gè)車(chē)燈系統(tǒng)的概念,或者安全氣囊ECU和被動(dòng)安全系統(tǒng)的概念。

控制器及其中的軟件是要滿足其上一級(jí)系統(tǒng)的需求。這部分的需求就會(huì)具體很多、貼近產(chǎn)品很多,比如,對(duì)于車(chē)燈系統(tǒng)而言,根據(jù)彎道路況和特定車(chē)速來(lái)自動(dòng)調(diào)整車(chē)燈的照明方向,可能就是它給車(chē)燈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)則來(lái)限定產(chǎn)品的設(shè)計(jì),比如,ECU一般的工作電壓在6.5~16V之間,但可能內(nèi)部設(shè)計(jì)準(zhǔn)則是3~20V都要能正常工作。

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

2.1.7 項(xiàng)目需求

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

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

2.2 外部需求整理

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

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

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

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

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

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

3需求分析與分解

在拿到這一攬子外部需求后,即便能夠制作一個(gè)清晰的需求列表,顆粒度依然不足以直接用于開(kāi)發(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ì)用它作為牽引來(lái)分解、定義產(chǎn)品級(jí)系統(tǒng)需求,但其含義多少有些含糊,有必要先來(lái)辨析一下。

3.1.1 特性與功能

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

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

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

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

3.1.2 特性的類(lèi)別

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

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

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

(1) 底層

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

(2) 應(yīng)用層

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

(3) 其他

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

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í)問(wèn)題,就是第2節(jié)收集的那些散亂的需求顯然不是按照特性清單(feature list)一個(gè)一個(gè)排布的,誰(shuí)去做這個(gè)分解呢?

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

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

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

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

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

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

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

3.3.1 為什么要分解?

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

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

第一,汽車(chē)軟件產(chǎn)品往往是機(jī)電軟硬多學(xué)科一體化的系統(tǒng),而系統(tǒng)級(jí)的需求通常就得需要這不同領(lǐng)域共同實(shí)現(xiàn)。不分解、不拆分,則具備完全不同知識(shí)、經(jīng)驗(yàn)的不同領(lǐng)域的工程師無(wú)法執(zhí)行,比如,讓一個(gè)軟件工程師通過(guò)代碼去處理發(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è)代碼單元集成而來(lái)的。

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ì)也類(lèi)似于“系統(tǒng)需求”,有時(shí)會(huì)被部分分解為“軟件需求”。

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

第二,對(duì)識(shí)別出來(lái)的“軟件需求”進(jìn)一步按其內(nèi)部組件的劃分方式,去分解而形成“軟件組件需求”,即將軟件組件作為“黑盒子”。同樣的,原書(shū)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 需求的文檔化

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

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

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

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

3.4.1 需求撰寫(xiě)的底層邏輯——條目化

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

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

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

當(dāng)我們真正開(kāi)始敲打鍵盤(pán)寫(xiě)字了,需求該包含什么?如圖8所示。

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

(1) 需求自身描述

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

即“在什么前提條件(邏輯條件或事件發(fā)生或時(shí)間段)下,什么系統(tǒng)(或組件)必須(或應(yīng)該或?qū)?huì),英文中常分別用具備法律強(qiáng)制意義的shall、可以有爭(zhēng)論空間的should及一般性描述的will來(lái)對(duì)應(yīng))能夠(或通過(guò)什么流程)實(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í)別出來(lái),比如,需執(zhí)行測(cè)試或者僅僅評(píng)審即可。這里不需要設(shè)計(jì)具體的用例或形式,但要明確其是可驗(yàn)證的。這其實(shí)也是V模型的關(guān)鍵點(diǎn)——早期就關(guān)注測(cè)試,這也成為其與瀑布模型的典型差異。

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

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

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

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

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

一步是分配給包含但不限于“軟件需求”的各領(lǐng)域需求,比如,如果要求我們的控制器能夠?qū)④?chē)速識(shí)別到0.1m/s的精度,光將軟件的信號(hào)分區(qū)做細(xì)是不夠的,傳感器硬件首先要能夠支撐這樣的物理精度。在這一步要保證每一條“系統(tǒng)需求”都要被分配(即追溯的概念)給至少一個(gè)領(lǐng)域,或軟件,或硬件,或既軟件又硬件,以確保“系統(tǒng)需求”沒(méi)有遺漏。另一步是,基于“系統(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)過(guò)程如圖10所示。

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

4.2 需求測(cè)試

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

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

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

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

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ì)來(lái)來(lái)回回,會(huì)弄錯(cuò),會(huì)扯皮,會(huì)沒(méi)有追溯,會(huì)更新不及時(shí),還會(huì)有各種各樣的個(gè)性化操作。

但這不是抱著負(fù)面的觀點(diǎn)來(lái)看待這種現(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ì)通過(guò)變更請(qǐng)求來(lái)驅(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)和快速上市的娛樂(lè)系統(tǒng),可以更敏捷、更靈活一些。經(jīng)過(guò)一到兩個(gè)項(xiàng)目的試探,確定是更詳細(xì)還是更簡(jiǎn)略,但最好對(duì)需求和測(cè)試兩端松手的幅度慢一點(diǎn)。底盤(pán)、動(dòng)力等高功能安全等級(jí)的模塊仍然需要比較嚴(yán)格的需求管控,但由于這類(lèi)產(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)、車(chē)身系統(tǒng)、娛樂(lè)系統(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í)理解的過(guò)程。真正的工程分析是在腦子里進(jìn)行的,真正在處理一個(gè)復(fù)雜的新需求時(shí),在工程師的腦子里,不是在對(duì)著需求分析原則和checklist來(lái)做的,是全方位調(diào)動(dòng)自己的經(jīng)驗(yàn)、教訓(xùn)、知識(shí)來(lái)做一個(gè)相對(duì)主觀的判斷。所以,一般來(lái)說(shuō),經(jīng)過(guò)各個(gè)領(lǐng)域有經(jīng)驗(yàn)的專家的評(píng)審,是對(duì)需求可靠的可靠保證。

5.多開(kāi)會(huì)

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

5.數(shù)字化的必要性

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

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

無(wú)論如何,工程和管理味道兼?zhèn)涞男枨蠊こ蹋ㄒ舶孕枨鬄樵搭^對(duì)后續(xù)實(shí)現(xiàn)與測(cè)試的拉動(dòng))是一門(mén)實(shí)踐學(xué)科,更好的、更合適的方式都是摸索后印證出來(lái)的。

6State of the Art

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

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

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

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

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

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

6.1 心理預(yù)期

心理預(yù)期指明了,汽車(chē)沒(méi)有絕對(duì)安全、沒(méi)有絕對(duì)完美、沒(méi)有絕對(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)過(guò)驗(yàn)證的規(guī)則、程序或通行做法。

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

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

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

6.2 高技術(shù)水平

說(shuō)回兩個(gè)要點(diǎn)的后者,其代表著更高的追求。我們不再滿足于追求工程成熟方案,而是更先進(jìn)的“科學(xué)狀態(tài)”,這描述了最新研究成果認(rèn)為有效的,但可能尚未在實(shí)踐中使用的、可公開(kāi)訪問(wèn)的發(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)品開(kāi)發(fā)需要至少“與時(shí)俱進(jìn)”,這能讓產(chǎn)品不至于被市場(chǎng)直接淘汰;最好是“引領(lǐng)潮流”,這將是賣(mài)點(diǎn)、增長(zhǎng)點(diǎn)、引爆點(diǎn)。而落后于State of the Art就會(huì)沒(méi)有競(jìng)爭(zhēng)優(yōu)勢(shì),甚至沒(méi)有存在的意義。

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

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

聲明: 本文由入駐維科號(hào)的作者撰寫(xiě),觀點(diǎn)僅代表作者本人,不代表OFweek立場(chǎng)。如有侵權(quán)或其他問(wèn)題,請(qǐng)聯(lián)系舉報(bào)。

發(fā)表評(píng)論

0條評(píng)論,0人參與

請(qǐng)輸入評(píng)論內(nèi)容...

請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字

您提交的評(píng)論過(guò)于頻繁,請(qǐng)輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無(wú)評(píng)論

暫無(wú)評(píng)論

智能汽車(chē)網(wǎng) 獵頭職位 更多
文章糾錯(cuò)
x
*文字標(biāo)題:
*糾錯(cuò)內(nèi)容:
聯(lián)系郵箱:
*驗(yàn) 證 碼:

粵公網(wǎng)安備 44030502002758號(hào)