軟體需求說明書

出自 MBA智库百科(https://wiki.mbalib.com/)

軟體需求說明書(SRS,Software Requirements Specification)

　　軟體需求說明書是需求分析階段的最後成果，是軟體開發中的重要文檔之一。軟體需求說明書是作為需求分析的一部分而制定的可交付文檔，該說明把在軟體計劃中確定的軟體範圍加以展開，制定出完整的信息描述、詳細的功能說明、恰當的檢驗標準以及其他與要求有關的數據。

　　軟體需求說明書所包括的內容和書寫參考格式如下：

　　一、概述

　　二、數據描述

　　口數據流圖

　　口數據字典

　　口系統介面說明

　　口內部介面

　　三、功能描述

　　口功能

　　口處理說明

　　口設計的限制

　　四、性能描述

　　口性能參數

　　口測試種類

　　口預期的軟體響應

　　口應考慮的特殊問題

　　五、參考文獻目錄

　　六、附錄

　　概述是從系統的角度描述軟體的目標和任務。

　　數據描述是對軟體系統所必須解決的問題做出的詳細說明。

　　功能描述中描述了為解決用戶問題所需要的每一項功能的過程細節。對每一項功能要給出功能的說明、處理的說明以及設計時要考慮到的限制。

　　在性能描述中說明系統應達到的性能和應該滿足的限制條件、檢測的方法和標準、預期的軟體響應和可能需要考慮的特殊問題。

　　參考文獻目錄中應包括與該軟體有關的全部參考文獻，其中包括前期的其他文檔、技術參考資料、產品目錄手冊以及標準等。

　　附錄部分包括一些補充資料，如列表數據、演算法的詳細說明、框圖、圖表和其他材料。

　　軟體需求規格說明是分析任務的最終產物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟體的各種需求。

　　軟體需求說明書主要有以下三個作用：

　　口作為用戶和軟體人員之間的共同文件，為雙方相互瞭解提供基礎。

　　口反映出用戶問題的結構，可以作為軟體人員進行設計和編碼的基礎。

　　口作為驗收的依據，即作為選取測試用例和進行形式驗證的依據。

　　軟體需求說明書是一份在軟體生命周期中至關重要的文件，它在開發早期就為尚未誕生的軟體系統建立了一個可見的邏輯模型，它是確保系統質量的有力措施，可以保證開發工作的／頃利進行。因而應及時地建立並保證它的質量。

　　作為設計基礎和驗收依據，需求說明書應該是精確而無二義性的。需求說明書越精確，以後出現錯誤、混淆、反覆的可能性越小。用戶能看懂需求說明書，並且發現和指出其中的錯誤是保證軟體系統質量的關鍵，因而需求說明書必須簡明易懂，儘量不包含電腦的概念和術語，以便用戶和軟體人員雙方都能接受它。

　　由於在一個企業組織中各部門的用戶可能提出相互衝突的要求，在分析階段必須協調和解決這些衝突，因而在需求說明書中的表達應該是一致的、無矛盾的用戶要求。

　　在軟體生命周期中，軟體錯誤發現得越早，糾正的代價就越小。所以需求說明書編寫完成後，應該組織用戶和一些專家反覆對其作檢驗和複查，爭取儘早發現錯誤並及時糾正，以免到系統後期改正錯誤時付出巨大代價。

　　某軟體的需求說明書

　　一.引言

　　軟硬體系統基本支持：系統的運行平臺是PC機。本系統擬採用××[[技術開發]]，一期開發實現單機模式，選擇CJHJ為開發語言。

　　二、主要目標

　　所開發的軟體要能實現以下要求。

　　1．日期和時間：實現多種日曆表，如農曆表。

　　2．日程事務提醒。辦公日程提醒：如會議、出差、上課、課間休息；生活瑣事提醒：如就餐時間、體育鍛煉。

　　3．提醒方案：實現多種提醒設定選項，比如每日、每周迴圈提醒。

　　4．提醒方式：以[[娛樂]]提醒方式為主(可以是音頻或視頻片斷)，比如學習工作中休息時刻到時就播放範曉萱的《健康歌》。

　　三、對現有系統的分析

　　現有系統是指當前實際使用的系統，這個系統可能是電腦系統，也可能是個[[機械繫統]]甚至是一個人工系統。對現有系統進行分析的目的是進一步闡明建議中的
開發新系統或修改現有系統必要性。

　　現有系統主要功能過於簡單，主要包括通訊錄、日程表、[[文檔管理]]、鬧鐘等，不能滿足對於各種提醒方案和各種提醒方式的要求。

　　四、所建議的系統

　　(一)鬧鐘，用於提醒各種事務，包括用餐、休息等

　　日期和時間：實現多種日曆表，如農曆表；根據已經成熟的日期換算演算法直接得到結果。

　　(二)日程事務提醒

　　根據用戶設定的某個時間的具體事務，當時間到達時，將用鬧鐘或是語音的方式提醒用戶。

　　提供日程安排提醒功能。使用了一個比較有效的事務處理模型，即緊急、重要事務處理模型。事務按照緊急性和重要性排在二維坐標上，那麼通知的時候會按照圖示
的模型提醒，保證用戶的工作最高效。

　　五、[[投資]]及[[效益分析]]

　　(一)[[支出]]

　　一次性支出：系統開發階段所需經費主要為書籍資料費，由開發團隊自行準備，總額不超過XX元。

　　非一次性支出：開發團隊日常生活費用自理。

　　(二)[[收益]]

　　本系統屬於非營利性的系統，不存在收益評估問題，但建議開發團隊確實能充分利用現有資源，適當減少[[投資]]。

　　六、[[可行性分析]]

　　1．法律方面的可行性。該軟體沒有侵犯任何的個人或是團體，也不違反任何的相關法律。

　　2．技術的可行性。在技術上不存在困難，完全可以達到。

　　3．時間的可行性。預定期限為四個月，可以完成。

　　4．用戶使用方面的可行性。本系統的主要用戶為辦公人員，對於基本的電腦使用和操作不會陌生。因此不會在系統的使用上遇到太大問題。同時系統將提供《操作手冊》
和《用戶手冊》指導用戶操作和使用，因此，系統在使用方面是完全可行的。

　　軟體需求說明書註意要點：

　　需求說明書要符合以下原則。

　　1．明確性：需求敘述的讀者應只能從其得到唯一的解釋說明，同樣，一個需求的多個讀者也應達成共識。每寫一個需求都應簡潔、簡單、直觀地採用用戶熟知的語言，每個需求必須精確描述要交付的功能。

　　2．可行性：在已知的能力、有限的系統及其環境中每個需求必須是可實現的。為了避免需求的不可行性，在需求分析階段應該有一個開發人員參與，在抽象階段應該有市場人員參與。

　　3．必要性：每個需求應載明什麼是客戶確實需要的，每個需求都有原始出處。

　　4．完整性：不應該遺漏要求和必需的信息。完整性也是一個需求應具備的。

　　5．一致性：一致性需求就是不要與其他系統發生衝突。需求中的不一致必須在開發開始前得到解決。只有經過調研才能確定哪些是正確的。修改需求時一定要謹慎，如果只審定修改的部分，沒有審定於修改相關的部分，就可能導致不一致性。