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

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

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

軟體需求規範文件可協助專案經理、產品經理和 Business 版分析師將高階概念分解為行動項目，以便每個團隊成員在開發過程中遵循。 

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

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

想像一下，您對應用程式有個很棒的想法。 您對其功能和外觀有自己的想法，但您知道您不能僅僅向開發人員提供口頭描述，並期望他們能夠滿足您的期望。 此時 SRS 就能發揮作用。

為什麼要使用 SRS？

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

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

由於軟體需求規範是動態文件，因此它們也成為產品開發流程中所有專案關係人之間的溝通點。 在任何軟體開發專案中，產品迭代都是不可避免的。 透過記錄 SRS 中的變更，所有各方都可以在文件中進行驗證，以防止對產品需求產生任何混淆。

如果您的團隊仍在定義軟體背後更廣泛的商業情境，請將您的 SRS 與Business 版需求文件範本配對，以便在記錄技術詳細資料之前定義目標、範疇和成功指標。

SRS 文件中應包含哪些內容

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

1. 簡介

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

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

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

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

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

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

• 目錄：完整的 SRS 文件可能會很長。 請包含一份目錄，以幫助所有參與者精準找到他們要找的內容。 

請確保您的介紹清晰簡潔。 請記住，您的介紹將成為您 SRS 概要其餘部分的指南，您希望使用該文件的每個人都能對其進行相同的解釋。

2. 系統需求和功能需求

有了介紹後，就可以更具體地說明了。 功能需求會分解系統特性和功能，使您的系統能夠按預期運行。 

填寫詳細資料時，請以概觀為參考，檢查您的需求是否滿足使用者的基本需求。 根據您的產品，有數千個功能需求需要納入其中。 其中一些最常見的包括：

• If/then 行為

• 資料處理邏輯

• 系統工作流程

• 交易處理

• 行政功能

• 監管和合規需求

• 績效要求

• 每個畫面的營運詳細資料

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

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

3. 外部介面要求

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

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

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

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

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

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

4. 非功能性需求 (NRF)

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

雖然系統在未滿足 NFR 的情況下仍然可以運作，但您可能會使使用者或專案關係人的期望面臨風險。 這些需求可確保功能需求得到滿足，因此它仍然包括產品可負擔性和易用性等屬性。 

最常見的 NFR 類型稱為「Itys」。 它們是：

• 安全性：確保軟體從使用者收集的任何敏感資訊受到保護所需的內容。 

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

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

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

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

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

• 可用性：產品的易用程度。 

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

軟體需求文件範本

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

撰寫 SRS 文件的最佳作法

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

使用可視化內容豐富您的 SRS

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

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

保持清晰簡潔

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

• 使用模稜兩可的詞語，例如「大致上」或「約莫」

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

• 使用複雜的界限值

• 使用雙重和三重否定

正式的同儕審查是找出 SRS 文件中模稜兩可之處的好方法。 請與每位參與者一起檢閱，比較他們對需求的理解，並進行必要的變更。 

瞭解您的終端使用者

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

納入彈性的空間

您的軟體需求規範是一份動態文件，這意味著您將在每次迭代中新增新功能和修改。 為此，請保持需求的彈性，以防結果不符合您的期望。 記錄文件的變更也是一種最佳作法，有助於避免任何誤解。 參與者應該能夠追蹤每個需求的原始版本，並查看誰進行了變更、何時進行變更以及變更的原因。 

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

撰寫 SRS 並不容易，但無休止的疑難排解或處理團隊成員之間的爭論也一樣。 您投入於全面性軟體需求規範文件的工作將為您和專案關係人帶來令人驚嘆的產品，讓您們引以為傲。