一份汽車軟件需求的生成過(guò)程

這是來(lái)源于ASPICE 3.1的一張追溯圖，非常流行。

盡管ASPICE并不是絕對(duì)的標(biāo)準(zhǔn)，但我們可以作為討論框架。今天講的是軟件需求。

1

生成軟件需求的4個(gè)步驟

拋開(kāi)理論，面對(duì)一個(gè)真實(shí)項(xiàng)目時(shí)，首先該思考的是如何一步一步展開(kāi)工作。

1.1?分析系統(tǒng)需求和系統(tǒng)架構(gòu)中與軟件相關(guān)的部分

軟件需求并非憑空而創(chuàng)，它的源頭是系統(tǒng)，我們?cè)谶@步要做的就是將軟件的部分剝離出來(lái)。

這是一個(gè)看文檔、分析、溝通、討論的過(guò)程。

1.2 編寫(xiě)軟件需求

經(jīng)過(guò)一番腦力與paper工作后，我們會(huì)得到一份軟件需求，按詳略程度，可能是針對(duì)完整集成軟件的，也有針對(duì)具體實(shí)現(xiàn)層面的軟件組件的。

1.3 建立基線

走完第二步，不能算完。

軟件需求是后續(xù)一系列工作的基礎(chǔ)，我們得定個(gè)基準(zhǔn)，也就是基線或baseline。

在Doors之類的工具里的話，基線是通過(guò)系統(tǒng)直接建立的。如果使用office，至少要有個(gè)版本管理。

1.4 對(duì)基線進(jìn)行review

review也是必要的，畢竟這份文檔涉眾多，還是后續(xù)的源頭。

如果review發(fā)現(xiàn)了問(wèn)題，修改后應(yīng)再次打基線。至此，一份軟件需求文檔正式生成。

下面我們看里面的一些細(xì)節(jié)。

2

一份軟件需求的4個(gè)基本屬性

我們經(jīng)常喜歡用word來(lái)寫(xiě)需求。

word的段落式描述和多級(jí)標(biāo)題會(huì)帶來(lái)較好的順序閱讀體驗(yàn)，但非條目化和無(wú)屬性拆分，這會(huì)讓后續(xù)的篩選、追溯、修改、統(tǒng)計(jì)、查閱多有不便。

所以，尤其我們有需求管理工具支持時(shí)，最好拆分多個(gè)屬性，這里提供4個(gè)最基本的。

2.1 類型

我們把整本需求拆分為很多條后，會(huì)知道有些條不是需求，或者是不同類型的需求，大體可分為如下類型：

標(biāo)題：這基本就等同于word里的各級(jí)標(biāo)題，這是基本要求，不用多解釋。

用例：用例也是需求，但它作為承接系統(tǒng)需求和架構(gòu)（如MBSE里的Use Case圖）的環(huán)節(jié)，會(huì)寫(xiě)得不很“技術(shù)”、寫(xiě)得很“故事”，也就是外行和領(lǐng)導(dǎo)都能看得懂的，而這對(duì)于交流很必要。

比如，用戶輸入賬號(hào)密碼登錄，如通過(guò)驗(yàn)證，系統(tǒng)進(jìn)入主頁(yè)，否則，提示錯(cuò)誤。

功能需求：功能需求是最名正言順的需求，描述了由某個(gè)軟件組件實(shí)現(xiàn)的功能，并且從軟件外部看，它是可觀察的或可測(cè)試的。

功能需求經(jīng)常會(huì)寫(xiě)得與更高一層級(jí)的需求、設(shè)計(jì)重復(fù)，這時(shí)，就需要我們做好裁剪。

組件需求：進(jìn)一步的架構(gòu)設(shè)計(jì)和開(kāi)發(fā)，可能需要更細(xì)化的需求，即軟件組件需求。

當(dāng)然，架構(gòu)設(shè)計(jì)與決策也伴隨著組件的劃分和需求的分配，這與組件需求是相互依托的。

非功能需求：提到非功能需求，我們最容易聯(lián)想到性能需求，但不僅僅于此。整體來(lái)看，非功能需求可分為兩大部分：質(zhì)量特性和結(jié)構(gòu)性需求。

質(zhì)量特性基本可以參考ISO/IEC 25010里質(zhì)量模型的劃分，如圖。

結(jié)構(gòu)性需求可以理解為架構(gòu)催生的，比如，接口需求。

定義：可用來(lái)對(duì)一些專業(yè)名詞進(jìn)行說(shuō)明、澄清。

備注：一些提示或解釋，主要為了增加可讀性。

2.2 狀態(tài)

需求是動(dòng)態(tài)變化的，所以其狀態(tài)會(huì)遷轉(zhuǎn)。

Proposed（被提議）：需求已被編輯完成，可以進(jìn)行review了。

Reviewed（已評(píng)審）：需求已經(jīng)完成評(píng)審，可以進(jìn)行問(wèn)題處理和決策了。

Approved（已批準(zhǔn)）：需求已經(jīng)完成批準(zhǔn)，準(zhǔn)備好導(dǎo)入執(zhí)行了。

Implemented（已執(zhí)行）：需求已經(jīng)執(zhí)行，軟件組件已釋放。

Rejected（被拒絕）：需求暫不計(jì)劃執(zhí)行，或者技術(shù)上不可行。

2.3 驗(yàn)證標(biāo)準(zhǔn)

寫(xiě)需求時(shí)就考慮驗(yàn)證，這是V模型的一個(gè)顯著特點(diǎn)。

需求工程師經(jīng)常不愿意寫(xiě)這一部分，一者總覺(jué)得不好寫(xiě)，二者覺(jué)得是測(cè)試的活兒。

我們分別看這兩個(gè)抱怨。

實(shí)際上，感覺(jué)驗(yàn)證標(biāo)準(zhǔn)不好寫(xiě)恰好反映了這部分工作的必要性。當(dāng)你覺(jué)得很難簡(jiǎn)單描述清楚怎么去驗(yàn)證，這條需求就應(yīng)該被返工，比如，重新描述、拆分、合并等。

那么，這是測(cè)試的活兒?jiǎn)?？也不合適，很顯然，測(cè)試用例要比驗(yàn)證標(biāo)準(zhǔn)復(fù)雜得多。這里主要為了讓需求工程師保證需求是可測(cè)的。

此外，也應(yīng)提示驗(yàn)證階段和方法。比如，單元測(cè)試、組件測(cè)試、需求測(cè)試、集成測(cè)試、評(píng)審。

2.4 配置

汽車有很多改款配置，軟件也有很多分支。配置組合背后往往伴隨著軟件需求的復(fù)用關(guān)系。

于是，編寫(xiě)軟件需求時(shí)，復(fù)用及配置工作很是必要。

我們可以增加配置屬性來(lái)共用一版需求，而配置可以是車型項(xiàng)目，也可以是硬件配置。

然后，在有某條需求的配置處標(biāo)記yes，或者可標(biāo)定或軟件參數(shù)化的部分也可標(biāo)記具體參數(shù)值。

以上描述了一些基礎(chǔ)的軟件需求屬性示例，可做參考。但我們實(shí)際項(xiàng)目中，可以根據(jù)需要增加很多其他的類別。

3

一份好軟件需求的特點(diǎn)

需求是自然語(yǔ)言描述的，這讓我們很難量化評(píng)價(jià)其好壞，且提供幾個(gè)特性做參考：

完整性

可行性

可驗(yàn)證性

不含糊性

一致性

正確性

可理解性

可修改性

為了盡量實(shí)現(xiàn)這些特性目標(biāo)，我們可以嘗試按照如下的“公式”來(lái)書(shū)寫(xiě)。

即“在什么前提條件（邏輯條件或事件發(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)這些基本信息。

5

軟件需求的評(píng)審

第一小節(jié)的最后一個(gè)步驟是評(píng)審，這里做一個(gè)擴(kuò)充。

評(píng)審是我們解決個(gè)體能力不足的幾乎唯一的手段，其主要涉及兩部分：誰(shuí)來(lái)評(píng)審和如何評(píng)審。

5.1?誰(shuí)來(lái)評(píng)審

軟件開(kāi)發(fā)是個(gè)團(tuán)隊(duì)合作的過(guò)程，而需求更是幾乎所有人都要關(guān)注的，我們要讓團(tuán)隊(duì)來(lái)評(píng)審（角色定義可參考《汽車電子軟件組織的“角色”大起底》）。

具體來(lái)看，不同角色要有不同的評(píng)審側(cè)重點(diǎn):

Feature Owner：確保軟件需求滿足更高層級(jí)的系統(tǒng)需求和系統(tǒng)架構(gòu)設(shè)計(jì)。

軟件架構(gòu)：確保需求范圍正確，滿足內(nèi)部guideline（對(duì)需求質(zhì)量的定義），并遵循產(chǎn)品roadmap。

軟件開(kāi)發(fā)：確保需求是可理解的，并且可以被組件實(shí)現(xiàn)。

軟件測(cè)試：關(guān)注需求的可理解性和可測(cè)試性。

5.2 如何評(píng)審

評(píng)審范圍可以是全部?jī)?nèi)容，也可以是增量或變更評(píng)審。如果選擇增量或變更評(píng)審，要注意檢查它們對(duì)軟件需求及下游架構(gòu)其余部分的影響。

進(jìn)一步地，我們給出一些checklist供參考。

是否遵循以下書(shū)寫(xiě)需求的規(guī)則：

必須清楚地確定主體；

每個(gè)需求都是“原子”級(jí)別的；

每項(xiàng)需求都應(yīng)說(shuō)得明確不含糊；

盡可能定量地表述需求；

描述系統(tǒng)在所有條件（如初始化、休眠、斷電、正常運(yùn)行、過(guò)壓、欠壓等）下的行為；

避免冗余和瑣碎；

使用一致的術(shù)語(yǔ)；

在適當(dāng)?shù)牡胤绞褂梅钦Z(yǔ)言描述，如流程圖。

不同的軟件需求之間沒(méi)有矛盾，以及與高層級(jí)需求與設(shè)計(jì)之間沒(méi)有矛盾？

軟件需求是否能夠覆蓋及滿足所追溯的需求與設(shè)計(jì)？

是否都使用內(nèi)部標(biāo)準(zhǔn)術(shù)語(yǔ)？

實(shí)現(xiàn)這些需求是否有任何風(fēng)險(xiǎn)？

需求是否有機(jī)會(huì)調(diào)整為復(fù)用現(xiàn)有設(shè)計(jì)？

時(shí)間相關(guān)事件的時(shí)間要求及公差是否定義？

是否描述了不同硬件之間存在的差異？

驗(yàn)證標(biāo)準(zhǔn)和驗(yàn)證方法是否明確?

是否有必要的需求屬性被遺漏?

......

6

全文小結(jié)

本文從以下幾個(gè)方面進(jìn)行了簡(jiǎn)要解讀：

生成需求的4個(gè)步驟（分析、編寫(xiě)、打基線、評(píng)審）。

需求所包含的4個(gè)基本屬性（類型、狀態(tài)、驗(yàn)證標(biāo)準(zhǔn)、配置）。

一份好需求的8個(gè)特點(diǎn)（完整性、可行性、可驗(yàn)證性、不含糊性、一致性、正確性、可理解性、可修改性）。

寫(xiě)好需求的公式（前提、主體、強(qiáng)制性、方式及目標(biāo)）。

需求評(píng)審的4個(gè)角色及評(píng)審側(cè)重點(diǎn)。

需求評(píng)審的9條checklist。

7

寫(xiě)在最后

從很多經(jīng)驗(yàn)看下來(lái)，一個(gè)做得爛的項(xiàng)目基本都有一套混亂的需求。當(dāng)想要治理項(xiàng)目時(shí)，幾乎都應(yīng)該從需求開(kāi)始。

完

原文標(biāo)題:一份汽車軟件需求的生成過(guò)程