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