因此，軟件開發過程都是經過深思熟慮、計劃、記錄、結構化和到位的。您已經在測試工具上投入了大量資金，這些工具可以生成您可能需要的盡可能多的工件。您有來自靜態分析、動態分析、功能測試、單元測試、對象代碼驗證的報告。沒有任何機會。一切都準備就緒，為評估小組的猛攻做好了準備。帶上它！

（輪胎在以每小時一百英里的速度行駛后尖叫停止的聲音。

DO-178B/C 充斥著對可追溯性的引用，而您的傳統測試文檔都沒有提供可追溯性。更重要的是，可追溯性必須雙向工作——下游（需求到實施）和上游（植入到需求）。“雙向可追溯性”可能只是一個兩個字的短語，但當涉及到軍事嵌入式系統時，它卻是一個沉重的打擊。為了理解它的重要性，讓我們看看軟件的演變。

幾十年前，瀑布式流程以其獨特的分析、設計、編碼和測試階段主導了軟件開發。該理論是每個階段都將獨立執行，一個階段的輸出是下一個階段的輸入。預期的結果是一個通過所有測試的工作系統。

使用瀑布式方法，分析階段的目的是完善利益相關者對系統的愿景，并生成需求列表，軟件需求規范 （SRS） 中逐項列出軟件需求。如果你能自豪地把它展示在你的書架上，你就是一個人！

當然，在印刷運行完成之前，由于新發現的錯誤或歧義，SRS 就已經過時了。無論項目經理多么希望SRS沒有錯誤，但事實并非如此。更改日志的大小將開始增加，直到新的打印運行變得不可避免。SRS落后于現實，錯誤是生活中的事實。

如今，需求可追溯性被廣泛接受為開發最佳實踐。它確保實現所有需求，并且所有開發工件都可以追溯到一個或多個需求。然而，盡管有良好的意圖，許多項目仍然陷入一種脫節的軟件開發模式，其中需求、設計、實現和測試階段彼此隔離——這通常被稱為“孤島效應”。這種隔離導致需求、開發階段和/或開發團隊之間的聯系變得脆弱。

要使軟件開發被認為是完整的，您必須包含可幫助您實現“雙向可追溯性”的工具。。需求本身需要清晰明確，也許可以通過用例或用戶故事來輔助。自動檢查需求規范可以通過確認是否存在特定關鍵字以及不存在不精確的短語來提供幫助。

有了由此產生的精確需求，使用跟蹤鏈接從需求到特定的代碼行，然后到該代碼的測試等等。..。..在整個生命周期中，可以通過確認范圍內的所有需求都已實現，并且所有設計或實現元素都可以追溯到需求來實現雙向可追溯性。更重要的是，對那些跟蹤鏈接的自動報告可確保需求維護永遠不會成為次要問題。

需求是每個項目的基礎。薄弱的基礎會導致大量缺陷、不可預見的補救工作、螺旋式上升的成本和錯過最后期限。對需求管理的投資應與設計和編碼處于同等地位。需求可追溯性為構建成功的項目奠定了堅實的基礎。如果沒有這個基礎，即使是配備最佳測試工具的項目也可能存在缺陷。

審核編輯：郭婷