返回文章列表
玄貓（BlackCat）

軟體開發檔案型別與可追溯性

本文探討軟體開發過程中各種系統檔案的型別、相互關係以及可追溯性的重要性。從系統需求規格檔案 (SyRS) 到軟體測試程式檔案 (STP)，闡述瞭如何利用標籤系統和反向追溯性矩陣 (RTM)

軟體工程 系統設計
系統檔案 可追溯性 軟體需求 測試案例 需求管理 軟體設計

在軟體開發專案中，維護清晰且一致的系統檔案至關重要。這些檔案不僅記錄了專案的各個導向，也作為不同團隊成員之間溝通的橋樑。從系統層級的需求到具體的測試程式，每種檔案型別都扮演著不可或缺的角色。建立檔案之間的可追溯性，能有效管理需求變更帶來的影響，確保軟體的品質和一致性。良好的檔案管理習慣能減少後續的修改成本，並提升團隊協作效率。台灣軟體開發團隊經常面臨檔案不足或更新不及時的挑戰，本文提供的檔案型別與可追溯性管理方法，能有效改善這些問題，建立更穩健的開發流程。

系統檔案型別與可追溯性在軟體開發中的重要性

在傳統的軟體工程領域中，系統檔案的撰寫是一項不可或缺的工作。這些檔案不僅有助於確保軟體開發的品質，也使得專案管理與溝通變得更加順暢。本篇文章將探討常見的系統檔案型別及其相互關係，並重點分析可追溯性在軟體開發過程中的關鍵作用。

常見的系統檔案型別

  1. 系統需求規格檔案（SyRS）
    SyRS 是一份系統層級的需求檔案，涵蓋了軟體需求以外的硬體、業務、程式、手動操作等相關需求。它為客戶、管理階層和利害關係人提供了一個「大圖景」視角，省略了過多的技術細節。

  2. 軟體需求規格檔案（SRS）
    SRS 從 SyRS 中提取出軟體相關的需求，並進一步細化這些需求，為軟體工程師提供了足夠的細節。這份檔案專注於軟體層面的需求。

  3. 軟體設計描述檔案（SDD）
    SDD 詳細闡述了系統將如何被構建，描述了軟體的設計結構和實作方案。理論上，任何程式設計師都可以根據 SDD 來編寫對應的程式碼。

  4. 軟體測試案例檔案（STC）
    STC 描述了用於驗證系統是否滿足所有需求的各種測試值，同時也確保系統在需求列表以外也能正確運作。

  5. 軟體測試程式檔案（STP）
    STP 詳細說明瞭如何有效地執行 STC 中的測試案例，以驗證系統的正確運作。

  6. 需求（或反向）可追溯性矩陣檔案（RTM）
    RTM 將需求與設計、測試案例和程式碼進行關聯，使得利害關係人能夠確認某項需求是否在設計和程式碼中得到了正確的實作，並且相關的測試案例和程式也正確地檢查了該需求的實作。

各檔案之間的依賴關係

這些檔案之間的關係可以用圖 9-1 表示：

SyRS --> SRS --> SDD
       |
       |
---
> STC --> STP

SRS 是根據 SyRS 編寫的，而 SDD 和 STC 則是根據 SRS 產生的。STP 的編寫則依賴於 STC。這種依賴關係表明了軟體開發過程中的階段性和連貫性。

可追溯性的重要性

在軟體開發過程中，保持系統檔案的一致性是一項巨大的挑戰。當某項需求變更時，可能需要同步更新 SDD、STC 和 STP 中的相關內容。為了應對這一挑戰，引入了「可追溯性」的概念。可追溯性允許開發團隊輕鬆地從一份檔案追蹤到其他相關的檔案。例如，從需求追蹤到設計元素、測試案例和測試程式，或者反過來從測試程式追溯到對應的測試案例和需求。

可追溯性的實踐意義

  • 提高變更管理的效率：當需求變更時，能夠迅速定位並更新相關的設計、測試案例和程式碼。
  • 增強軟體品質：透過確保所有需求都被正確地實作和測試，減少遺漏或錯誤。
  • 促進溝通與協作：不同角色的團隊成員可以透過可追溯性鏈條，更好地理解彼此的工作內容和依賴關係。
此圖示

此圖示展示了不同系統檔案之間的依賴關係。SRS 由 SyRS 產生，而 SDD 和 STC 則根據 SRS。同時，STC 也會受到 SDD 的一定影響，並最終用於指導 STP 的編寫。透過這種視覺化的方式，我們可以更直觀地理解各檔案之間的關聯。

系統檔案中的追溯性與反向追溯性實作

在系統開發過程中，保持需求、設計元素、測試案例及測試程式之間的追溯性（Traceability）至關重要。這不僅能確保各階段的一致性，也能幫助專案團隊在變更發生時快速定位相關檔案。

為何需要追溯性與反向追溯性

  • 追溯性：允許從需求、設計到測試的完整鏈條追蹤，確保每項需求都有相應的測試案例。
  • 反向追溯性：可以從測試結果反推至原始需求，確認變更是否影響既有測試案例或需求。

如何在檔案中建立追溯性

  1. 使用標籤（Tags）：為需求、設計元素、測試案例等檔案內容建立唯一標籤。

    • 標籤格式可自訂，但需保持一致性，如使用段落編號或描述性文字。
    • 常見做法是使用段落編號，但需注意跨檔案參照的支援問題。

  2. 建立需求/反向追溯性矩陣（RTM）：一張表格用於追蹤系統檔案中各元素之間的關聯。

    • RTM提供完整且易用的機制來管理系統元件間的關係。
    • 雖然需要額外維護，但能有效提升追溯效率。

標籤格式規範

系統需求規格檔案（SyRS）標籤

  • 格式：[產品ID_SYRS_編號]
  • 範例：[POOL_SYRS_001]
  • 說明：
    • 產品ID：簡短產品或專案代號，如「POOL」。
    • SYRS：表示來源為SyRS檔案。
    • 編號：唯一識別碼，可使用小數點分隔的多個整數（如001.1）來擴充層級。

實際應用範例

假設有以下SyRS需求：

[POOL_SYRS_001]: 泳池溫度監控
系統應監控泳池溫度。

[POOL_SYRS_002]: 最高泳池溫度
若泳池溫度超過86華氏度，系統應開啟「高溫」LED燈。

後續新增需求時，可使用小數點擴充編號以保持相關需求的鄰近：

[POOL_SYRS_001]: 泳池溫度監控
系統應監控泳池溫度。

[POOL_SYRS_001.1]: 最低泳池溫度
若泳池溫度低於70華氏度，系統應開啟泳池加熱器。

[POOL_SYRS_001.2]: 加熱器關閉溫度
若泳池溫度達到70華氏度，系統應關閉泳池加熱器。

[POOL_SYRS_002]: 最高泳池溫度
若泳池溫度超過86華氏度，系統應開啟「高溫」LED燈。

程式碼示例與解析

以下是一個簡單的 Python 程式碼，用於生成 SyRS 標籤：

def generate_syrs_tag(product_id, number):
    return f"[{product_id}_SYRS_{number}]"

# 使用範例
print(generate_syrs_tag("POOL", "001"))  # 輸出：[POOL_SYRS_001]
print(generate_syrs_tag("POOL", "001.1"))  # 輸出：[POOL_SYRS_001.1]

內容解密：

  1. generate_syrs_tag 函式：此函式接受兩個引數，分別是 product_id 和 number，用於生成符合 SyRS 格式的標籤。
  2. product_id：代表產品或專案的簡短代號，例如「POOL」。
  3. number：代表需求的編號，可以是簡單數字（如「001」）或帶有層級結構的編號（如「001.1」）。
  4. f-string 格式化：使用 Python 的 f-string 功能，將輸入引數嵌入字串中，形成完整的 SyRS 標籤格式 [產品ID_SYRS_編號]。
  5. 範例輸出：展示如何使用該函式生成不同型別的 SyRS 標籤，便於在檔案中參照相關需求。

最佳實踐與建議

  • 保持標籤一致性：確保所有檔案中使用的標籤格式統一，便於跨檔案參照。
  • 合理規劃編號：使用小數點擴充機制或預留編號間隙，以便未來插入新需求時保持檔案結構清晰。
  • 定期維護RTM：更新需求/反向追溯性矩陣，以反映最新的檔案變更與關聯。

綜上所述，在系統檔案中建立良好的追溯性與反向追溯性機制，不僅能提升專案的可維護性，也能增強團隊對變更的管理能力。透過合理的標籤設計與RTM維護，可以有效降低專案風險並提高交付品質。

系統檔案標籤管理規範

在系統檔案管理中，標籤（Tags）的使用對於追蹤需求（Requirements）和反向追溯（Reverse Traceability）至關重要。本篇檔案將詳細闡述不同檔案型別中的標籤使用規範，包括系統需求規格（SyRS）、軟體需求規格（SRS）、軟體設計描述（SDD）以及軟體測試案例（STC）。

SyRS 標籤

SyRS 標籤用於標識系統需求，其格式為 [產品ID_SYRS_xxx]，其中 xxx 為需求編號。例如：

  • [POOL_SYRS_017]: 當泳池溫度超過 70 華氏度時，系統應關閉泳池加熱器。
  • [POOL_SYRS_020]: 當泳池溫度超過 86 華氏度時，系統應開啟「高溫」LED。

SRS 標籤

對於僅包含 SRS 的檔案集，可以使用 [產品ID_SRS_xxx] 的格式。然而，當檔案集同時包含 SyRS 和 SRS 時，為了實作從 SRS 到 SyRS 的反向追溯，SRS 標籤的格式應為 [產品ID_SRS_xxx_yyy]。

  • xxx 對應於相關的 SyRS 標籤編號。
  • yyy 是 SRS 標籤的值。

有效的 SRS 標籤範例包括：

  • [POOL_SRS_020_001]
  • [POOL_SRS_020_001.5]
  • [POOL_SRS_020_002]

這種格式允許透過 xxx 值直接在 SyRS 檔案中查詢相關的 SyRS 需求。

程式碼範例

def check_pool_temperature(pool_temp):
    if pool_temp > 70:
        # 關閉泳池加熱器
        heater_status = "off"
    else:
        heater_status = "on"
    return heater_status

def check_high_temp_led(pool_temp):
    if pool_temp > 86:
        # 開啟「高溫」LED
        led_status = "on"
    else:
        led_status = "off"
    return led_status

內容解密：

  1. check_pool_temperature 函式根據泳池溫度決定是否關閉加熱器。當溫度超過 70 華氏度時，傳回 “off” 狀態，否則保持 “on” 狀態。
  2. check_high_temp_led 函式檢查是否需要開啟「高溫」LED。當溫度超過 86 華氏度時，LED 狀態設為 “on”，否則設為 “off”。

SDD 標籤

由於 SRS 需求與 SDD 設計元素之間不一定存在一對多的關係，因此在 SDD 標籤中建立反向追溯較為困難。SDD 標籤的格式簡化為 [產品ID_SDD_ddd]，其中 ddd 是唯一的識別符。

STC 標籤

STC 標籤用於測試案例，其格式為 [產品ID_STC_xxx_yyy_zzz]。這允許從 STC 到 SRS，乃至 SyRS 的反向追溯。如果測試案例不根據任何 SRS 需求，可以使用保留的 xxx_yyy 值 000_000 或 *_*。

Plantuml 圖表範例

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 軟體開發檔案型別與可追溯性

package "NumPy 陣列操作" {
    package "陣列建立" {
        component [ndarray] as arr
        component [zeros/ones] as init
        component [arange/linspace] as range
    }

    package "陣列操作" {
        component [索引切片] as slice
        component [形狀變換 reshape] as reshape
        component [堆疊 stack/concat] as stack
        component [廣播 broadcasting] as broadcast
    }

    package "數學運算" {
        component [元素運算] as element
        component [矩陣運算] as matrix
        component [統計函數] as stats
        component [線性代數] as linalg
    }
}

arr --> slice : 存取元素
arr --> reshape : 改變形狀
arr --> broadcast : 自動擴展
arr --> element : +, -, *, /
arr --> matrix : dot, matmul
arr --> stats : mean, std, sum
arr --> linalg : inv, eig, svd

note right of broadcast
  不同形狀陣列
  自動對齊運算
end note

@enduml

此圖示展示了 SyRS、SRS、STC 之間，以及 SRS 與 SDD 之間的關係。

系統檔案追溯性管理

在軟體開發過程中，保持需求、設計、測試案例和測試程式之間的追溯性至關重要。這種追溯性確保了系統的每個部分都符合最初的需求，並且所有的變更都有跡可循。本篇文章將討論如何使用標籤和可追溯性矩陣（RTM）來實作這種追溯性。

標籤系統

標籤系統是用於識別和追溯不同檔案中的需求、設計專案、測試案例和測試程式的關鍵工具。這些標籤通常遵循特定的語法，以便於識別和排序。

STC 標籤

STC 標籤用於測試案例，它們通常具有特定的格式，如 POOL_STC_020_001_001。如果 STC 標籤採用 000_000 的數字形式，則不包含任何追溯性資訊。在這種情況下，需要使用其他方法來提供連結資訊，例如使用 :source 來描述測試案例的來源，或使用 RTM 來提供來源資訊。

STP 標籤

STP 標籤用於測試程式，它們與 STC 標籤具有多對一的關係。這意味著一個 STP 標籤可以對應多個 STC 標籤。STP 標籤的語法為 [productID_STP_ppp]，其中 productID 是產品的識別符號，ppp 是唯一的 STP 標籤值。

可追溯性矩陣（RTM）

RTM 是一個二維矩陣或表格，用於建立不同檔案之間的連結。每行代表一個連結，每列代表一個特定的檔案型別（如 SyRS、SRS、SDD、STC 或 STP）。每個單元格中包含相應檔案型別的標籤。

RTM 的結構

RTM 的結構如下：

SyRS 標籤SRS 標籤SDD 標籤STC 標籤STP 標籤
POOL_SYRS_020POOL_SRS_020_001POOL_SDD_005POOL_STC_020_001_001POOL_STP_005
POOL_SYRS_020POOL_SRS_020_002POOL_SDD_005POOL_STC_020_002_001POOL_STP_005

RTM 的排序和追溯

RTM 可以根據不同的列進行排序，以實作不同的追溯目標。例如，根據 SyRS 和 SRS 標籤排序可以得到按需求排序的檔案列表；根據 SDD 標籤排序可以得到按設計元素排序的檔案列表。

新增欄位和排序

除了基本的檔案型別欄位外，還可以新增其他欄位來提供額外的資訊，例如描述、分配和驗證方法。這些額外的欄位可以幫助更好地理解和管理追溯性資訊。

新增欄位

  • 描述欄位：用於描述相關的標籤或需求。
  • 分配欄位：用於指定 SyRS 專案是硬體、軟體還是其他。
  • 驗證欄位：用於描述如何驗證特定的需求。

排序 RTM

RTM 可以根據不同的欄位進行排序，以實作不同的追溯目標。例如，根據 SyRS 和 SRS 標籤排序，然後根據 STC 和 STP 標籤排序，可以得到按需求和測試案例排序的檔案列表。

軟體開發過程中的驗證、確認與審查

在軟體開發過程中，驗證（Verification）與確認（Validation）是兩個至關重要的步驟。驗證是指確保產品符合專案規格的過程，而確認則是確保產品滿足終端使用者需求的過程。兩者缺一不可，共同保證了軟體產品的品質。

驗證與確認的差異

  • 確認（Validation）：確認的目的是確保開發的產品是正確的，即「我們是否正在建造正確的產品？」。這個過程通常發生在需求階段結束時以及整個開發週期的結束時。
  • 驗證（Verification）：驗證則是確保產品按照專案規格正確建造的過程，即「我們是否正在正確地建造產品？」。驗證通常在軟體開發過程中的每個階段結束時進行，以確保該階段滿足所有輸入需求。

各階段的驗證步驟

  1. SyRS/SRS（系統需求規格/軟體需求規格）：確保檔案中包含的所有需求都完全覆寫了客戶提供的需求。
  2. SDD（軟體設計描述）：確保設計涵蓋了所有需求，輸入來自SRS中的需求。
  3. STC（軟體測試案例）：確保每個可測試的需求都有至少一個測試案例，輸入來自SRS中的需求。
  4. STP（軟體測試計畫）：確保所有測試案例都被測試程式所覆寫，輸入來自STC中的測試案例。

審查過程

在每個階段結束時，需要對產出的檔案進行審查。利用可追蹤性矩陣（RTM）可以有效地輔助審查過程。例如，在審查SDD時，可以查詢SRS中的每個需求，並驗證對應的設計元素是否正確實作了指定的需求。

程式碼審查的最佳實踐


#### 內容解密：
1. **逐一檢查輸入**：在審查程式碼時，最安全的做法是檢查該階段的所有輸入（如SDD和STC的需求，以及STP的測試案例），並在驗證後對每個輸入進行標記。
2. **確認輸出的正確性**：在審查過程中，不僅要檢查輸入是否被正確處理，還要確認輸出的正確性，例如檢查SRS中的每個需求是否合理，SDD中的設計專案是否正確。
3. **獨立審查**：為了獲得最佳結果，最好由非檔案作者的工程師進行最終的正式審查，或由第二位工程師參與審查過程，以避免作者因為過於熟悉專案內容而忽略錯誤或遺漏。

利用檔案降低開發成本

檔案成本往往佔據專案整體成本的一大部分。Steve McConnell在《Code Complete》（Microsoft Press, 2004）中指出，相對於需求階段，設計階段修正錯誤的成本是其3倍，編碼階段是5到10倍，而系統測試階段則高達10倍。

降低成本的有效方法

  1. 早期缺陷修正：早期發現並修正缺陷可以避免後續浪費在錯誤設計上的檔案編寫、編碼和測試工作。
  2. 全面檢查關聯專案：當在某個階段發現缺陷時，需要遍尋整個系統中與該缺陷相關的所有內容並進行編輯，這是一項費力的工作，並且容易遺漏，從而導致後續的不一致性和其他問題。

透過確認降低成本

在需求階段（SyRS和SRS開發期間）進行確認活動至關重要。透過要求客戶理解並批准所有需求，可以確保沒有不必要的需求，並且正在解決客戶的問題。這樣可以減少後續因需求變更或誤解導致的大量返工，從而節省成本。

軟體需求檔案的重要性與規範

軟體需求檔案是軟體開發過程中的基礎，它明確了軟體需要滿足客戶需求的功能和非功能性要求。需求檔案的重要性在於它定義了軟體必須執行的功能、效能要求以及運作的限制條件。

需求的來源與可追溯性

每個軟體需求都必須有其來源，這些來源可能包括更高層級的需求檔案、特定的使用案例檔案、客戶的工作宣告或客戶的口頭溝通等。需求的可追溯性是指能夠追蹤到需求的原始出處，如果無法做到這一點，那麼這個需求很可能是不必要的，應當被移除。

反向追溯矩陣（RTM）

反向追溯矩陣是一種檔案或資料函式庫，用於列出所有需求及其來源。透過RTM，可以輕易地識別需求的來源，以確定其重要性。

建議的需求格式

一個書面需求應該採用以下格式之一：

  • [觸發條件] 執行者應當 動作 物件 [條件]
  • [觸發條件] 執行者必須 動作 物件 [條件]

其中，方括號內的專案是可選的。應當（shall）表示功能性需求；必須（must）表示非功能性需求。

需求格式的解析

以範例需求為例：當水池溫度在40°F至65°F之間時，除非大氣溫度高於90°F，否則水池監控器應當關閉“良好”指示燈。

  • 觸發條件：指明需求何時生效的短語，如範例中的“當水池溫度在40°F至65°F之間時”。
  • 執行者：執行動作的人或事物，如範例中的“水池監控器”。
  • 動作：需求所引起的活動，如範例中的“關閉”。
  • 物件：被動作影響的事物，如範例中的“‘良好’指示燈”。
  • 條件：通常是阻止動作發生的負面條件，如範例中的“除非大氣溫度高於90°F”。

驗證與確認

在軟體開發過程中，驗證和確認是兩個重要的步驟。驗證是檢查軟體是否符合其規格和需求的過程，而確認則是確保軟體滿足客戶需求的過程。

驗證問題

在完成每個檔案後，應當提出以下問題進行驗證：

  1. 設計元件是否完全覆寫了SRS中的所有需求？
  2. 是否存在多對一或一對一的關係在需求和軟體設計元素之間？
  3. 軟體設計元素是否提供了一個準確的設計來實作給定的需求？

同樣，在測試案例和測試程式的建立過程中，也需要進行類別似的驗證，以確保測試案例和測試程式能夠正確地測試軟體是否滿足需求。

參考資料

對於想要進一步瞭解軟體需求相關知識的人，可以參考以下文獻：

  • IEEE Standard 830-1998: IEEE Recommended Practice for Software Requirements Specifications
  • Managing Software Requirements by Dean Leffingwell and Don Widrig
  • Software Requirements by Karl E. Wiegers
  • Code Complete by Steve McConnell

這些文獻提供了關於軟體需求規格、需求管理、軟體開發最佳實踐等方面的深入見解。