如何撰寫軟體需求文件 (附範本)

您還記得在學校讀過 19 世紀的小說，並想：「這還是同一種語言嗎？」 好吧，當您在辦公室中與技術型 AI 開發人員或網路專家 SEO 分析師進行協作時，很可能也有過這樣的想法。 要是有同事專用的 CliffsNotes 就好了。

有時候，組織中位於兩端的部門必須合作，即使他們使用不同的技術語言也是如此。 如果您曾經在跨職能團隊中工作過，您就知道讓每個人都能維持資訊同步是多麼具有挑戰性。 

軟體需求規格文件可以幫助專案經理、產品經理和業務分析師將高階概念分解為每個團隊成員在開發過程中都可以遵循的行動項目。 

什麼是軟體需求規範文件 (SRS)？

軟體需求規格 (SRS) 文件列出了未來專案的需求、期望、設計和標準。 這些包括決定專案目標的高階 Business 版要求、終端使用者要求和需求，以及產品在技術方面的功能。 簡單來說，SRS 詳細描述了軟體產品應該如何運作，以及您的開發團隊應該如何使其運作。

想像一下，您有一個很棒的應用程式構想。 您對於應用程式的功能和外觀有自己的願景，但您知道不能僅僅向開發人員提供口頭描述，並期望他們能夠符合您的期望。 這就是 SRS 的用武之地。

為什麼要使用 SRS？

若開發人員在建立新產品時沒有明確的指示，您可能會花費比預期更多的時間和金錢，才能讓軟體與您的想法相符。 

撰寫 SRS 文件有助於您將想法寫在紙上，並設定清晰的需求清單。 此文件成為產品的唯一事實來源，因此從行銷到維護的所有團隊都能維持資訊同步。 

由於軟體需求規範是動態文件，因此也可以作為產品開發流程中每個關係人之間的溝通點。 在任何軟體開發專案中，產品迭代都必然會發生，透過記錄 SRS 中的變更，所有相關方都可以在文件中驗證這些變更。 這將減少對產品需求的任何混淆。 

SRS 文件中應包含哪些內容

基本的 SRS 文件大綱有四個部分：引言、系統和功能需求、外部介面需求和非功能需求。

1. 簡介

SRS 介紹正是您所期望的，它是整個專案的 10,000 英尺視圖。 在撰寫引言時，請描述產品的目的、目標受眾以及受眾將如何使用產品。 在引言中，請務必納入：

• 產品範疇：範疇應與產品的整體 Business 版目標相關，若有多個團隊或承包商可以存取該文件，這一點尤為重要。 列出產品的優勢、目標和目的。 

• 產品價值：您的產品為什麼重要？ 它將如何幫助您的目標受眾？ 它將發揮什麼功能，或將解決什麼問題？ 問問自己，您的受眾將如何在產品中找到價值。 

• 目標受眾：描述您的理想受眾。 他們將決定產品的外觀和感受，以及您如何行銷產品。 

• 預期用途：想像一下您的受眾將如何使用您的產品。 列出您提供的功能，以及受眾根據其角色使用產品的所有可能方式。 納入使用案例以說明您的願景也是一個最佳作法。

• 定義和縮寫詞：每個產業或 Business 版都有其獨特的縮寫詞或術語。 請列出您在 SRS 中使用的術語定義，以確保所有各方都能理解您想表達的內容。

• 目錄：詳細的軟體需求規範文件可能會很長。 請附上目錄，協助所有參與者精確找到他們要找的內容。 

確保您的介紹清晰簡潔。 請記住，您的引言將是您 SRS 大綱其餘部分的指南，您希望使用該文件的每個人都能以相同的方式解讀。

2. 系統需求和功能需求

撰寫完簡介後，就可以更具體地說明了。 功能需求分解了系統的特性和功能，使您的系統能夠按預期執行。 

填寫詳細資料時，請使用您的概述作為參考，以確認您的需求符合使用者的基本需求。 根據您的產品，有數千個功能需求需要納入。 其中一些最常見的有：

• 如果/則行為

• 資料處理邏輯

• 系統工作流程

• 交易處理

• 行政功能

• 監管和合規需求

• 效能要求

• 每個畫面執行的操作詳細資料

如果這讓您感到不知所措，請嘗試一次處理一個需求。 您在 SRS 文件中納入的詳細資料越多，之後需要進行的疑難排解就越少。 

當您進入詳細的需求時，保持支援材料的一致性和易於遵循也同樣重要。 技術文件範本可以節省時間、減少錯誤，並確保從開發人員到終端使用者的每個人都有清晰、最新的說明。

3. 外部介面需求

外部介面需求是一種功能性需求，可確保系統與外部元件正確溝通，例如：

• 使用者介面：應用程式可用性的關鍵，其中包括內容呈現、應用程式導覽和使用者協助等組成部分。

• 硬體介面：系統軟體和硬體元件之間每個介面的特性，例如支援的裝置類型和溝通協定。  

• 軟體介面：產品與其他軟體元件之間的連線，包括資料庫、庫和作業系統。 

• 溝通介面：對於產品將使用的溝通功能的要求，例如電子郵件或內嵌表單。 

內嵌系統依賴於外部介面需求。 您應該納入螢幕版面配置、按鈕功能等內容，以及產品如何依賴於其他系統的描述。 

4. 非功能性需求 (NRF)

SRS 的最後一個區段詳細說明非功能性需求。 雖然功能性需求會告訴系統該做什麼，但非功能性需求 (NFR) 會決定系統如何實施這些功能。 例如，當客戶訂購您的產品時，功能性需求可能會告訴您的系統列印裝箱單。 NFR 將確保裝箱單列印在 4 x 6 英寸的白紙上，這是裝箱單的標準尺寸。 

儘管在不符合非功能性需求的情況下，系統仍可運作，但您可能會讓使用者或關係人存在風險。 這些需求可確保功能需求得到控制，因此它仍然包括產品可負擔性和易用性等屬性。 

最常見的非功能性需求類型稱為「Itys」。 分別是：

• 安全：確保您的軟體從使用者那裡收集的任何敏感資訊都受到保護所需的條件。 

• 工作量：產品目前和未來的儲存需求，包括系統如何擴展以滿足不斷增加的工作量需求的計劃。

• 相容性：軟體的最低硬體需求，例如對作業系統及其版本的支援。 

• 可靠性和可用性：您預期使用者使用軟體的頻率，以及在正常使用下的關鍵故障時間。 

• 可擴展性：系統仍能如預期運作的最高工作負荷。 

• 可維護性：您的應用程式應該如何使用持續整合，以便快速部署功能和錯誤修復。 

• 可用性：產品的使用難易度。 

其他常見的非功能性需求類型包括效能、法規和環境需求。 

軟體需求文件範本

準備好開始您自己的軟體開發企業了嗎？ 我們的 SRS 範本列舉了優質 SRS 文件的所有四個關鍵組成部分，為您和您的團隊提供關於您將開發的產品的深入解析。 請記得讓您的需求詳細、清晰且簡潔，以便所有各方都能有相同的願景。

撰寫 SRS 文件的最佳作法

SRS 的目的是讓每個部門的每個團隊都朝著明確的目標努力。 話雖如此，仍有一些最佳作法可遵循，以確保您的 SRS 符合其目的。

使用視覺材料豐富您的 SRS

納入圖表、圖解和模型等視覺材料，將有助於團隊成員更好地理解流程。 在說明軟體的主要功能和可操作性時，這些內容特別有用。 

在為專案進行腦力激盪時，可以嘗試的一種技術是心智圖，它可以組織想法、功能和情境，並畫出它們之間的連結。 當您開始將構想拼湊在一起時，請建立一個心智圖來組織隨機的想法。 此圖表不需要超級詳細，這就是您 SRS 的用途。 相反，請專注於軟體的關鍵功能以及它們之間的關係。

保持清晰簡潔

您最不希望發生的情況是，您的開發人員在構建產品時對自己產生懷疑。 請盡量不要讓團隊成員有發揮創意和填補空白的空間。 在描述軟體需求時，請盡可能提供詳細資料，並避免：

• 使用模糊的詞彙，例如一般或大約

• 使用「/」來組合術語，這可能會被解讀為「和」或「或」

• 使用複雜的邊界值

• 使用雙重和三重否定

正式的同儕審查是確定 SRS 文件中模糊不清之處的好方法。 請計劃與每位參與者進行討論，比較他或她對需求的理解，並進行必要的變更。 

瞭解您的終端使用者

在軟體需求規範中新增欄位研究和使用者訪談，以便清楚瞭解終端使用者的要求、期望和需求。 這應該有助於您將最終使用者將使用軟體執行的操作可視化。 考慮可能發生的每一種可能情境和細微差別，並將其納入您的軟體需求規範中。 請記住，您的開發人員將確切地實施您在文件中包含的內容，不多也不少。 

納入彈性的邊界

您的 SRS 是一份動態文件，這意味著您將在每次迭代中新增功能和修改。 為此，請保持需求的彈性，以防結果不符合您的期望。 記錄對文件所做的變更也是一種最佳作法，可避免任何誤解。 參與者應能夠追蹤每項要求的原始內容，並瞭解是誰進行了變更、變更的時間和原因。 

使用軟體需求文件來闡明您的願景

撰寫 SRS 並不容易，但團隊成員之間無休止的故障排除或爭論也很困難。 您投入到全面的軟體需求規格文件中的工作將會得到回報，您和您的關係人都會為這款出色的產品感到自豪。