軟體需求規格檔案是軟體開發流程中不可或缺的基礎，它清晰地定義了軟體系統的功能和非功能性需求，確保開發團隊與客戶對專案目標達成共識。一份優良的需求規格檔案應具備正確性、一致性、可行性、必要性及明確的優先順序，並避免任何含糊不清或容易產生歧義的描述。此外，完整性也是至關重要的，所有需求都必須完整記錄，不得遺漏任何待定專案。良好的需求規格檔案應使用精確的技術詞彙，並遵循業界標準，例如 IEEE 830-1998，以確保檔案的可讀性和可維護性，有效引導開發團隊進行軟體設計、實作和測試。
良好需求規格的特性
本章節將討論構成良好需求規格的屬性。
正確性
需求規格必須正確無誤，這一點不言而喻。然而，研究顯示，大約40%的專案成本是由於需求規格錯誤所導致。因此，花時間審查需求規格並糾正錯誤，是確保軟體品質最具成本效益的方法之一。
一致性
需求規格之間必須保持一致性，即一個需求規格不能與另一個相矛盾。例如，如果一個泳池溫度監控器規定，當溫度低於70度時須觸發警示，而另一個規定則指出，當溫度低於65度時觸發同一個警示，這兩個需求規格就是不一致的。
可行性
如果無法實際實作某個軟體需求，那麼它就不能被視為真正的需求。需求規格闡述了提供令人滿意的軟體解決方案所需完成的任務；如果某項需求不可行，那麼也就無法提供該軟體解決方案。
必要性
根據定義，如果某個軟體需求並非必要，那麼它就不是真正的需求。實作需求規格需要付出成本，包括檔案撰寫、程式碼編寫、測試程式和維護等，因此，除非某項需求是必要的，否則不應將其納入其中。不必要的需求往往是由於「錦上添花」或新增某些被認為「很酷」的功能而產生的，卻未考慮實作這些功能所需的成本。
一項需求是必要的，如果它：
- 使產品在市場上具有競爭力；
- 滿足客戶、終端使用者或其他利益相關者表達的需求；
- 使產品或使用模式與眾不同；
- 由商業策略、路線圖或可持續性需求所規定。
優先順序
軟體需求規格闡述了開發所需應用程式所需完成的所有任務。然而，由於各種限制（時間、預算等），可能無法在軟體的第一個版本中實作所有需求。此外，隨著時間的推移（以及資金的耗費），某些需求可能會因情況變化而被放棄。因此，一個良好的需求規格應具有相關的優先順序。這有助於推動開發進度，因為團隊會首先實作最關鍵的功能，並將次要功能安排在專案開發週期的後期。通常，三到四個優先順序別就足夠了，例如：關鍵/必備、重要、理想和可選。
完整性
一個良好的需求規格應該是完整的，即不包含任何待定（TBD）專案。
無歧義性
需求規格必須不會被誤解（注意，TBD是一種特殊的歧義情況）。無歧義意味著一個需求規格只有一種解釋。
由於大多數需求規格都是以自然語言（如英語）撰寫的，而自然語言本身具有歧義性，因此，在撰寫需求規格時必須特別小心，以避免產生歧義。
歧義需求的例子：
當泳池溫度過低時，軟體應發出警示。
無歧義的例子：
當泳池溫度低於65華氏度時，軟體應發出警示。
歧義通常是由以下自然語言特徵引起的：
- 模糊性：在需求規格中使用弱詞（即沒有明確含義的詞語）。
- 主觀性：不同的人會根據自己的個人經驗或意見對某個詞語（弱詞）賦予不同的含義。
- 不完整性：在需求規格中使用待定專案、部分規格或無界列表。
- 可選性：使用使需求成為可選而非必需的短語（例如，“是由…引起的”、“使用…”、“應該”、“可能”、“如果可能”、“在適當的情況下”、“按照期望”）。
- 欠缺具體性：需求規格未完全闡述要求，通常是由於使用了弱詞（例如，“支援”、“分析”、“回應”、“根據”）。
例如，考慮以下需求：
泳池監控器應支援華氏和攝氏溫標。
在這種情況下，“支援”究竟意味著什麼？一位開發者可能會將其理解為終端使用者可以選擇以華氏或攝氏度作為輸入和輸出的單位（固定的），而另一位開發者則可能理解為輸出同時使用兩種溫標，並且輸入允許使用任一溫標。更好的表述方式可能是：
泳池監控器的設定應允許使用者選擇華氏或攝氏溫標。
其他導致歧義的因素還包括：
- 參照不完整：對其他檔案的參照不完整或缺失。
- 過度概括：使用諸如“任何”、“所有”、“總是”和“每個”等全稱量詞，或在否定意義上使用“沒有”、“永不”和“僅僅”。
- 難以理解：由於寫作不佳（語法）、未定義的術語、複雜的邏輯（例如雙重否定）和不完整性導致難以理解。
- 被動語態：未指定執行某項動作的主體。例如，一個不良的需求可能寫作：
如果溫度低於65華氏度，應發出警示。
誰負責發出警示？不同的人可能會對此有不同的理解。更好的表述方式是：
泳池監控器軟體應在溫度低於65華氏度時發出警示。
在需求規格中使用弱詞通常會導致歧義。弱詞的例子包括：“支援”、“一般”、“種類別”、“大多數”、“相當”、“稍微”、“有點”、“各種”、“幾乎”、“快速”、“容易”、“及時”、“之前”、“之後”、“使用者友好”、“有效”、“多個”、“盡可能”、“適當”、“正常”、“能力”、“可靠”、“最先進”、“毫不費力”和“多”。
例如，像“泳池監控器應提供多個感測器”這樣的一個需求是有歧義的，因為“多個”是一個弱詞。它究竟是什麼意思？兩個？三個？一打？
另一種產生歧義的方法是使用無界列表——即缺少起始點、終止點或兩者都缺失的列表。典型的例子包括類別似“至少”等短語；“包括但不限於”；“等等”；以及“等”。
撰寫優良需求規格的重要性與特性
撰寫優良的需求規格對於軟體開發專案的成功至關重要。優良的需求規格必須具備多項特性，以確保開發的系統能夠符合使用者的需求和預期。
1. 明確性與無歧義性
需求規格必須明確且無歧義，避免使用模糊或容易被誤解的語言。例如，對於「池塘監控器應支援三個或更多感測器」這樣的需求，需要明確最大支援的感測器數量。更好的寫法是「池塘監控器必須支援三到六個感測器」。
2. 完整性與一致性
需求規格必須完整涵蓋所有必要的系統功能和特性，並且內部保持一致。無界列表（unbounded lists）是不可行的，因為它們無法被設計和測試。
3. 獨立於實作
需求規格應該僅根據系統的輸入和輸出，而不涉及具體的實作細節。這樣可以給軟體設計者更多的靈活性。例如，需求可以規定系統輸入一串數字後輸出排序後的列表，但不應該指定使用某種特定的排序演算法，如快速排序。
4. 可驗證性
需求規格必須是可驗證的，也就是說，可以設計測試來檢查系統是否符合該需求。「如果無法測試，就不是需求」是一個重要的準則。如果無法為某項需求設計實際的測試，可能意味著該需求不是根據系統的輸入和輸出。
5. 原子性
每個需求規格應該是獨立且不可再分的，避免將多個需求合併成一個複合需求。使用「和」或「或」等連線詞時需要小心，以避免形成複合需求。例如，「池塘監控器應在溫度低於70華氏度或高於85華氏度時清除『良好』指示」是一個複合需求，應拆分為兩個獨立的需求。
6. 唯一性與可修改性
需求規格中不應有重複的需求，以避免維護困難。同時，需求規格應該是可修改的，以適應專案過程中可能發生的變化。
7. 可追溯性
所有需求都應該是可追溯的，既可以向前追溯到相關檔案，也可以向後追溯到其來源。這需要為每個需求分配一個唯一的識別符號。
8. 積極陳述
需求應該以積極的方式陳述，即說明什麼是必須實作的，而不是什麼是不允許的。大多數消極陳述的需求是無法驗證的。
此圖示說明瞭撰寫優良需求規格的逐步流程，從開始到完成審查的全過程。
程式碼範例與內容解析
以下是一個簡單的程式碼範例，用於示範如何實作池塘監控器的溫度檢查功能：
def check_temperature(temp):
if temp < 70 or temp > 85:
return "不良"
else:
return "良好"
# 測試範例
print(check_temperature(75)) # 預期輸出：良好
print(check_temperature(60)) # 預期輸出：不良
內容解密：
check_temperature函式：此函式接受一個溫度值作為輸入，並根據溫度範圍傳回相應的狀態（「良好」或「不良」）。- 條件判斷：函式內部使用條件判斷陳述式檢查輸入溫度是否在70至85華氏度之間。如果不在此範圍內，則傳回「不良」；否則，傳回「良好」。
- 測試範例：透過兩個測試範例展示了函式的實際應用，分別測試了溫度在指定範圍內和外的情況。
這樣的程式碼實作直接對應了前文所述的需求規格，例如「池塘監控器應在溫度低於70華氏度或高於85華氏度時清除『良好』指示」。透過此範例，可以清楚地看到如何將需求轉化為具體的程式碼實作。
軟體需求規格檔案（SRS）製作
軟體需求規格檔案（Software Requirements Specification, SRS）是軟體開發過程中不可或缺的檔案，用於完整記錄軟體專案的所有需求和設計目標。本文將依據IEEE 830-1998推薦的SRS範本，詳細介紹如何製作一份完整的SRS檔案。
1. 簡介（Introduction）
簡介部分提供SRS檔案的整體概述，包括檔案的目的、範圍、定義、參考文獻以及概述。
1.1 目的（Purpose）
在目的章節中，需要明確SRS檔案的目的和預期讀者。SRS的主要讀者包括需要驗證需求的客戶以及將根據SRS進行軟體設計、測試和編碼的開發人員和設計師。
### 1.1 目的
本SRS檔案的目的是完整記錄軟體專案的需求和設計目標，供客戶驗證和開發團隊參考。
1.2 範圍（Scope）
描述軟體專案的範圍，包括軟體的功能、效能和其他相關特性。
1.3 定義、縮寫和簡稱（Definitions, Acronyms, and Abbreviations）
列出檔案中使用的專業術語、縮寫和簡稱，以避免誤解。
1.4 參考文獻（References）
列出與SRS相關的所有參考文獻，如相關標準、法規和其他技術檔案。
1.5 概述（Overview）
提供SRS檔案的整體結構和內容概述。
2. 整體描述（Overall Description）
本章節描述軟體的整體特性，包括產品視角、使用者特性、限制條件和假設。
2.1 產品視角（Product Perspective）
描述軟體產品在整個系統中的位置及其與其他系統元件的介面。
2.1.1 系統介面（System Interfaces）
描述軟體與其他系統元件之間的介面。
2.1.2 使用者介面（User Interfaces）
描述軟體的使用者介面，包括螢幕佈局、按鈕功能等。
2.2 網站適應需求（Site Adaptation Requirements）
描述軟體在不同環境下的適應性需求。
2.3 產品功能（Product Functions）
列出軟體的主要功能模組。
2.4 使用者特性（User Characteristics）
描述預期使用軟體的使用者特性，包括技能水平和經驗。
2.5 限制條件（Constraints）
列出影響軟體開發的任何限制條件，如技術限制或法規限制。
3. 具體需求（Specific Requirements）
本章節是SRS的核心，詳細列出了所有功能需求、效能需求和其他特定需求。
3.1 外部介面（External Interfaces）
描述軟體與外部系統或裝置的介面需求。
3.2 功能需求（Functional Requirements）
詳細描述軟體的功能需求，包括輸入輸出處理邏輯等。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 軟體需求規格撰寫最佳實務
package "系統架構" {
package "前端層" {
component [使用者介面] as ui
component [API 客戶端] as client
}
package "後端層" {
component [API 服務] as api
component [業務邏輯] as logic
component [資料存取] as dao
}
package "資料層" {
database [主資料庫] as db
database [快取] as cache
}
}
ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取
note right of api
RESTful API
或 GraphQL
end note
@enduml
此圖示說明瞭使用者輸入如何被系統處理並產生輸出結果的流程。
3.3 效能需求（Performance Requirements）
描述軟體的效能需求，如回應時間、吞吐量等指標。
#### 內容解密：
此章節需詳細闡述效能指標的具體要求，例如：
- 系統需在0.5秒內回應使用者請求。
- 系統需支援每秒100筆交易的處理能力。 這些指標需根據實際應用場景進行定義，以確保系統能夠滿足使用者需求並保持高效運作。
軟體需求規格檔案（SRS）撰寫
撰寫一份完善的軟體需求規格檔案（SRS）是軟體開發過程中至關重要的一步。IEEE 提供了 SRS 的標準結構，幫助開發團隊確保需求的完整性和清晰度。
SRS 結構概述
根據 IEEE 的建議，SRS 主要分為兩個部分：簡介和整體描述。
簡介
簡介部分主要介紹軟體產品的基本資訊，包括：
- 目的：說明檔案的目的和預期讀者。
- 範圍：描述軟體產品的功能、目標和應用範圍。
- 定義、縮寫和縮略語：提供檔案中使用的術語和縮寫的解釋。
- 參考文獻：列出與 SRS 相關的外部檔案和資料來源。
- 概述：描述 SRS 的結構和內容。
整體描述
整體描述部分則詳細闡述軟體產品的需求，包括：
產品視角：將軟體產品置於更大的系統中，描述其與其他產品的關係和介面需求。
- 系統介面：描述軟體與系統其他部分的介面，如 API。
- 使用者介面：列出實作需求所需的使用者介面元素。
- 硬體介面：描述軟體與底層硬體的互動，如感測器連線。
- 軟體介面：列出實作系統所需的外掛軟體，如作業系統或第三方函式庫。
- 通訊介面：描述產品使用的通訊介面，如 Wi-Fi 或藍牙。
- 記憶體限制：描述對記憶體和資料儲存的限制。
- 操作：描述產品的各種操作模式和功能。
現場適應需求：描述任何與特定安裝或組態相關的需求。
產品功能：詳細描述軟體的主要功能。
使用者特徵：描述將使用該產品的使用者型別及其相關需求。
限制：列出可能影響設計和實作的限制，如法規政策、硬體限制等。
假設和依賴：列出對需求的假設，如果這些假設改變，將需要修改需求。
撰寫 SRS 的最佳實踐
- 明確和簡潔：確保所有需求都清晰、簡潔，避免模糊不清的表述。
- 完整性：確保 SRS 包含所有必要的資訊，無論是功能性還是非功能性的需求。
- 一致性：確保 SRS 中的需求之間沒有衝突。
- 可驗證性：確保所有需求都是可驗證的，即可以透過測試或其他方法確認是否滿足需求。
程式碼範例與解說
// 定義感測器讀取函式
int readSensorData(int sensorPin) {
// 讀取模擬輸入
int sensorValue = analogRead(sensorPin);
// 將讀取值轉換為實際物理量
float actualValue = convertToPhysicalQuantity(sensorValue);
return actualValue;
}
內容解密：
readSensorData函式的作用：此函式用於從指定的感測器引腳讀取資料。它首先使用analogRead函式讀取模擬輸入值，然後呼叫convertToPhysicalQuantity函式將讀取值轉換為實際的物理量（如溫度或壓力）。analogRead的使用：此函式用於讀取 Arduino 板上的模擬輸入引腳，傳回一個介於 0 和 1023 之間的值，代表輸入電壓相對於參考電壓的大小。convertToPhysicalQuantity的作用：這個函式（未在此程式碼中顯示）負責將原始的模擬讀取值轉換為有意義的物理量，如攝氏度或巴斯卡。這通常涉及到線性或非線性轉換，取決於感測器的特性。
軟體需求檔案規範詳解
軟體需求檔案（Software Requirements Specification, SRS）是軟體開發過程中不可或缺的重要檔案，用於詳細描述軟體系統的功能性與非功能性需求。本章節將探討SRS的各個組成部分及其規範。
需求檔案的組成結構
SRS主要包含三大部分：簡介、整體描述和特定需求。每個部分都有其特定的撰寫重點和技術要求。
簡介部分
簡介部分主要介紹檔案的目的、範圍和定義。它為讀者提供了理解檔案的基礎框架。
整體描述
整體描述部分闡述了軟體產品的視角、功能概覽和使用者特性。這部分內容需要結合具體的案例，透過深度分析呈現產品的整體架構和設計考量。
特定需求
特定需求是SRS的核心內容，詳細列出了軟體系統的所有需求和支援檔案。這些需求應該具備可追溯性、明確性和可測試性。
外部介面需求
外部介面需求描述了軟體系統的所有輸入和輸出詳細資訊，包括資料格式、命令格式和通訊協定等。這些資訊對於系統設計師構建軟體設計至關重要。
### 外部介面範例
- 標籤
- 描述
- 輸入來源或輸出目的地
- 有效值範圍及必要的準確度/精確度/容忍度
- 測量單位
- 時序和容忍度
- 與其他輸入/輸出項的關係
- 畫面/視窗格式
- 資料格式
- 命令格式、協定及必要的哨兵訊息
功能性需求
功能性需求列出了軟體系統的基本活動及其對輸入的處理方式。這些需求通常包含輔助動詞「shall」，例如：「當水池低輸入啟動時，軟體應發出警示。」
### 功能性需求範例
1. 輸入有效性檢查及對無效輸入的回應
2. 操作順序
3. 異常狀況回應，包括溢位、下溢、算術例外、通訊失敗、資源過載、錯誤處理和還原等
4. 資料在軟體執行過程中的永續性
5. 引數的效果
6. 輸入/輸出關係，包括合法和非法的輸入模式、輸入與輸出的關係以及輸出如何從輸入計算而來
效能需求
效能需求規定了軟體系統必須達到的靜態或動態效能目標。例如：「軟體必須能夠控制內部顯示和遠端顯示。」靜態效能需求與系統整體相關，而動態效能需求則關注軟體執行期間的表現。
### 效能需求範例
1. 軟體必須能夠從5到10個類別比感測器讀取感測器輸入資料（靜態需求）
2. 軟體必須每秒讀取每個感測器10到20次（動態需求）
邏輯資料函式庫需求
邏輯資料函式庫需求描述了應用程式必須存取的資料函式庫的記錄和欄位格式。這部分內容通常涉及外部存取的資料函式庫。
設計約束
設計約束列出了限制軟體設計師實施任意實作的條件，例如標準相容性或硬體限制。
標準相容性
標準相容性部分描述了軟體必須遵守的所有標準，並提供相關標準檔案的連結。
軟體系統屬性
軟體系統屬性包括可靠性、可用性、安全性和可維護性等非功能性需求。
可靠性
可靠性描述了系統在無故障運作下的預期時間百分比，例如「預期可靠性為99.99%」。
可用性
可用性指定了在最終應用中可接受的停機時間，區分了排程停機和非排程停機。
安全性
安全性屬性規定了預期的系統安全，包括加密預期和網路通訊端型別等。
可維護性
可維護性是一個難以規範和測試的非功能性需求。有效的規範應該明確指出維護人員上手和進行變更所需的時間，例如「經驗豐富的維護程式設計師在一週內完成系統上手並進行變更。」