需求規格書撰寫指引

引用

基本概念

   1. 顧客至上 -- 所有的系統功能都是因為要滿足使用者或是開發者的需求。
   2. 客戶的需求 = 系統要提供的功能
   3. 唯有清楚的描述需求，我們才有設計的依據。
   4. 需求分為兩種，使用者需求與系統需求。前者是由客戶端提出來的，比較抽象; 後者是與開發端討論過的，是完整的 、 經過可性評估的 、可作為後續設計的依據 、使用者確認過的 、加上系統觀點的。
   5. SRS (System Requirement Specification）的內容主要以系統需求為主。
   6. 需求的描述多半用自然語言描述，但可以輔以模組語言，例如 UML 的 use case modeling, class diagram等。
   7. SRS 與 SDD 要分開，SRS 交代系統的 WHAT (系統提供什麼功能？) ，SDD 交代系統的 HOW (我們如何提供這些功能？）。

規格書內容



          o 1 Introduction (Section 1 of the SRS) 簡介
                + 1.1 Purpose (1.1 of the SRS) 系統要達成的目標
                + 1.2 Scope (1.2 of the SRS) 主系統與各項子系統
                + 1.3 Definitions, acronyms, and abbreviations (1.3 of the SRS) 定義文件中使用的技術性字詞
                      # E.g. IIR-001：內部介面需求 (Internal Interface 5.1.4 References (1.4 of the SRS) 參考文件
                + 1.4 References (1.4 of the SRS) 參考文件
                + 1.5 Overview (1.5 of the SRS) 簡述系統的功能與大綱
          o 2 Overall description (Section 2 of the SRS) 全部描述
                + 2.1 Product perspective (2.1 of the SRS) 產品概述
                      # a)系統界面
                      # b)用戶界面
                      # c)硬體界面
                      # d)軟體界面
                      # e)通信界面
                      # f)記憶
                      # g)行為
                      # h)場所適應需求
                + 2.2 Product functions (2.2 of the SRS) 產品功能
                      # 用文字或圖表的方法來表現不同的功能和他們的關係
                      # 系統所提供的功能描述必須淺顯易懂，讓第一次閱讀的人也能了解。
                + 2.3 User characteristics (2.3 of the IEEE-830) 客製化
                      # SRS的這個分部應該描述這種產品的用戶，有那些一般的特性，包括教育水準，經驗和技術專門技能。
                      # E.g.
                            * 人事管理員
                                  o (1) 維護與輸入各種單據
                                  o (2) 假單與出缺勤判讀作業
                                  o (3) 報表列印
                            * 一般使用者人
                                  o (1) 假單輸入與查詢
                                  o (2) 打卡資料輸入
                + 2.4 Constraints (2.4 of the IEEE-830) 限制
                      # a)規章的政策
                      # b)硬體限制(例如，顯著計時要求)
                      # c)聯接其他應用程式介面
                      # d)平行操作
                      # e)偵錯功能
                      # f)控制操作
                      # g)高優先權的要求
                      # h) Signal handshake protocols(例如 XON-XOFF、ACK-NACK)
                      # i)可靠性需求
                      # j)臨界的應用
                      # k)安全考量。
                + 2.5 Assumptions and dependencies (2.5 of the SRS) 假設與依賴性
                      # SRS的這個分部應該列舉影響在SRS裡說明的要求的每個元素。這些元素不設計在軟體上的限制條件，但是能影響他們在SRS裡的要求。
                      # 如假定系統需用到某一作業系統的資源，但某些作業系統不提供，則SRS的需求就必須改變。
                + 2.6 Apportioning of requirements (2.6 of the SRS) 需求分配
                      # 記錄少分部SRS需求功能可能在未來新的版本中可能被實現。
                      # 一次要做出所有的功能，會花費太多時間，目前許多公司都用此方法發展軟體。
          o 3 Specific requirements (Section 3 of the SRS) 特殊需求
                + 3.1 External interfaces 功能介面
                      # 系統輸入、輸出的詳細描述，如輸入的來源或輸出的地方、有效的範圍、容錯…。
                      # E.g
                            * EIR-002 由GDM須提供使用者界面讓使用者透過鍵盤、滑鼠直接操作本系統。
                + 3.2 Functions 功能性需求
                      # 負責處理輸入資料，和產生輸出。
                      # E.g.
                            * FNR-001 本系統提供員工基本資料與代碼的管理功能。[GDM 1.1.0]
                            * FNR-002 本系統提供對行事曆及班表的管理功能。[TAM 1.2.0]
                + 3.3 Performance requirements 效能需求 (非功能性需求)
                      # 記錄系統的效能
                      # 如 95% 的傳輸處理程序在１秒內完成。
                + 3.4 Logical database requirements 邏輯資料庫需求
                      # 邏輯資料的需求，如各功能使用的訊息的類型
                + 3.5 Design constraints 設計限制
                      # 設計的限制，如硬體的限制
                + 3.6 Software system attributes 軟體系統的屬性
                      # Reliability 可靠性
                      # Availability 可行性
                      # Security 安全性
                      # Maintainability 可維護性
                      # Portability 可移植性
                + 3.7 Organizing the specific requirements 組織的特別需求
                + 3.8 Additional comments 附註
          o 4 Supporting information
                + 4.1 Table of contents and index
                + 4.2 Appendixes 附件，一些範本

      

你可以參考 IEEE Std 的標準來寫計畫書。以下為此標準的 outline。

    * * 的部分表示大學部專題可以跳過不寫
    * # 表由本實驗室或資工系規範，學生可暫時跳過不寫。



    * 4. Considerations for producing a good SRS 考慮好的 SRS產出
          o 4.3 Characteristics of a good SRS 的特色
                + 4.3.1 Correct 正確性
                      # 每一項需求都必須準確地陳述其要開發的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統需求規格說明。若軟體需求與對應的系統需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評審將導致此類說法：“那些毫無意義，這些才很可能是他們所要想的。”其實這完全是評審者憑空猜測。
                + 4.3.2 Unambiguous 明確性
                      # 所有需求說明的讀者都只能有一個明確統一的解釋，由於自然語言極易導致二義性，所以儘量把每項需求用簡潔明瞭的用戶性的語言表達出來。避免二義性的有效方法包括對需求文檔的正規審查，編寫測試用例，開發原型以及設計特定的方案腳本。
                + 4.3.3 Complete 完整性
                      # 一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要資訊。
                + 4.3.4 Consistent 一致性
                      # 一致性是指與其他軟體需求或高層（系統，業務）需求不相矛盾。在開發前必須解決所有需求間的不一致部分。只有進行一番調查研究，才能知道某一項需求是否確實正確。
                + 4.3.5 Ranked for importance and/or stability 重要性和穩定性的排序
                      # 每項需求、特性或使用實例分配一個實施優先順序以指明它在特定產品中所占的分量。如果把所有的需求都看作同樣重要，那麼專案管理者在開發或節省預算或調度中就喪失控制
                + 4.3.6 Verifiable 可驗証性
                      # 查一下每項需求是否能通過設計測試用例或其他的驗證方法，如用演示、檢測等來確定產品是否確實按需求實現了。如果需求不可驗證，則確定其實施是否正確就成為主觀臆斷，而非客觀分析了。一份前後矛盾，不可行或有二義性的需求也是不可驗證的。
                + 4.3.7 Modifiable 可修正性
                      # 必要時或為維護每一需求變更歷史記錄時，應該修訂 S R S 。這就要求每項需求要獨立標出，並與別的需求區別開來，從而無二義性。每項需求只應在 S R S 中出現一次。這樣更改時易於保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟體需求規格說明更容易修改。
                + 4.3.8 Traceable 可追縱性
                      # 能在每項軟體需求與它的根源和設計元素、原始碼、測試用例之間建立起鏈結鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（ f i n e - g r a i n e d ）的方式編寫並單獨標明，而不是大段大段的?述。
          o 4.4 Joint preparation of the SRS 開發者與客戶間共同的準備工作
          o 4.5 SRS evolution SRS發展進度
          o 4.6 Prototyping 原型創建
          o 4.7 Embedding design in the SRS SRS的嵌入式設計
                + 4.7.1 Necessary design requirements 必要設計需求
          o 4.8 Embedding project requirements in the SRS 嵌入式專案需求的SRS

from http://140.134.26.20/~nien/CapStone/template/SRS_Guide.htm