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