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

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

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

幾十年前，瀑布式流程以其獨特的分析、設(shè)計、編碼和測試階段主導(dǎo)了軟件開發(fā)。該理論是每個階段都將獨立執(zhí)行，一個階段的輸出是下一個階段的輸入。預(yù)期的結(jié)果是一個通過所有測試的工作系統(tǒng)。

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

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

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

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

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

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

審核編輯：郭婷