俗話說，“未能構建正確的產品或構建正確的產品”的成本會影響收入和聲譽。構建“正確產品”的唯一方法是開發既有效又可追溯到軟件的需求。這使開發團隊、質量保證 （QA） 和認證機構能夠檢查軟件中的任何功能，通過將其追溯到需求來確定其用途。

挑戰在于了解如何在當今動態市場條件和更短的發布時間驅動的快速變化的軟件面前保持需求可追溯性。了解雙向可追溯性并知道如何維護它可確保產品功能是合理的，反之，沒有理由地構建任何東西。

失敗的代價

如果客戶認為產品功能受到損害，并且如果出現召回或安全漏洞，則不可避免地會造成災難性的收入或聲譽損失。例如，特斯拉今年早些時候因與擋風玻璃除霜相關的軟件錯誤而召回了汽車[1]。在特斯拉的其他召回中，許多與自動駕駛有關，這說明了管理所有可能場景的復雜性，以及快速識別、修復和更新軟件以最大限度地降低成本和聲譽損害的需求。

Deepanshu Natani 在 Atlassian 社區發表的一篇文章“需求管理中的挑戰”寫道[2]：

“分析師報告說，多達71%的軟件項目失敗是因為需求管理不善，使其成為項目失敗的最大原因 - 比糟糕的技術，錯過最后期限或變更管理慘敗更大。

從編寫良好的要求開始

每個軟件項目的基礎都是它的需求。它們應該是精確和明確的，引導軟件開發朝著清晰、可測試且可追溯到特定目的的方向發展。

編寫要求有幾種方法，其中文本規范是最流行的方法。文本可以非常有效，包括使用通俗語言，以便更廣泛地理解更接近具體實施計劃的技術術語。

由于人類語言本質上是不精確的，容易產生歧義，因此需要高度的嚴謹性來克服可能的陷阱。將經過驗證的規則應用于需求有助于避免問題 - MISRA 編碼標準提供了這些規則的示例[3]：

使用段落格式將要求文本與非要求文本區分開來

每個段落僅列出一個要求

使用動詞“應”

避免在需求中使用“and”，并將重構視為多個需求

避免使用“除非”或“僅當”等條件，因為它們可能會導致模棱兩可的解釋

圖 1 列出了有效需求的十個屬性。

[圖1.有效要求的十個屬性。（資料來源：LDRA）]

確保適當的需求可追溯性

必須實施所有要求。同樣，反之亦然——所有源代碼（和所有測試）都應該可以追溯到設計，并最終追溯到需求（功能性或非功能性）。

當需求開始發生變化時，挑戰就來了。若要快速有效地管理更改的影響，需要修改相關要求或添加新要求，請務必了解如何在代碼中反映更改以及驗證更新所需的測試中。

圖 2 說明了需求和測試之間的典型關系[4]。在這里，系統級需求 （SLR） 應該可追溯到高級需求 （HLR），而高級需求又可追溯到低級需求 （LLR）。HLR 可追溯到高級測試 （HLT），LLR 可追溯到低級別測試 （LLT）。

這種雙向可追溯性使團隊能夠看到從需求規范到構建、測試、更改和返回的可見性（圖 2）。

[圖2.不同類型需求之間的典型可追溯性結構。（資料來源：LDRA）]

在不失去可追溯性的情況下管理變更意味著需求和測試的耦合必須自動化 - 這也使得了解測試和需求變更的上游和下游影響變得簡單。

驗證需求滿足情況

證明系統滿足要求有助于量化“構建了正確的系統”。這有兩種風格：

使用單元測試來證明應用程序組件單獨滿足其各自的目的

使用集成測試來顯示應用程序的各個部分作為一個整體協同工作

自動化和自動化工具通過將單元和集成測試與其適當的要求聯系起來并報告履行情況，而無需耗時的手動工作，從而提供幫助。圖 3 說明了需求管理平臺中的兩個場景[5]：

HLR_100 –綠點表示滿足要求，反映了已驗證關聯的高級測試 （TCI_HLT_100） 和低級別要求（LLR_104 到 LLR_109）的事實。

HLR_101 –紅點表示需求未滿足，反映低級別需求LLR_103由于低級別測試TCI_LLT_103失敗而未滿足的事實。

[圖3.使用自動化工具報告需求履行情況。（資料來源：LDRA）]

在后一種情況下，失敗的測試具有關聯的測試用例文件，可以使用單元測試工具和關聯的回歸報告進行回歸，以幫助了解測試失敗的原因。

確定結構覆蓋率

結構覆蓋率是嵌入式軟件中的一個重要概念，因為它保證了整個代碼庫已得到一致和充分的執行。作為 ISO 26262、DO-178B 和 IEC 62304 等標準的關鍵準則，結構覆蓋可幫助開發人員檢測和刪除死代碼，而質量保證 （QA） 則使用它來確定缺失的測試用例。在這兩種情況下，將此覆蓋范圍追溯到需求有助于確保每個已實現的組件都有一個原因，并確定尚未實現的要求。

自動化有助于確定結構覆蓋率，顯示隨著基于需求的測試完成而執行代碼的哪些部分[6]。圖 4 展示了一個測試驗證報告，其中顯示了不同類型的覆蓋指標的結果：

[圖4.使用自動化工具報告結構覆蓋率（來源：LDRA）]

陳述–在執行應用程序時執行的語句數，占該應用程序中語句總數的百分比。100% 覆蓋率意味著所有語句在測試期間至少執行過一次。

分支/決策 –在執行應用程序時執行的分支數占該應用程序中語句總數的百分比。

單聲道/直流 –修改條件/決策覆蓋率 （MC/DC） 衡量決策陳述中的所有條件是否至少對所有可能的結果進行一次評估，以及所有這些條件是否獨立地影響決策的結果。

圖 5 顯示了這些測試與其相關的低級需求之間的映射，以形成可追溯性矩陣。在此示例中，所有要求 （LLR_*） 均已使用測試 （TCI_LLT_*） 進行驗證。這種類型的報告只能通過應用此處討論的可追溯性原則來實現。

[圖5.一個可追溯性矩陣，顯示映射到測試用例的需求驗證。（資料來源：LDRA）]

可追溯性確保制造出“正確”的產品

團隊絕不能將系統和軟件要求降級到貨架軟件中。隨著產品變得越來越復雜，軟件更新的頻率越來越高，需求可追溯性對于最大限度地降低風險仍然是相關性和必要的。

了解需求實施和測試的方式和位置可確保軟件適合用途。在軟件更改中保持這種意識可確保開發人員了解對代碼和測試的影響，而無需花時間搜索它們。

自動化是動態保持雙向需求可追溯性并確保產品“正確構建”的唯一現實方法。沒有它，團隊將花費太多時間試圖手動解決，從而導致成本增加和下游的潛在問題。

審核編輯：郭婷