這是來源于ASPICE 3.1的一張追溯圖，非常流行。
盡管ASPICE并不是絕對的標(biāo)準(zhǔn)，但我們可以作為討論框架。今天講的是軟件需求。
1
生成軟件需求的4個(gè)步驟
拋開理論，面對一個(gè)真實(shí)項(xiàng)目時(shí)，首先該思考的是如何一步一步展開工作。
1.1 分析系統(tǒng)需求和系統(tǒng)架構(gòu)中與軟件相關(guān)的部分
軟件需求并非憑空而創(chuàng)，它的源頭是系統(tǒng)，我們在這步要做的就是將軟件的部分剝離出來。
這是一個(gè)看文檔、分析、溝通、討論的過程。
1.2 編寫軟件需求
經(jīng)過一番腦力與paper工作后，我們會(huì)得到一份軟件需求，按詳略程度，可能是針對完整集成軟件的，也有針對具體實(shí)現(xiàn)層面的軟件組件的。
1.3 建立基線
走完第二步，不能算完。
軟件需求是后續(xù)一系列工作的基礎(chǔ)，我們得定個(gè)基準(zhǔn)，也就是基線或baseline。
在Doors之類的工具里的話，基線是通過系統(tǒng)直接建立的。如果使用office，至少要有個(gè)版本管理。
1.4 對基線進(jìn)行review
review也是必要的，畢竟這份文檔涉眾多，還是后續(xù)的源頭。
如果review發(fā)現(xiàn)了問題，修改后應(yīng)再次打基線。至此，一份軟件需求文檔正式生成。
下面我們看里面的一些細(xì)節(jié)。
2
一份軟件需求的4個(gè)基本屬性
我們經(jīng)常喜歡用word來寫需求。
word的段落式描述和多級標(biāo)題會(huì)帶來較好的順序閱讀體驗(yàn)，但非條目化和無屬性拆分，這會(huì)讓后續(xù)的篩選、追溯、修改、統(tǒng)計(jì)、查閱多有不便。
所以，尤其我們有需求管理工具支持時(shí)，最好拆分多個(gè)屬性，這里提供4個(gè)最基本的。
2.1 類型
我們把整本需求拆分為很多條后，會(huì)知道有些條不是需求，或者是不同類型的需求，大體可分為如下類型：
-
標(biāo)題：這基本就等同于word里的各級標(biāo)題，這是基本要求，不用多解釋。
-
用例：用例也是需求，但它作為承接系統(tǒng)需求和架構(gòu)（如MBSE里的Use Case圖）的環(huán)節(jié)，會(huì)寫得不很“技術(shù)”、寫得很“故事”，也就是外行和領(lǐng)導(dǎo)都能看得懂的，而這對于交流很必要。
比如，用戶輸入賬號(hào)密碼登錄，如通過驗(yàn)證，系統(tǒng)進(jìn)入主頁，否則，提示錯(cuò)誤。
-
功能需求：功能需求是最名正言順的需求，描述了由某個(gè)軟件組件實(shí)現(xiàn)的功能，并且從軟件外部看，它是可觀察的或可測試的。
功能需求經(jīng)常會(huì)寫得與更高一層級的需求、設(shè)計(jì)重復(fù)，這時(shí)，就需要我們做好裁剪。
-
組件需求：進(jìn)一步的架構(gòu)設(shè)計(jì)和開發(fā)，可能需要更細(xì)化的需求，即軟件組件需求。
當(dāng)然，架構(gòu)設(shè)計(jì)與決策也伴隨著組件的劃分和需求的分配，這與組件需求是相互依托的。
-
非功能需求：提到非功能需求，我們最容易聯(lián)想到性能需求，但不僅僅于此。整體來看，非功能需求可分為兩大部分：質(zhì)量特性和結(jié)構(gòu)性需求。
-
質(zhì)量特性基本可以參考ISO/IEC 25010里質(zhì)量模型的劃分，如圖。
結(jié)構(gòu)性需求可以理解為架構(gòu)催生的，比如，接口需求。
-
定義：可用來對一些專業(yè)名詞進(jìn)行說明、澄清。
-
備注：一些提示或解釋，主要為了增加可讀性。
2.2 狀態(tài)
需求是動(dòng)態(tài)變化的，所以其狀態(tài)會(huì)遷轉(zhuǎn)。
-
Proposed（被提議）：需求已被編輯完成，可以進(jìn)行review了。
-
Reviewed（已評審）：需求已經(jīng)完成評審，可以進(jì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)
寫需求時(shí)就考慮驗(yàn)證，這是V模型的一個(gè)顯著特點(diǎn)。
需求工程師經(jīng)常不愿意寫這一部分，一者總覺得不好寫，二者覺得是測試的活兒。
我們分別看這兩個(gè)抱怨。
實(shí)際上，感覺驗(yàn)證標(biāo)準(zhǔn)不好寫恰好反映了這部分工作的必要性。當(dāng)你覺得很難簡單描述清楚怎么去驗(yàn)證，這條需求就應(yīng)該被返工，比如，重新描述、拆分、合并等。
那么，這是測試的活兒嗎？也不合適，很顯然，測試用例要比驗(yàn)證標(biāo)準(zhǔn)復(fù)雜得多。這里主要為了讓需求工程師保證需求是可測的。
此外，也應(yīng)提示驗(yàn)證階段和方法。比如，單元測試、組件測試、需求測試、集成測試、評審。
2.4 配置
汽車有很多改款配置，軟件也有很多分支。配置組合背后往往伴隨著軟件需求的復(fù)用關(guān)系。
于是，編寫軟件需求時(shí)，復(fù)用及配置工作很是必要。
我們可以增加配置屬性來共用一版需求，而配置可以是車型項(xiàng)目，也可以是硬件配置。
然后，在有某條需求的配置處標(biāo)記yes，或者可標(biāo)定或軟件參數(shù)化的部分也可標(biāo)記具體參數(shù)值。
以上描述了一些基礎(chǔ)的軟件需求屬性示例，可做參考。但我們實(shí)際項(xiàng)目中，可以根據(jù)需要增加很多其他的類別。
3
一份好軟件需求的特點(diǎn)
需求是自然語言描述的，這讓我們很難量化評價(jià)其好壞，且提供幾個(gè)特性做參考：
-
完整性
-
可行性
-
可驗(yàn)證性
-
不含糊性
-
一致性
-
正確性
-
可理解性
-
可修改性
為了盡量實(shí)現(xiàn)這些特性目標(biāo)，我們可以嘗試按照如下的“公式”來書寫。
即“在什么前提條件（邏輯條件或事件發(fā)生或時(shí)間段）下，什么系統(tǒng)（或組件）必須（或應(yīng)該或?qū)?huì)，英文中常分別用具備法律強(qiáng)制意義的shall、可以有爭論空間的should及一般性描述的will來對應(yīng)）能夠（或通過什么流程）實(shí)現(xiàn)什么目標(biāo)以及其他細(xì)節(jié)”。
這會(huì)反映出前提、主體、強(qiáng)制性、方式及目標(biāo)這些基本信息。
4
軟件需求的評審
第一小節(jié)的最后一個(gè)步驟是評審，這里做一個(gè)擴(kuò)充。
評審是我們解決個(gè)體能力不足的幾乎唯一的手段，其主要涉及兩部分：誰來評審和如何評審。
4.1 誰來評審
軟件開發(fā)是個(gè)團(tuán)隊(duì)合作的過程，而需求更是幾乎所有人都要關(guān)注的，我們要讓團(tuán)隊(duì)來評審（角色定義可參考《汽車電子軟件組織的“角色”大起底》）。
具體來看，不同角色要有不同的評審側(cè)重點(diǎn):
-
Feature Owner：確保軟件需求滿足更高層級的系統(tǒng)需求和系統(tǒng)架構(gòu)設(shè)計(jì)。
-
軟件架構(gòu)：確保需求范圍正確，滿足內(nèi)部guideline（對需求質(zhì)量的定義），并遵循產(chǎn)品roadmap。
-
軟件開發(fā)：確保需求是可理解的，并且可以被組件實(shí)現(xiàn)。
-
軟件測試：關(guān)注需求的可理解性和可測試性。
4.2 如何評審
評審范圍可以是全部內(nèi)容，也可以是增量或變更評審。如果選擇增量或變更評審，要注意檢查它們對軟件需求及下游架構(gòu)其余部分的影響。
進(jìn)一步地，我們給出一些checklist供參考。
-
是否遵循以下書寫需求的規(guī)則：
-
必須清楚地確定主體；
-
每個(gè)需求都是“原子”級別的；
-
每項(xiàng)需求都應(yīng)說得明確不含糊；
-
盡可能定量地表述需求；
-
描述系統(tǒng)在所有條件（如初始化、休眠、斷電、正常運(yùn)行、過壓、欠壓等）下的行為；
-
避免冗余和瑣碎；
-
使用一致的術(shù)語；
-
在適當(dāng)?shù)牡胤绞褂梅钦Z言描述，如流程圖。
-
不同的軟件需求之間沒有矛盾，以及與高層級需求與設(shè)計(jì)之間沒有矛盾？
-
軟件需求是否能夠覆蓋及滿足所追溯的需求與設(shè)計(jì)？
-
是否都使用內(nèi)部標(biāo)準(zhǔn)術(shù)語？
-
實(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)證方法是否明確?
-
是否有必要的需求屬性被遺漏?
......
5
全文小結(jié)
本文從以下幾個(gè)方面進(jìn)行了簡要解讀：
-
生成需求的4個(gè)步驟（分析、編寫、打基線、評審）。
-
需求所包含的4個(gè)基本屬性（類型、狀態(tài)、驗(yàn)證標(biāo)準(zhǔn)、配置）。
-
一份好需求的8個(gè)特點(diǎn)（完整性、可行性、可驗(yàn)證性、不含糊性、一致性、正確性、可理解性、可修改性）。
-
寫好需求的公式（前提、主體、強(qiáng)制性、方式及目標(biāo)）。
-
需求評審的4個(gè)角色及評審側(cè)重點(diǎn)。
-
需求評審的9條checklist。
6
寫在最后
從很多經(jīng)驗(yàn)看下來，一個(gè)做得爛的項(xiàng)目基本都有一套混亂的需求。當(dāng)想要治理項(xiàng)目時(shí)，幾乎都應(yīng)該從需求開始。
轉(zhuǎn)自汽車電子與軟件
